Synoptro Blog

When the canvas becomes the broker

Dennis Berger — Thu, 11 Jun 2026 12:55:00 GMT

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.

The transformation will be staffed eventually

Dennis Berger — Thu, 28 May 2026 12:55:00 GMT

It's conference season again. Adaptive DesignOps is the new framing; the banner on this year's Design Operations NYC says so, and a handful of Medium pieces filed since January echo it. The pitch: efficiency was the 2018-era DesignOps story, scaling was the 2022 one, and 2026's job is transformation. AI-native operating models, the dissolving boundary between DesignOps and ProductOps, AI as the new team member. It's a tidy story. The room I'm in tells a different one.

Three in five design system teams are understaffed, per zeroheight's 2026 Design Systems Report, up from last year. Only 44% have a dedicated DesignOps manager. I work inside one of those orgs full-time, and most of the people I talk to do too. The story and the room don't quite match.

This isn't surprising. The discourse always leads the staffing by a few years. Conferences need a story to sell, and "twice the work with the same headcount, again" doesn't fill an auditorium. But the gap is widening, and I notice what fills it. When the keynote tells me AI will be a true team member that balances bandwidth before a manager thinks about it, and the calendar I'm looking at has me running intake triage solo across four squads while a fifth waits its turn, I am not the manager who hasn't thought about bandwidth. I am the part of the org that was supposed to get the budget, the headcount, the productivity...and got this instead.

The transformation tax

A useful question to ask of any "DesignOps is becoming X" claim: who does the becoming?

If transformation is something a team does, fine, but a team needs people, and the staffing data says many of us are short the people. If transformation is something a tool does on the team's behalf, that's a different sentence with a different consequence. The version where AI takes on ops work that doesn't show up anywhere on the org chart is a real version. It's also the version where the headcount conversation goes only one way at the next budget cycle, and it's not the way the keynote implied.

I am not against the framing. Adaptive is a real word and the practice does adapt. I just notice that "adaptive" can describe a discipline gracefully accommodating a new tool, or a discipline absorbing the cost of being permanently under-funded. From the outside they look similar enough that the same talk can apply to both.

What the report actually says

The same zeroheight survey notes that DesignOps, accessibility, and content design are increasingly represented in design system teams. That's true; the roles exist and new openings still happen. What's also true: the representation is uneven, and the dedicated-DesignOps-manager number is under half. The teams with an ops layer are increasingly the ones whose design system survives a reorg. The teams without an ops layer are the ones whose design system degrades until the next rebrand.

That is the part of the story that has not become a conference theme: "Some of you will get the budget and some of you will not, and the ones who don't will be told the AI will take care of it" is a less appealing keynote.

Where the gap shows up

I don't know how to close this gap from inside a corporate job. I know the gap is real; I see it in the calendar of the people I talk to. I see it in the design system audits that take six months because there's one person doing them with only 20% their total capacity. I see it in the fact that the most common DesignOps job posting in 2026 is still "one person, multiple squads, build the function." The discipline has not been staffed to deliver the future that the conference keynotes describe.

What I can say with more confidence: when you don't know where the friction is coming from, the abstract talk about transformation lands poorly. It feels either aspirational or accusatory, depending on the day. The more useful move is usually pointing at the specific friction point (intake, handoff, the team's weekly rhythm, scoring of what got shipped) and describing what's actually breaking. Synoptro has a short diagnostic for this at synoptro.com/friction-finder. I built it because the question kept coming up and I wanted to stop answering it from scratch.

That conversation about the specific friction is what precedes any conversation about transformation, and it's what the budget cycle is actually going to be about. The pitch that lands with a CFO is "here are the three things breaking, here is what that's costing the company, and here is the smallest set of moves that fix it." That's the pitch the keynote can't make for us, because the keynote doesn't know our companies, our org charts.

The next year

I'd love for the adaptive-DesignOps framing to age well. Some of us will end up in the truly adaptive version and some in the work-absorption version, and which side of that you land on will depend less on the framing and more on whether the company funded the DesignOps role this cycle. The conferences will continue to tell a single story, because it feels good. The staffing data will continue to tell two stories at odds with each other, because it's the uncomfortable truth.

Of course, both can be true at once. We are adapting. We are also tired. The discourse is allowed to celebrate the first half, but we don't have to pretend the second half isn't there.

When juniors leave, the library remains

Dennis Berger — Thu, 14 May 2026 12:55:00 GMT

Nobody on your team has run a token audit in nine months and you know exactly why. The person who used to do it left in the spring. The role that would have replaced them didn't get backfilled. "We're being more selective at junior right now," went the all-hands. The work hasn't gone anywhere. It's just on the shelf.

The AI-and-design-jobs conversation has settled into a comfortable shape: designers are being sorted, not replaced. Template-pixel-pushers in trouble; strategic, systems-thinking, AI-fluent designers in growth. Job postings up at the senior end. Lenny's job market write-up has the numbers; Figma's State of the Designer has the sentiment. None of that is wrong.

The story stops at the sorting. It doesn't follow what the sorted-out people used to do.

Junior designers seeded the system. Not the first version of the design system. That was usually a senior or staff designer with a vision. The maintenance, though. The hygiene work. The audit-and-clean-up cycles that happen monthly, the new-component intake that gets triaged, the deprecated-token cleanup nobody volunteers for, the documentation pass after a quarter of features have shipped past it. That work has lived on junior calendars for as long as I've been doing this. It pays a junior to learn the system from the inside out by maintaining it. It gives them craft repetitions on a real codebase. It produces leveling artifacts they can point to in their next review. And it keeps the system not-broken.

Take that role out of the org chart and the work doesn't follow it out the door. It lands somewhere else.

So, where does it land? Three places. First, on the senior or staff designer who is now also the maintainer of the thing they used to design. Their week's deep work shrinks by some number of hours because the deprecated-color migration has to happen by Thursday. Second, on the DesignOps person, who absorbs it because that's where unowned operational work goes by default and because they can write a script for half of it. Third, nowhere. The work doesn't get done, the system rots a little each quarter, and the rot becomes visible in design quality six to eighteen months later, by which point the cause and the effect are far enough apart that nobody connects them.

Pick the bucket. None of them are good. The first costs you senior-craft hours you're paying for at senior-craft rates. The second loads more onto a function that is already, by every count, the most over-extended in design. The third is the one nobody's seeing yet because the lag is too long. None of them solve the underlying issue, which is that someone has to keep the system honest, and the org chart no longer has a slot reserved for that someone.

The 2026 hiring data is mostly right. Senior-strategic roles are growing. AI-fluent designers are in demand. The economics are real. But "senior-only design org" is a structural choice, and structural choices have consequences the hiring spreadsheet doesn't see. The pipeline that produced the next senior was, partly, this maintenance work. Some of it was the very-junior labor of doing it; some of it was the staff-level mentorship of teaching it; all of it was a context where craft repetitions happened on real surfaces. Take it out and the seniors of 2030 come from somewhere else. From companies that still hire junior, fewer each cycle. Or from a labor market where the ramp got shorter and produced fewer people who can do the work seniors used to do.

This is the part that compounds. AI gets more efficient quarter over quarter. Human craft gets developed by doing the work, repeatedly, with feedback, on real surfaces. We are removing the work and the surfaces. The line on the AI side keeps going up; the line on the human side bends the other way, slowly, in the kind of way that's hard to see in a single-quarter scorecard. Six years from now we will be hiring "senior" titles for skill sets that have lost half a decade of compounding. And we will look at the comparison, AI capability versus human output at our cost basis, and the conclusion will write itself. Because we wrote it years ago, when we stopped funding the bench.

What I keep watching, lately, is which of my friends are absorbing the maintenance work onto their own plates without saying so. They are framing it as "I just couldn't get to the documentation updates this sprint," "the icon library is in a weird state right now," "we'll catch up on the audit when things slow down." Things will not slow down. The audit will not happen. The system will get a little stranger every quarter. And the next time we hire, we will hire senior, because that is what the data says, and because the slot for the person who used to do this work is no longer in the budget.

What helps is seeing the second-order cost clearly enough to keep it in front of you when the next staffing conversation happens. Not as a position paper. Not as a slide. Clearly enough that you can spot the moment it would have been priced in, and notice what you traded for the version where it wasn't.