To get my confession out of the way up front - I’m not a user researcher. I’m a content designer who’s had the benefit of working with world-class user researchers.
I’ve learnt a lot from my time in user research labs and on field visits, and this post is about observing research sessions.
Every project, service, feature, product and thing needs user research. It’s not optional. You will not build a good thing without user research.
Like any tool, there are pitfalls if it’s not used the right way. Research findings can be incredibly powerful in helping a team make good decisions. But without careful thought and analysis, it can be used to jump to poor decisions.
To observe or not to observe, that is the question
After observing my first sessions, I asked myself (and anyone too polite to ignore me), “what’s more dangerous: someone who doesn’t attend any sessions, or someone that attends 1 or 2 sessions but misinterprets what they see and hear?”
What I came to realise is that the question is not whether people should attend research. It’s how they listen and observe during research, and whether they take part in group analysis after research.
Working together
At GDS, we say that user research is a team sport. This means that everyone in a team should spend some time watching users interact with their product. And everyone who takes part in research should help to analyse and interpret the results.
Working together like this leads to more thoughtful analysis, reduces bias, creates shared understanding and builds consensus.
Tips for observing research
It’s difficult to pick out the most important things to remember when watching users try your product, but here are some avoidable behaviours I’ve often spotted.
- Don’t overlook the Hawthorne effect. When being observed in testing labs, users don’t behave exactly as they would at home or at work. Even if you visit them, they still don’t behave as they would if they were alone. This can be due to many things, but most commonly it’s that we don’t want to look stupid when someone is watching us.
- Don’t rely on second or third hand accounts of what happened at a session or what a user said. We all add our own emphasis when retelling what we see. Attend the session, join in group analysis and listen to your researcher’s guidance.
- Go to sessions with an open mind. It’s all too easy to attend a single lab session with the intention of confirming an existing hunch or assumption.
- Don’t write down solutions. Write down what the problems are, and verbatim quotes. Your service and content designers will help you come up with solutions later.
- Preferences aren’t as important as getting people the right outcome through the service.
- Never underestimate the significance of the order in which you ask a user questions, or the way they are worded. You only have one chance to get a good response, don’t waste it.
- If you ask a user if they’d prefer a solution that hasn't been built, they’ll probably say yes out of politeness. It’s unfair to expect someone to know what you mean, and you won’t get a useful answer.
- It’s not your user’s fault if they struggle to use your product. Do the hard work to make it simple.
- If you have it, compare your test participant’s behaviour with data from your live or beta service.
- Lastly, enjoy it. We’re lucky to be able to witness this stuff and have the technology to study it.
Keep in touch. Sign up to email updates from this blog. Follow Keith on Twitter.
Feature image credit: walibiholland, Halloween, Attribution-NonCommercial-NoDerivs 2.0 Generic (CC BY-NC-ND 2.0)
1 comment
Comment by Kristen posted on
Thank you. This article is very useful. I've shared this my team and a few other folk as well.