← CASE STUDIES
CASE STUDY · DESIGNER'S RETROSPECTIVE
Why review feedback keeps dying in group chats
A recurring annoyance became a data model, then a shipped plugin — the full trail from problem discovery to the decision that shaped it.
problem-discoverydata-modelingfigma-api
Why review feedback keeps dying in group chats
ROLE
Lead designer
PLATFORM
Figma plugin · Web
TEAM
1 designer · 2 engineers
TIMELINE
2025.04 – 2025.10 · 6 weeks design
MY CONTRIBUTION

Owned problem framing, the data model behind annotations, the full plugin UI, and the export format engineers ended up adopting as a handoff artifact.

↔ THIS CASE STUDY IS ABOUT
Figma Annotate
A structured review-trail plugin that turns scattered design feedback into addressable, statused, traceable records — so critique stops dying in chat threads.
VIEW PRODUCT →
[ TL;DR ]

Design decisions were being made in review, then lost — nobody could reconstruct why a screen changed two weeks later.

CORE HIGHLIGHTS

Reframed feedback as structured data rather than chat, then designed and shipped a Figma plugin around that model.

3.4k installs, and the decision-trail export became the reason teams kept it installed.

Plugin panel
Annotation detail
Export view
[ 01 · CONTEXT ]
Where this started

I was embedded with three product squads that shared one Figma file per surface. Reviews happened in a weekly call, and everything said in that call lived in Slack afterwards.

The plugin ecosystem already had commenting. What it didn't have was any notion of a comment being resolved, owned, or exported.

Before state
[ 02 · PROBLEM ]

Across three teams I kept watching the same pattern: a design review would produce a dozen good decisions, and two weeks later nobody could say why the checkout button had moved.

I logged every instance for a month. The insight wasn't that feedback was missing — it was that feedback had no shape. It couldn't be assigned, tracked, or exported, so it evaporated.

  • 31 decisions logged over four weeks
  • 19 of them unreconstructable after 14 days
  • 0 teams had a written record outside chat
Audit board
CONSTRAINTS I DESIGNED WITHIN
Figma plugin sandbox
No persistent backend available — everything had to fit in document storage and survive file duplication.
Existing comment feature
Figma already had comments. Anything I built had to be obviously worth switching to, not marginally better.
Three squads, three workflows
No single team could dictate the model, so the schema had to be the minimum all three agreed on.
[ 03 · APPROACH ]
Treat a comment as a record, not a message

Once feedback had a schema — owner, status, anchor, timestamp — exports, filtering and accountability all fell out of it for free.

I prototyped three anchoring models before committing, because anchoring was the thing that would decide whether this survived contact with real files.

IA sketch
Flow
[ 04 · DESIGN DECISIONS ]
01
Anchoring annotations to node IDs

Comments needed to survive layout changes. A pin fixed to x/y coordinates is wrong the moment anyone nudges a frame — and frames get nudged constantly.

Node ID binding was the only model that survived a real week of file churn in testing. The deleted-layer edge case was rare enough to handle with an "orphaned" state rather than designing around it.

Anchoring comparison
Orphan state
02
A four-state machine, not a workflow builder

Two of the three squads asked for custom statuses. Configurable workflows are the obvious answer and also the thing that would have killed adoption.

The whole value proposition was "less ceremony than Slack". A configuration step before first use would have contradicted that on the first screen.

Status states
[ 05 · WALKTHROUGH ]
01PinningClick anywhere on a frame; the pin binds to the node underneath it.
Pinning
02Thread panelEvery thread carries its owner and state without opening it.
Threads
03ExportOne click produces a Markdown or CSV decision log.
Export
[ 06 · OUTCOME ]

3.4k installs in the first six months, with a 41% four-week retention rate — high for a plugin of this type.

The export is the only reason our retro doesn't take an hour anymore.

The unexpected result: the Markdown export became a handoff artifact engineers asked for by name, which wasn't the feature I'd expected to matter.

[ 07 · REFLECTION ]

The decision-trail export was a late addition, but it turned out to be the feature people actually adopted the plugin for.

If I ran this again I'd validate the output artifact first and design the capture flow backward from it — I built the input experience for five weeks before I knew what the output needed to be.

[ CONCEPT EXPLORATION ]
If there were no legacy baggage

Without Figma's comment API as a constraint, I'd anchor annotations to component instances rather than nodes, so a decision made on a button would follow every instance of that button across the file.

Concept sketch
EXPLORATORY · NOT SHIPPED
↔ THE PRODUCT
Figma Annotate
A structured review-trail plugin that turns scattered design feedback into addressable, statused, traceable records — so critique stops dying in chat threads.
VIEW PRODUCT →
OTHER CASE STUDIES
012025.01
The handoff doc nobody reads — so I made it executableDesigning a CLI as a design deliverable: what changes when the spec is something engineers run instead of skim.READ CASE STUDY →
022026.02
Turning the weekly report into something a system doesMethodology for moving a recurring manual chore into an automated pipeline — without losing the judgment that made it worth reading.READ CASE STUDY →
RELATED WRITING
Versioning a design system beyond the Figma library2026.06 · 7 MINWhere AI-assisted design review stops being useful2026.05 · 6 MIN