Prototype First
Overview
Head of Product Design at Embat, a B2B treasury platform that helps finance teams manage cash, automate processes, and see their cash flow in real time. Leading design across a wide product surface, since April 2024.
The problem
Once a problem was prioritised, the team would spend real time in PRDs and specs, comment threads in Notion and Google Docs, rounds of review, all before anyone had touched pixels, let alone built something a person could actually click through. Decisions got debated on paper, revised on paper, debated again. By the time anything tangible existed, most of the available time had already gone into a phase that produced nothing anyone could react to directly. The bulk of the process was going into documents nobody could click through.
The approach: Prototype First
The name says what changed.
Before, once something was prioritised, the team spent real time in PRDs and specs, rounds of documentation sitting between product discovery and design, all before anyone had touched pixels. Prototype First moves the prototype to the front: once something is prioritised, the mandate is to launch straight into building it. An idea gets embodied, not written up. It also meant the artefact itself changed, not a Figma mockup for someone else to interpret and rebuild, but working code, closer to what would actually ship.
Every week, in a ceremony we call Experience Review, whoever’s driving brings something tangible: a flow you can click through start to finish, even if the UI isn’t polished yet. That’s the artefact the team reacts to and refines, not a document, and a clickable flow makes for a far more productive conversation than comments scattered across a 20-page PRD. That conversation gets transcribed too, becoming part of what feeds the next round of work, instead of disappearing into a thread nobody rereads.
This took two different kinds of work, and I did both. One was writing the skills and agents themselves, several of which I authored directly with the design team, deciding which capabilities we actually needed instead of defaulting to generic tooling. The other was designing the process they run in, deciding what each stage owns, where one hands off to the next, and where a human decision has to sit in the middle. Getting it to actually stick meant going beyond my own team: I drove adoption directly with PMs, not just designers, because PM-led mode only works if PMs trust the tool enough to run with it themselves.
Two ways of running it, depending on who’s driving discovery:
- PM-led mode. The PM launches straight into a prototype to test a hypothesis fast. Design’s default role is to validate, refine, and step in to correct, staying close without owning it outright. This is the right mode for adjustments to what already exists, changes that don’t require inventing anything new.
- Designer-led mode. Design leads from the start, working hand in hand with the PM, when the work genuinely calls for it: a pattern that doesn’t exist yet, a complex flow built from scratch, several components that need to evolve together, or work on a new surface, agentic or otherwise, that’s going to set a precedent other teams end up copying.
A design system flywheel keeps both modes honest: every prototype pulls from the same system, and anything genuinely new that a prototype introduces feeds back into it, instead of living as a one-off. The system lives in two forms that stay in sync: documented for people in Storybook, encoded for the tooling in the repo and the skills themselves.
Design system flywheel: the Embat UI documentation feeds a prototype, the prototype introduces a new pattern, and the pattern is filed back into Storybook. 28% of prototypes improve the system.
Two principles shaped the whole framework:
- Floor, not ceiling. The framework had to work for anyone on the team, not just the strongest generalists. Nobody learns the names of 30-plus skills, you describe what you want in plain language and an always-on orchestrator, Charlie, routes it to the right one. A baseline everyone could use, not an elite practice only a few people could pull off.
- Sequencing, not territory. The framework organises around when work happens in the process, not who owns a phase. That single shift removed most of the turf questions that come with any process change.
The process
The Prototype First pipeline, six stages left to right: prototype start, product discovery, ux designer, ui designer, prototype deploy and prototype handoff, plus feature launch kit off-flow. Human context feeds in from the top and every confirmed decision is written to the prototype’s memory below.
Every idea gets its own branch, pulled fresh off a base that’s always current, design system, skills, and guardrails included, so nobody prototypes for a day against rules that changed yesterday. Whatever came out of discovery, meetings, or a refinement session gets loaded in as real context before any of it moves forward.
/prototype-start
Discovery comes first, and it doesn’t design anything. It checks the idea against evidence pulled from several sources at once, over MCP: past interviews and user tests logged in Notion, sales and implementation calls transcribed in Gong, feedback client-facing teams leave in Slack, real usage pulled live from BigQuery and Amplitude, and a curated library of treasury industry research for whether the idea is actually a differentiator. With that much ground to cover, it doesn’t search sequentially, a set of agents goes looking in parallel, each one specifically where that kind of answer actually lives, so the pass stays fast and precise instead of slow and approximate. The sources never get blended into one average opinion, agreement or disagreement between them is itself the finding. What comes out is a clear call: build it, build it narrower, validate first, or kill it, not a pile of research notes for someone else to interpret.
/product-discovery
Once the problem holds up, one stage works out how it should behave: the flow, the logic, the interaction, before a single component gets touched. It draws on hours of specialised treasury podcast transcripts for business context and on UX heuristics and interaction design theory for the craft itself, with agents searching each body of knowledge in parallel rather than one at a time, and it checks first against how that part of the product already works in production, because a good number of “problems” turn out to already be solved, or would just duplicate something that exists.
/ux-designer
Then it gets built, and this is the stage that does the actual coding. In React, on the real design system, inside the actual front-end repo pulled fresh with the branch. It’s connected directly to Storybook and knows the component library cold, and with that much surface to search, agents look across the repo and the pattern library in parallel, each pulling exactly the piece it needs rather than loading all of it at once. What comes out isn’t a mockup of the design system, it’s made from it.
/ui-designer
Before anything moves further, it gets tested against a panel of synthetic users, several treasurer archetypes, each answering independently so real disagreement stays visible instead of collapsing into groupthink. It’s a hypothesis generator, not proof, but it surfaces objections nobody thought to ask before a real person ever sees it.
/prototype-user-research/prototype-user-testing
Whatever ships also has to exist in every language the product runs in, translated for meaning and register, never word for word, against a glossary, a tone-of-voice guide, and a running list of do’s and don’ts, because the right term in Embat’s own vocabulary is rarely the dictionary’s first choice.
/translate
Getting it in front of people matters as much as building it: a staging environment and a shareable URL, spun up on Firebase straight from the branch, no PR comments to dig through, no CI tab, nothing to configure by hand. Re-deploying the same branch keeps the same link, so a week of iteration lives at one URL, not five scattered ones.
/prototype-deploy
Everything accumulated along the way, discovery findings, decisions, screenshots, becomes the raw material for launch itself. It doesn’t just suggest which Help Center articles are needed, it writes them and opens the pull request to publish them in GitBook. It checks the website itself for gaps against what just got built, and reviews the sales deck in Google Slides, catching what’s now out of date. Whatever a given feature actually needs, generated from real context instead of written from a blank page.
/feature-launch-kit
From there it crosses into engineering through a structured handoff, so what ships is a continuation of the same branch, not a rebuild of it.
/prototype-handoff/feature-handoff
36 skills and 19 specialised agents run underneath all of this, backed by a shared knowledge base of curated documentation and raw research corpora. Skills carry the stages, agents do the parallel digging inside them, discovery, UX and UI especially, where there’s too much ground to search one thing at a time. None of it has to be learned by name, you describe what you want and the system routes it to the right stage.
Rolling it out
Introducing a new process across a live team surfaces real friction, not just enthusiasm. Four tensions came up directly, and I dealt with each one head on:
- Shared ownership, unclear accountability. I set an explicit evidence bar: a prototype isn’t done because someone stopped working on it, it’s done when it clears a specific, agreed threshold. Whoever’s driving owns getting it there, no ambiguity about who signs off.
- Dupla vs. domain maker. I drew the boundary by phase, not by person: pairing where discovery is genuinely unresolved, single ownership once direction is set. That ended the running debate over whether pairs or individuals should own a project.
- Power asymmetry between PM and design. In PM-led mode, I made design’s involvement a checkpoint, not a courtesy: no prototype moves past early discovery without a design pass on interaction and system fit. Design’s voice stayed load-bearing, not decorative.
- The bottleneck doesn’t disappear, it moves. Once the slow documentation cycle was gone, review became the new one. I built a lightweight review ritual before it could turn into an invisible backlog.
The numbers
Five months of the process running, measured against the repo, the roadmap, and production usage.
Speed. Median time from starting an initiative to a shareable, clickable prototype: 7.4 hours of working time, less than a single working day, counting only business hours rather than nights and weekends (10.2 hours of wall-clock time either way). 56% of prototypes have a link the same day they start; 84% within three days. It didn’t ramp up to that, it ran at that speed from the first month.
Reach. 10 of the 12 people who start prototypes aren’t designers, PMs, engineers and product folks running the process themselves, end to end. Every product designer and every identified product profile in the company uses it, 100% coverage either way you count it. By raw volume of prototypes the split runs closer to half and half between design and everyone else, which says the same thing from a different angle: this isn’t design handing a tool to the rest of the company, both sides are genuinely building.
Follow-through. 78% of prototyped initiatives have shipped or are being built, 56% already released. Across 150 days: 68 prototypes, 341 shareable links, roughly one new prototype every two working days.
The cost of a bad idea. 15 prototypes died before ever being shared, at a median of 3 commits each and zero engineering hours. Killing an idea costs an afternoon now, not a sprint. That’s the argument that lands with a CFO, and it’s the one people rarely measure.
Compounding. 28% of prototypes fed an improvement back into the design system. Roughly one in three leaves the system better than it found it, so the next prototype starts from further along.
It reaches real customers. Ask Mode, prototyped and deployed in a single day, was used by 36% of production customers within a month of launch, 79 of 218 paying accounts. Display currency, also prototyped and shipped the same day, reached 13%.
What I learned
Part of the craft has become a commodity, and that’s worth accepting. Work designers obsessed over three years ago is now done by AI, sometimes better. Denying it doesn’t bring it back. Accepting it frees up focus for what AI doesn’t reach: real contact with users, understanding a problem nobody has framed properly yet. Other people being able to design because of your system isn’t giving up ground.
Designing the system that lets others design is a different craft. A PM doesn’t speak your language or know the design system. The real work is shaping the agents to interpret someone who isn’t a designer. That’s where adoption is won or lost.
Evidence stopped being a luxury. Backing a decision with real data used to cost enough that plenty of decisions got made on judgement alone. Now it arrives backed by default, even working alone on something purely speculative.
I was a skeptic, and I enjoy this more than what came before. The results are immediate, and watching the system sharpen with every iteration is a different kind of pull than designing screens. It demands staying current with no let-up, but experimenting has always been part of a designer’s DNA.