Considering UX research
When designing and building software we have to keep in mind that we are designing for humans, for people that in most of the cases are unlike ourselves.
Product teams conduct UX research to get an understanding of the user and their objectives and problems. Research can generate and evaluate ideas and features, it can test and validate — research can do a lot. This article is meant to give an overview of the different phases of the research roadmap, what tools and methods one can use, and how to formulate the right questions.
Note that this is my personal evaluation based on experience and resources linked below. If you find something to be incorrect please email me and I make sure to change it asap! If you’re looking for more content about UX Research, this Notion board by Lade Tawak is a great point to start.
What is UX Research?
UX research is an investigation into the problems, needs, and experiences of users (people). A range of research types and methods exist, but the main goal is uncovering insights that can be passed along to UX designers and used to create more helpful/delightful user experiences.
Being a researcher means to stay curious and not getting attached to what it is we are designing. UX researchers establish a system and a process to nurture and harvest the curiosity of the whole team.
Good user research comes from empathy (the ability to understand, share — and design for — the feelings of another and leads to evidence (the available body of facts or information indicating whether a belief or proposition is true or valid).
Whatever kind of research you are doing, you establish a shared reality by (1) form questions, (2) gather data, and (3) analyze data.
1 — Form Questions
Questions determine your results. Bad questions will produce a harmful set of data, good questions are specific, actionable and practical and the best questions are about the unknown that carries the most risk.
Especially the words actionable, practical and unknown are important when developing a set of questions because in the end, it is your product team that has to work with whatever the outcome is.
It’s a healthy exercise to start nurturing the natural curiosity of your team to establish that shared reality and get a common understanding what the unknown parts of the user, the objectives, the business context, etc. are. There are tons of different workshop methods to do so, but the goal is to sit together and evaluate what you know and whatnot. This exercise will most likely lead to bad questions (not specific, actionable and full of biases) and that’s okay. It’s a first rough sketch of what we’re trying to explore.
In the next step it is all about refining your areas of interest. A quick way to validate whether or not you’re sitting on a decent stack of questions is by asking your team how sure they are that they already know the results your research topics will lead to. If everybody feels like they already know the outcome chances are high that something went wrong when translating your commonly agreed areas of interest into questions.
As an additional step cognitive pretesting ensures that you remove all biases and expectations from your questions to ensure a high-quality set of data.
2 — Gather Data
There’s a huge landscape of tools and methods to gather data and there’s no right way to conduct your questions. What tools you choose depends on a number of factors such as the product phase you are in, the decisions your research will inform, the time you have, your resources, money, etc.
In the following graphic I’ve compared common research tools and put them in relation to each other:
When collecting data it can be very useful to take parts of your team with you. It builds on the shared reality and the empathy towards the people you are designing for and—again—it helps to establish a sense of ownership over the outcome.
The single most important tip for your colleagues conducting their first research session: Know your question, warm them up, shut up and listen.
3 — Analyze Data
After executing the different steps of a research plan it is essential that the researcher quickly delivers learnings back to the team, giving them what they need to move on with their work. Nobody likes a long report, especially researchers.
It’s an elegant way to understand your learnings in the same way you started the research process — together with your team. Take some nice workshop exercises and synthesize on the learnings you collaboratively framed when starting out. This too will establish ownership over the concrete steps that result out of synthesizing on the data (vs. a bunch of deliverables researchers define and put in front of the product team).
- Here are the insights we’ve learned
- Agree upon set of insights
- Define what we’re gonna do about them
- Work out design/product decisions we need to make
- Understand if and how it affects our strategy
One last note
I think it is important to mention that no matter what you do, your research will be full of biases and assumptions. Even in clinical focus groups, there’s at least one disturbing factor: the human answering your questions.
“Much of consumer behavior involves everyday routines and practices that consumers do not actively think about. […] And when asked, they do not necessarily come to talk about — or do not even do not actively think about — these routines or patterns” — Interpretive Marketing Research: User Ethnography in Strategic Market Development, Johanna Moisander
Tobias Micko | mickykramer.com | @mickotobias | tobiasmicko@hey.com
- A Beginner’s Guide to Getting Started in UX Reserch — Lade Tawak
- Just Enough Research — Erika Hall
- New Layer—Jasmine Friedl, Tanner Christensen
- UX Researach—Nielsen Norman Group
- UX Research Landscape—Nielsen Norman Group
