Insights
Prototype in Figma by default. Move to code when the answer depends on real behaviour, data, viewports, AI output, feasibility or speed. Prototype in Figma by default: it is quick, cheap to change and good at testing flow, layout and content.
Prototype in Figma by default: it is quick, cheap to change and good at testing flow, layout and content. Build a coded prototype when the answer you need depends on something a design file can only depict: how an interaction behaves under real input, how a screen copes with real or messy data, how it responds across real screen sizes, what an AI model actually returns, whether engineering can build it, or how fast it feels. One test decides it: if the answer could change once the thing runs in a browser, the prototype belongs in code.
Code costs more to build and to change, so it has to earn that cost by answering something the design file leaves open. And a coded prototype needs a written boundary, or a convincing demo starts to be treated as the product.
Figma prototype vs coded prototype
| Figma prototype | Coded prototype | |
|---|---|---|
| Best at answering | Is the sequence clear? Does the content make sense? Does the layout support the task? Do stakeholders agree on the direction? | Does it behave correctly with real input, data and screen sizes? Can it be built? |
| Who makes it | A designer | A designer who codes, or a designer working with an engineer |
| Changing it | Edit the frame | Edit the code, run it and check it again |
| Logic and state | Variables, conditions and expressions, on any paid Figma plan | Whatever logic the question needs |
| Accessibility | A screen reader can use the prototype in a desktop browser or the desktop app, but Figma infers the roles: anything with a click becomes a button or a link, and Tab follows the layer order | The real markup, focus order and keyboard behaviour, which you can test |
| What it can mislead you about | Anything it only depicts | Its own readiness: it works, so it looks finished |
| Afterwards | Stays a reference | Retired, hardened or carried into delivery, decided on purpose |
Starting cheap has research behind it. In a 1996 CHI study, think-aloud tests on low- and high-fidelity prototypes found "substantially the same sets of usability problems", but the paper version could not test physical handling, and the authors cite earlier work in which prototypes that hid slow responses earned inflated ratings. Fidelity matters when your question is about the thing the cheap version leaves out. We choose fidelity the same way in our prototyping and usability testing work: to see whether people follow a sequence, a clickable flow is enough.
Six questions that need code to answer
Each row is a question a design file can describe but not settle. If your open question is one of these, a coded prototype earns its cost.
| The question | Why a design file falls short | What the coded prototype must make real |
|---|---|---|
| How does the interaction behave? Drag and drop, nested reordering, keyboard control, focus | A design file shows the start and end of an interaction; the behaviour in between, and the keyboard route through it, exists only when it runs | The real input methods, including the non-drag alternative |
| What happens with real or messy data? | Placeholder content is chosen to fit; long names, empty fields, large lists and odd values are not | Representative data, labelled real or synthetic |
| Does it hold across real screen sizes? | Each frame is one fixed width; the layout between and beyond those widths is assumed | The target screen sizes and devices |
| What does the AI actually return? | A mocked response is written to suit the design | Real model output, even with synthetic records |
| Can engineering build it as designed? | Feasibility questions are about the platform, and the platform is absent | The technical approach the team is unsure of |
| Does speed change how it feels? | Transitions are instant or timed by hand | Realistic loading, latency and response |
What Tcules found by building in code
Working code raised a feasibility question while the design could still change. For Benchmark Gensuite, an enterprise suite of more than 75 applications, we built the attachments prototype in working HTML, CSS and JavaScript, so stakeholders could review how it behaved and whether it could be built before broader production decisions. It covered nested folders, previews, reordering and system states while the direction was still open. With drag and drop working in front of them, a Benchmark engineering stakeholder asked: "I was curious if you use an external library for the drag and drop because Bootstrap 5 doesn't natively support drag and drop." In our reading, the running prototype is what prompted that question about the delivery platform. The modules had not reached customers when the case was written up, so it shows design direction and feasibility, not adoption.
Building finds states that a design file misses. On Chestnut, software that insurers use to pay and inform the agents who sell their policies, our designers and engineers worked in the client's product for about thirteen months: we coded the bonus designs, built part of the communications front end, and checked every feature against its design once it was in the build. Even with a fully annotated design file, building turned up states nobody had drawn, and we added them as they appeared. Specifying finds fewer states than designing, and designing finds fewer than building. So when missing states are the risk, bring code in early, and compare what gets built with what was agreed.
Where the six questions come from
Interaction and accessibility. Vercel's design engineers, describing how they work in March 2024, list prototyping explorations that are easier outside Figma among the things they consult designers on, noting that "animations, keyboard controls, and touch are better implemented in code", which also saves rebuilding them for the web. Drag and drop carries a duty that only a working build can check: WCAG 2.2 success criterion 2.5.7, at level AA, requires that "All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging", with narrow exceptions.
Realistic research. The UK government's guidance on making prototypes says code prototypes "are better for user research because they're more realistic". Teams there build them with the GOV.UK Prototype Kit, copying example code from the GOV.UK Design System. That suggests a condition worth checking in your own team (our inference, not the guidance's claim): code is cheaper to prototype in when the components already exist in code.
AI output. Qian Yang and colleagues at Carnegie Mellon traced what makes human-AI interaction hard to design to two sources: uncertainty about what the system can do, and the complexity of what it outputs (CHI 2020). A response written by a designer removes both. If the design depends on what the model says, the prototype needs the model.
Feasibility. Stephanie Houde and Charles Hill, in What Do Prototypes Prototype? (1997), separated prototypes by the question they answer: role, look and feel, and implementation. Implementation prototypes exist to answer technical questions about how a product could actually be made to work.
Test fairly: equal depth and a stated question
Whichever medium you choose, a comparison is only as good as its weakest prototype. For Phoenix, a decentralised crypto exchange, we built two competing trading models as clickable prototypes for user testing, both to the same depth: filled forms, review screens, an asset changed midway through, and success and timeout states. Any difference a tester noticed had to come from the product model, not from the finish of one prototype.
The same rule applies when one option is coded and the other is a design file: in our view, a coded prototype's extra realism can win a comparison on its own. Compare directions in the same medium and to the same depth, and write down the question before anyone sees either.
Write the evidence contract before you build
A coded prototype carries a risk a design file does not: it works, so people start to treat it as finished. Houde and Hill saw this in 1997: "since they actually work, it is common for them to find their way directly into the final system", and they warned that the result may be code that is hard to maintain. The GOV.UK guidance is blunt: "Do not just copy prototype code into production."
Every coded prototype we build starts with an evidence contract, so a polished demo does not quietly acquire production expectations. It records:
- The question and the decision rule. The hypothesis, and the observation that will decide the next move.
- Implemented states. Which product states and interactions work, and what sits outside the prototype.
- Data and dependencies. Which data is real, synthetic or static, which model, API or service is connected, and which is simulated.
- Included quality work. What security, performance and accessibility work is in, and which shortcuts would be unacceptable in production.
- The exit. Retire it after learning, harden a useful slice into product, or carry selected components into delivery, decided after the review rather than by drift.
A contract also tells reviewers what not to conclude. An AI review screen that uses real model output with synthetic records can test whether people can inspect and correct a source. It cannot establish production security or model performance at scale.
If people already want to ship a prototype, that is a different question, covered in our article on taking a vibe-coded app to production. If the design is settled and the job is a faithful build, see our guide to keeping a React build true to the Figma design.
Where AI prototyping tools change the threshold
AI tools can now write working prototype code from a prompt. Figma describes its own Figma Make as "an AI-driven, prompt-to-app tool" that turns ideas and existing designs into interactive apps whose code you can open and edit. General-purpose coding agents can also write prototype code from a prompt (an observation about current tools, not a measured comparison).
That moves the cost line, not the logic. When code is cheap to produce, the scarce part is knowing what the code is evidence of. We use AI to speed up prototype code and test preparation, and a person still owns the hypothesis, the boundary and the acceptance. A generated prototype that looks finished needs the evidence contract more, not less, because nobody chose its shortcuts on purpose.
The decision for your next prototype comes back to one question: what does your team need to see working before it commits? If a design file can show it, use the design file. If it has to run, build the smallest piece of code that answers it, and write down what that code does not prove.
Reviewed by Devagya Sharma, our Design Engineer.