Intro
I worked at different companies, and I saw the same issue again and again: everyone makes designs for the Happy path, when the user goes from the start to the end without any issue and almost no one designs what happens if the user has an error or empty spaces whereas the user journey. To make the user experience complete and ‘healthy’, it should be included Errors and Empty states (Negative Cases) and every possible option around the user behavior.
What does it give to us?
- Maintaining and fixing costs are reduced by adding different states during the feature development
- In the end, users get high-quality products without any ‘surprises’ (e.g: when they cannot do anything with the product)
- The loading for the support team can also be reduced because the product covers all situations, including Error and Empty states.
0. What is the Happy path?
The Happy path is the way when the user goes from point A (start) to point B (conversion) without any issues. It’s how the user behavior has been planned: our business need is to get purchases done or to have renewed App subscriptions, etc.
The Happy path is required to exist because you have to rely on some flows or paths to build the product logic around it. Stakeholders are providing the business logic, Product Owner is working on prioritization of these ideas, and designers are working on the product design screens. Everything is okay. But during the preparation before development, sometimes people forget about other cases.
Example: what happens, if the user lost the Internet connection or what should be shown on the client-side, when the feature doesn’t respond, etc.
To cover such expected and unexpected cases, you should come up with ideas on how to display them and describe all possible negative cases
1. Why describe Error States?
The Error state is a situation when the user is struggling to do something through the use of a software product or the product behavior was unexpected as how it should be. In other words, any product behavior outside the all-defined Happy paths is a negative case. As a Product Owner, you don’t want to see the user which had an issue with the product interaction. Nevertheless, it’s significant to cover such cases to satisfy your users.
What could be worse, when the user closes your software product or cancels a subscription because something didn’t work, and the app didn’t respond properly or at all? Great question. Losing money because of not covering Negative Cases can cost a lot.
When should you start to work on that? After that, when you came up with Happy paths. And you should deeply focus on that part. If you did not make it before, you cannot imagine how many aspects should be claimed and resolved. To work on Negative Cases is mandatory if you want to write great requirements and make awesome products.
By the way, maybe you ask how to add Negative Cases in tickets: should they be placed as a part of the Happy path ticket or separately? It’s up to you and your developers. It can be combined: when the Error States do not require a lot of effort like adding warning alerts, then you can include it as a part of the main ticket. If you plan to build something bigger, decompose it as a separate ticket. The main idea is to communicate with developers. See the Best practice part of this article.
My advice:
- Work on Negative Cases after you defined Happy paths
- Having a list of Error states will reduce a lot of questions from the development team and help focus on more important aspects
- Cleverly implemented Negative Cases decrease customer escalation and the chance to save and increase incomes from your users.
2. Why describe Empty states?
Another issue that is forgotten regularly. What does the user see when there is no content after doing some actions? Which advice can the application give to help users leave the certain page or direct them to a more helpful page?
Without planning the clever Empty States can potentially cause a lot of problems for the product: lost revenue, increased Bounce Rate, and even the deleted application. You don’t need this, do you?
Also, about Empty State. Keep in mind that these states also can help users to make an action. Sometimes it’s not enough to show ‘No results, sorry, dude’, but to provide some advice: ‘Maybe you did mean that option?’ or ‘We didn’t find that, but maybe you’re interested in that product / service / page’.
The more traffic to the app you get, the more unexpected cases could be. Ignoring Error and Empty States is a big mistake.
Herman | pownery.com
Example: let’s imagine, you build an e-commerce app. Users input in the search field some request and your app didn’t return any product. For this Empty State, we can build the widget with product suggestions based on their device information (iPhone, Samsung, Xiaomi, etc.) which might be interesting for users: some wireless headsets or cases. Plus, it could be shown attractive sales propositions. It’s up to your business needs. But see, how cool it can be implemented instead of ‘No results’ text, right?
My advice:
- Don’t ignore Empty States. If needed, push designers to build it.
- Cleverly created Empty States can reduce the Bounce Rate and in some cases increase Average Purchase Value (APV). You might not lose your conversions.
- If you didn’t implement such states, create a separate scope of work to cover these cases. That will increase the product quality.
3. Make requirements completed
So, the importance of describing Error & Empty States has been explained. No doubt, it has to be included in your requirements. Without that, you cannot say you’ve completed your requirements for the particular feature.
Let’s imagine the regular situation when you came to your dev team to present the brand-new feature. You described each Happy Path: the user does this and your app responds to this. But you haven’t prepared any Negative cases. The dev team is starting to ask you, what if, what if, what if… It could be nervous, right? Especially if you don’t have the answer. You spend more time either explaining what should happen in a certain Negative case or marking down additional requirements directly in the meeting. The dev team spends time for clarification of fundamental stuff instead of asking advanced questions related to Business Objectives or plans of implementation.
I recommend you avoid such situations and make your requirements completed before presenting them to your dev team. It’s significant, trust me. It saves time and costs.
Note: as an experienced Product Owner, you can decide which cases cannot be covered right now because there is no sense if you know that a few people will see it one time per year or will never see this Negative case or there is no time and money to implement that. It’s up to your business need and current resources.
4. Common mistakes
Based on my experience, managers try to cover Happy paths, as I mentioned before. The most common mistake is not even to start thinking out of the box, namely out of Happy Path’s scope. You have to remember:
Once you described the Happy path, you have to start thinking about all possible cases around the certain feature.
Herman | pownery.com
That’s the first step to making your requirements better – just to start thinking about 🙂
The second mistake is you think about Error and Empty states after the design has been created. It’s a pretty common mistake. Once you noticed that (if you noticed), you write to your design departments and ask them to create that.
Imagine how much time you’re already lost through forgetting to create Negative cases:
the design team didn’t create these cases ->
you didn’t describe that ->
you presented requirements without Negative Cases ->
dev team asks you about design for unexpected cases (or maybe not) ->
requirements are added ->
you go to your design team ->
new design screens have been added ->
you describe it ->
you present to your dev team updated requirements again…
And only for one particular feature, you can see a lot of huge issues: requirements weren’t completed, time has been lost, resources have been burnt, and in the end, the feature cannot be delivered with high-quality standards.
My advice:
- Think about different cases in the product designing stage. It’ll save you a lot of resources.
- Don’t hesitate to ask for adding these cases even after you have verified design screens.
- Well-planned design cases allow dev teams to make the product more qualitative and prevent a bunch of unexpected situations.
5. Best practices / Bonus
When we’re talking about the presenting of requirements to dev teams, you have to agree with them on how it’s more convenient to decompose these requirements. It could be several options:
- Separate the Happy path and combine Error & Empty states
- Combine Happy path & Negative Cases and separate Empty states
- Separate every type of product behavior in a ticket
- Combine everything in one ticket
- Advice for postponed work: combine different Error and Empty states in a separate scope to cover the ‘logic debt’.
Also, it could be mixed differently, it has to be clear for each teammate who’s working on your product. As mentioned in the part Why to describe Error States, some of the tasks can be easy to do, that’s why you can include all possible cases around the certain product feature in one ticket. When it’s more complicated, it does make sense to separate it into smaller increments, just based on the faster delivery perspective. Again, it’s up to development teams and general logic.
A tiny bonus
Here is the most effective template to describe Error states & Empty states. I included the template from my article 10 principles of great requirements and combine it into one ticket. Then you can split it as you wish. Check it.
Business Objective
explain_here
Design screens
paste_design_screen
User Story
AS A [who]
I WANT [what]
SO THAT [why]
AND [why, if needed]
Scenarios
Scenario # – Action
GIVEN THAT: I’m [who]
WHEN: [action]
THEN: [action]
Scenario # – Action
GIVEN THAT: I’m [who]
WHEN: [action]
THEN: [action]
— HAPPY PATH —
Scenario # – Action
GIVEN THAT: I’m [who]
WHEN: [action]
THEN: [action]
Scenario # – Action
GIVEN THAT: I’m [who]
WHEN: [action]
THEN: [action]
— ERROR STATES —
Scenario # – Action
GIVEN THAT: I’m [who]
WHEN: [action]
THEN: [action]
Design screens: attached_screenshot
— EMPTY STATES —
Scenario # – Action
Precondition: something_happened_before
GIVEN THAT: I’m [who]
WHEN: [action]
THEN: [action]
Business Requirements
clarify_additional_business_logic
Technical Notes
tech_notes_by_developer
Additional links
link_to_prototype_or_design_or_any_useful_source
Do me a favor
If you liked this article, share it with your colleagues on LinkedIn, in social networks. Let me know if you have some questions in the comments or contact me on LinkedIn.
Good luck and God bless you.
