Engineering crits: Figma’s middle ground between design crit and technical review
Figma’s engineering team runs structured critique sessions—borrowing principles from the company’s design crits—to get early feedback on technical work. The goal isn’t approval. It’s an open conversation where engineers can bring unfinished ideas, brainstorm approaches, and unblock each other. The format sits between a design crit and a technical review, which tend to fall at opposite ends of the feedback spectrum.
Late-stage technical reviews are often the only checkpoint for engineering work. When they happen after a design has been built out, their feedback can be launch-blocking. Design crits, by contrast, are framed as “a safe space for exploration and feedback,” giving practitioners what they need to move forward. Engineering crits aim to capture that same spirit for technical decisions.
Why the format matters
Early engineering teams have a “landscape architect and gardener” dynamic: the same people shape the big picture and nurture the details. As teams scale, newcomers steward existing designs they didn’t create. The instinct can be to keep them at the perimeter, contributing only where they can’t disrupt work already in motion.
When Figma first floated the idea of engineering crits broadly, there was skepticism. Design crits focus on visual UX details, and technical reviews often hinge on sharing a spec for thumbs-up or thumbs-down approval. It wasn’t obvious that critiquing a technical design could work the same way. The breakthrough came from rethinking the format itself.
Synchronous technical reviews tended to anchor on input from a few team leads. Asynchronous reviews in other tools devolved into long comment threads—lists of disjointed feedback rather than real conversation. Running crits in FigJam changed that. An open canvas lets people share early thinking, inspirations, and in-progress screenshots alongside context, and the team can contribute in parallel rather than one at a time.
After piloting with a team of eight to ten people, the approach gained traction. Once the format became repeatable, calendar invites opened up and participation grew to over 200 engineers.
How a crit session works
Invites go to every engineer working on the Figma editor, listed as “optional” so people can join or skip as needed. Anyone is free to attend—sometimes cross-functional teammates join—but most opt in when a topic relates to their expertise. Sessions are recorded for reference.
The stated goals of an eng crit are to:
- Brainstorm and generate ideas
- Identify difficult engineering challenges
- Validate hypotheses
- Share knowledge
- Call out irreversible decisions
Crits are most useful in the early and middle phases of technical design, though occasionally a targeted question brings one in late. They happen at every scale: existential questions, focused technical challenges, or a series of crits to converge on an approach.
Before the crit
Presenters must prepare a FigJam file with the design to review, ideally using a dedicated engineering crit template with prompts tailored for feedback. Reviewers shouldn’t have to digest a full PRD. The presenter frames the discussion up front: are they after high-level architectural ideas, or a deep dive on a specific component? They also share approaches already considered, leaving room for exploration.
That said, a lightweight shortcut—pasting targeted screenshots from a design doc into a FigJam file—happens sometimes, though it’s the exception.
During the crit
The sessions explicitly are not decision-making meetings. Reviewers are asked to lead with suggestions rather than mandates, capturing as much of the group’s collective expertise as possible. (Technical reviews remain the forum where key feedback gets acknowledged and acted on.)
The bulk of the meeting is synchronous but silent: reviewers leave stickies in FigJam. That lets multiple conversations happen in parallel, so everyone can weigh in on the area where they have the most expertise. If time remains, the facilitator directs attention to additional discussion topics or questions that might help the working group.
After the crit
One crit is usually enough for a team to settle on an approach. Occasionally, the takeaway is that none of the proposed options are viable—in which case the team goes back to the drawing board and comes back for another round.
Engineering crits aren’t a replacement for technical reviews. For features touching many teams or carrying high stakes, a crit is a stepping stone on the way to a fuller technical review.
How FigJam AI made its way through Figma’s engineering crits
Figma’s AI features for FigJam, which help teams get past the “blank canvas” problem, offer a clear look at how the engineering crit process plays out in practice. The project moved through five distinct stages, each with its own purpose and set of participants, and the feedback at every step shaped the final implementation.
Stage 1: Scoping the concept
The first crit was a gut check. The AI team brought a set of four possible approaches to a mixed group of engineers, designers, and product managers, each option laid out with its pros and cons. The goal was to gauge feasibility and get a broad read on which directions seemed realistic and which looked risky.
Early context came from both sides: the design team shared speculative “what if” ideas, while engineers framed the problem at a high level and explained how prompt engineering works. One hard requirement anchored the discussion — AI features would need to read from and write to the current file. People with machine learning expertise contributed additional perspectives, surfaced challenges, and pointed to solutions Figma had used in the past. By the end, the team had enough confidence to pick one option and build out an end-to-end prototype.
Stage 2: Iterating with a wider net
Because AI in FigJam touches many parts of the Figma editor, the follow-up crits pulled in a broader set of engineering teams. The team also used this round to ask for help on how to score AI model quality.
That question — “How might we improve our processes around measuring quality?” — got a practical answer from the ML team. The existing system was a manual spreadsheet tracking how comprehensive, precise, structurally sound, and useful a model was. Given the small dataset, a more quantitative scoring approach wouldn’t have been statistically meaningful, so the recommendation was to stick with qualitative evaluation, using AI feature bashes to gather feedback on summarization and generation.
Stage 3: Refining the details
AI features have a lot of edge cases, so the team ran a dedicated deep-dive crit on versioning. The ML platform team weighed in on how to update AI prompt versions and roll out changes safely, and in the process pointed the group to an existing versioning system already used in Figma’s multiplayer technology. That discovery sent the team back to the drawing board, and the system ultimately informed decisions on data input and summarization as well.
Stage 4: Final decisions without a meeting
Not every project needs a formal crit at every step. After several rounds of feedback, the directly responsible individual (DRI) had enough information to make final calls without presenting to the group again. The team moved forward without working through an approval checklist, which is a sign that the earlier sessions had done their job.
Stage 5: Shipping with follow-ups
The project skipped a formal technical review, but the working group followed up with specific subject matter experts and stakeholders before implementation. After getting the green light, the team shipped FigJam AI.
This five-step structure isn’t a rigid path — some projects collapse several steps into one session, while others need a series of dedicated crits. It’s meant as scaffolding, especially for teams unsure where to start. The goal is to make engineering crits feel like an accelerant, not an obstacle.
