The preparation that leads up to doing a piece of user research is often as important as the research activity itself. Getting participants who are representative of your users, who aren’t accidentally prepped with expectations that might influence them, is key to getting maximum value out of a session.
There are a few issues that can arise in sessions if research preparations don’t have a clear focus, such as:
- Gathering insights about a non-representative group of people
- Learning about small issues rather than the big blockers
- Getting a skewed picture of the service experience because participants feel unable to be truthful
Whenever we’re about to start a new piece of research with a client there are a few tips we ask them to think about to minimise the risk of those things happening, and to help keep the work on track.
Involve your researchers in the recruiting process
Often, clients choose to do their own participant recruitment. This is usually because they want to make the best of existing user groups or communication channels before resorting to paying a recruitment firm.
Using these channels first can be a worthwhile exercise in cost-saving, but because recruiting from them is so immediate, it can be easy to get started without a clear brief of which kinds of people you should be speaking to.
Without that brief, you’ll almost always end up with participants with very similar backgrounds or experiences, reducing the type and variety of insight that can be discovered.
Before recruitment starts, we work with clients to create selection criteria for the kinds of people that will give us the insights we need to answer the research question. These criteria will often cover things like gender, age, type of relationship with the organisation and last time the person actively engaged with the service.
Recruiting with these criteria in mind helps to ensure that we speak to people with a variety of experience, as well as helping us to identify any gaps in our research.
Let your researchers introduce themselves and what they’re working on
It’s important that we have the opportunity to set the scene for a research session in a way that will help our participants to be honest about their experiences. One of things that can stop this from happening is when participants identify us as responsible for the current solution, becoming concerned that we might be offended by criticism.
Sometimes it helps to be a little bit vague about our relationship to the organisation. It’s important that participants understand why we’re there and what we’ll do in the context of the session. However, any more detail than that, and you risk participants making assumptions about our relationship to the project that could influence their answers.
If you’ve recruited participants or organised a session, it can be difficult to remember to refer to us as the researchers rather than the web team, or not to accidentally set an expectation over what will be discussed.
To stop this from happening we ask clients to let us introduce ourselves at the beginning of sessions, and to let us help them to write any copy being used for recruitment.
Keep schtum with your colleagues
Different research activities have different aims, and often it’s useful to be vague about the purpose of a research project.
Loose lips sink ships, and unless your colleagues have a full understanding of what you’re trying to achieve, they might let something slip to a participant that will frame their expectations of a session. Approaching sessions with open questions and minimal expectations about the topics that will be discussed helps us to reveal unexpected insights that might impact our findings.
This is a particularly high risk if working on an intranet or internal tool. Say we’re trying to learn more about some fundamental, structural problems in an organisation: perhaps new content needs to be signed off by 5 senior staff members, or half the content actually exists in a completely different system inaccessible to certain teams.
If participants have been inadvertently prepped to think we’re just researching the current technical solution that runs the intranet, they’ll be tempted to focus their feedback on minor UI gripes and content inaccuracies, and we might never get the opportunity to understand those bigger issues.
We ask clients, where possible, to keep discussions of the upcoming research as broad as possible. Sticking to phrases like “understanding user needs and experiences” is an accurate description, and has the added benefit of keeping the content of the sessions just a little bit vague.
Don’t be offended if your researchers ask you not to sit in on sessions
The ideal environment for a user research session is one in which the participant feels comfortable in freely expressing their genuine thoughts and feelings about the experience that’s being evaluated.
If the people running the service are in the room, then common standards of politeness often dictate that participants should moderate any criticisms: they don’t want to be rude or cause offence.
Alternatively, some participants will go in the other direction; using the facetime with the people responsible for the service as an opportunity to express their dissatisfaction. All of their experiences become heavily weighted into the negative category, even the parts which were satisfactory.
Of course, it’s important that our clients get engaged in and involved with research; no one ever got excited from reading a dry 10 page report. However, it isn’t always possible; where a client might be recognised by participants, or where we’re dealing with personal subject topics (such as health and finance) we often recommend against sitting in.
Expect that your researchers will recommend further research
It’s unlikely that we’ll form a clear picture of user needs in a couple of sessions. We will almost always come out of research sessions with some useful and actionable insights. But once we’ve done something with those insights – such as designing and build a prototype – we’ll need to measure how well that solution is working.
Research is an ongoing process, particularly when you’re not only seeking to understand the people who use your service, but to actively change their experience by designing and building new things. Plus, as your service evolves your users’ experience does too: users who started interacting with a service during its alpha phase will have a very different perception of the service from those who started using it post-beta.
It’s important to keep engaged with your users over the lifetime of a service, and understanding their experience and changing needs over time is a critical part of that engagement.
Your tips and experiences
What do you do to smooth the research process, and get the best value out of it? We’d love to hear your best advice.