A team may enter an innovation lab with a complete solution in mind: a new interface, an intelligent tool or a process change. Yet running an attractive prototype does not answer the essential question: which assumption are we testing, and what would make us change our minds? Without that question, an experiment can become a demonstration that confirms what the team wanted to hear.

A useful experiment supports a bounded decision with evidence rather than promising the success of an entire project. This article proposes an experiment card for innovation offices and challenge owners, connecting the problem, hypothesis, participants, measure and test boundaries. The card and examples are editorial recommendations, not an official template, universal success standard or reported RMG project results.

Turn the proposed solution into an observable assumption

Improving the beneficiary experience is a broad intention, not a testable hypothesis. Identify a particular situation and separate your explanation from available evidence. Repeated reports or staff observations may indicate a difficulty while its cause remains untested. Naming a technology is not a substitute for identifying the behavior that should change.

A practical structure connects a specific change with an observable response in a defined group and a reason that can be examined. GOV.UK comparative-testing documentation links a change, expected outcome and rationale and calls for a primary metric. [1] We use that principle without suggesting that every lab experiment must be an A/B test or treating UK guidance as a Saudi obligation.

Write the card before building the prototype

Give the card an owner and version. Record changes to the hypothesis or measurement method and their reasons. If the participant task changes during testing, do not combine earlier and later findings as though the procedure stayed the same. Documentation protects the meaning of learning; its purpose is not to maximize the field count.

A proposed experiment card connects six components from the research question to a decision.

Choose the evidence type before the sample size

If the question is whether users understand the next step, observing likely users attempting a task can expose sources of confusion. Estimating a change in completion rate instead requires a suitable quantitative design, analysis plan and specialist review. A small qualitative set of sessions is not a general success percentage or proof of a causal effect.

Identify relevant participants: first-time or repeat users, varied digital experience and applicable access needs. Colleagues who already know the process are not enough if they are not the target audience. GOV.UK’s research-round guidance connects questions and assumptions with participants and suitable methods. [2] No fixed participant count or mandatory duration is imported here; the research need and design determine those details.

Treat the example as a learning test, not a published outcome

In a hypothetical example, some users booking a branch visit reach the final steps before noticing a requirement. The team does not yet know whether the problem is placement, wording or understanding the requirement itself. It selects one assumption: showing requirements before booking begins may help a first-time user identify what is needed without facilitator intervention.

The team builds a prototype outside live operation using test information unrelated to real people. Suitable participants attempt a clear task. Observers record where participants look for requirements, whether they can explain them, when they request help and their stated reasons. The facilitator does not supply the answer or treat praise for the visual design as evidence of understanding.

If the difficulty remains, the experiment is not worthless merely because it failed to support the proposed solution. It may show that wording matters more than placement and lead to a new hypothesis. If understanding improves in the prototype, record the limits: these participants, setting and task do not represent every user or live operation. The example includes no performance figures or delivery dates.

State what the experiment will not do

Record exclusions: making an actual decision, altering an operational record, using sensitive data or making an unauthorized external connection. Identify who can stop a session if an access problem, harm or information disclosure arises. If personal data or live systems are needed, specialists must assess the relevant basis, permissions, data protection and sector requirements before execution. The card does not replace that review.

Four proposed evidence-reading prompts follow the test; inconclusive findings do not support the hypothesis.

Agree how to read the findings before seeing them

Decide beforehand how observations will be interpreted and what would justify repeating the test, modifying the solution or seeking a larger study. Distinguish missing evidence from evidence that an effect did not occur. Avoid changing the judgment criteria afterwards to protect a preferred solution. Conflicting or limited data, or a changed procedure, may warrant an inconclusive result rather than an artificial binary decision.

Retain a summary of what was tested, observed and reasonably inferred, including what cannot be concluded, and name the next-action owner. RMG describes innovation lab design, build and operation services, including customization, operation, training and support. [3] A service-scope discussion can begin with one experiment card and the environment, roles and evidence it needs. The lab then supports a better decision rather than validating every idea or promising that each becomes a successful project.