Introducing a Prototype-First Approach Across Product, Design and Engineering
Design Director - Sam Fuller
Autone.io is an AI-powered retail management SaaS platform operating in a genuinely complex product space - allocation logic, replenishment flows, assortment planning, where the behaviour of the system is difficult to describe in words and even harder to evaluate from a static screen.
The Situation
When I joined as Director of Design, that complexity was being managed in the hardest possible way.
Designers were in constant, pressured production mode - spending almost all of their time authoring and tweaking endless static screens and flows, responding to feedback that arrived slowly, in fragments, and rarely with enough context to act on confidently. Interactive prototypes existed, but they were manually constructed, brittle, prone to bugs, and costly to update. Every change was a project in itself.
The result was a process that looked busy but moved slowly.
Design was a bottleneck not by intent, but by design - a function permanently behind the curve, delivering artefacts rather than enabling decisions.
The Opportunity - and the Problem Within It
The arrival of AI-assisted prototyping tools made the solution obvious.
High-fidelity, interactive prototypes that previously took days to build could now be produced in hours. The case for changing approach was straightforward.
The harder question was what to do with that capability responsibly.
Left unchecked, faster prototyping creates its own chaos.
Without structure, everyone starts building - designers, engineers, product managers, producing parallel artefacts with no declared intent, no shared language, and no clear ownership. The "hidden prototype" problem doesn't go away; it multiplies.
Speed without a system is just faster confusion.
The challenge, then, wasn't adopting AI prototyping.
It was building the culture, process, and guardrails around it that kept design firmly in creative and quality control - and that would scale as the business grew.
The Approach
Start with the problem, not the tool.
Before any process change, the team needed a shared understanding of what was actually going wrong - and a shared vocabulary for talking about it.
I developed a set of named anti-patterns drawn directly from what I was seeing in the existing workflow: The Hidden Prototype, Solution First Thinking, Engineering Defines UX by Default, Multiple Sources of Truth.
Naming these things gave the team a way to recognise and call out failure modes without it becoming personal. It also made the case for change in concrete terms rather than abstract process arguments.
Establish clear principles before process.
The process would only stick if the principles behind it were understood and owned across all three functions - Product, Design and Engineering.
Ten prototyping principles were developed collaboratively, centred on a single mental model:
Explore widely → Align together → Refine carefully → Build confidently
Critically, each principle was expressed as specific behaviours for each function - not as design team rules handed to everyone else, but as a shared contract with clear ownership at every stage.
Product frames problems and owns direction.
Design facilitates collaboration and owns experience coherence.
Engineering surfaces constraints early and builds from shared understanding, not interpretation.
Define four prototype types - and require them to be declared.
One of the most disruptive shifts was introducing a requirement that every prototype must have a declared type before work begins: Exploration, Concept, Validation, or Production. This single change addressed several anti-patterns simultaneously. It set shared expectations about fidelity and intent, prevented early explorations from being mistaken for final directions, and gave Product a clear framework for deciding when a prototype was ready to commit to the backlog.
Build a 9-step playbook - and a team contract.
The full process ran from trigger and brief through convergence workshop, design checkpoint, validation loop, build alignment, and post-build UX review.
Three non-negotiables sat at the heart of it:
No prototype without a declared type
No direction chosen without cross-functional review
Design signs off UX before build starts
Alongside the playbook, a team contract formalised the day-to-day working norms - ten commandments including Make it visible early, One direction, one source of truth, and Build what we agreed.
The contract was deliberately written to be a living reference, not a document that sits in a folder. It was designed to be used in sprint kickoffs, prototype reviews and retros.
Manage the chaos of the transition.
The initial reception to the idea was positive - nobody wanted to defend the status quo. The challenges came from the transition itself. With the new approach partially in place but not yet embedded, the board that captured this work honestly described the interim state: everyone blue-sky prototyping without the control or structure of a system.
Managing that period - maintaining momentum while establishing guardrails, keeping engineering and product bought in while the process was still being stress-tested - required as much leadership as design thinking.
The board also captured two alternative versions of the proposed process. The team ultimately adopted a hybrid of both, reflecting the reality that no framework survives first contact with a real product organisation unchanged. The ability to adapt without losing the core principles was part of what made it stick.
The Tools
The design system and the prototype-first approach were developed in parallel, and each reinforced the other.
An embedded Figma design system - connected via MCP to Cursor/Claude design/Claude Code - gave engineers a reliable foundation for building prototypes that were consistent with the product's established patterns. Design Office Hours, running three times weekly, ensured that engineers could unblock quickly without bypassing design, and that the design system remained the safety net rather than an afterthought.
The toolchain that emerged:
Miro for alignment and brief
Figma/Claude Design for early stakeholder review
Claude Code/Cursor for working prototypes
Miro again for synthesising feedback before the next iteration
This gave the team a clear, repeatable flow that matched the right tool to the right moment in the process.
The Outcomes
The shift produced three changes that mattered.
Stakeholder alignment arrived earlier and held longer.
With a working, interactive prototype in the room before any engineering commitment was made, conversations about direction became concrete rather than speculative. Stakeholders could react to something real - which meant fewer reversals downstream.
Time from concept to go-live reduced, with less friction throughout.
The validation loop that previously happened during or after build was pulled forward into the prototyping phase. Sprints started with higher-quality, pre-aligned briefs. Engineers built with intent rather than interpretation. Mid-sprint pivots decreased.
Design regained its proper role.
Rather than a production function permanently in catch-up mode, design became the function that shaped how decisions got made - facilitating convergence workshops, owning the canonical prototype, and signing off experience quality before a line of production code was written.
The rebuilt assortment module - Autone's most complex product area - was the first major test of the approach at full scale, and the clearest demonstration of what prototype-first made possible: a product decision process that moved faster, aligned more people, and produced a better outcome than the previous model had been capable of delivering.
"If we follow the behaviours, the process takes care of itself."
