How we engineer feedback at Figma with eng crits

At Figma, we’re encouraged to give and get feedback on in-progress work—the earlier the better. This is especially true on the engineering team. But sharing early work can be daunting. It requires an environment and culture in which individual contributors feel comfortable bringing unpolished ideas to the table to ask for feedback and have an open conversation, not face another approval step. Most engineering teams have some sort of approval process, often called a technical review, which is usually reserved for the later stages in a project. The problem with late-stage technical reviews is that when they happen too late, like when a direction or design has already been built out, they can lead to launch-blocking feedback.

Noah Levin, Vice President of Product Design at Figma, calls design critiques a “safe space for exploration and feedback.” It’s not about approval, but giving a designer what they need to move a project forward.

Inspired by the Figma design team’s principles and methods for running design crits, a core group of Figma engineers, led by Ojan Vafai, set out to introduce a process somewhere in between a design crit and a technical review. This was the genesis of Figma’s engineering critiques, dedicated time for the engineering team to brainstorm novel approaches to technical problems, get feedback on existing work, and unblock each other. Today, engineering crits are a core part of our workflow, but it didn’t start out that way.

Lifting ideas up

In the early stages of an engineering team, everyone is both a landscape architect and a gardener—they not only shape the overall concept and design, but also nurture how it comes to life. There’s often a surplus of work and a dearth of resources at this stage. As the team scales, you begin to bring in more people who are unfamiliar with the existing design, but who have agreed to stewarding the concept. Ojan likened this stage to an anecdote about his grandfather: “I have a vivid memory of my grandfather wanting to build a small garden in our backyard. He asked my siblings and I to dig out the rocks to clear the area, but as soon as the soil was prepared, the garden was off limits.” He and his siblings weren’t allowed anywhere near the garden, lest they accidentally step on a burgeoning plant.

On a high-growth team, the instinct might be the same—to limit others to the perimeter, allowing them only to clear rocks but never plant flowers. On the one hand, you need help building the garden; on the other hand, you’re afraid that someone might trample something that’s been growing for a long time and is about to bloom.

When we brought the idea of hosting engineering crit to the broader team, many were skeptical. Design crits center visual UX details, so some of us wondered if it was even possible to critique the design of a technical solution in the same way. Similarly, engineering reviews are often based on sharing a detailed eng spec for approval, and the result is thumbs up or thumbs down. With so many of us used to this binary approach, we wondered how we might architect engineering crits to plant flowers together.

We reflected on the times when we felt like we were really in the flow as a team; brainstorms and retros—which we run in FigJam—came to mind. We also thought about what didn’t quite work in technical reviews. When we ran technical reviews synchronously, we anchored on the input of just a few team leads; they weren’t structured for everyone on the call to weigh in. When we ran them asynchronously in other tools, everyone’s instinct was to share feedback as a comment, which led to unwieldy comment threads that were just a list of disparate pieces of feedback, rather than a conversation. Immediately, the format seemed like the key to unlocking a more collaborative process.

Figma CTO Kris Rasmussen shares more about how we lift ideas up with engineering crits.

By running engineering crits in FigJam, we could solicit a lot of feedback in a short amount of time, making it easier for more collaborators to jump in. Rather than having one person talk at a time or respond to a long thread of comments, everyone on the team could contribute. And FigJam’s open canvas would allow engineers to share early thinking, inspiration, and even screenshots of in-progress work, alongside helpful context or prompts for the broader team. As soon as we piloted our first few engineering crits with our immediate team of eight to ten people, everyone was bought into the collaborative approach. Once we arrived at a repeatable format, we opened up calendar invites and welcomed more and more people into the process, growing to upwards of 200 people.

Anatomy of an eng crit

Today, the invite list includes the entire organization. While anyone—even cross-functional teams—is free to join, most Figmates opt in if a topic is related to their expertise. Sometimes, we’ll have insights to share on work that doesn’t directly involve us, and other times, many of us will simply be curious about what’s going on in the rest of the organization. My teammate and fellow Software Engineer Shirley Miao and I now host these sessions, which we record for posterity.

Our goals are to:

• Brainstorm and generate ideas
• Identify difficult engineering challenges
• Validate hypotheses
• Share knowledge
• Call out irreversible decisions

The engineering crit has become core to the early and middle phases of developing technical designs—and even sometimes in the late phases for a particularly targeted question. It has spread through much of the engineering organization, at every altitude: crits that involve existential questions, ones that center a specific technical challenge, or a series of focused crits to gradually arrive on an approach.

Now that engineering crits are such a central part of our work, we have the process dialed in. Here’s a look at what we expect before, during, and after the session.

Before the crit

To run engineering crits as efficiently as possible, we ask engineers to do some prep work. The must-have is a FigJam file with the design they want critiqued. We use this template, which has different prompts than a technical design doc. Reviewers need to quickly get the context they need and give meaningful feedback on it, as we know they don’t have time to digest full PRDs.

Before we begin, the presenter provides background context and frames the discussion: Are they looking for high-level ideas on large-scale architecture, or are they diving deep on a specific component? They also provide some details on ideas they’ve considered and leave plenty of room for discussion.

During the crit

Engineering crits are explicitly not an approval or decision-making meeting. They are about getting the right feedback to lift ideas up. We ask reviewers to lead with suggestions as opposed to mandates, because we want to ensure we use the time in these meetings to capture as much of the collective learnings and wisdom of the group. We have other forums, including technical reviews, to ensure key feedback is acknowledged and acted on.

After that, the bulk of the meeting is still synchronous, but silent, as reviewers leave stickies in FigJam. This means we are able to have multiple conversations in parallel—allowing everyone to speak up—and reviewers can focus on the part of the conversation where they have the most expertise. If there’s time at the end of the meeting, the facilitator will turn attendees’ attention to other discussion topics or questions that might help the working group.

After the crit

In most cases, one crit is enough for a team to figure out their approach, but sometimes they come out of the crit concluding that none of the proposed options are feasible. In that case, they’ll go back to the drawing board and attend another crit.

Of course, the process isn’t perfect, and it’s unrealistic to outline every possible edge case. Engineering crits are also not meant to replace technical reviews entirely. If we’re working on features that touch many different engineering teams or feel particularly high stakes, the engineering crit is a solid stepping stone on the way to a technical review.

Laura sat down with the High Growth Engineer newsletter to share more learnings and examples. Check out the interview here.

An example (real) eng crit

We recently launched AI in FigJam, which helps teams overcome the “blank canvas” problem. It’s the perfect example of how a project flows through the engineering crit process and comes out better as a result. Here’s a look at how this project evolved at every stage of the engineering crit:

Step 1: Scope

Goal: Gut check concepts with a diverse group of people across engineering, design, and product management.

The AI team kicked off an engineering crit by exploring how we might leverage AI to empower users to work more efficiently in FigJam. We’ve been thinking a lot as a team about how to bring AI into Figma and FigJam, so the design team began dreaming up “what ifs” while the engineering team started reasoning about this problem space at its highest level, offering context around how prompt engineering works. The AI team shared one requirement: AI features need to read and write content on the current file. Other folks with expertise in areas like machine learning helped provide more information from various perspectives, identified challenges, or surfaced relevant solutions we’ve used in the past. The team shared four options, each with pros and cons, and aimed to get a sense for overall feasibility and architecture. Ultimately, they came away with a gut check on which approaches might be realistic, and which might be particularly challenging. Based on the feedback, they were empowered to take one of the options and start running with it, prototyping out an end-to-end functioning flow.

Step 2: Iterate

Goal: Solicit feedback at a regular cadence as the work evolves, addressing new challenges and revisiting early work as needed.

Next, the team sought feedback from a wider range of engineering teams because building AI functionality into FigJam required touching many different parts of the Figma editor. At this point, they also wanted guidance on how to score AI models. They posed a question to the group: “How might we improve our processes around measuring quality?”

In response, crit participants shared that the current system for quality measurement was manual: a large spreadsheet with an evaluation of how comprehensive, precise, structurally sound, and useful a model is. Rather than trying to engineer a quantitative approach, the ML team suggested focusing on qualitative attributes by running AI feature bashes for feedback on AI summarization and generation; since the dataset is so small, a more quantitative approach wouldn’t have been statistically rigorous anyway.

Step 3: Refine

Goal: Focus on polishing specific aspects of the project with relevant experts.

When it comes to building AI features, the devil is in the details. In this case, the team chose to do another deep dive crit specifically on versioning and got more feedback from the ML platform team on how we want to think about updating the version of our AI prompts and safely roll-out changes. In doing so, they learned about an existing versioning system we already use in Figma’s multiplayer technology, and went back to the drawing board with this newfound knowledge. This system also helped inform the technical details around data input and summarization.

Step 4: Review

Goal: Make any outstanding decisions and review the plan holistically.

At this point, the team made final decisions informed by earlier crit feedback. In this case, they didn’t need to attend a crit because the directly responsible individual (DRI) had enough information to make a confident decision. They were empowered to move forward, without working their way through a more formal approval checklist.

Step 5: Ship

Goal: Attend technical reviews as needed, move forward with the project, and schedule any follow-up crit sessions for further work.

While this project didn’t go through a formal technical review, the working group did follow up with specific subject matter experts and stakeholders. After getting the green light on implementation, the team shipped FigJam AI.

You can try out engineering crits with your team with this template, the same one we use at Figma.

Many projects won’t fit neatly into this structure; some steps are collapsed into one crit, while others require a series of dedicated sessions. Still, these five steps are helpful scaffolding for anyone who isn’t sure where to begin. As we continue to evolve the process, our priority is making engineering crits a process that teams look forward to because it accelerates their work, rather than feeling like it gets in the way.