Design for the worst-case
How to find the unhappy path and design user experience around it
How to find the unhappy path and design user experience around it
Key Takeaways
Unexpected product behavior leads to negative impact and can be avoided with proper design.
Design for the unhappy path should consider the user journey and the application behavior.
For better delivery and excellent experience, Product Managers should drill down with engineers to design the worst-case scenarios as well.
The Happy Path
We tend to talk, build, design, and test the happy path. That is how we expect our customers to behave and our product to work. Unfortunately, customers will experience bugs or misuse of the product, as well as our product and system not functioning as they should.
We tend to be impatience when it comes to the unhappy path. While the happy path impact is clear (conversion), the consequences of the unhappy one can be more extensive.
Think of the last time you clicked on a button while nothing happened, a site failed to load, or an app refused to sign you in.
For that reason, I encourage design for the unhappy path.
The Unhappy Path
When thinking about the unhappy path, I divide it into two main courses –
The user journey
The application behavior
Let’s walk through an example of a checkout experience on an e-commerce site.
The user journey
An example user journey following the happy might look like this –
Reviewing shopping cart
Apply a coupon
Proceed to checkout
Enter credit card & billing details
Pay
Get payment approval
The questions I would ask myself for each step are –
What alternate paths does the user have?
What repetitive tasks can he do?
Let’s take the “coupon” step as an example. The happy path would assume the user adds a correct coupon code, apply it once, and move on to his following tasks. The unhappy course could include adding an incorrect coupon code, or use a correct code a couple of times, or refreshing the page and trying again.
The more we know how the user journey can go wrong, the better engineers will provide a smooth experience.
The application behavior
As Product Managers, we should always consider how applications could go wrong and how to recover from it. When thinking about an application, I imagine the happy path being the highway where you can quickly go straight and reach your goal. However, you could take sideways and alternate routes that complicate the journey.
Let’s take the “coupon” example from the previous section. Let’s assume our application architecture flow is the following –
The customer enters a coupon code
The application validates the coupon exists
The application applies the coupon to the shopping cart
Next, I would discuss with my engineers the following questions –
What are the possible failure points/dependencies?
What type of communication will we use?
In one case, the coupon system might be an independent service with synchronous communication. In another, it could be a 3rd-party provider with asynchronous communication (webhooks). Each has its drawbacks and failure points to consider.
From my experience, to deliver the best product experience, the Product Manager needs to drill down with his engineers to find alternate and problematic routes and decide how to handle them together.
Let’s demonstrate what the process of paying for an order might look like in a workflow approach versus an event-driven one.
In the workflow approach, we have one main flow that involves multiple services trying to achieve the goal of completing an order. It’s a synchronous flow where a tiny error fails the entire process.
Summary
Designing great products and excellent user experience may start with the happy path, but it can’t be done without finding the unhappy way. The negative impact of unintended user experience is more significant than all the shiny features and tweaks.
To achieve it, here are my tips –
Brainstorm how the user journey could go wrong
Find out what unexpected tasks the user might do (such as rage clicks, refresh)
Find the application failure points
Design the best routes to deal with unexpected tasks and failure points
And next time you click on a button with nothing happening or a site fails to load, be more patient and consider reporting the bug to help others find what is going wrong with their product.