Tips to make user research a team sport
A design project is simply a series of decisions. When you’re working with competent people, the limiting factor on how quickly you can finish a project is the speed of decision-making. (Decision-speed does vary with project complexity, but it might vary with organization size even more.)
The difference in individual perspectives will rear up to wreak havoc on your project plan whenever you need to make a decision. Arguments will break out. Not the good kind of arguments. The really annoying kind about priorities, requirements, constraints, or user needs. These are the arguments that indicate you lack a shared basis for decision-making.
Erika Hall
Reading Erika Hall’s post a few years ago really struck a chord with me. It was by far the best way someone told me why we should do user research and what happens without it. It also highlighted the importance of creating a shared understanding.
Having an observer was a luxury
Exactly what I was told when I started out in my graduate role. I was a team of one when it came to research sessions — asking the questions, taking notes, observing. This also extended to doing analysis by myself. The metaphorical unveiling only happened when a report was ready, subjecting everyone to pages and pages of it.
Practically, It was a tough juggling act to do it all and do it well. Ethically, it was open to my biases and assumptions.
Over the years, what I’ve learnt is that research is most effective when the team is actively involved in it, right from start to end. By moving through these research activities as a unit, you will help your team have a shared understanding of why you’re doing it, clarity in what you learn and the evidence to make better decisions.
9 tips to try
I’ve tried different ways to include the team in research activities right from the start. Some worked, some didn’t. Hopefully these tips can come in handy when you’re thinking making that shift with your team or already have and looking for ways to improve it.
1. Plan research together.
A good place to start is when you plan research. Hold a discussion with your team to understand what decisions they are trying to make.
It’s a chance for you to capture what they assume is true about their users and their needs.
Here are some common things team members wonder about:
- Product owner — Where should the product expand to? Who else could we be helping? Should we make this feature now or later? Why are people dropping off during the trial?
- Engineers and designers — How do I make this feature? How would users go through it? How do we handle cases where it doesn’t go right? How would someone discover this? Will this idea work? How will it scale?
It’s also a chance for the team to collectively see what’s on everyone’s mind. It creates a shared understanding and you’ll hear things like:
“I just realised something related to this.”
“Oh, we never thought of that. That’s a good point.”
“It looks like we all have similar questions.”
Now plan the research to answer those questions. This effectively creates an incentive for them to attend research sessions. It’s their chance to find out the answer or at least get closer to it.
2. Put up a schedule.
Now that they know what this round is about, tell your team about when those sessions . Ask your team to put their names down on at least three sessions they could attend.
Why? Going to just one session will either validate or invalidate what they thought the problem was. Going to many will help see if there’s a pattern emerging about the problem or if there’s more to it. The choice of solution will also change as your team learns more about the problem from many people.
Side note: To be clear, there is no magic number. Attending more research equals more clarity of the problem.
3. Give them roles.
Team members may often tempted be to do another thing during research, especially when it’s remote. It’s only natural to think that they can be efficient a do a few things at the same time. We as researchers know the benefit of active listening. It’s about fully focusing on what the participant is saying and doing. When your attention is divided, you’re likely to miss some of the details that matter.
I also think it’s a bit rude. It’s not that different from looking at your phone when sat in front of a person. It doesn’t show that you’re fully engaged.
One way to make sure your team is present is giving them roles to play in research. One could take notes, one could spot all the things they see, one could ensure that all the questions have been covered and so on. Make everyone responsible for the success of a research session.
4. Huddle before a session.
As a researcher, you are fully focussed on planning the research leading up to a session. It’s not the same for your product team. They may be fixing bugs, developing a feature, producing reports etc.
To get your team in the zone, get everyone together ten minutes ahead of a research session and use it to help your team switch context and get in the mindset of learning.
- Jog their memory by going through the objectives of the research and the interview guide,
- screener answers to gain some context (if it is relevant),
- and any previous research write up.
This transition exercise will give your team that extra bit of focus right from the start of the session.
It’s also good etiquette. This means you’ll start the session on time and not keep the participant waiting.
5. Observe. Not infer.
Many a time during analysis I’ve heard someone say “So my understanding of that the participant didn’t want X to happen because it would’ve led to Y.” Except only there was nothing that a participant said or did to support that statement.
So, why does this happen? Because we are human. It’s in our nature to make assumptions and be biased. Our brain makes associations as a way to help learn, fill gaps in order to make sense. For product teams, it means that it might lead us to make decisions that might backfire e.g. build a feature or parts of it that’s not useful.
The best way I’ve found to keep assumptions and biases from creeping in is to ask observers to write exactly what they hear or see, not what they think it means.
Even better, show your team examples of helpful and unhelpful notes. They’d be able to see what good looks like and adjust.
6. Encourage them to spot things participants do
During research, you’ll often find a discrepancy between what participants say and do. Just last week during a research session we observed someone clearly struggling to write some code (not their fault) and upon reflection said “yeah, that was fine.”
Ask your team to go beyond the things participants say and look at what they do. They’ll be able to catch these situations.
They’ll also find unexpressed needs. Things they know, as a part of the product team, is a problem and can be improved.
To get them started, think about what’s relevant to your team and make a ‘watch out for’ list. Here are some of my suggestions: clicks and mouse movements, how things are organised (folders, bookmarks, shortcuts etc), what they type, how things are named.
7. Make room for clarifications.
With many people observing, someone is bound to have a question about what they’re hearing or seeing. Make sure these get answered. Helping them gain clarity will in turn give them a better chance at solving the problem.
So plan for this. At natural points, ask your team if they have questions before moving on to the next topic. Alternatively, save time towards the end and open up the session for questions from the team. At the very least, have them pass on the questions to you so you can ask it when the time’s right.
8. Use a parking lot.
It’s only human to start thinking of how to solve a problem as and when you hear it. And your product team is made of problem solvers, so it’s natural to see them thinking of solutions right away.
There are few downsides to that. They may be solving just one person’s problem. They won’t know if it’s exactly the same problem for others or not. And more importantly, it’s taking their focus away from the research session and the problem.
So, use a parking lot instead.
- If an idea pops up during a session, ask your team to write it down and put it aside.
- To make sure these ideas don’t fade away, at the end of each session, ask your team to put their ideas up on a part of a wall or whiteboard. Remind them they are our best guesses and will need to revisited after analysis.
9. Analyse as a team.
This is where the sense making happens. It is important to collectively compare notes with each other and help interpret what it means. You also need the diverse expertise of engineers, designers and product owners to collectively decide what to do about the findings. You need your entire team here!
- Ask team members to take turns and re-tell the highlights from a session to the room. This playback can then open up discussions about what we saw and heard.
- When you’re affinity sorting, mix it up by getting others to analyse a cluster of post-it notes. This not only helps them see the value of analysis, but you also help them become better at it.
Bribe them with snacks. A sugary treat can go along way towards keeping the energy levels up.
Final thoughts
Making this shift with your team is going to take time. I’m not saying this to put you off it but to set your expectations better.
So be patient but persistent. Pick one thing, try it and build up from there. Retrospect regularly with your team so you can see how it’s going and adjust. I cannot emphasis how valuable it is.
The tips above are the things I’ve tried with teams so far. I’d love to hear your ideas, stories, and comments.
A special thank you to Jonathan Roberts for the valuable feedback to help me get this post past the finish line and Ian Johnson for these awesome sketches.
