The designer shares a Figma link in Slack. The PM opens it, clicks around, leaves three comments. The engineer opens it later, sees the same three comments plus two older ones from last sprint, and closes the tab. Nobody resolves anything. Next week, there are nine comments. Some are still relevant. Nobody knows which ones.
This is the most common failure mode in design collaboration, and it has nothing to do with the designs.
What Figma comments are actually for
Figma enables direct commenting on design files for clear, efficient feedback. That's the intent. The reality is that comments become a second inbox nobody agreed to maintain. Designers send files for feedback and open them a week later with 40+ comments — and it takes a lot of time to review them, since the feedback can be repetitive and sometimes mean the same thing written differently.
Teams with lots of resolved comments on a board find it very distracting and hard to find the unresolved ones that actually need a response. This is a solved UI problem that turns into an unsolved workflow problem. Figma gives you the ability to resolve a comment thread. It does not tell anyone, anywhere, what to do next.
The deeper issue: a Figma comment is spatially anchored to a frame, not temporally anchored to a sprint. It lives outside Jira, outside Linear, outside the Slack channel where the actual work gets assigned. It has no owner, no deadline, no status beyond "open" or "resolved." A Figma handoff is supposed to transfer not just design files but everything developers need to build what was designed — but most handoffs deliver the first and miss the rest, which is why implementations routinely diverge from designs and revision cycles extend timelines.
The handoff gap is structural, not personal
The Cash App design team described the traditional developer handoff model as not fluid or intuitive — it often felt like final screens and assets had to be tossed over a fence for developers to catch, leaving room for ambiguity and, often, frustration. Figma fixed part of that. Dev Mode means the developer no longer guesses at spacing and colors — they inspect the actual design. But no amount of spacing inspection tells a developer why a decision was made, or whether that stale comment from three weeks ago reflects a change that already happened or one that still needs to happen.
Developers build for real data; designers often design for ideal data — edge case frames showing how the design handles empty states, long content, truncation, and error states are supposed to bridge that gap explicitly. In practice, those frames exist in maybe a third of handoffs. The rest get improvised in code.
Developers rely on layer names when inspecting a design and building out the structure in code — a name like "Frame 123" connotes a generic div with no inherent meaning and asks a developer to interpret the intent of the layer. This is a small thing. It compounds fast. A file full of unnamed frames and unresolved comments isn't a handoff — it's an archaeology project.
The comment thread is not a task. It becomes one only when someone deliberately moves it somewhere tasks live.
Where the work actually gets lost
Here is the specific moment things go wrong: a stakeholder leaves a comment in Figma. The designer sees the Figma notification, thinks about it, and starts working on a revision. They don't reply to the comment — they just fix the thing. The comment stays open. The engineer, checking in two days later, sees an open comment and assumes the issue is unresolved. They ask in Slack. The designer explains. This exchange happens an average of several times per sprint, per team.
When a design file lacks proper organization, developers spend valuable time trying to decipher design intentions rather than writing code. Comment hygiene is part of that organization. But nobody budgeted time for comment hygiene. It's maintenance work that surfaces during the week of a deadline and gets blamed on "process."
The workarounds teams actually use: a weekly "resolve stale comments" ritual that nobody enjoys, a separate Notion doc that mirrors Figma feedback in ticket form, a Slack channel called #design-feedback that becomes the second inbox, or — most commonly — nothing formal at all.
More advanced version control, clearer change tracking, and better permission granularity would help teams manage large-scale design workflows. Users have been asking for this for years. The gap between design tooling and project tooling is still wide enough to fall through.
What a Slack-native teammate would do here
The friction point isn't inside Figma. It's at the seam between Figma and wherever the team actually tracks work. A teammate like Beagle would watch for new comment threads in shared Figma files, surface unresolved ones in the relevant Slack channel at the start of each day, and ask a simple question: does this need a ticket?
That's not complicated AI. It's presence at the right moment — when a comment has been open long enough to signal it's been forgotten, not resolved.
Figma's MCP server, in beta, is meant to bring Figma context into developer workflows so LLMs can generate more design-informed code. That direction is right. The ingredients that make for a successful design system — better communication, extensive documentation, shared patterns and languages — are also the foundation for effectively leveraging AI, which needs that context to produce not just any output, but the right output. But the comments problem predates code generation. It's a coordination problem. The file has the feedback. The team has the Slack channel. Nothing connects them automatically.
A few things teams can do right now
The cleanest approach doesn't require a new tool:
- Agree on a comment lifespan. Any open comment older than five business days without a reply gets surfaced in the standup channel. Manual is fine while you build the habit.
- Use the "Ready for dev" status intentionally. Tagging the relevant sections or frames with the Ready for dev status serves as a clear visual indicator of what's finalized on the design side. Don't mark something ready while comments are still open on it.
- Reply before you resolve. One sentence explaining what changed — or why the comment was dismissed — takes thirty seconds and saves a ten-minute Slack thread two days later.
- Name your layers. Even naming your main layout layers — like a feature callout, main content, or a related aside — allows developers to use proper tags or attributes. This compounds positively at the same rate messy naming compounds negatively.
The comment graveyard is a symptom, not the disease. The disease is that feedback lives in the tool where it was left rather than in the system where work gets done. Closing that gap — consistently, across every sprint — is what separates teams that ship clean from teams that spend Monday mornings asking "wait, did we ever fix that thing?"