Picture the scene: You’re a product manager, excited about a big new feature you’re about to launch. Your team has been working on it for over 2 months and it was requested by one of your biggest customers. You’re confident it will really move the needle for your product.
But, you’re no fool. You know how important it is not to build for just one customer, no matter how big they are. You want to find out if this feature will be useful for other customers too.
So, you work with your UX team to organise some usability testing of a prototype before launch. The testing goes exactly according to plan. The feature is a hit! Every user found it to be intuitive and easy to use and they all said they will definitely be using it when it’s released. Jackpot!
The feature gets released. You’re excited to hear all of the positive feedback. You can practically smell that promotion you’ve been gunning for. But, the feedback never comes. After about a week, you check the usage stats…
Nobody has used the feature! What’s going on? All of the users you tested with loved it. What happened?
You fell victim to the usability trap.
The Usability Trap
What do we mean when we say a product is usable? What’s the difference between something being usable vs useful? The Oxford dictionary provides the following two definitions of usable and useful:
Usable (adjective): able or fit to be used.
Useful (adjective): able to be used for a practical purpose.
With the above definitions in mind, we can see how a product/feature can be user-friendly (usable) without providing much practical value to users (useful). It’s also important to note that a product cannot provide practical value to users (be useful) without also being usable.
The usability trap is what happens when you mistake the usability of a feature for the usefulness of a feature. This often occurs during usability testing.
It’s a common trap that can happen at even the most user-centric companies. But why? Often, a number of things occur during usability testing that seem like positive signals for usefulness but are really false flags:
Users are aspirational. During usability testing, a user may tell you how useful this feature would be to them. How it would help them be more productive and effective. The problem here is that users often project the person they would like to be as opposed to the person they really are. True, this feature might help them to be more productive if they bother to use it. But that doesn’t mean they will. If I exercised every day I could have the 6-pack I want. But that doesn’t mean I will.
Usability testing is not real life. During usability testing, users have the time and space to focus just on using the feature you are testing. When given this time and space, the feature might feel incredibly useful to that user. They begin to imagine how it could help them perform X action more effectively. But usability testing is not real life. In reality, that user has countless other tasks and priorities they need to get through daily. They will not have the same time and space to get the value out of your feature. It’s important to keep this in mind when you start to hear ‘usefulness’ feedback.
Problems do not exist in isolation. Good features are designed to solve user problems. During usability testing you may get a sense that the feature you are testing is well-designed to solve its associated problem. One thing to keep in mind is that problems do not exist in isolation. While your feature might solve a problem well, if that problem is outside your user’s 5-10 most painful problems, it’s likely that they are not too bothered about solving it. Which means, it’s likely they won’t bother using your feature.
To be clear, this is not an attack on usability testing itself. Usability testing is an incredible tool for determining how easy to use your product is. There are so many products out that are clunky, confusing and the opposite of intuitive. We need more usability testing, not less. The problem is when we assume that a product is useful based on positive usability testing.
The usability trap can happen no matter what ‘type’ of product you are building, who your users are or how mature your product is. However, there is one ‘type’ of feature where the usability trap can tend to occur more often…
Delaying the job to be done
Great products help users to get a job done, as simply and effectively as possible. There are a certain ‘type’ of features that help users with their JTBD in the long-term but negatively impact their JTBD in the immediate moment. Features that fall into this category are typically personalisation, setup or customisation-based features. These features are particularly susceptible to the usability trap.
Imagine you are building a CRM to help sales teams to manage prospects. You might build a custom notifications feature. This would allow salespeople to configure notifications to trigger when there has been activity on certain key accounts. This would help them close more deals over the long term. However, salespeople are very busy. The time and effort it would take them to setup the feature would hurt their JTBD (close prospect deals) in the immediate moment. They wouldn’t be focusing their full attention on closing current deals.
It’s very important to keep this in mind during usability testing. If you did manage to get a busy salesperson to sit down with you for testing, the feature might seem incredibly useful to them. But when they go back to their busy day, it may not be useful enough for them to go to the bother of setting it up.
This is not to say that personalisation/customisation-style features should never be built. They should. But they need to be as quick and easy to setup as possible. Otherwise, they might never get used. And an unused feature can’t be useful.
Avoiding the Usability Trap
Unfortunately, there is no magic trick for avoiding the usability trap. All new features are in some way a guess at ‘usefulness’. You can’t truly know if a feature is useful until it is used by real users in your live product.
But that doesn’t mean you can’t increase the odds that you will avoid the usability trap. Here are some key pieces of advice that will help you to do just that:
Awareness is key. Merely being aware of the usability trap and the common false flags for usefulness can be a huge help in avoiding it.
Solve the right problems. A full book could be written on how to solve the right problems. One useful (obvious) tip is to aim to only solve your users 10 most painful problems. Identifying your users 10 most painful problems is just as much an art as it is a science. But one thing you can do is to just talk to your users. A lot. Doing lots and lots of generative user discovery will help you to build a clear picture of their most painful problems. Most PMs don’t talk to their users enough at all.
Use the Jobs to Done framework. JTBD is a powerful framework/mindset you can employ when talking to users. It helps you to understand and focus on your users’ core jobs and problems to solve. In other words, it helps you to solve the right problems.
Create an anti-roadmap. While anti-roadmaps won’t necessarily help you to avoid the usability trap by themselves; they are a very useful tool in helping you to avoid solving ‘pointless’ problems.
Avoid the feature factory mentality. When you deliver a feature, it’s critical to assess the impact of that feature. Was it actually useful? Too many teams are stuck in an endless cycle of feature delivery, not understanding if they are providing any real value to users.
Ask the right questions. During usability testing, it’s important to focus on task-based questions which test for usability. Don’t ask leading questions or “would you” questions. Remember, you are testing the usability of your feature, not its usefulness.
I really love this quote from Andy Rooney, particularly as it relates to the usability trap:
“Computers make it easier to do a lot of things, but most of the things they make it easier to do, don't need to be done.”
Remember, you can build the most usable product in the world, but that doesn’t mean your product is useful. If it isn’t useful, if it doesn’t truly help people do the things they need to do, then what’s the point in building it?