Designing for the Unhappy Path

A version of this article was originally published on CMSWire on February 15, 2024.

In real life, user experiences aren’t always the “happy path.” The “happy path” is when users follow the default scenario with no issues or errors. For example on a form, the “happy path” is when a user fills in all the fields correctly and submits the form without issue. The “unhappy path” might occur when the user tries to submit the form and they include a “dash” in their phone number. The validation rules for that form field allow only numbers.

If they are lucky, there is an error message that is informative and the user only has to take the  “dash” out. It’s an easy fix. 

But, users rarely interpret and use software exactly how product teams expect them and the “unhappy path” happens quite often. Understanding how users interact with software helps teams recognize and prevent errors.

What are the Consequences of the “Unhappy Path”?

Consider another scenario where a user tries to upload a file but receives an error message that the file is not the right size. However, it doesn’t give the user any other information or troubleshooting tips to resolve the issue.

The user becomes frustrated trying to adjust the file so it can be submitted. It doesn’t work. What happens next? Does the user try the search feature, scroll through the Help section, look for a chat option or just leave. If the customer relationship isn’t strong or the task isn’t vital, the user likely just leaves. A lost customer and lost revenue over something that could have been prevented. According to Amazon Web Services, “88% of online shoppers say they wouldn’t return to a website after having a bad user experience.”  A lost customer and lost revenue over something that could have been prevented.

Designing for the “Happy Path” and “Unhappy Path” 

Proactively planning for what happens when things go wrong is just as important as planning for what goes right. That’s where user research comes in. Conducting user interviews and task-based usability testing can help to proactively identify not just problems but what solutions may be needed.

User Research can focus on:

• Identifying unexpected user flows – there may be other paths that users may navigate instead of the one expected. Teams need to plan a smooth user flow for that path as well. 

• Testing out error messaging – When an error happens, an informative error message that communicates what’s wrong, what needs to happen, and what’s next helps users get back on track. 

• Identifying support preferences – When a user unfortunately gets on the “unhappy path,” this can identify what support options are likely to use and any issues users may have with them including how difficult or easy it is to:

• Locate contact options

• Use the site search feature

• Use chat messaging

Designing for the “unhappy path” goes beyond designing for edge cases (those rare but potential behaviors or errors), it’s designing the user experience for resolving problems.

So, Why Aren’t Teams Conducting User Research?

Ideally, User Research has been conducted to understand users’ needs/wants and solutions are designed to address those needs/wants and business goals. Even then, users can still encounter issues that take them on an Unhappy Path because of :

Lack of testing

Some teams don’t conduct  user research because they feel they know their customers so well that they don’t need to do interviews or testing. That’s a mistake. Users are trying to solve their particular needs or wants and have different expectations, preferences, life experiences, mental models, etc. than that of the teams that build a particular software.

Deadline Constraints

A release date has been set , the team doesn’t feel it has time to do research, but there’s a cost of not doing research that will come back on the team, But, there is an additional expense of correcting issues after the system has gone live that teams need to consider. Users on the “unhappy path” complain and need more customer support to get tasks done.

Changing Priorities

There may have been a change in direction on the project and they spent more time on one feature over another and ran out of time to make all the changes they anticipated. Another item gets added to the backlog.

Benefits of Designing for the “Unhappy Path”

If users can complete transactions or tasks successfully, it’s a win for the company. When teams consider not designing for the “unhappy path” or not doing user research, they also need to consider the cost of  lost customers or the additional expense of correcting issues after the system has gone live and users on the “unhappy path” complain and need more customer support.

Even with the best of intentions, there may be an unexpected issue but planning for the “unhappy path” when the path goes wrong helps users get back on track.