Studio culture & creative process / DIJION
The one question a prototype should answer
An experiment card separating the question, observation and decision boundary, with app and game examples.
Adding screens to a prototype is easy; explaining what it taught you can be harder. Replace a broad question such as Is the idea good? with a narrow question whose answer could change the next decision. The level of detail should serve that question rather than visual impressiveness.
Turn uncertainty into a sentence
For an illustrative list app, the question could be Can someone find an item they saved? In a fictional game, it might be Does the player understand that dragging determines direction? These test different uncertainties; neither should be presented as a verdict on the entire product.
Scroll the table horizontally to see all columns.
| Field | Information to write |
|---|---|
| Question | Which uncertainty are we reducing? |
| Decision | What could change after learning the answer? |
| Prototype boundary | What is realistic and what is simulated? |
| Task | What will the participant try to accomplish? |
| Observation | Which behavior will we watch? |
| Limit | What will this exercise not establish? |
Choose realism for the question
GOV.UK’s prototyping guidance describes approaches from paper sketches to interactive code. Discussing heading hierarchy may not require production infrastructure, while testing movement timing may exceed what linked drawings can represent. Choose the details that could affect the observation.
Do not give away the solution
Press the bookmark button on the right does not test discoverability. Explain the goal instead: You want to keep this article to read later. Record when help is provided; a task completed with assistance is not an independently completed task.
Do not turn an observation into a market claim
A few people completing a prototype task does not establish demand or long-term usage. Document conveniences such as prepared data, instant responses and limited failure paths. These limits explain which question the result answers rather than making the exercise worthless.
Finish with a decision
- Record observed behavior separately from interpretation.
- State how far it answers the original question.
- Explain why to retain, change or test again.
- Avoid changing many conditions together in the next prototype.
Do not assume prototype code is production-ready. Reliability and access controls skipped for rapid learning need attention before release. This card does not report research conducted by Dijion; it helps readers plan their own experiment.