Research-to-Design Loop

Research-to-Design Loop: trace each design decision from the observation behind it to the evaluation that supports, contradicts or changes it.

Why research findings need explicit decision handoffs

The Research-to-Design Loop makes a design decision traceable from the observation that motivated it to the outcome that supports, contradicts or changes it.

Its output is a linked chain: evidence, interpretation, design hypothesis, intervention, evaluation and updated understanding. Each link keeps observation, interpretation and recommendation separate, and each records where its evidence came from.

The loop belongs to the same family as the UX Clarity Framework and shares TYPENORM's pattern registry with it. It introduces no new scoring system.

The six stages

Each stage produces one artifact and hands a defined piece of it to the next stage.

Observation

Produces a factual record with context and capture references. Passes forward what happened, where, and under what conditions. Choosing the method that produces the record is covered in UX research methods, the overview of research methodologies and how to run user interviews.

Interpretation

Produces a problem statement and a justified pattern match where one fits. Passes forward the proposed explanation, the task consequence and the uncertainty. Research synthesis helps turn raw notes into findings at this stage.

Design hypothesis

Produces a prediction about a specific intervention. Passes forward what should change, for whom, why, and how it will be checked. The reasoning step from finding to prediction is the subject of inductive vs deductive reasoning in research.

Intervention

Produces a prototype or product change. Passes forward the change to evaluate and the relevant version.

Evaluation

Produces results against the prediction and its guardrails. Passes forward supporting, contradictory or inconclusive evidence. A usability test answers qualitative questions, an A/B test answers quantitative ones, and a concept test is a quick check on a prototype. If you want our team to run the sessions, see moderated testing.

Updated understanding

Produces a revised case, recommendation or next research question. Passes forward what the team has learned and what starts the next loop.

Every intervention should point back to evidence and forward to an observable check.

How cases and patterns connect the stages

The loop uses the existing TYPENORM pattern registry, its categories and its codes. An approved pattern name and definition is distinct from evidence maturity or proof that a suggested remedy works.

  • A pattern helps connect a local observation to a reusable problem definition.
  • Its symptoms help assess fit; its suggested remedies inform possible interventions.
  • A match is an interpretation that needs evidence, not an observed fact.
  • Keep unmatched observations and findings; do not force them into the registry.
  • Reviewed cases can contribute to the registry's existing maturity process. No automatic promotion follows from using this framework.
  • Evidence that a problem recurs is distinct from evidence that a particular intervention works.

A worked hypothesis and evaluation

The illustration uses the registry pattern FBK-001 — Silent wait: the system is working on a request and shows nothing that says so.

If task import immediately acknowledges the action and communicates progress, users should better understand that import is running.

The evaluation checks whether users can identify the current state and what to do next. If repeat submissions are relevant and measured, check those too. Do not claim an improvement before collecting the result. For background on why response time shapes this kind of wait, see the Doherty Threshold.

This is a proposed experiment, not a completed study. No result has been collected.

Handling negative and inconclusive results

Inconclusive or negative results still contribute by changing the next decision. A result that contradicts the hypothesis updates the case, the recommendation or the next research question, in the same way a supporting result does.

Keep the reasoning and the review history with the case rather than only the conclusion. Checking a result against the prediction you made before collecting it, rather than one adjusted afterwards, guards against confirmation bias.

A reusable decision record and how to start

The decision record is the chain itself, kept as six linked fields: evidence, interpretation, design hypothesis, intervention, evaluation and updated understanding. Each field points to the one before it, so any decision can be traced back to its observation.

To run one loop:

  1. Select a bounded finding from Frictions Map or another research source.
  2. Resolve its provenance and separate fact, interpretation and recommendation.
  3. Identify a pattern match if supported.
  4. State the design hypothesis and intended user outcome.
  5. Choose an evaluation method and guardrails appropriate to the question.
  6. Implement or prototype the intervention.
  7. Record what the evaluation supports and what remains uncertain.
  8. Update the case and next action; preserve the reasoning and review history.

Put this framework to work

We teach and apply our frameworks with product teams — in a facilitated workshop or through ongoing consulting.