Prototyping to make a decision, not to get approval
By Allan Leone on
Most prototypes are built to survive a review meeting: perfect data, happy path, nothing that could go wrong while someone senior is watching. They always get approved and they teach nobody anything.
There are two kinds of prototype and they are frequently confused. One exists to get permission. The other exists to settle a question. They look similar and they are built completely differently.
The approval prototype has clean data, a single path, no empty states and no failure modes. It is a sales artefact. That is a legitimate thing to need, but it cannot come back with bad news, which means it cannot inform a decision.
Write the sentence first
Before building, write the single sentence the prototype is meant to settle. Then check that the sentence has a version you would hate to be true. If it does not, you are building a demo.
- "People will paste their existing spreadsheet in rather than start from our template."
- "Users will not trust an auto-generated summary unless they can see the source."
- "Onboarding survives someone who arrives with no data at all."
Each of those can fail, and each failure changes what gets built. That is the whole test.
Build the ugliest thing that can answer it
Fidelity should be set by the question, not by the audience. If the question is whether people will paste data in, you need a text box and a parser. You do not need the visual design, and adding it makes the result harder to read, because participants start commenting on the styling.
There is a real trap here now. Generation made polished output nearly free, which makes the beautiful demo more tempting than ever at exactly the moment it became less necessary.
Ten probes beat one showcase
The economics changed in favour of breadth. When each probe took three days you could afford one and you made it count. When each takes two hours you can test ten variations of the same question and find where the answer flips.
That is where the leverage from these tools actually is, and most teams are spending it on making a single artefact prettier instead.
Where to start
- For the next prototype, write the sentence it settles at the top of the file. If you cannot, do not build it yet.
- Deliberately strip the visual design from one research prototype and see whether the feedback gets more useful.
- Budget prototypes in questions, not in screens. Three questions this sprint, not one flow.
- Record the answer somewhere durable, including the ones that killed an idea. Those are the expensive ones to relearn.
Tags: process, prototyping, product