Not a vague goal. Not a drawer full of reports nobody reads.
Over the years I stopped treating research as a reactive troubleshooting exercise and started treating it as a structured operational system. Here's exactly how it works.
UX research often feels like staring into a chaotic void of user complaints, feature requests, and contradictory data. Without a clear compass, it is incredibly easy to get lost in the noise and end up with a report that sits completely ignored by the product team.
Whether I am testing a brand-new concept or optimizing an existing flow, I follow a specific framework to ensure every hour spent researching translates directly to screen-level design decisions. Here is a walkthrough of my exact process, from blank canvas to actionable insight.
The biggest mistake in research is talking to users before you know what you are trying to learn. Research without a targeted objective generates data, not direction.
Before recruiting a single participant, I sit down with stakeholders, product managers, developers, designers, and force clarity. Two primary questions get asked:
We list everything we think we know about the user's problem, every belief, bias, and hunch on the table before the research begins.
Are we deciding whether to build a feature at all? Trying to fix a drop-off in the checkout flow? The decision determines the method.
From here, we write a core Research Objective, not a vague goal like "Learn about our users," but something specific: "Understand why users abandon the onboarding flow after connecting their bank account." Every question asked moving forward must serve this objective.
Once the objective is locked in, I choose the tool. The method follows the question, not the other way around.
Unmoderated card sorts, tree tests, surveys. Validates assumptions at scale. Good for patterns across large groups.
Moderated user interviews, contextual inquiries. Digs into motivations, anxieties, and mental models. Can't be replaced by numbers.
Structured sessions with real users against a live or prototype interface. Reveals where people get stuck, confused, or drop off.
In a qualitative study, talking to 5–7 users typically uncovers 80% of core usability issues or behavioral patterns. More isn't always better.
"My primary job during interviews is to get out of the way. It is incredibly tempting to guide users toward the right answer. That instinct has to be actively suppressed."
On facilitationWhen conducting the research, the job is to listen, not solve. Here are the facilitation principles I follow without exception.
When a user stops talking, wait three seconds. People naturally fill the silence, and that's usually when the most valuable, unfiltered insights surface.
"Would you use this feature?" gets polite lies. "Tell me about the last time you tried to solve this problem" gets the raw truth. The difference matters enormously.
Mouse hesitations, sighs, workarounds, these are the data. The body often tells a more honest story than the words. Pay attention to both simultaneously.
You have hours of recordings, pages of notes, and a brain full of biases. Affinity mapping is how I impose structure on the chaos, every individual quote, observation, and pain point gets its own sticky note, then grouped by underlying motivation or friction, not by feature.
The distinction matters. Grouping by feature produces a feature list. Grouping by motivation produces understanding.
Participants 3, 5, and 6 each asked whether their data was secure at the point of entering personal information.
Users are hesitant to enter their social security number at the point of the onboarding flow where it is requested.
Users lack context on why sensitive information is needed, causing a spike in anxiety that halts the onboarding momentum, not a trust issue with the product, but an information gap at a critical moment.
An insight is actionable. It explains the why behind the what. Raw data and findings don't change screens. Insights do.
The final step is translating synthesis into tangible design direction. I never hand over a massive, text-heavy report. Findings are presented directly alongside proposed design interventions.
To bridge the gap between "what we learned" and "what we should build," I turn insights into How Might We (HMW) statements, then straight into screen decisions.
Users experience high anxiety when asked to input their social security number without context on why it's needed or how it's protected.
How might we provide immediate, reassuring context at the exact moment we ask for sensitive data?
Add a persistent trust badge and a plain-English tooltip beneath the input field explaining exactly what the data is used for and how it is encrypted, triggered at focus, not before.
By tying the final UI decision back to a specific sticky note from a specific user, design stops being about subjective opinions and becomes entirely about solving verified human problems.
The five phases aren't steps in a checklist, they're a discipline of moving from assumption to evidence to decision without losing the thread between them.
Every screen-level change that comes out of this process is traceable back to a specific person, a specific moment, a specific truth.