I‘m the Lead UX Designer at DNV GL Energy, a global company that provides expert advice and certification services to the renewable energy sector. As part of our offering, we deliver software products and services built by our in-house development team.
The renewables industry, with its technical focus and high stakes projects, isn’t commonly associated with UX work, but research and design have in fact become a core part of our software process.
Our users working in this industry expect their software tools to keep up with the latest in technology and best practice, and their work can deal with some pretty complex physics and engineering. That makes it vital our development team really understand what users need, and so one of the most valuable activities we do here is user research.
The researcher is a pivotal role for someone who knows how to engage with people, uncover their needs—even ones they may not realize themselves—and then translate that into feedback for the development team to act upon. Some of our most noticeable breakthroughs in the past year were a direct result of insights gathered through research activities.
Though more and more companies are realizing just how much value there is in this kind of work, it can be a difficult thing to do well—particularly if you and your company are new to the discipline. Real skill comes with practice, but I believe a great first step in learning to be a user researcher is knowing how to conduct yourself during an interview or testing situation so that you get the most out of it.
Keep the following 14 tips for conducting a user research session in mind, and you’ll be on your way to gaining some solid insight for your product.
1. Put people at ease
Research participants won’t give honest, candid feedback if they feel uncomfortable. Spending the first few minutes of the session chatting with them and getting them to relax can make all the difference.“Research participants won’t give honest, candid feedback if they feel uncomfortable.”
2. Set the scene
Begin the session by clearly explaining your goals—be direct. Don’t assume anyone there understands software jargon or knows anything about your project. Later on, it’ll help to refer back to the goals you mentioned here, so write them down.
3. Go with a plan, not a script
Before the session, write down what you want to learn and the questions you want to ask. Be prepared to go with the flow—surprises will come up. For example, in the renewables world it’s not uncommon to find users augmenting products with spreadsheet tools should the software not meet their needs. Learning to be flexible and how to change things on the fly will come with experience.
4. Treat users as experts
You’re there to listen and appreciate your users and their point of view. Treat UX research participants as experts and ask their advice—people will be more likely to give real feedback if you’ve made them feel important, or given them a chance to air their frustrations and suggestions.“Treat UX research participants as experts and ask their advice.”
5. Be impartial
It’s not easy for designers to remain impartial, but you have to when you’re testing out your product. I often state at the beginning that I’ve had limited involvement in the design and that users can be candid with me. People need to feel that it’s okay if they don’t like something, and no one will be offended if they speak their mind.
6. Invite criticism
Don’t defend your product. Be open to criticism—it’s going to help you in the long run. If something isn’t right, it’s far better to know early on when there’s still time to do something about it.“A user testing session isn’t the place to defend your product.”
7. Ask open, not loaded questions
Choose the wording of your questions carefully, and avoid pushing your preconceptions onto others. Instead, invite users to form their own answers. Simple, open questions are far more likely to enable the discovery of new things.
Instead of “Did you go to that screen to complete your project?”, ask “Why did you go to that screen?” And instead of “Do you like that new feature?”, ask “Can you tell me your thoughts on the feature you just tried?”
8. Probe with “why?” and “how?”
When something interesting happens and you want to know more, ask. This is where it’s good to have a testing plan that allows you be flexible should your user do something unexpected and interesting. A simple “Why did you do that?” or “Can you tell me more about that?” are often enough to uncover more detailed information.“You have to remain impartial when you’re testing your product.”
9. Keep the session on track
With limited time and important things to investigate, sometimes the conversation needs gentle nudges to stay on track. If you’ve set the scene well at the beginning, you can always refer back to the goals you stated to be clear about what’s relevant. Again, though, stay open to new things should your user want to express something important to them, and try to plan for extra time to allow for this.
10. Ask to be shown, not just told
It’s almost always preferable to actually watch people use your product. You’ll see things they didn’t think were important, or things they forgot to mention. You’ll also find things more memorable and easier to understand thanks to this context.
11. Look out for unspoken things
A good researcher spots unspoken feedback. What people say and do can often be very different—you can’t just rely on a participant’s words.“A good researcher spots unspoken feedback.”
12. Travel and document light
Try to be a fly on the wall and disrupt people’s environment as little as possible. Facilitating and note-taking at the same time are difficult, so find a way to take short, efficient notes, or ask a colleague for help. Get out from behind a laptop screen if possible and look people in the eye—you want to engage them and keep them at ease.
13. Write a summary of your findings as soon as possible
You’ll forget quickly, so write up a summary of your findings while the information is still fresh in your mind.
14. Write concise, shareable conclusions
Your research is in vain unless others can understand and act on your recommendations, so consider your audience—stakeholders, product managers, developers, etc.—and give them concise feedback in language they’re familiar with.
This post was originally published on Matt Corrall’s blog.