Dear Reader,
Last time we talked about Figma (Part 1, Part 2) they were on the verge of a $20bn acquisition by Adobe, which had to be abandoned because of competition objections from UK and EU regulators.
Since then, Figma has raced on with a host of new products and features. One of the significant new products released last June is Dev Mode.
Recognising that 30% of their users are developers, and in line with their mission of a collaborative space for product development, Figma has built Dev Mode as a space for developers, and their collaboration with designers.
In this article, I would be deep diving on the development of Dev Mode – what it is? why it was built? and how it was built. The goal is to explore the product thinking behind Dev Mode, and how it might evolve.
Note: I studied different resources for research, and these were the most useful: Introducing Dev Mode by Kris Rasmussen, Config 2023 by Dylan Field, Dev Mode: Building a design tool that works harder for developers by Alia Fite, The anatomy of launching a Figma open beta by Emily Brody, and the Changelog podcast: Bringing Dev Mode to Figma with Emil Sjölander.
Dev Mode: What
Dev Mode is a new workspace in Figma that is designed to empower developers with the tools they need to work efficiently, and to collaborate with designers within the Figma canvas.
Developers can use Dev Mode to understand design, compare changes, and translate it to code faster. They can also copy relevant code snippets, and connect it to their tools and codebase via plugins (Jira, GitHub, Storybook), and the Figma for VS Code extension.
Dev Mode: Why
From my research, Dev Mode was built for 2 reasons: To provide a native experience for developers to work efficiently within Figma, and to bridge the design-development gap and simplify the collaboration and iteration process, towards higher quality and faster product development.
This gap exists because when designing and developing, both users are optimizing for different things. “In the design process, you optimize for rapid iteration and ideation”, while in the development process, you optimize for implementation and review.
Closing this gap, aligns with Figma’s vision to build a new kind of design tool – one that is designed for the entire product development team. Also, Developers make up 30% of Figma userbase, hence optimizing the Figma experience for them is a priority.
“The easier it is for teams to design, document, find, and implement high-fidelity designs without losing sight of the work and each other along the way, the better the product outcomes” - Kris Rasmussen, CTO, Introducing Dev Mode
This is the goal. We shall now look at how Dev Mode was built.
Building Dev Mode
Acquisition and user feedback
The first step was to understand how developers are currently interacting with Figma. Designers were already inviting their developer counterparts into Figma for design handovers and to explore work-in-progress. The Figma team spoke to these users, to learn from them and get early signals on their existing workflows.
“We talk to tons of developers, but that’s really different than having an intuition”. “You have to immerse yourself in that world” - Sho Kuwamoto, VP of Product, Dev Mode: Building a design tool that works harder for developers
In 2021, to gain this ‘developer’ intuition, Figma acquired Visly – eight designers and engineers who built a tool for developing design components from code (React). The Visly team brought “with them months of research on developer tooling and years of hands-on experience” as developers, and Figma users.
“When we joined, we brought the developer perspective” - Emil Sjölander, Visly co-founder and Dev Mode lead at Figma, Dev Mode: Building a design tool that works harder for developers
This reminds me of one of my earlier articles on when Spotify was building their first Machine Learning (ML) first product: ‘Discover Weekly’, and had to acquire the startup Echo Nest, that had the data and expertise on how artists and their music were described by listeners at scale.
I guess the lesson in that article still holds true:
If you don’t have one side of an equation inside your company - look outside for it.
Problem Statement
The Figma team’s initial hypothesis for Dev Mode was a code generation (codegen) tool that would help translate design to code, and increase productivity.
But when this prototype was put in front of different Figma user groups (startups and big corporations), the feedback was mixed.
This was due to the difference and complexity of how different developers work.
The team pivoted and focused on the most important and common aspects of their user’s workflow, and how to support that through customisation (using plugins and extensions) rather than codegen.
“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.” - Sho Kuwamoto, VP of Product, Dev Mode: Building a design tool that works harder for developers
The general problem statement identified was that everyone wants to build better products faster, and it’s hard to keep their developer’s velocity and quality high, as the organisation grow.
The problem statement could be further separated into 3 problem buckets:
The 1st problem bucket was on organisational alignment/information asymmetry – because designers and developers work with different tools, there is a silo of information. An engineer could be working with Jira on a ticket that includes screenshots which have been updated on the final design, but not changed on the ticket.
The 2nd problem bucket was on maintaining product quality as the organisation/team grows - Figma currently solves this through design systems, but the challenge was that companies didn’t always use them.
The 3rd problem bucket was on maintaining developer efficiency as the organisation/team grows. This includes repetitive work e.g. “sometimes developers would get different versions of a design and would open up two screens side-by side, and spend a day comparing the different versions”.
- Bringing Dev Mode to Figma with Emil Sjölander
An additional consideration was how can team alignment and communication be improved throughout product development, so that both developers and designers are working in sync, and seeing the same thing at all times.
““We asked ourselves, ‘What would a design tool look like if it was built from the ground up with developers in mind?”” - Bringing Dev Mode to Figma with Emil Sjölander
Now that the team had a clearer understanding and intuition of the user, and their needs, the next step was to decide how Dev Mode would ‘look and feel’.
Dev Mode: The Look and Feel
After several iterations, the response received by the team fell within a spectrum across two options for Dev Mode: a siloed version, and an integrated option.
The siloed option “mimicked a traditional handoff process, in which polished designs are handed off from design to development and built out independently. In that scenario, the developer doesn’t even have access to the original design files”.
In the integrated option, “both the designers and developers would be co-creating in one integrated space”, like Figma.
The team used a series of questions to understand the designer-developer information handover process:
Should it be a snapshot in time, or part of a living, evolving file?
Do developers want to feel like they’re jumping into someone else’s file, or do they want their own experience?
Does it make sense to focus on an individual screen?
Is a “handoff” file the same as a design file?
Ideas ranged from creating a dedicated doc for developers: ‘a Dev File’, or a screen-by-screen interface. These options had different trade-offs such as: isolating the developer from the design process, which is counter to Figma’s vision of collaboration.
“The way that designers lay things out on the canvas is critical to understanding the UX and flow of a design,”. “You need to see all the pieces together, rather just in isolation.”
- Joel Miller, Product Designer, Dev Mode: Building a design tool that works harder for developers
The team settled on a toggle option, that enabled developers to switch from the design space (Figma editor) into the development space (Dev Mode). This option was the best of both worlds, siloed and integrated.
“This solution allowed them to get the best of both worlds—siloed enough that they could create tools and features optimized for a developer’s needs, but integrated as a space within Figma so that developers have important context from their design counterparts”
- Joel Miller, Product Designer, Dev Mode: Building a design tool that works harder for developers
Dev Mode: Better Collaboration
Beyond building a space for developers in Figma through Dev Mode, there was the need to also understand and improve the collaboration process with Designers. The Figma team considered this collaboration beyond the handoff process, but from the onset of product development.
“Handoff is perceived as a single moment in time and a linear process. But in reality, there is no single handoff moment. It's an ongoing collaboration. We needed something that placed designers and developers in the same space where they could collaborate and iterate together” - Joel Miller, Product Designer, Dev Mode: Building a design tool that works harder for developers
“Quality comes from iteration,” says Emil. “Dev Mode was designed with collaborative handoff in mind—that’s how we think teams want to work,” says Joel. “We wanted to get rid of this handoff ‘wall.’” - Dev Mode: Building a design tool that works harder for developers
Dev Mode facilitates this collaboration by providing a single place to access everything, annotate and comment, and track artifacts (design files and code) for production. Designers can simply label a section as ““ready for development” …without creating a separate page or file””.
Launch, Feedback, Iterate
The team launched Dev Mode in open beta (free access to users till Dec. 2023) at Figma’s Config 2023 conference and included a ‘give us feedback’ button on the top of the page.
In the first 24 hours after launch, they got “over 2,000 community responses from the feedback form, support forum, social media, sales conversation, and other channels”.
They collected, prioritised, and analysed this feedback and were able to iterate, resolve bugs, and make Dev Mode better. In the first 2 months the team shipped 200+ new features and fixes in response to user feedback.
Closing Thoughts
We have explored the product thinking behind Figma’s Dev Mode, what it is, and why it was important. We have also examined how it was built, from defining the problem statement, initial codegen approach, the ‘look and feel’, and product launch.
I like the emphasis of a toggle to go between the two views – of a designer, and developer. This should facilitate collaboration and help developers keep track of changes.
The ‘customize’ approach is a good starting point for developers to use plugins (e.g. GitHub, and Jira) to extend Figma with tools they use already. It is interesting how Figma could transform and become a full developer platform (using the Figma REST API and Plugin API).
I wonder how Dev Mode evolves further, is it through better codegen (e.g. Anima), more AI design features (AI FigJam AI), and code for design systems ? I can’t wait to find out at Figma’s Config 2024.
All of these can really empower developers, turbocharge collaboration, and enable companies to build quality products faster.
What a time to be alive.
Thanks for reading and bye for now.
Nero
Go Further