Konstantin Semenenko
July 20, 2026
4
minutes read
Mural does not do design-to-code, and evaluating it as if it should misses what it is for. Its low-fidelity artifacts carry no components, tokens, or specs, so there is nothing for a generator to convert. What Mural genuinely contributes to handoff is the context engineers rarely get: why the feature exists, what the user is trying to do, and which edge cases the team already discussed. Treat it as the shared-understanding layer, and keep design-to-code in a tool that produces structured design data.
Mural and design-to-code is a question with a short answer and a more useful longer one. The short answer: Mural does not convert designs to code, and it is not built to. Its output is low-fidelity and conceptual, sticky notes, flows, journey maps, rough wireframe sketches, with no reusable components, no design tokens, no measurements, and no structured specs, which is precisely the structured design data that design-to-code tools depend on. There is nothing there for a generator to convert. The longer and more useful answer is that Mural still has a real role in handoff, just a different one: it carries the shared understanding, why the feature exists, what the user is doing, which edge cases the team already argued about, that engineers usually never receive. This explains both halves.
We build production front-ends from design handoffs every week, so this is a practitioner's view of what transfers from Mural and what has to come from somewhere else.
To see why Mural is the wrong input, look at what design-to-code actually requires. Tools that convert designs into code (Anima, Locofy, Builder.io, or an AI assistant fed by the Figma Dev Mode MCP server) read structured design data: real components with names and hierarchy, auto-layout describing how things respond, named tokens for color and spacing, and exact measurements. From that they infer markup structure and styling. The single biggest predictor of output quality is how well-structured the source file is, which we cover in design-to-code in 2026.
Mural has none of that by design. A Mural board is shapes and text on an infinite canvas, meaningful to humans and structurally empty to a machine. A rectangle labeled "nav" is not a component; a sketched layout has no responsive rules; nothing carries a token. So a design-to-code tool pointed at a Mural board has no hierarchy to parse and no system to conform to. This is not a gap Mural should close, it is the consequence of being a low-fidelity thinking space rather than a design system tool. If your pipeline needs design-to-code, the design has to exist in a design tool first.
Here is the part teams undervalue. The most common handoff failure is not missing pixel specs, engineers can read a design file, it is missing intent: why this flow exists, what the user is actually trying to accomplish, which alternatives the team rejected and why, and which edge cases came up in research. That context usually lives in someone's head or a meeting nobody recorded, and its absence is why engineers build exactly what was drawn and still get it wrong.
Mural is where that context is produced and, unusually, where it stays visible. The journey map shows the user's path, the workshop board shows the alternatives considered, the research synthesis shows which edge cases are real, and the flow diagram shows how the pieces connect. Linking that board into the handoff gives engineers the "why" alongside the "what," so when they hit a decision the design file does not answer, and they always do, they have the reasoning instead of a guess. That is a genuine contribution to handoff quality, and it is one design-to-code tooling cannot provide at all.
The practical pattern is a sequence, with each tool doing its part:
The failure mode to avoid is skipping the middle step, going from Mural sketches straight to implementation or to an AI code generator. That produces code built on an unresolved design, where the component structure, states, and responsive behavior were never decided, so they get invented during implementation, which is exactly how a codebase acquires the inconsistency that later reads as technical debt, the pattern behind the hidden cost of vibe-coded MVPs.
Even with a clean pipeline, handoff is not automatic. Generated code reliably reproduces layout and reliably misses accessibility, semantics, design-system conformance, and state, the parts that make an implementation maintainable rather than merely rendering. And no tool transfers judgment about edge cases: what happens when the list is empty, the name is 80 characters, the API is slow, the user lacks permission. Some of those were discussed in the Mural board, which is why linking it matters, and the rest are engineering decisions.
So the honest picture of a modern handoff is three layers: intent (Mural), structured design (design tool), and generated-plus-refined code (design-to-code tooling with an engineer finishing it). Each layer answers questions the others cannot. Expecting any single tool, including a design-to-code generator, to carry all three is the assumption that makes handoffs fail.
Mural does not do design-to-code, and asking it to misunderstands the tool: its low-fidelity, conceptual output contains no components, tokens, or specs for a generator to convert, and structured design data is exactly what design-to-code depends on. What Mural does contribute is the layer handoffs usually lose, the intent, the user context, the alternatives considered, the edge cases already surfaced, which engineers need precisely when the design file runs out of answers. Use Mural to define and align, a design tool to produce the structured design, design-to-code to accelerate the front-end, and link the Mural board into the handoff so context travels with the spec. Skip the middle step and you get code built on decisions nobody made.
If you want design handoffs that carry both structure and intent into production code, that is where our AI Dev Team work starts.
Does Mural support design-to-code? No. Mural produces low-fidelity, conceptual artifacts with no reusable components, design tokens, measurements, or specs, which is the structured design data that design-to-code tools require. There is nothing for a generator to convert. Design-to-code needs the design to exist in a design tool first.
Can you hand off Mural boards to developers? Yes, but as context rather than specification. A Mural board carries intent, user journeys, flows, alternatives considered, and edge cases from research, which is exactly what handoffs usually lose. Pair it with a proper design file that carries the implementable structure.
Why can't AI generate code from a Mural board? Because the board has no machine-readable structure. A labeled rectangle is not a component, a sketch has no responsive rules, and nothing carries tokens or measurements. AI code generators infer markup from component hierarchy, auto-layout, and named tokens, none of which exist in a low-fidelity canvas.
What is the right workflow from Mural to code? Define and align in Mural, build the structured design in Figma or an equivalent design tool (real components, auto-layout, tokens, states), use design-to-code tooling to accelerate the front-end from that structured file, and link the Mural board into handoff so engineers get the reasoning alongside the spec.
What does design-to-code still get wrong? Accessibility, semantics, design-system conformance, and state, the parts that make code maintainable rather than just rendering. It also cannot supply judgment about edge cases (empty states, long content, slow APIs, permissions), which is why an engineer finishes the work regardless of how good the generation is.
