Code-First Design Still Needs a Map
2026-05-12 · 7 min read · Editorial
Code-first design has made prototyping feel dramatically faster. A designer can now move from idea to working interface in VS Code, Lovable, v0, Bolt, or another AI-assisted builder without spending days polishing static screens first.
That speed is real. The friction is real too.
The moment the prototype leaves the visual canvas, the team often loses the map. In Figma, a product journey is visible before anyone clicks. You can zoom out and see the entire system: entry points, branches, dead ends, edge cases, alternate states, and the rough shape of the experience. In a code-first prototype, that same journey is buried inside routing, component state, conditional logic, and whatever was generated or changed through prompts.
The prototype may feel more real, but it can become harder to understand.
The “God View” Was Doing More Work Than We Realised
Figma was never just a drawing tool. It was also a thinking surface.
The spatial layout of frames gave teams an informal architecture diagram. A stakeholder could look at a board and understand the shape of the product before touching anything. A developer could scan the canvas and see intent. A product manager could ask why a branch existed, why a state was missing, or whether a particular flow had been considered.
That bird’s-eye view did quiet but important work:
- It made journeys visible.
- It exposed missing states.
- It helped teams compare alternatives side by side.
- It created a shared reference point for discussion.
- It made the designer’s intent easier to audit.
When design moves straight into code, that visibility often disappears. The experience becomes something people must discover click by click. If the reviewer does not know where to click, what path to follow, or what decision is being tested, they will only respond to the screen in front of them.
That is not a small problem. It changes the quality of feedback.
Live Prototypes Encourage Screen-Level Feedback
A live prototype is impressive. It has motion, real interactions, responsive behaviour, sometimes even realistic data. It can make a static mockup feel flat by comparison.
But live prototypes also narrow attention. When stakeholders are given only a URL, they tend to react to what they see immediately:
- “Can this button be clearer?”
- “This page feels too busy.”
- “I didn’t notice that option.”
- “Where am I supposed to go next?”
Those comments can be useful, but they are usually local. They are about the current screen, not the system. The larger questions become harder to discuss:
- Does this journey match the user’s mental model?
- Are we asking for the right decision at the right moment?
- What happens when the user takes the “wrong” path?
- Where do we recover from errors?
- Which states are intentionally excluded from this prototype?
Without a map, stakeholders are not reviewing the flow. They are exploring the interface. Those are different activities.
The Handover Problem Has Not Disappeared
There is a popular assumption in code-first design: if the designer is already making the prototype in code, handover becomes easier.
Sometimes it does. For interaction details, responsiveness, microcopy, timing, and component behaviour, a working prototype can communicate far more than static frames ever could.
But handover is not only about assets. It is about intent.
A developer inheriting a code-first prototype still needs to understand why the experience works the way it does. Which paths are canonical? Which behaviours are experimental? Which states were deliberately designed, and which ones are just what the AI builder generated by default? Which parts of the prototype are production-worthy, and which parts are disposable scaffolding?
If the only record is a folder of components and a long prompt history, the next person has to reverse-engineer the product logic. That is not handover. That is archaeology.
The New Black Box: Prompt History as Documentation
In the Figma era, imperfect as it was, the design file often became the documentation. It contained screens, annotations, comments, variants, and the fossil record of decisions.
In the AI-assisted code era, that documentation is frequently replaced by prompt history. This is a terrible trade if left unmanaged.
Prompt threads are not designed for auditability. They are messy, chronological, full of dead ends, and rarely structured around the final product logic. They explain how the prototype evolved, not necessarily what the team decided.
This matters for teams. When someone new joins, when an engineer needs to implement properly, when a stakeholder asks why a path exists, or when a compliance-sensitive product needs traceability, “it is somewhere in the prompts” is not good enough.
The Community Split Is Really About Thinking vs Building
The debate is often framed as Figma versus code. That framing is too shallow.
The real split is between two modes of work:
- Canvas for thinking: mapping, comparing, sequencing, naming intent, exposing structure.
- Code for building: validating behaviour, interaction, responsiveness, data, and implementation realism.
Code-first tools are excellent for the second mode. They are not automatically good at the first.
That does not mean designers should retreat to static mockups. It means teams need to protect the visual and conceptual artefacts that make the work understandable. The goal is not to preserve Figma as a ritual. The goal is to preserve shared understanding.
What Better Teams Are Starting to Do
The strongest emerging workflow is not “design only in Figma” or “design only in code.” It is hybrid.
1. Keep a lightweight flow map.
Before or alongside the code prototype, maintain a simple map of the journey. This can live in FigJam, Miro, Figma, a whiteboard, or even a markdown diagram. The tool matters less than the visibility. The map should show the happy path, major branches, decision points, error states, and areas not covered by the prototype.
2. Label the purpose of the prototype.
Every prototype should say what it is testing. Is it testing interaction feel? Information architecture? Stakeholder appetite? Technical feasibility? Copy? Data density? If the purpose is not explicit, reviewers will invent their own.
3. Add a guided walkthrough.
Do not just send a link. Send a short recorded walkthrough or written review path: start here, click this, notice this decision, then test this alternate state. This prevents stakeholders from getting lost and gives them the right frame for feedback.
4. Document intent outside the code.
A code prototype still needs a human-readable note: what is final, what is experimental, what was generated quickly, what needs engineering hardening, and what decisions remain open.
5. Use component canvases or story views where possible.
For complex products, render key components and states in a grid or storybook-style view. This brings back part of the old visual overview without forcing the whole process back into static design files.
The Practical Rule
Use code to validate feel. Use a canvas to preserve the map.
If a team moves into code and immediately starts losing track of the journey, the problem is not that code-first design is wrong. The problem is that the flow artefact was removed without being replaced.
The designer’s job is not only to make the interface real. It is to make the product understandable. In the code-first era, that responsibility becomes even more important, not less.
Fast prototypes are useful. Shared understanding is essential. The best teams will keep both.