Flywheel

Test

Run the artefact against real users or operators, capture feedback in DASH, feed the next Design iteration.

What this phase is for

Test is where the work meets reality. The goal is to gather evidence about whether the artefact delivers the intended outcomes — and to feed that evidence into the next Design iteration quickly enough to act on it.

For both digital and engineering teams, the measurement instrument is DASH. The survey type changes with the artefact's maturity — a prototype survey runs immediately after a rapid-prototype session; a system survey runs after a deployed system has been used long enough to give real-world signal. When test results conclusively validate or invalidate a target, the team updates OKRs in DASH.

How Test relates to Design and Research

Test is the other half of the inner loop: each Design pass produces something testable, Test exercises it, and the findings drive the next Design adjustment. Those findings live in DASH — measurements, survey responses, and OKR updates — for Design teams to pick up and apply in the next iteration.

Research is re-engaged only when findings exceed the threshold for "the problem framing itself has shifted" — that's the outer-loop re-trigger.

What to do, in sequence

The phase, broken into stages. Read top-to-bottom; each card links to the prompt that does the work.

Stage 1

Plan

Decide what you're measuring and how. A plan that ties back to the success criteria from Research is the difference between learning and confirmation.

1. Generate the test plan

Single plan with scenarios, participants, measurement, and analysis — produced in one pass from the artefact being tested and the Research synthesis.

Stage 2

Measure

Gather feedback using DASH. The survey type changes with the artefact's maturity — a prototype survey runs immediately after a rapid-prototype session; a system survey runs after a deployed system has been used long enough to give real-world signal.

1. Run a prototype survey

Quick survey administered after users see a rapid prototype iteration. The fast measurement for the inner loop.

2. Run a system survey

Comprehensive feedback on a deployed system. Used when the artefact has been live long enough that real-world signal is available.

Stage 3

Act

Close the loop. When test results validate or invalidate a target, the team adjusts what gets measured in the next iteration.

1. Update OKRs

When test results validate or invalidate a target, update OKRs in DASH so the next iteration measures against the right thing.

Before you leave this phase

The exit gate. Confirm each item is true before moving on.

Test plan ties back to success criteria

Each test answers: did the thing we said would happen actually happen? The success criteria from the Research synthesis are the targets.

If a baseline exists, the test plan names it as the comparator

When the team captured DASH baseline data in Research against the existing or legacy system, the test plan should reference those numbers as the comparator — not absolute targets pulled from intuition.

Sample is representative

Five users from the wrong segment is worse than three from the right one. Confirm the participants match the persona or operator profile being tested.

Findings include at least one result that disconfirms a prior assumption

Record the assumption alongside the finding. If every result confirms what the team already believed, the test was scoped for confirmation, not learning.

Next-iteration adjustments are clear

The team knows what to change in the next Design pass — captured in DASH and in the design conversation that follows.

Common pitfalls

Recurring traps to watch for as you work through this phase.

Measuring what's easy, not what matters.

Click counts are easy. Whether the user accomplished their goal is harder, and the right thing to measure.

Picking the wrong survey type.

A system survey on a one-day prototype gives misleading numbers; a prototype survey on a deployed system misses the operational signal.

Testing too late to act on findings.

If the next Design iteration has already started by the time you have evidence, the evidence cannot change anything.

Treating DASH output as the end.

The measurements are the input to the next Design conversation, not a finishing line.