Prototype

Arguments about whether a feature will feel right can go on for weeks. Watching one person try a rough version settles it in an afternoon. A prototype turns an opinion into evidence while changes are still cheap. It is also how people who do not write code can show what they mean, instead of describing it.

1. Write down the single question the prototype must answer, such as "can a new user create their first project without help?"
2. Build only what that question needs. Skip everything else.
3. Put it in front of three to five real people and watch without explaining.
4. Note where they hesitate, misread or give up.
5. Decide whether to rebuild properly, change direction or drop the idea.

A prototype is a draft you can touch. It can be sketches linked together in a design tool so they click through, a spreadsheet that mimics a calculator, or a rough page generated with an AI coding tool. It does not need to be correct underneath. It needs to be good enough that someone can react to it.

Low-fidelity prototypes are rough and quick, and test whether the idea makes sense. High-fidelity ones look like the finished product, and test whether the details work.

• Polishing too early. Time spent on colours is time not spent learning.
• Asking "do you like it?" instead of watching what people do.
• Letting the prototype become the live product. Shortcuts that are fine for a test, such as hard-coded data and no security, cause trouble in production.