Most UX researchers are fluent in the research lifecycle: scope the problem, select a method, gather and analyze evidence, socialize findings with stakeholders. I use that process too — it's the execution layer of rigorous research. But over time I've found that the process alone doesn't capture how I think about the purpose of research.
Instead of starting with "What study should we run?", I start somewhere else.
That distinction matters. A perfectly executed study can still have limited value if it answers an inconsequential question, duplicates evidence we already have, arrives after the decision, or produces findings with no path to action. My operating principle is DECIDE — a decision-first approach that moves from decisions to evidence, evidence to understanding, understanding to action, and action to organizational learning. It shifts the center of gravity from conducting research to improving decisions through evidence.
The operating system
Stage 1 — De-risk the decision
Frame the decision before you frame the research
I start by mapping the key product and strategic decisions the team expects to make — not just the research requests already on the table. For each, I surface the assumptions, consequences, and uncertainties to find where being wrong would be costly and where research could meaningfully de-risk the path forward.
Importantly, the decision itself is a hypothesis. Research doesn't have to accept the frame it's given. Sometimes the highest-value contribution is discovering that we're solving the wrong problem, or asking the wrong question.
What this looks like in practice
A team plans a global launch. Rather than start with launch usability, I surface the assumption that the value proposition transfers across markets — that may deserve evidence before optimizing the experience.
Decision mapping can reveal that several teams are independently choosing around the same unmet need. Instead of three tactical studies, the pattern may warrant foundational research that sets a new direction.
A request to compare two onboarding concepts might reveal that neither addresses the real reason people fail to activate. The opportunity becomes understanding the activation problem — not choosing A versus B.
Stage 2 — Map what we already know
What evidence exists, where are the gaps, and what would materially reduce uncertainty?
Once I understand the decision landscape, I map the evidence landscape against it: what we know, how we know it, how much we trust it, and which important decisions still rest on unsupported assumptions.
The Evidence Compass
Overlaying the Decision Map × Evidence Map reveals where consequential decisions rest on weak, missing, stale, or contradictory evidence. Those intersections become candidate research opportunities.
What this looks like in practice
Interviews suggest customers struggle with setup. Instead of more interviews, I look for behavioral telemetry showing abandonment, support data showing recurring failures, and context explaining the mechanism. Triangulation combines evidence with different blind spots — not simply more sources.
A team asks for interviews on low adoption. Existing research may already explain the barriers while telemetry establishes their prevalence. The better move may be to act on what we know and instrument the change.
Survey data says users distrust an AI feature. The gap isn't whether trust is low — it's what people mean by trust, what conditions change it, and which forms of failure are unacceptable.
Stage 3 — Research the uncertainty that matters most
Decide whether research is needed at all — and how much the decision deserves
With the decision and evidence landscapes visible, I can make a deliberate judgment: is research needed — and if so, how much evidence does this decision deserve? I use RITE to make that call. The principle is proportionate rigor.
RITE — sizing the evidence bar
Only then do I choose methods. I construct evidence around the behavior and context the decision requires me to understand: the relevant people, their workarounds, workflows, incentives, constraints, handoffs, environments, and competing needs. Method follows the evidence need — not the other way around. Good research judgment isn't maximizing rigor; it's knowing where rigor matters most.
What this looks like in practice
Changing microcopy in a reversible flow may need a quick usability check. Changing a pricing model, permissions architecture, or global payment infrastructure carries a far higher cost of being wrong — and deserves a different standard.
To understand an enterprise buying journey, interviewing only the end user is insufficient. Procurement, IT, finance, legal, and executives each shape the outcome. The unit of analysis becomes the system of decisions and handoffs.
Evaluating automation, "Would you use this?" is weak evidence. I observe where people already delegate work, where they verify outcomes, when they override, and what happens when the system fails.
If the decision is reversible, the downside limited, evidence strong, and production behavior can answer the rest faster — I may recommend shipping an instrumented experiment instead.
Stage 4 — Build a point of view from the system
A point of view from the system, not a theme from the study
I don't treat synthesis as theme generation. I integrate new research back into the broader evidence map and product context to understand the system behind the findings — looking across methods, segments, workflows, lifecycle stages, incentives, dependencies, and contradictory evidence. Contradiction isn't something I smooth away. It can reveal a segment boundary, a contextual shift, a competing need, or an assumption that was wrong.
When two sources disagree, I don't pick a winner — I ask what each is measuring. I use a short protocol to name the tension before resolving it.
The CALM protocol — when data conflicts
What this looks like in practice
"Users struggle with permissions" is an observation. If admins build spreadsheets before configuring permissions, the insight may be that they're preserving an accountability model the product forces them to translate — a very different design response than simplifying the UI.
A survey shows high satisfaction while observation reveals workarounds. Rather than decide one is "right," I ask what each measures. Perhaps experienced users have normalized the friction — or the workaround itself creates the feeling of competence.
Several unrelated usability problems may share one cause: fragmented ownership across a multi-product journey. The recommendation then isn't five UX fixes — it may be a change to the product architecture or operating model.
Stage 5 — Move evidence into decisions
Evidence into decisions, decisions into action, action into change
A finding has limited value if it doesn't alter a decision, priority, product direction, or operating assumption. My responsibility extends beyond communicating what I learned to taking a defensible point of view about what should happen next. By involving partners in decision framing, aligning on the evidence standard, and exposing signals as they emerge, the final recommendation should crystallize the evidence — not surprise the people expected to act on it.
SCORE — structuring the recommendation
What this looks like in practice
Instead of ending with "users need more control," I recommend assisted automation over full automation, name which consequential actions require human review, and identify what to measure before expanding.
One solution maximizes simplicity while another preserves expert control. Rather than hide the tension, I make the trade-off part of the decision.
Sometimes the strongest recommendation is not to launch, not to invest, or not to decide yet — because the uncertainty is too consequential.
I may have enough evidence to change an onboarding sequence but not to predict a revenue effect. Being explicit about that boundary makes the recommendation stronger, not weaker.
Stage 6 — Research should compound
Close the loop, so one investment becomes evidence for the next
Every decision is also a hypothesis about what will happen next. Closing the loop tells us whether our understanding was right and turns one research investment into evidence for future decisions.
The Impact Chain
What this looks like in practice
Research changes the onboarding strategy → the team ships a guided experience → completion improves → activation moves. I can credibly describe research's contribution without claiming it alone "caused" the outcome.
A recommendation may ship and fail to produce the expected behavior. That's not the end of the story — it's new evidence that should update the original assumption.
A finding about when people trust automation shouldn't disappear into a study deck. If it generalizes, it can become a product principle informing future AI experiences.
The outcome of one DECIDE cycle feeds the next Evidence Map. What we learned yesterday changes what we need to research tomorrow.
Research as a decision discipline
DECIDE is how I think about research — as a decision discipline, not just a research process.
As AI increasingly accelerates parts of research execution — from planning and analysis to synthesis and communication — the researcher's value shifts further toward judgment: deciding what matters, what evidence deserves trust, where new evidence is worth creating, what it means in context, and what action it warrants.