Should you build for the unhappy path?

Why are Error scenarios more important than a happy path?

At the time of designing, developing, testing, releasing we all tend to check if a user can launch, login, navigate around, play, watch, submit and consume whatever features we have provided.

We end up giving extra focus on the happy path. Of course, it is important to set completion goals for the team and the stakeholders.

There are teams who design for a few unhappy paths too. But the main focus remains on Positive testing.

When we refine the feature, we create an intended workflow -that’s what is the focus. But, there are countless ways in which users can deviate from the workflow.

Do you cover all possible error scenarios? Should you?

Suppose you launched the product, covered 100% test coverage, all user stories were signed off by PO, the Unit test coverage was 100% too.

And you wake up to see complaint emails, negative reviews from users saying the product doesn’t work for them.

What went wrong here? How do you dig down in your test cases and justify or solve the issue/crash at hand?

For e.g. The user is using the product and -

1. Suddenly the wi-fi signal is weak or off and on

2. Backend API returns failure while call is being received

3. User closes the product in between

4. User switches between the apps/tabs

5. OS just got upgraded and the user is not able to launch the product

6. Real-time validation fails or doesn’t occur at all

7. Leap year data is looked for which you missed as the app was launched in non-leap year?

8. Update of the Product cleared all the data

9. Multiple things go wrong (create, update, delete, submit)

If you identify with one or more of the above, then you may have not considered various error scenarios during feature development.

How do you recover from the error? How do you tell users what to do next? Or you don’t?

As the app/website is used by the user, an error can happen from the System, network, backend or OS of the handset. Or a valid user for the client but the product, who tries to access the Product.

Do you just close the application or give users enough chances to recover gracefully?

I understand this could be once given 100 positive experiences. And the team doesn’t find the right reason why users would do something wrong. Well, don’t assume.

The one bad user experience makes customers uninstall the product or shift to other products or leaving the bad reviews. None of which add to the revenue!!

Do you have a general error message or the right error messages when things go wrong?

It’s better to have a general error screen as well than having none for sure! ;)

Providing a general error screen without right content on what really went wrong and what you should do next is a bad idea.

One should always opt for clarity in Error messages displayed on why the issue happened rather than telling the user it’s their fault or just a plain Sorry.

Make sure you perform Exploratory Testing as part of the Release.

It indeed takes creativity to put yourself in a user’s shoes. If you know your users well, you can design for them.