Prototype the assumption that could change the plan

A polished happy path can make an uncertain product feel settled. That is precisely the danger. If the important unknown is whether users will trust an automated recommendation, whether an integration can return useful data quickly enough, or whether an operator can handle exceptions, a smooth click-through proves very little. The first prototype should isolate the assumption that could force the team to change the plan.

Rank assumptions by consequence and evidence

Begin with assumptions, not screens. Ask what must be true for the product to work as a useful service and a viable operation. The answers usually fall into four groups: user behaviour, technical feasibility, operational delivery, and economics.

Write each assumption as a testable statement. “Users want simpler reporting” is too loose. “A finance manager will submit this report without asking an analyst to check it first” exposes a behaviour that can be observed. “The API will work” becomes “The API can return the fields needed for a decision within the acceptable waiting time and usage cost.”

Then score each assumption on two dimensions:

1. How much would the product change if this were false?
2. How strong is the evidence that it is true?

Start with assumptions that have high consequences and weak evidence. This is close to the UK Government’s current Test and Learn guidance, which prioritises critical assumptions with the greatest uncertainty and treats early tests as preparation for later evaluation, not as definitive proof.

This ranking prevents a common failure: choosing what is easy to demonstrate rather than what is important to learn.

Match the prototype to the uncertainty

Prototype fidelity is not a ladder that every idea must climb from sketch to production-like interface. It is a choice made for a particular question.

A paper flow can test whether people understand a decision. A clickable interface can expose navigation and comprehension problems. A concierge test, where a person performs work that may later be automated, can reveal whether the result has value. A narrow technical spike can test latency, data quality, or integration constraints without any finished interface. A service rehearsal can show whether support staff, approvals, and handoffs make the proposition economically workable.

The prototype needs only enough realism to produce the behaviour or measurement the team needs. The GOV.UK Service Manual’s alpha guidance explicitly advises teams to prototype the challenging parts rather than an entire journey and to build only enough to test the riskiest assumptions.

That principle also sets a useful limit. Do not add account settings, polished onboarding, or complete navigation unless they affect the question. Every extra feature consumes time and can distract participants from the uncertainty under examination.

Put real constraints into the test

A prototype can be visually realistic while remaining behaviourally artificial. Sample data is often unusually tidy. Tasks arrive in a convenient order. Responses are instant. Nobody is interrupted, uncertain, or accountable for a mistake.

If the assumption concerns real work, bring representative constraints into the prototype. Use realistic record lengths, missing fields, ambiguous cases, permissions, waiting periods, and handoffs. Remove or anonymise sensitive information; “realistic” never requires exposing personal or confidential data.

The same rule applies to economics. If a feature depends on paid model calls, manual review, or a third-party service, simulate or measure those costs. A prototype that conceals the expensive step can confirm interface usability while leaving the business model untouched.

At Alfcode’s product-design practice, clickable prototypes appear in week one, and the wider process describes prototypes using real data. The useful point is not speed by itself. Early realism lets the team steer while interaction, scope, and implementation choices are still inexpensive to revise. In Alfcode’s process, that prototype sits between scoping and engineering, where evidence can still alter what gets built.

Define the decision before the session

A prototype session should end in a product decision, not a collection of reactions. Before testing, record the assumption, the observable signal, and what each result will change.

For a permissions workflow, the signal might be whether participants can identify who must approve an exception and complete the handoff without prompting. If they cannot, the response may be to redesign the responsibility model rather than adjust button labels. For an AI-assisted task, the important signal may be whether users notice a weak answer, verify it, and recover. If they accept it without checking, the product may need constrained outputs or a different division of responsibility.

Use thresholds carefully. A small formative study can expose confusion and explain behaviour, but it cannot establish a population-wide conversion rate. Likewise, a technical spike can show that one integration works under tested conditions, not that it will remain reliable at production scale.

Decide in advance whether the evidence will cause the team to continue, modify the concept, run a stronger test, or stop. Precommitting reduces the temptation to reinterpret disappointing results as encouragement.

Test the break in the journey

Happy-path prototypes invite people to complete a task under ideal conditions. Risk-focused prototypes introduce the moment where the product’s promise could fail.

If trust is the uncertainty, show an imperfect recommendation and observe the response. If adoption is the uncertainty, ask participants to give up an existing workaround rather than merely comment on a new interface. If operations are the uncertainty, run an exception through every human handoff. If integration feasibility is the uncertainty, use representative payloads and failure responses. If price is the uncertainty, present the actual trade-off before measuring interest.

Avoid asking whether participants like the concept. Preference is easy to express and often weak evidence of future action. Give them a task, introduce the relevant constraint, and watch what they do. Follow-up questions should explain observed behaviour rather than ask participants to predict it.

For the next prototype, complete this sentence before drawing a screen: “If we learn that ___ is false, we will change ___.” If the second blank does not affect scope, economics, feasibility, or user behaviour, test a more consequential assumption first.