I recently had a friend ask me about how you would fit user research into your product development process, when:
- you already have a product released to users
- and there’s no structured plan for doing user research, nor previous experience with in-house researchers
The first thing I did was invite her to the #researchOps workspace on Slack – it’s a fantastic resource, and there are loads of really experienced people who can give better answers than me.
I’m now writing this up, based on what I said to her, in case others are in a similar position.
In the post below I present a model for understanding the value of user research, which I find useful. I also share why I think that if you’re in a relatively small organisation, it’s worth starting by testing things you already have in production first.
Note: In this post I use the term user research interchangeably with the term design research, as used in the Australian DTO.
The main benefit of user research
It’s worth taking a second to talk about the value of user research. I explain the value of user research to budget holders like so:
User research reduces the risk of building the wrong thing.
Building digital products is expensive. This is because it typically takes the time of expensive people.
So, waiting a long time while expensive people build lots of stuff before you see whether any of it works, is not only is a really expensive, but it’s really risky.
So, it makes sense to spend a part of your total budget to find out, as early as possible, if things do work. This is so you can respond to this new information, while you still have some budget to act upon in it.
This can apply to an existing feature, or with your entire value proposition.
Got that?
If you’re working with people who are driven by numbers, then it’s useful to talk about user research as about reducing risk.
What this looks like — incorporating research into product development
Okay, so once people are onboard with reducing risk with user research, what do you do next?
Will Myddelton’s blog is a brilliant resource anyway, but I think his model describing three main kinds of user research you might do is really helpful here.
It’s the clearest, snappiest, most usable description of user research I’ve come across so far, and he presents the three kinds as:
- Testing things the team have built
- Working out what the team should build next
- Understanding potential users and their lives
I’ll cover these in detail below, then I’ll explain why, in the context I’ve described above, I think you should start with the first one if you’re not doing user research regularly.
Testing things the team have built
This is probably the most straightforward to incorporate into how you build things and gives you immediate insights you can act upon.
The goal is to uncover areas where users get stuck using what you already have. The outcomes are typically slightly revised designs, and updated copy to address the most obvious problem areas.
As Will suggests, doing this first also helps the rest of the team learn first hand why user research is valuable. You always learn something new, and it often shows that users use what you have built differently to how you would use it.
Here, you’re reducing the risk that your product is currently underperforming for reasons that are obvious in retrospect, and easy to fix quickly.
However, it’s really, really important to act upon what you learn, to realise the value of this research, and make it worth repeating.
You’d typically refer to this activity as usability testing, user testing or something similar. I’d suggest avoiding the phrase user testing if you can, as you’re not testing the user, you’re testing the product.
If there’s one book to read for this doing, I’d recommend Steve Krug’s Rocket Surgery Made Easy.
Working out what the team should build next
If there’s future work planned, there will also be risk in assumptions you will have made about how valuable, useful, or even feasible much of it is.
When you’re applying research techniques here, you’re using them to reduce the risk that your planned solution won’t solve the problem you’ve identified.
Here, the focus is identifying these assumptions you’re making, and carrying out activities to reduce the uncertainty in them.
Testing Prototypes
It’s not the only way to do this, but a common way to do this is building one or more prototypes first, and having a user researcher run moderated sessions with users themselves, or design unmoderated sessions for users to take, to review later.
You typically make a trade-off between simulation of value, versus time to actionable insight.
Low-fidelity prototypes are fast to get to users, so you get feedback quickly.
Higher fidelity prototypes are more complete, and slower to build, but let you test richer interactions, so offer a more faithful simulation of the value you will eventually provide.
Generally speaking, the riskier, and more substantial the new feature is, the more effort you can justify spending on prototyping to reduce the risk.
This isn’t the only approach through. You may be lucky enough to find that a competing product has a feature that’s similar enough to what you want to build, to justify using that instead of taking time to build a prototype yourself.
This is also valid, and will often help you understand issues associated with this kind of feature, as long as you are clear about which parts you’re trying to test.
People might refer to this as user testing a prototype, or validating an idea in the backlog,
Who are our users, and what are their problems?
The final kind of research is arguably the most impactful, and if you were starting a project anew you’d begin with this, to make it clear who your users were, and what needs you think you’re meeting.
Run at the beginning of a project, you might associate this with what people refer to as a Discovery Phase, and typically involves sets of in-depth interviews with people about their lives, and habits more than being directly about your product.
The findings and insights for this kind of research are things that underpin your entire value proposition, and this kind of research reduces the risk that you are basing your entire product strategy on a premise that is inaccurate or poorly understood.
Picking your battles
This kind of research also requires the most effort organisationally to respond to, and therefore from the perspective of a someone trying to champion user research, it’s the riskiest.
Typically, when I’ve been involved in research like this, or seen others do the same, even when you take great pains to share well supported, valid findings, these can be ignored if acting upon these findings means overcoming inertia in the organisation.
People in the organisation might already be invested making a specific product decision that is undermined by these findings, or pressure from outside the team may make changing course harder (i.e. investors might assume this is already settled, and be pushing for growth over changes to a business model, etc.)
Until you’ve build up some credibility by sharing some prior insights that have clearly helped make an existing product or service work better, telling managers that people are using a product for totally different reasons than they first thought, or that the value proposition needs rethinking will often be resisted, as it creates a load of new work, and on a human level can raise awkward questions that inside the management team, about why this risk is being discovered now, rather than earlier.
They might respond to your findings positively, and rethink their entire product focus, but they may also dismiss it, and you’ll end up wasting a load of social capital trying to bring about some change in an organisation not ready for it yet.
How to start — test that the thing you have works the way you’d expect
For this reason, if you have a product that people already use and pay for and you don’t have loads of influence, you’re probably better off answering the question of Is what we have working? first.
Starting out with this is fairly low risk — people working on products typically have heard of usability testing, and it will result in generating ideas for updating copy or similar, that the team can implement to based on where they saw users struggling.
This helps demonstrate the value of research and helps get buy-in from the team. From there, it’s easier to start moving to the other questions.
I’ll outline the specifics on Is what we have working?, in a future post, and a bit about operationalising it.
Learning more
BTW, I found Will Mydelton’s model via Leisa Reichelt’s tinyletter, This Deserves your Attention – you should absolutely subscribe if any of this post interested you.
If you’re also interested in making research part of how products are built where you work, I’d really, really suggest joining the researchops community slack. It’s great.