When the canvas becomes the broker

Figma shipped Workflow Lab on April 30, 2026. Their pitch: the canvas now hosts the live conversation between design and the code that gets built, with the MCP server brokering the back-and-forth. Designers see the build state in the file as it emerges. Engineers pull components, variables, and layout data into their dev environment via Code Connect. What used to be a feedback loop of JIRA tickets and Slack threads is now a conversation between design and code, with the agent making the connections.

Around the same time, Figma Make added Skills: markdown files where you write the conventions and workflows your team repeats, so prototypes match your standards with fewer prompts. Skills like /follow-ds-guidelines to enforce design system rules, or /sync-figma-token to keep color and type tokens current across the file. Skills live in your Figma Make account, invoked by slash command across whatever Figma file you're in. The agent reads them and the prototype lands closer to your prescribed style on the first try.

Both of these are real wins for designers. They are also a sleight of hand for DesignOps, worth looking at squarely.

The artifact problem the tool finally fixed

For a long time, the operational work of design tooling sat in the gap between the file and the build. Component renames in Figma didn't propagate to the engineering side. Variables defined in design didn't match tokens defined in code. The design system team, usually one person, sometimes one-and-a-half, spent a meaningful slice of every week reconciling the two.

MCP plus Code Connect closes a real chunk of that gap. The variables match. The components map. The component a developer pulls into their environment is the component the designer created, not a screenshot of it.

This is the part of the story Figma is telling correctly. The reconciliation tax really did exist. Most of us who run design system ops at small companies know the weekly cost of it in hours consumed, capacity brokered, happy-hour drinks ordered.

The work that didn't go anywhere

Then the question becomes: where did the operational work go?

Well...

Skills files don't write themselves. Somebody has to author the markdown that captures how your team actually wants prototypes built. Somebody has to audit the file when a new convention emerges, or when an old one starts producing artifacts that look wrong. Somebody has to notice when a junior designer runs a PRD through whatever build-from-PRD skill the team set up and the result looks plausible but skips the accessibility step your house style was supposed to incorporate.

That somebody, at most companies in our size range, is one person whose calendar is already full.

Same logic for the MCP server. The variables match because someone defined them well. The components map because someone curated the library to a state where mapping is possible. When the variables drift, the agent's output drifts with them. When the library is half-organized, the build pulls a half-organized version of the system. The tool's value scales with the underlying hygiene, and the hygiene is created and curated by the same person it has been.

The shift in the ask

What changes is the nature of the operational ask, not its size or scope.

Three years ago the ops question was: how do we get engineers and designers to agree on what the source of truth is? The answer was always some version of "documentation and discipline and a weekly sync." Now the source of truth is computable. The MCP server pulls it. The agent honors it. The new question is: how do we get the source of truth to be the actual truth?

That is a more interesting question. It is also more ops-heavy in the early years, even though the demo suggests otherwise. Codifying conventions into machine-readable skill files is the kind of work designers have historically resisted, partly because it felt like making rules and partly because the payoff was indirect or unclear. The payoff is now direct; the benefits are clear.

What this looks like on the calendar

For a solo DesignOps practitioner at a 50-200 person company, the practical near-term effect of Workflow Lab and Skills is probably:

• A two-quarter project to define and harden the skill files the team will use most often (the team-specific equivalents of the /follow-ds-guidelines pattern, the /sync-figma-token pattern, and the rest)
• A library hygiene push to make MCP pulls predictable (this was probably overdue)
• A new ritual, review-the-skills-file, bolted onto whatever weekly cadence you already run
• A budget conversation that has to acknowledge the work above as design system ops, not "just configuring the tool"

The last bullet is perhaps the most important one. The risk is that leadership sees Workflow Lab demo'd at a conference, decides the design system runs itself now, and re-pools the headcount somewhere else. We have seen this pattern with other tools, because the demo always looks like the system is the work instead of the team behind it. The pattern repeats roughly every 18 months.

The honest answer

I think Workflow Lab and Skills are net positive for designers and net neutral for DesignOps. The reconciliation work goes down. The codification work goes up. The total ops work stays roughly constant, but its character changes from cleanup to authoring, which is a more satisfying kind of work to do.

The part I am hedging on: whether the leaders signing the budgets understand the trade. The Figma blog post says the workflow "shortens the feedback loop, shifting time away from requirements discussions and toward designing and building actual features." That sentence is true for designers. It is not the sentence a CFO reads when they decide whether DesignOps gets the additional headcount they need next year.

If you're about to spend a quarter on Skills authoring, the move is probably to write down what you're doing as ops work and put a metric on it. Metrics aren't honest about everything DesignOps does, but the absence of a number is the gap that gets filled by keynote demos and marketing prose.

If you don't yet know which part of your current workflow is going to bear the codification load, that uncertainty is itself a useful signal. The part of the practice most likely to break under MCP-driven workflows is the part that was already half-documented and held together by one person's memory. Synoptro's Friction Finder is a short diagnostic for finding where that's happening. It points at the kit closest to the friction, most often the Ready-for-Engineering checklist when teams are about to lean on MCP, since that's the conversation Skills files end up codifying.

The canvas becoming a broker is real. The reconciliation work it absorbs is real. The brokerage being free is not.