The art of decision making in prototyping
As designers, we don’t create for the sake of creation; we provide provocations to solve problems identified by user research
“Just keep it quick and low-fidelity.” We’ve all heard it. It’s intended as a kind gesture, a way to ease the pressure on design colleagues. But as an Interaction Designer, especially within the rigour of the public sector, we need to have an honest conversation with our teammates.
Low fidelity is not a synonym for “quick.” In fact, choosing the wrong level of polish can slow us down.
Prototyping can sometimes be treated as a checkbox in the design process, but it’s actually a sophisticated tool for thinking. To use it well, it is worth clearing up a few common misunderstandings about what a prototype is, and what it isn’t.
Inspired by the Grammy winner Olivia Dean’s album The Art of Loving, I’m calling this blog post The Art of Decision Making in Prototyping. Thanks, Olivia.
The true goals of prototyping
Before we discuss how to prototype, we should understand why we do it. In the context of a fast-moving service team, I see prototyping as 3 specific activities:
- Validating hypotheses: providing testable materials that can be created with manageable effort. These allow user researchers to observe how people interact with our ideas and validate our assumptions.
- A communication tool: visualising design ideas for teammates and stakeholders. It is often the only way to demonstrate to developers exactly what we want to achieve.
- Surfacing constraints: finding technical, legal, or accessibility “dead ends” early. It’s about discovering what cannot be done before we commit to building the real thing.
Seven principles for better prototyping decisions
Principle 1: You can prototype anything (even without a UI)
Some designers feel uncomfortable in the early stages of a project because the “service” hasn’t yet taken the shape of screens or layouts. However, if our goal is validating hypotheses, we can prototype the experience of the service itself.
If you want to test a customer support journey, you don’t need a website – you need a fake hotline and a willing teammate to act as the operator. A physical space, a flow of information, or even a deliberate “five-minute wait” can be prototyped. If it generates evidence, it’s a prototype.
Principle 2: Prototyping must be research-led
Without a specific problem to solve, a prototype is little more than an artist’s personal expression on a canvas. As designers, we don’t create for the sake of creation; we provide provocations to solve problems identified by user research.
Sometimes stakeholders argue they “already know” what the user needs. But problems often lie far beyond the interface. UX design alone cannot magically help you sell a box of chocolates for £1,000. No amount of iteration on a button’s colour will fix an overpriced product or a flawed policy. User research identifies these “policy-level” issues, ensuring we aren’t just rearranging deckchairs on a sinking ship.
Principle 3: Fidelity is a research variable, not a tool choice
We often assume pen and paper is “low-fi” and code is “hi-fi.” In reality, fidelity is about how realistic the experience feels to the user.
For example, if you want to test if your content is clear but you use Lorem Ipsum in a fully functional HTML prototype, that is a low-fidelity experience. The tool is high-tech, but the material fails to answer the research question. Conversely, if you are testing a navigation system, a few well-labelled index cards for a card-sorting exercise are “higher fidelity” than a beautiful Figma file with broken links.
Principle 4: Speed is about mastery, not “polish”
The demand for a quick turnaround doesn’t automatically mean you should grab a sharpie. In the public sector, using a Prototype Kit is often faster than drawing boxes in a wireframing tool because the components already exist.
And new technologies are shifting our definition of “speed.” I’ve written more about Prototyping public services with AI – looking at both practical tips and the designer’s new role – showing that we can now reach high levels of polish in the same time it takes to sketch a wireframe. Speed is determined by your mastery of the tools, not the level of “polish” in the output.
Principle 5: The prototype is disposable; the code is the truth
This is the biggest time-sink in design: trying to maintain a “full set” of prototypes that mirror the live service.
Think of it like testing a new safety feature for a car. If you want to test a new sensor, you don’t rebuild the entire car from scratch. You take an existing car and modify the specific part you need to test. In our world, the live application is the single source of truth. The prototype is a disposable tool meant to answer a question. Once that question is answered and the feature is built, the prototype has served its purpose. Don’t fall into the trap of “administrative double-entry.”
Principle 6: Choose a tool for research, but a method for collaboration
Design is a team sport. While we must choose tools that help us validate hypotheses, we must also remember that the prototype is our primary communication tool.
You likely communicate with your teammates more often than with your users. Choose a tool that allows the team to collaborate. If you prototype in HTML, ensure you’re sharing screenshots on a virtual whiteboard so everyone can comment. If your teammates aren’t comfortable editing code, ensure the way you present it makes them feel comfortable providing feedback.
Principle 7: Prototypes are for “Why”, not for A/B Testing
Putting 2 versions of a design in front of ten users is a usability preference test, rather than A/B testing. True A/B testing requires a massive volume of data to reach statistical significance, from which design decisions can be made purely on performance metrics. Prototypes are built to understand a user’s mental model and the “why” behind their actions. If you need to perform a genuine A/B test, you must deploy different versions of the real application to real users. Use your prototype for qualitative insight instead of quantitative guesswork.