Prototype the riskiest assumption first

Use a focused prototype to test one uncertain business assumption before paying to build an entire workflow.

Hands test a physical prototype beside a smartphone and planning notebook.

A prototype is valuable when it answers a question you cannot resolve confidently in conversation. It might test whether customers understand a request form or whether staff can make a scheduling decision from a proposed summary. Its value comes from the uncertainty it removes, rather than how closely it resembles a finished product.

Choose a question with consequences

List the assumptions behind the proposed software and identify which would most change the project if false. A hypothetical Melbourne specialist printer may assume customers can select materials without staff assistance. If that assumption fails, a self-service ordering portal could need a different purpose. Test material selection before polishing account pages. The GOV.UK alpha guidance similarly recommends using prototypes to examine risky assumptions, although your small-business experiment need not copy a government delivery process.

Match the prototype to the question

Paper sketches can expose confusing terminology. Clickable screens can test navigation. A small technical experiment can establish whether a required input can be processed in a useful way. These are different forms of evidence. A clickable interface cannot prove that a supplier connection works, and a technical demonstration cannot prove customers understand the interface. Agree which parts are simulated and make that limitation visible to everyone who reviews the result.

Observe behaviour without coaching

Give participants a realistic task using invented or anonymised information. Ask them to work through it while explaining what they expect, but avoid steering them towards the intended answer. In the printer example, watch how they choose a material and what they do when uncertain. Successful completion after a lengthy explanation is useful feedback about assistance needs, not proof that the design is self-explanatory. Record the confusing moments as carefully as the completed steps.

Decide what happens after the test

Before running sessions, agree what findings would support continuing, revising or abandoning the idea. A small experiment will not settle every question, and polished visuals can make uncertain ideas feel prematurely final. Prefer a narrow prototype that can change cheaply. The next scoping step is to write the test question, participants, task, observable evidence and decision owner on one page, then commission only the work needed to run that experiment.

Planning checklist

  • State one risky assumption.
  • Choose a prototype that can test it.
  • Record simulated behaviour and unresolved questions.

Further reading

Discuss your software project with 110s

Related Insight