The Figma app for Slack has been live since Figma's earliest days. Dylan Field wrote in 2016 that "we didn't want to create yet another place to check messages," so rather than duplicate features, they decided to build Figma's collaboration experience on top of Slack. Eight years later, that bet mostly holds. Paste a Figma link into any channel and Slack displays a visual preview with the file name and last editor. Subscribe a channel to a project and notifications can include comments, mentions, branching updates, new files, and new projects. It is a genuinely useful pipe. The problem is that teams mistake the pipe for the workflow-and that is where everything quietly falls apart.
What the Figma-Slack integration actually does
With the Figma integration in Slack, you can view a single feed of Figma comments you've been mentioned in, get timely feedback from teammates and stakeholders, and customize Slack channels with updates on specific projects and teams.
You can also reply to Figma and FigJam comments directly in Slack. The more recent update goes further: when connected to Figma, Slackbot can generate FigJam diagrams from prompts, pull context from Slack messages, threads, channels, or canvases to create diagrams, and create structured diagrams including flowcharts, Gantt charts, sequence diagrams, and state diagrams.
That last capability is genuinely new and worth knowing about. A product manager can describe a sign-up flow in a Slack thread and get a FigJam flowchart back without opening Figma. Each diagram opens as a new FigJam file in your Figma account with a link you can edit in Figma.
The integration currently supports FigJam only and cannot create files for other Figma products.
So the integration surfaces activity, routes notifications, and now bootstraps early-stage diagrams. Those are real capabilities. None of them solve the thing that actually slows product teams down.
Where design decisions disappear
Important comments get buried under layers of iterations and versions. Critical feedback fragments across Figma, Slack, email, and meeting notes. Design decisions lack clear ownership and accountability. The context behind feedback gets lost in translation.
This is the pattern. A designer posts a Figma link in #design-review.
An engineer opens the file, sees three versions of the same flow, and starts guessing. One hour later, a Slack thread grows around spacing, empty states, and what happens on mobile.
The Figma integration dutifully delivers the comment notification to Slack. The reply happens in Slack. The resolution-if there is one-gets typed into a thread that has no formal connection to the Figma file. Two sprints later, the engineer who was not in that thread has no idea the decision was made.
A "context gap" is missing intent: the team lacks the why behind the UI-the user problem, the business rule, the research insight, the content constraint, the edge case that drove a decision. Notifications cannot fix a context gap. They only amplify activity.
One head of design leading a team of roughly 10 designers working across 20 files at any given moment noted that they were missing "tons of comments" because there is no clear way to see which files have unread comments versus which do not. That is a notification problem. The deeper problem is that even when the comment is seen, replied to, and resolved in Figma, the Slack thread where the actual decision happened is invisible to anyone who searches the Figma file later.
The handoff is where Slack threads metastasize
The design-engineering handoff breaks because of two gaps: the spec gap (Figma shows the happy path but not edge cases) and the feasibility gap (designers create interactions engineers cannot build as designed). Both gaps get filled by Slack-which means they get filled inconsistently.
Sending Slack messages with individual design notes throughout the build is disruptive. A structured review-engineering builds to staging, the designer reviews staging and compiles all feedback into a single pass-works better. Most teams know this and do it anyway, because the friction of opening Figma is just slightly higher than typing into whatever channel is already open.
Figma introduced Dev Mode to cut some of this friction. Dev Mode launched as the company's answer to the handoff problem-a developer-focused view inside Figma that surfaces measurements, code snippets, and component properties without requiring developers to learn the design tool's full interface.
The pitch is that both sides stop writing Slack messages that begin with "hey, quick question about the padding on…" Dev Mode helps when the file is well-prepared. Code generation creates a false sense of completeness: a button with correct padding and border-radius is not a finished button-you still need to handle loading states, disabled states, keyboard navigation, screen reader announcements, and interaction animations. Dev Mode generates visual properties. Behavior is still your job.
So Slack fills the gap. The thread becomes the unofficial spec. That thread is not searchable six weeks later by the engineer picking up a related ticket.
What a smarter setup looks like in practice
The goal is not to eliminate Slack from the design review loop. It is to make sure decisions that happen in Slack do not vanish there.
A few concrete things that work:
Subscribe channels by project, not by team. Routing notifications by project-sending landing page updates to the marketing channel and component library changes to the engineering channel-keeps the signal relevant to the people who need to act on it. A single firehose subscription to every Figma update is how teams start muting the bot.
Reply in thread, resolve in file. When a Figma comment notification lands in Slack and the discussion starts, whoever closes the thread should also resolve the comment in Figma with a one-line summary of what was decided. Using async comments with ownership-tagging one person, asking one question, and resolving the thread after the fix-keeps the file clean.
Use the FigJam-from-Slack capability for flow discussions, not file reviews. When an engineer asks how a flow should behave and the answer involves sketching it out, generating a FigJam diagram from the Slack thread gives that discussion a persistent artifact. The diagram lives in Figma, not buried in a 40-message thread.
An AI teammate can close the last gap here-watching a #design-review channel, recognizing when a Slack thread contains a design decision, and writing that decision back to a designated log or tagging the relevant Figma comment with a summary. That is a simple pattern: observe a thread, extract the conclusion, write it somewhere durable. The Figma Slack integration gives you the notification surface to make that possible; what it does not give you is the agent that acts on it.
Research shows that design errors contribute to 68% of rework costs in product development, and companies with formal handoff practices reduce rework cycles by 47%. Most of those formal practices amount to the same thing: writing down what was decided, and putting it somewhere the next person will look. The Figma-Slack integration is good infrastructure for that. Teams that treat it as a notification system instead of a decision-capture surface are leaving most of the value on the table.