Essay

Prototype to decide

A prototype isn't a deliverable. It's a question you can hold in your hand. The right one is whatever gets a real answer from a real person, fastest.

Teams argue about designs for weeks that a prototype would settle in an afternoon. The argument is usually about something nobody can know yet: will people understand this, will it be fast enough, will it fit how they actually work? Opinions don't answer those questions. Watching someone use the thing does.

Match the fidelity to the question

Every prototype should start with the question it's meant to answer. The question decides the material.

• "Do people understand the structure?" Paper. Sketches and index cards, rearranged on a table while someone talks through what they expect.
• "Does this flow make sense?" Clickable screens in Figma. Enough to move through a task, nothing more.
• "Does it feel right at speed?" Working code. Timing, keyboard shortcuts, live data and real interruptions only show up when it actually runs.

Over-building is as wasteful as under-building. A polished prototype invites comments about color when you needed to learn whether the workflow works.

Twenty years of the same lesson

At Granicus, redesigning a touchscreen voting system for elected officials, we started with paper prototypes on a table, then built interactive prototypes to test with people who were openly skeptical of technology. Each round removed something they didn't need.

At [24]7.ai, I made prototyping a formal design competency and hired for it. Prototypes became how we tested ideas with users, how we showed engineers what we meant, and how sales showed clients what was possible.

Last year, for a public meeting platform, I prototyped a keyboard-first clerk console directly in working code, with AI writing much of it. The engineers didn't get a spec. They got a running app they could use, question and build from.

What AI changes

A working prototype used to take weeks. Now it can take days, sometimes hours. That moves the line: questions that once only got answered after launch can be answered before anything is committed.

It also raises a risk. When building is cheap, it's tempting to build everything and decide nothing. The discipline is the same as it always was: write down the question, build the least you need to answer it, put it in front of someone, and decide.