Think beyond the happy path to make sure your user’s needs are addressed
How to make sure optimism doesn’t blind you from user needs
It can be tough to be the only negative person in an overly-optimistic team, but it’s sometimes necessary to adequately capture the user’s perspective.
Whether you’re working with exciting new technology like Augmented Reality or are working on a project which you know will have huge benefits, like addressing a long-standing issue everyone hates, you may find yourself on very optimistic teams.
This can be an energizing and rewarding experience, but at the same time, it can leave you vulnerable to blind spots. For example, the team may have an idealized view of the user’s workflow (known as the “happy path”), and you might have designed for that as well.
But it would be best if you considered alternative paths users can take. You need to ask yourself several tough questions, including “What’s the worst that could happen?”
Considering that much earlier in the process can save you time and effort. I found that out the hard way when a single spoken line caused my stomach to drop when user testing.
The problem with the happy path
The happy path is a great starting point for many designers. This is the ideal scenario, where the user has access to all relevant information, makes no mistakes, and quickly and easily navigates to complete tasks without any issues.
You can’t stop here, though. You must consider other scenarios that users might encounter and gather feedback about them. Otherwise, you might just be blindsided by scenarios you hadn’t considered.
I was fortunate to encounter that during user tests, specifically regarding accessibility. We had done a lot of work to make sure that our design patterns were accessible to blind users, so I hadn’t considered that there would be anything wrong with the design when I used several of those patterns.
However, when one person came to our user test with a screen reader, we were shocked when we heard the following sentence out loud:
“Your Social Security Number is XXX-XX-XXXX.”
The screenreader had read one of the read-only fields, which caused us all to pause. This application was meant to be accessible in public settings, which meant that if that occurred in real-life, other people could have heard extremely sensitive information.
We then realized we had a blind spot in our design, and we needed to consider other scenarios.
Why do you need to consider negative scenarios?
While it’s not great to constantly dwell on the negative, one of the most critical questions we can ask ourselves is, “What’s the worst that can happen?” Teams often focus on positive experiences because we want the users to use the product.
But we also need to consider the worst-case scenarios and make sure they aren’t damaging. Users remember the best and the last impressions the most. If their experience ends negatively, possibly even damaging them in some way, they will remember that and probably never use your product again.
In these cases, we need to make sure that you ask tough questions early. But it can be tough to take up that role by yourself.
After all, you don’t want to be the cynic or the negative person who is always dragging down meetings: that might be a great way to get yourself uninvited from the project. Both overoptimism and pessimism can inhibit creative solutions, so the best thing to do is to consider possible design solutions and have your users speak to the problems.
To do that, we need to design alternative paths and factors.
Factors to consider as alternative paths
New versus expert users
Should your site and workflow be the same for first-time and regular users? Or are you likely to have a subset of power users? If so, it may be helpful to design a couple of alternative screens.
These are screen designs that aren’t likely to take a lot of time but can yield many insights depending on their level of familiarity. For example, one typical design pattern that many websites use is an instructional overlay: nothing on the page necessarily changes, but tooltips appear to guide the user to specific functions on the website.
On the other hand, if some users might use this page dozens or hundreds of times a day, being able to dismiss some steps (or otherwise customize your actions) will save your users a whole lot of time. One of the most common uses of this is the ability to “Don’t show this message again.”
These are not substantial design changes to test, but gathering direct feedback about these, especially after reviewing your happy path, may yield information about how to support different user groups.
However, we also need to consider worst-case scenarios.
What’s the worst that could happen?
It would be best to consider worst-case scenarios as a possibility, which often involves thinking about many scenarios and asking tough questions.
Some of the most common scenarios that might occur include things around:
Accessibility (What is the experience like for users with disabilities?)
Errors (What happens if users make critical errors?)
Digital literacy (What happens if users don’t know how to use your website?)
Exclusion (What happens if users aren’t aware of specific selections or options?)
Attention (What if users aren’t drawn to what we want them to focus on?)
However, there could be dozens of different worst-case scenarios, and it’s impossible to account for every single one of them. So what should we do in that case?
The answer is to consider which things we can user test.
Consider which alternative designs you can user test
While it’s good to have these types of discussions with your team, the primary purpose of considering these things is to put these ideas in front of your users and get their feedback.
You should consider how much time you have in your user tests. Usually, after you get through testing your happy path (and other tasks), there might be anywhere between 5–15 minutes to talk with your participants, ask additional interview questions, or more.
This is often the best time to consider how your user has reacted to your happy path and test out alternative screens with which you will probably get good feedback.
For example, you might test your process and find that many people starting don’t have a clear idea of where to start. That is already a usability problem that you might bring up with the team, but you’d probably get good feedback if you showed an alternative design catered towards new users.
However, you don’t need to predict user behavior to determine which alternative designs to create for testing: you can also look at clues, like participant demographic information. For example, if you are testing with people who have lots of experience with a particular application, asking for feedback about customizing or skipping steps may provide helpful insights.
This is useful for two reasons: first, you’ve already identified the usability problem with your regular testing. If what you sketched doesn’t work for your users, there’s no loss. You’ve still identified a problem that needs to be addressed.
Second, gathering additional feedback about an alternative design lets you see if the solution you came up with works for users.
Addressing otherwise unspoken problems
It’s likely that whenever you user test, you probably tell your users one particular thing: to be honest (or even blunt) about giving feedback.
After all, you can’t fix usability problems that you’re unaware of. That’s why we often ask users to vocalize what they’re thinking and encountering to be aware of what’s going on.
This should also be brought to the table when it comes to thinking of alternative paths as well. When everyone else is optimistic about the happy path and everything that entails, it can be tough to focus on the negative.
However, it’s essential to understand other scenarios or things that users encounter. Therefore, we should always keep these alternative paths in mind and test them when we can. This can ensure we’re not surprised when users don’t always follow the happy path.
Kai Wong is a UX Specialist, Design Writer, and Data Visualization advocate. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.