At Config 2026 in June, Figma introduced code layers, which turn a design layer into interactive code with a click or a prompt. At Config India on 15 October, code layers and Specs moved into open beta. For teams that have spent years translating static screens into working interfaces, this is a meaningful change in the tools. It does not remove the need for engineering, but it changes where some conversations happen and how much is left to interpretation.
The gap static designs leave
Static mockups are good at showing layout and visual style. They are poor at showing behaviour: what happens when a list is empty, when a name is very long, when the screen is narrow, when data is loading or when an action fails.
Those details are usually discovered during the build, when changing them is more expensive. Engineers fill gaps with their best guess, designers review later, and the cycle repeats.
What code layers change
Code layers let designers prototype interactive states, real data and responsive behaviour with the same material that will eventually ship. A component can be reviewed as it will behave, not only as it will look.
This shortens feedback loops. Questions about edge cases surface during design, when they are cheap to answer, rather than during development.
A convincing prototype is not the same as finished software.
What they do not replace
Code in a design file is not production code. Performance, accessibility, security, data handling, testing and long-term maintenance still belong in the codebase, reviewed by engineers.
The main risk is treating a convincing prototype as finished software. Clear agreements about what is reference material and what is intended for reuse help avoid that confusion.
The design system is still the bridge
Handoff works best when design and code share a vocabulary. Named tokens for colour, type and spacing, and components that exist in both the design file and the codebase, remain the bridge between the two.
Code layers are most powerful when they use those shared components. Then a prototype is not a one-off, but a combination of pieces that engineering already recognises.
How roles shift
Designers who are comfortable with basic code will be able to explore interactions more independently. Engineers can spend less time interpreting static screens and more on the hard problems underneath.
Collaboration still matters most. The best results come when designers and engineers review interactive prototypes together, early, and agree on what needs to be built properly.
Where it helps most
Consider a filterable data table. In static frames, a designer would need dozens of screens to show sorting, filtering, empty results, long values and loading states. An interactive code layer can show all of that in one prototype that reviewers can actually use.
Complex forms are another good fit, especially those with conditional fields and validation messages that are hard to describe in static frames.
Keeping it organised
As more code appears in design files, teams need simple rules: where prototypes live, how they are named, which ones are current and who maintains them. Without this, files fill up with outdated experiments that confuse everyone.
How to adopt it
Start small. Use code layers for interactions that are hardest to describe in static frames, such as complex forms, data-heavy views or responsive navigation. Agree with engineering which outputs are reference and which are reusable. Keep the design system as the single source of truth, and expand use as the team learns.
Before you adopt it
- Use code layers for interactions that are hard to describe.
- Agree what is reference and what is reusable.
- Build prototypes from shared design-system components.
- Review interactive prototypes with engineers early.
