Inside the Design Process at Figma
We visited Figma HQ to document how their design team builds the tool that designers use to build everything else.
Design Editor
Inside Figma: The Design Process
An exclusive look at how Figma's design team works, from ideation to shipping.
When you spend your days designing tools for designers, the pressure is unique. Every decision is scrutinized by people who notice kerning, who care about pixel alignment, who will absolutely call you out on Twitter if something feels off.
We spent three days at Figma's San Francisco headquarters documenting how their design team navigates this challenge. What we found wasn't just a process—it was a philosophy.
Starting with Problems, Not Solutions
The first thing that struck us was how much time Figma's designers spend not designing. Before any pixels are pushed, there's an extensive problem definition phase. The team calls it 'understanding before solving.'
We've learned the hard way that the best-designed solution to the wrong problem is still the wrong solution. So we obsess over problem definition.
Problem Definition Workshop
This means extensive user research, competitive analysis, and internal debate before design work begins. A typical feature might spend 2-3 weeks in this phase before anyone opens a Figma file.
Designing in Public
One of the most striking aspects of Figma's process is transparency. Design work happens in shared files that anyone in the company can access and comment on. There are no secret projects, no big reveals.
- All design files are accessible company-wide from day one
- Weekly design reviews are open to anyone who wants to attend
- Feedback channels are always active in dedicated Slack channels
- Shipping decisions are documented publicly with rationale
This transparency creates vulnerability but also trust. Designers get feedback early, engineers understand context, and the whole company feels ownership over the product.
The Prototype-First Culture
Static mockups are rare at Figma. Instead, the team moves to interactive prototypes as quickly as possible. They use their own prototyping features extensively, but also build functional prototypes in code when needed.
Building Interactive Prototypes
This prototype-first approach means that design decisions are tested early. Interactions that look good in static designs often feel wrong in motion. Catching these issues before engineering begins saves enormous time.
Shipping and Learning
The final phase is perhaps the most instructive. Figma ships features behind feature flags, rolling them out gradually and collecting feedback at each stage. The design team remains involved throughout, iterating based on real-world usage.
Design doesn't end at handoff. Some of our best improvements come from watching how real users interact with what we built.
Key Takeaways
After three days embedded with Figma's design team, a few principles stood out as universally applicable:
- Invest heavily in problem definition before solution design
- Make work visible—transparency builds better products and stronger teams
- Prototype early and often—static designs hide interaction problems
- Stay involved after shipping—real usage reveals what research can't
- Build psychological safety—great design requires risk-taking
The full documentary captures much more, including interviews with individual designers, a look at their tooling setup, and the story of how recent features came to be. Watch above for the complete picture.