Help, They’re Not Using Our Feature!
Recently I was asked how I would approach the following hypothetical situation:
A product team has come to you stating that users are not utilizing a feature they’ve released. They’d like to add a button on the home screen to make the feature more obvious. How would you approach this as a UX Researcher?
What was unstated? The likely internal debate where some people probably support this idea, while others do not so somehow they’ve agreed to call on the research team to help them.
Anyone who’s worked in UX research will recognize this dynamic.
I stammered something on the spot. Then, on the drive home (always on the drive home!), I crafted a much more thoughtful and thorough response I’ll share here.
HOW TO WORK WITH STAKEHOLDERS
My first thought is that it’s great the team would turn to UX research to help resolve debates. It takes time and patience to earn “trusted advisor” status, but it’s a sign that the relationship is established and the value delivered by past research is paying off.
So, to get the conversation started with the stakeholders I’d thank them for coming to me and acknowledge why this approach can help them find a resolution.
Then, I’d gather more of the backstory. For example:
- Who are the stakeholders in this decision?
- Who are the advocates for one side or another?
- What is their reasoning?
- What information do they have that leads them to their position?
Next I’d clarify by asking, “What decision are we trying to make?” Are we deciding whether to add the button, or how and where to add the button?
Understanding the decision on the table is critical. In this case it is a major determinant between whether to conduct exploratory research or iterative design and usability research.
Regardless of my personal opinion, my job is to help the team come to a resolution that moves them along, often by facilitating outside input.
But to do that, I need to understand the debate, the options on the table, and the appetite for change. Eventually I’ll also need to understand any logistic constraints (like time and budget) but those can wait for now.
SHOULD WE ADD THE FEATURE OR NOT?
When the debate is about whether or not to add the button, there are two key points to understand:
- people not using a feature is not a user problem, it’s a tool problem, and
- it’s best to find out why people aren’t using the feature before proposing a solution in order to ensure a match between their reason and our solution.
So the next step is a root-cause analysis of why people aren’t using the feature. In general, there are four reasons why people don’t use a feature:
AWARENESS
- Users don’t know the feature exists,
- Users don’t know what benefit using the feature brings
- User don’t know how using the feature might help them
DESIRABILITY
- Users choose not to use the feature, because they don’t value the benefit.
DISCOVERABILITY
- Users know the feature exists, but can’t find it.
USABILITY
- Users know what the feature is and where to locate the feature, but it is unusable in some way (either too hard or too complicated or it doesn’t match their way of thinking).
These reasons (Awareness, Desirability, Discoverability, and Usability) form a ladder where it’s best to work on the first rungs first.
With limited resources, it doesn’t make sense to invest in improving the usability of a feature that people don’t know exists or don’t value.
HOW TO USE THE REASON LADDER
Looking back on the hypothetical situation with this reason ladder in mind, we can see that elevating the button onto the home page presumes the problem is one of discoverability. Until we confirm discoverability is the root cause, however, having the development team elevate the button to the home page may not be the best use of our time.
If, instead, the problem is awareness, or awareness of benefits, we may be better served by an on-boarding flow or other promotional campaigns that explain the feature and how it helps.
If the problem is usability, we have to improve what happens after the button is pressed, regardless of where the button is located.
If the problem is desirability, we may have to go back to the proverbial drawing board to understand the real user problem and how to deliver value.
‘SHOULD WE’ RESEARCH METHODS
Awareness and desirability can be confirmed via qualitative research even before the first line of code is written. It’s a terribly sad situation to get to the end of a development cycle and release something only to have it fall flat because no one wants what we’ve worked so hard to develop. Instead, we can use in-depth interviews to propose ideas, study interest, and gauge desirability
If the tool is already released and instrumented, and we have access to usage data, an interesting question to explore is whether people ever found and used the feature. If so, that past usage rules out discoverability as a problem and points instead to a problem of desirability or usability or perhaps awareness of value.
Desirability is directly related to solving a real user problem (not a tool problem, as above). Users have goals to accomplish, and using a tool is a means toward that goal and not a goal in itself (with perhaps a few exceptions like gaming). If you are unsure of what user problem you are solving, then some formative ethnography or field studies would be in order. Ideally there is a direct link between product features and user needs.
‘HOW SHOULD WE’ RESEARCH METHODS
If the question of whether we should do it has been settled, the focus can shift into how we should do it. This is very straightforward design and usability testing cycles, using the proposed designs, prototype, or the working system, to gather feedback on user preference and usability and then iterate on designs.
CONCLUSION
When asked to help the team understand why users aren’t using a feature, here are the key points to remember:
Work with stakeholders to understand the backstory and what has gone on before they called you in.
Keep in mind the difference between tool problems and user problems. Not using a feature is a tool problem.
Before proposing a solution, make sure you understand the root cause of the problem. Draw on usage data and your users to determine where it falls on the reasons ladder.
Solve problems in order of importance: Awareness, Desirability, Discoverability, and Usability.
Research awareness and desirability with ethnography and qualitative interviews; research discoverability and usability with iterative design and usability testing methods.
While the situation was posed as a hypothetical, it rings very true to life. How would you respond to the question if you were asked?