
There's a particular kind of design meeting I used to dread: the one where someone suggests a completely different approach on Thursday and you're demoing on Monday. Not because the suggestion was bad — often it was good — but because the cost of genuinely exploring it was a weekend of work. That calculation has changed. When a prototype can be built to a testable standard in hours rather than days, the conversation about which direction to explore shifts completely.
When prototyping is expensive, you unconsciously protect your ideas. You invest time in a direction and that investment makes you reluctant to abandon it even when evidence suggests you should. This is well-documented cognitive territory — sunk cost thinking shows up in design work as clearly as anywhere else. The answer has always been to prototype early and cheaply. The problem was that 'cheap' was relative. A day's work on a wireframe still felt like enough of an investment to defend.
When a testable prototype takes two hours, you're not protecting anything. You try three directions simultaneously. You discard two of them without ceremony. The one that survives does so on merit, not on the basis of how much time you spent on it. This changes not just the process but the psychology of design work.
It also raises the bar for what counts as a testable prototype. If you can build three variations in the time you used to spend on one, there's less excuse for testing a half-formed concept. The standard for what you put in front of participants should be going up, not down.
My current prototyping workflow starts with a structured brief to an AI: the user scenario, the key decision point I want to test, the constraints (platform, existing design system, technical limitations already known), and what a successful prototype would allow me to observe. This level of specificity in the brief produces output that's actually useful rather than generic. Vague input to any tool produces vague output.
For interaction structure and content hierarchy, I use Claude to generate a first pass and then shape it. For visual realisation, I move into Figma where AI assists with component suggestions, layout variants, and auto-generated states. For click-through logic, tools like Framer have made AI-assisted prototyping accessible to designers who don't write production code. For higher-fidelity coded prototypes, Amazon Q Developer has genuinely changed what's possible for designers willing to work in that space — I'll cover that in a separate piece.
The workflow isn't about removing human decisions — it's about removing the mechanical parts that used to sit between decisions. The time I save on scaffolding is time I spend on the choices that actually determine whether the prototype tests the right thing.
When you're showing participants something that took two hours to build, you watch it differently. You're not defending it. You're genuinely curious about what breaks. This changes how you moderate — you're more willing to let participants stray from the script, to explore the parts you didn't fully think through, because you know you can rebuild before the next session.
It also changes the conversation with stakeholders. 'We tested three different approaches' lands differently than 'we tested the approach'. It signals rigour, not uncertainty. And having the artefacts to show — even rough ones — builds confidence in the process even with stakeholders who are sceptical of design research.
Not everything benefits from speed. If you're testing something where the visual quality of the design is part of what you're testing — a premium experience, a consumer brand context, a trust-sensitive flow like payment or identity — fidelity matters. Participants read rough prototypes as rough products, and that reading affects their responses. Knowing when cheap and fast is appropriate and when investment in fidelity will produce more reliable data is still a human call.
The broader shift is this: AI has removed the excuse for not testing early. The cost of a testable prototype has fallen to the point where 'we didn't have time to test it' is no longer a credible position. If you're not testing, it's a choice — and increasingly, it's one that's hard to justify.
From here
Designing AI-enabled products and using AI inside the design process are two different problems. We do both, and keep them separate.
Let's turn your idea into a digital product people love.
Tools we work with
Whether you have a defined project or an ongoing need — we have a model that fits.
Perfect for defined projects — a new website, app redesign, or design system build. Fixed scope, clear timeline, no surprises.
A monthly design partner for teams with ongoing needs. Flexible capacity, no hiring overhead, pause or cancel anytime.
No pitch, no pressure. Just a focused conversation about your design challenges and how we can help.