The reading room · Digna Legi
How we engineer feedback at Figma with eng crits
/100
80–100: high value. 70–79: worth the time. Below 70: below the usual publication threshold.
Evidence-reviewed score based on available publisher text. Evidence provides a detailed internal process, but generalizability beyond Figma's culture and tooling is not established.
Scores reflect one reader’s profile, not an objective quality rating. Best is a separate personal selection.
How scoring works →This brief · about 3 min with detail
Original article ↗ · about 9 min (text estimate)
Why read this
Early, non-approving engineering critique turns technical design from gatekeeping into structured exploration before teams overcommit.
AI brief · Checked against source text
The main idea
Figma’s engineering crits sit between informal brainstorming and formal technical review: they create a structured forum for feedback on technical designs without making the session an approval gate. The mechanism is timing plus format: teams bring early or mid-stage work into a shared FigJam canvas, reviewers contribute silently and in parallel, and the presenter leaves with suggestions, risks, and options rather than a binary decision.
Go a little deeper
Timing changes the cost of feedback
The article’s core distinction is not feedback versus no feedback, but feedback before versus after commitment. Late technical reviews can produce launch-blocking feedback after a direction or design has already been built out, making course changes harder. Engineering crits are meant to move that learning earlier, when architecture, feasibility, and irreversible decisions can still be discussed without treating the conversation as a veto.
Format makes participation less hierarchical
Figma found that synchronous reviews tended to anchor on a few team leads, while asynchronous comments became scattered threads rather than conversation. The FigJam format solves a social and information problem at once: silent parallel sticky-note feedback lets more people contribute, lets specialists focus where they know most, and avoids forcing one speaker to control the room.
Crits preserve responsibility instead of diffusing it
The process invites broad input without turning consensus into the decision rule. Reviewers are asked to offer suggestions rather than mandates, and other forums exist to ensure necessary feedback is handled. In the AI in FigJam example, the directly responsible individual eventually had enough information to decide without another crit or a formal approval checklist.
The useful unit is a focused question
The crit can operate at several altitudes: existential architecture questions, a specific technical challenge, or repeated sessions as work evolves. The presenter’s framing matters because reviewers need to know whether they are judging broad feasibility, exploring alternatives, or digging into one component. Without that frame, the same meeting could collapse into unfocused opinion collection.
A case from the article
AI in FigJam
The AI in FigJam project used crits at different stages: first to test broad feasibility across engineering, design, and product; later to ask how to measure AI model quality; then to dig into prompt versioning with machine-learning platform experts. One concrete outcome was rejecting a quantitative scoring approach because the dataset was too small, and another was discovering an existing multiplayer versioning system that informed the design.
How the case is made
The case is made through Figma’s internal practice description, process taxonomy, and one project walkthrough for AI in FigJam.
Where the idea has limits
Engineering crits do not replace technical reviews; Figma treats them as a stepping stone when work crosses many teams or carries high stakes.
A question to take away · from Digna Legi
Where would earlier nonbinding critique expose hard-to-reverse technical choices before your team has already built around them?
What the original adds
The source includes operational details not fully captured here: optional organization-wide invites, presenter preparation expectations, facilitator behavior, and the five-stage AI in FigJam walkthrough.
About this brief
AI-written, then separately checked for source support, useful detail and clarity. The author’s claims and our editorial question are kept separate. The original remains the author’s work. How we select and summarise →
How was this brief?
Rate this summary, separately from the author’s article.
Optional. Saved in this browser; shared only if you allow analytics.
How was the original article?
Rate the author’s original after reading it.
Optional. Saved in this browser; shared only if you allow analytics.
Digna legi. Worth reading.