Prototype with real users or don’t call it testing

In local government, the price of an untested assumption is unusually visible: it’s a resident who can’t claim what they’re entitled to, a form abandoned at question three, a call centre queue that exists because the website failed. That price is why I’m evangelical about getting prototypes in front of real users early — and honest about what "testing" means, because most of it isn’t.

What a prototype is for

A prototype exists to answer a question, not to look finished. Before I build anything, I write the questions down:

• Can users find X without being told where it is?
• Does the label "waste collection" mean anything to someone who just wants to know "which bin"?
• Where do they hesitate, backtrack, or guess?

If a prototype can’t answer a real question, it’s decoration, and it will gather opinions instead of evidence.

The fidelity ladder

• Paper and pen, first, always. Screens drawn on cards, a human playing the computer. It feels ridiculous; it works. Users critique the idea honestly at this fidelity precisely because nobody’s protecting feelings about a sketch. A week of paper beats a month of opinions in a meeting room.
• Clickable wireframes — grey boxes, real words, real task flows. The words matter more than the boxes: I test content design at this stage because people navigate by labels, not by visual hierarchy.
• HTML prototype — the moment interaction details matter: focus order, keyboard flow, error recovery, how the form behaves on a cracked Android phone. This is where accessibility meets usability, and it’s always earlier than people expect.
• Pilot with real users — small numbers, real tasks, watched in silence.

What I deliberately leave broken

A prototype with polished visuals collects feedback about the visuals — spacing, colour, "I don’t like green" — while the task flow quietly escapes scrutiny. So I deliberately ship prototypes that look unfinished. Ugly is a feature: it keeps the conversation on the flow, the words, and the interaction, which is where the expensive mistakes live.

The rules I test by

• Real users, real tasks, small n. Five users find most of the serious problems. The council’s advantage is access to actual users of the actual service — use it. Recruiting people who match the real audience (not colleagues, not "someone from marketing") is the whole game.
• Silence is data. The pause before they tap. The re-read. The return to the home screen "just to check". I note hesitations as carefully as errors — often they’re the same finding, one frame earlier.
• Watch what they do, not what they say. Post-session opinions are unreliable theatre. The recording of the attempt is the data.
• Test the failure paths. Everyone tests the happy path. The judgement of a service is what happens when something goes wrong — the wrong postcode, the ineligible case, the session that drops. Prototype those states or you’ve tested nothing.
• Close the loop. Findings get triaged and attached to the prototype’s next version, and the version after that gets a short re-test. A usability test whose findings die in a document is a ritual, not research.

Why this holds for solo products too

The indie products get the same discipline at smaller scale — Horrorometer’s rating axes, SENDadvisor’s search-first homepage, Stay With Me: Deep Sea’s first-hour pacing, all prototyped and watched before being built properly. The difference between solo work and council work is the budget, not the principle: five real users, an honest question, and the humility to change the plan is a portable method. It fits in a founder’s week, and it’s still the cheapest insurance in the industry.