UX designers identify as problem solvers, because we’re always breaking big problems down into smaller, step-wise problems and solving them one question at a time.
A big part of solving problems is just understanding the problem really, really well. And that, my friends, is called UX research. As a discipline, it borrows from social sciences, information science, and a whole lot of gritty, guerrilla tactics.
Unlike true sciences, though, the goal is not to come up with statistically significant data, but to capture trends and insights that unearth the most helpful framing of the problem. What is really at stake for users? How are they thinking about this problem?
From the get-go, as a UX design student, this made a lot of sense to me. I’ve always liked to dig into the theoretical underpinnings of an idea and mine it for insight. But I expected to learn a specific process for approaching this. If I’ve learned anything at CMCI Studio, though, it’s this:
There is no UX research process. Or rather, there is no standard UX research process. Every project will have it’s own process based on its timeline, budget, team, and the particular challenge at hand.
A savvy UX designer knows this, and has a stash of techniques, tools, and methods ready to pull from. At every step, the designer identifies the highest priority question — the unknown that is the highest-level blocker to forward progress — and then pulls the best tool to answer that one question. Repeat.
OK, great! Now we know. But this is still so theoretical. What does it actually look like in practice? “It depends” was not a satisfying answer for someone, like me, who was trying to wrap my mind around the work.
So, with that in mind, I’ve come up with a framework to explain UX research to myself and anyone else out there who needs a bit more structure than “it depends.” My goal is to show that there’s not one “right way” and open up your problem-solving brain to customize research for your particular problem.
UX Research Framework
The goal of research is to understand the problem better, which also means understanding users and any stakeholders better. We’re “done” with research when we stop uncovering new insights or intuit that we understand the problem well enough to create a refined problem statement, or How Might We statement. I use quotation marks when I say “done” because good design should be validated by continued research and user testing throughout the entire design process, so we’re never quite done with research. Sorry. Unless you really like research, in which case, not sorry.
So, here’s the framework:
It involves 5 steps:
First, break down the initial problem.
Take the initial problem, as handed to you, and break it down into parts. I find that the Johari window, as adapted for design thinking, is really helpful for this. Basically, your known knowns are your facts, your known unknowns are your questions and hypotheses, your unknown knowns are your biases and intuitions, and your unknown unknowns are the wild cards you’ll hopefully uncover along the way.
The research process is really great for validating known unknowns and unknown knowns, so make a list of your questions, hypotheses, prejudices, and intuitions. This is what frames what you’ll do next.
Tools I’ve used: whiteboard, sticky notes, spreadsheet
Second, plan and carry out research.
Look at the list you made in step one, and choose research methods best suited for finding answers. (You’ll have constraints to work around of course — budget, time, access to users, etc.)
You might need to review data, or do a lot of reading, or talk to people, or observe processes and behavior, or immerse yourself in the user’s environment. It all depends on your questions and your problem. What gets you the answers you need?
On one recent project, I did a web analytics review, lean competitive analysis, stakeholder and user interviews, and a survey over the course of three weeks. In this instance, the client was a partner in facilitating interviews, funded the research phase, and allowed us to have that access.
On another recent project, I had one day for research, so I set up some phone interviews, read a lot of secondary research, and had access to notes from a stakeholder focus group.
Point is, every project will be different.
As you carry out your research, be sure to document everything, and keep an open mind — you’ll likely run across information, attitudes, or experiences you hadn’t thought of before. They might challenge your biases (unknown knowns) or alert you to completely new questions (unknown unknowns), so it’s worth staying curious.
Methods I’ve used:* Interviews (how/when/why to interview, plus 6 tips), card sorts, Treejack test (one-click), surveys (Google Forms is great for this), observation and contextual inquiry, web analytics, secondary research (including media and peer-reviewed scholarship), competitive analysis
*This is not a comprehensive list. Check out usability.gov for more UX research methods/tools.
Third, synthesize research findings and extrapolate insights.
If you did your research thoroughly, you now have a lot of data to sift through. Maybe a whole lot. You need to synthesize it and see what shape it takes.
My ride-or-die method for synthesizing research is to use a spreadsheet. It’s so simple to quickly sort and filter a whole lot of data, keep track of the source, add notes, and start to discover patterns and trends. I’ve used the ELITO method to track insights across research methods, as well, and this can become a helpful touchstone throughout the design phase, too. It’s helpful to force rank these insights, too, so you can start to prioritize facets of the problem.
Other outputs of this phase can include personas, mental models, etc. These are helpful ways to start wrapping your head around who you’re designing for as well as the dimensions of the problem you’re working on. The process of creating these artifacts also clarifies any questions that may remain.
Methods I’ve used: ELITO method, spreadsheets, personas, mental models, user journeys, affinity mapping, UX collage
Next, repeat steps 1–3 for remaining unknowns.
So, those questions that remain. Go back and do more research, then work the new data into your synthesis. Once you’ve answered all the pressing questions, all the questions that are standing in the way of moving toward a solution, then go on to the final step.
Finally, revise your problem statement.
This is where you get really clear about what you have to solve. It’s the thesis statement for the design work ahead. You might think, “oh, I have all those research/synthesis artifacts, so I’m good to go.” No. If you can’t explain in one sentence what you’re solving, you don’t really know what you’re working toward, or how you might test for or define success.
So, that’s the most direct way I can think to describe the UX research process, which can be a very elusive beast. Leave any additional thoughts, tips, methods, and tools below. I know I missed a ton.
