Why Figma built a separate space for developers
Developers now account for a third of Figma’s users. That shift didn’t happen by accident — designers have long invited developer colleagues into files to look at in-progress work. But being welcome in a tool isn’t the same as having a tool built for how you work. The Dev Mode team set out to close that gap, and the journey involved a significant pivot away from their original codegen-first plan.
To build for developers, Figma needed people who thought like developers. In 2021, the company acquired Visly, an eight-person team building a tool for developing UI components in React. The Visly team brought research on developer tooling and hands-on experience — the kind of intuition that’s hard to gain from user interviews alone.
“We talk to tons of developers, but that’s really different than having an intuition,” says Sho Kuwamoto, Vice President of Product. “You have to immerse yourself in that world.”
Codegen wasn’t the answer
In early iterations, the team imagined Dev Mode primarily as a codegen tool — automatically translating designs into code. The logic was sound: when it worked well, it saved hours or even days on a project. But the team found that codegen that works in a testing scenario doesn’t necessarily hold up in the real world.
Teams differ widely in their constraints. Large companies don’t all operate alike — Meta and Wells Fargo face different security requirements, codebase structures, and levels of maturity. Many teams rely on existing code that doesn’t mesh with generated output. Some designers share gestural sketches never meant to be translated literally. The mix of languages, platforms, and internal frameworks across companies is too varied for a single generated-code solution to fit everyone.
“You assume, ‘There are big companies and there are small companies, and I understand what big company needs are and what small company needs are,’” says Emil Sjölander, Visly co-founder who led the Dev Mode workstream. “But Meta is very different from Wells Fargo. They’re both big companies, but they operate in extremely different spaces with extremely different constraints.”
Moving away from codegen as a primary feature was a major pivot. Codegen still has a place as a jumping-off point, but translating design to code still needs human judgment. The team shifted focus to supporting workflows rather than replacing them — adding diff support to compare changes when work is marked “ready for development,” and building Figma for VS Code so developers can see notifications and comments without leaving their editor.
“Everybody wants this process to feel like magic — wouldn’t it be great if you pushed a button and it just worked? The reality is this magic button doesn’t exist,” says Kuwamoto. “We thought less about making things automated. Now, it’s about how companies can customize the experience of moving from design to code so that it’s as good as it can be for them.”
Finding the right frame: a mode, not a separate file
A central question shaped the product: what should the developer experience in Figma actually look like? “We probably spent a year and a half on that question,” says Sjölander. “We went through a million iterations on this, all scattered across this spectrum between isolated versus integrated files.”
At the isolated end was a traditional handoff model — polished designs copied into a separate file, with developers potentially locked out of the original. At the integrated extreme sat a vision where designers and developers co-create in one space with shared tools. The team considered a Dev File format, where designers would copy relevant information into a dedicated doc, and also explored a screen-by-screen interface similar to Figma’s present mode.
They rejected the screen-by-screen approach because it felt too disconnected from the work. “The way that designers lay things out on the canvas is critical to understanding the UX and flow of a design,” says Joel Miller, a product designer on the Visly team. “You need to see all the pieces together, rather just in isolation.”
What emerged was a mode — not a separate file, and not the full design editor. The solution allows developers to flip the Figma editor into Dev Mode, moving between design and development spaces without changing tools. It’s segmented enough for tools optimized for developer needs, yet integrated enough for developers to see design context that matters.
“Developers shouldn’t need to worry about learning all of the interactions in [design mode],” says Miller. “It’s more about tailoring the Figma experience to them.”
Early on, the team framed the question around what a design tool would look like if built from the ground up for developers. The answer, as the team describes it, moves beyond the tool itself — since “they’re not going to be living in a design tool.” The goal is supporting the workflow where developers already live, with design context when they need it.
Design and development as one workflow
The team’s research went beyond individual user needs. They also studied how designers and developers actually collaborate, looking for friction in the way information flows between the two disciplines. “It was important to think about how developers ingest information, while focusing on improving the communication and overall workflow between designers and developers,” says Sho. The goal was not merely to smooth the final transfer of files, but to enable developers to participate earlier and more continuously. “One of the key pieces which required the most iteration and also lacks the most collaboration is between design and development,” says Emil.
Catching implementation problems early, rather than at the end of a design cycle, can dramatically speed up iteration. Treating a handoff as an ongoing conversation rather than a one-off delivery changes the dynamic. “Quality comes from iteration,” says Emil. The team deliberately designed Dev Mode with this in mind. “We wanted to get rid of this handoff ‘wall,’” says Joel, aiming for what they call collaborative handoff.
This collaborative mindset extends beyond the designer-developer pair. Emil stresses that product decisions involve the entire product team—including product managers, researchers, and marketers—and that design tools need to support that broader group as well.
For more details on the development process and upcoming features, Emil discusses the work on the Changelog podcast.
