The “happy path” is the expected or desired path a user will take through your app. It’s how you want the average user to interact with your app, ideally to achieve some goal that’s important to your product.
However, things that may feel obvious to you during product development may not feel obvious to others. Users don’t always do what we expect. Their deviations from the happy path may cause them to feel frustrated or even prompt them to abandon your app entirely.
Ultimately, your goal is to guide users to the end of the happy path: the destination in your app that helps you attain your goals. Perhaps your happy path ends with a successful purchase, winning a game, or engaging with others in an online community. Leaving the happy path puts these goals in jeopardy, so we want to minimize the possibility of people leaving the user journey before they reach the end.
What could possibly go wrong?
There are plenty of things to consider when identifying how users may stray from your happy path. Most causes of problems will fall into one of the following categories:
- User input: users may use emojis or special characters in text fields, or select hundreds of options when you expect them to select just a few.
- Unmet preconditions: users may find a way to skip an expected step and end up in an unexpected state.
- Ambiguous language: instructions that feel clear to you may not be clear to your users.
- External services: WiFi or Internet service may get interrupted, or third-party services may encounter problems.
The fallacy of “user error”
Many of the aforementioned problems are often dismissed as “user error,” implying that the user is at fault for not doing what we expect. I challenge that characterization for most problems, though: if it’s a “user error,” why did we put the user in a position to make an error? Instead of describing a problem as a user error, I prefer to ask myself what can be done to ensure the user stays on the happy path. What can we do to ensure users don’t experience these problems?
For example, a user might break the application by uploading a 200 megabyte image file for their profile photo. If the system has constraints that prevent it from handling such a large file, the user should be made aware of those limitations and directed to upload a smaller image. An even more ideal solution (at least, from the user’s perspective!) would be to accept the large file and resize it behind the scenes on the user’s behalf.
In another example, let’s imagine a user is using a social media app for the first time. They are prompted to select some topics to follow for their news feed. Without guidance in the UI, what’s to stop them from following 10,000 topics? Is that permissible behavior? Will the application work if they do that? If it’s not permissible behavior, what is permissible, and how can we make the limitations clear to the user?
Finding your way off the happy path
The easiest way to identify problems is to treat every interaction with your app as a potential point of failure. Try entering hundreds of characters into the text field for your name. Select no options when the app prompts you to select at least one. Try backing out of a screen during an important action and see what happens.
Software developers have tools available to them to test network connectivity issues. For example, they can simulate using your app or website on an extremely slow cellular network. You can also switch your phone into airplane mode to see how the app behaves without an Internet connection.
The simplest way, though, to find potential problems is to have someone new test your app. It’s easy to overlook potential problems with an app you’ve been working on for a while. Ask friends and family who are unfamiliar with your app to try it out and see what happens. Better yet, contract or recruit a beta testing group prior to public release of your app. The sooner you have people testing your app, the more enjoyable the user experience can be by the time you release it to the public.
Returning to the happy path
Once you’ve identified problems that need fixing, there are a number of tools at your disposal to guide users back to the happy path.
First, data entry on form fields should have input validation. If a user enters an invalid value in a text field or overlooks a required field, the app should present a clear message that tells them exactly what to do to complete the form.
“Empty” states in the application should be informative. If a list screen is empty, it should display a message to the user explaining why the list is empty and what they can do to add items to the list. Blank text fields should have appropriate placeholders or “hints” that show the user what their expected input looks like.
Network issues or service disruptions should cause the user to be notified that the app is unavailable, and explain why they are unable to complete their desired action. If there are steps they can take to resolve the problem, those steps should be presented to the user as well. For example, you might have your app suggest that they reconnect to WiFi or restart their phone if the app can not establish a network connection.
Finally, ensure that the instructions presented on the user’s screen make sense. If you only follow the instructions displayed in the app, can you make it all the way through the happy path? If not, consider tweaking the instructions or simplifying the user experience.
Once you do all of the above, most users should easily find their way back to the happy path with little effort. Users will be more satisfied with your application, and you will be on your way to attaining your product goals.