USER RESEARCH
Is user research losing its user focus?
The user research being carried out by many research teams is becoming less and less about understanding things which are important to users.
If you were to hang out in user research forums and Slack groups, you would run in to a lot of questions like this.
“Does anyone know any research on (or any resources that would lead me to research on) the best placement of ads on streaming video content from a UX perspective?”
“Hi guys. Being a UX’er how would you research whether a specific new feature or product is a good idea to implement?”
“hi everyone! A start-up working in women’s health is looking for a UX research consultant located in Berlin ASAP to help them design a user research study on the impact of adding branded content to their website”
“Hey folks, is there a method for comparing the aesthetic appeal of two design approaches against one another?”
These are genuine questions. There’s nothing specifically wrong with most of them. They do however, reflect what I believe is becoming a new norm in user research that I don’t much like.
We are not putting users at the centre of user research.
Finding important problems
A user-centred approach to user research allows an organisation to understand what is important to its users. We discover their unmet needs, so we can improve their lives by meeting them.
In order to do so, at least some of the research we do should focus on what our users lives and environments are like, how they use our software and where they feel the most pain when using it. I type that out and it seems totally obvious. Not even worth writing.
So why doesn’t it seem to be happening enough? All too often, research projects have a ‘strategic (someone important asked a question) focus’ rather than a user focus. The research questions can be something like this
What do our users believe <thing they don’t give a shit about> is for?
What is the impact of <thing users neither want nor need>?
That seat at the table
If you spend any amount of time following people within the design community on Twitter then you’re likely to have seen discussions about designers getting a ‘seat at the table’. A negative symptom of this quest for that seat, is designers doing sucky things which have an negative impact on users.
That same influence is negatively affecting in-house user research teams. In order to show what we can do for the business, there is pressure to prioritise the things the rest of the business wants to know about users. The answers often have little real impact.
We start caring about the things the big bosses care about over the things that are important to users.
User research is the means not the end
User research is the foundation upon which user-centred design stands. If you’re not doing research then you’re not doing user-centred design.
Proponents of user-centred design (or human-centred, if you prefer) believe that the human experiencing the design belongs at the centre of the design process from beginning to end (OK, there’s no end, but let’s not go there).
User research is how you put them at the centre. As research has grown in relevance, this notion of user-centred design seems have become a bit lost. We don’t get the benefits of user research unless we apply it to user-centred design.
Instead, user research is sometimes simply referred to as ‘qual’. This is unhelpful. It’s a reference to a cluster of popular techniques rather than a mindset about how we design things the world actually needs.
Not everything we do can be user-centred
As we saw in some of the quotes at the beginning of this post, not every piece of design work can be born from trying to satisfy a user need. Instead there needs to be an overlap of user needs and an organisations goals. Sometimes we find ourselves making sure something doesn’t suck really badly, rather than trying to find out if it’s useful or usable. I get that.
But very often we can be attempting to answer a question when the answer is ‘our users don’t care about it’. We perform research for which only the boldest researcher would come back with ‘meh’ as the answer.
Deckchairs trumping icebergs
The user experience of any given software often has a dominant problem which is either deemed too difficult to fix or (worse still) the result of an important person’s pet idea. Let’s think of this problem as the iceberg to an approaching ship, something the ship’s crew should be most concerned about.
But the organisation doesn’t want to hear about the iceberg anymore. Shouting “Iceberg!” in user research findings can be bad for your career. Some researchers will understandably prefer to overlook or downplay it in their findings and suggest rearranging some deckchairs instead.
By overlooking the most important finding, the research loses its focus on what’s most important to the user.
Assuming relevance
The trap a lot of organisation-focused user research falls into is to assume an impact where it might not exist. This happens because one thing is assumed (without evidence) to follow on to another. Let’s take an earlier example…
“Hey folks, is there a method for comparing the aesthetic appeal of two design approaches against one another?”
Behind this request is an assumption that the users’ opinion on the matter has a behavioural impact. Instead of trying to answer the question of which design performs better, they have instead jumped to the assumption that the nicest looking design will perform better. Sometimes the opposite is true.
Behaviour over opinion
User research shouldn’t entirely ignore opinion, but it is overwhelmingly more concerned with behaviour. The same is true of emotion. If the opinion or emotion is impactful enough for us to be concerned by, then we identify it through the behaviour it affects.
When you jump straight to uncovering emotion and opinion, most of what you find won’t be actionable in terms of making impactful improvements.
It’s just noise.
What should we be doing instead?
Will Myddleton dissects the purposes of user research very well in his blogpost on the subject. These purposes can’t be totally separated from one another, but they present a very easy way to understand what user research is mostly for.
1. Test the things the team has built
2. Work out what the team should build next
3. Understand potential users and their lives
1. Test the things the team has built
The best you can hope to uncover when testing things the team has built, is to find potential usability improvements and also get an idea whether it matches the way users approach the problem it’s trying to solve. This can lead to refinements in that thing you built and can also inform what you should build next (see no.2).
When an organisation’s user research isn’t user-focused, they sometimes use this bit to decide whether the thing they have build will be a success. This is because they didn’t do research to decide what to build in the first place. User research can’t answer such a question at this stage. We seek to understand behaviour, but generally can’t predict it.
A by-product of this research is often finding out some useful things about your users that you hadn’t previously considered (see no.3).
2. Working out what to build next
How do you know what to build next? Is your roadmap full of ‘strategic bets’? If so you can find yourself trapped working on things which don’t affect anything. Your user research should be helping you understand what impactful things you could be doing to help users in the future.
You won’t build a very clear picture if you’re spending all your time answering very specific business-centred questions. Instead you’ll be blind to a load of stuff you didn’t know you’re unaware of.
When your software allows people to make progress in their lives, it creates new blockers for them. They often don’t really know what those are because they living their life not observing it. But you should be, otherwise the thing that eventually unblocks them, might rule your software obsolete.
3. Understand potential users and their lives
All of the decisions your organisation takes regarding its users are based on its current understanding of them. That understanding is often heavily biased and based on bad assumptions. This is especially dangerous when your employees are also users themselves.
User research can help you build a more realistic picture of users and therefore allow everyone to make better decisions. You can build a better general awareness with an immersive exposure programme. The research aimed at deciding what to build next (in no.2) can also help you understand users better.
Read some other stuff I wrote
I don’t spend all my time moaning, honest. Here are some more practical things I’ve written.
Design
- Designing around the choice of a single option
- Design guidelines for mobile date-pickers
- The blurry eye test
- Getting real about delightful design
User research
- Cognitive interviews for user research
- Moderating user research with Zoom
- Communicating UX issues with comics
- Understanding sampling bias
- Usability test tasks to avoid
Product management
📝 Read this story later in Journal.
🗞 Wake up every Sunday morning to the week’s most noteworthy Tech stories, opinions, and news waiting in your inbox: Get the noteworthy newsletter >
