It’s the last week of December, and I’ve spent most of the month trying to figure out what actually separated the designers I know who had a good 2025 from the ones who had a rough one. Not “rough” meaning laid off. Rough meaning their work got cheaper without them doing anything differently. Rough meaning the PM started asking for two variants instead of one, then five, then stopped asking and just pasted v0 output into Slack.
I had a handful of conversations in November and early December that all pointed at the same answer.
The split was about design systems. More specifically, whether the design system was something a model could read.
That’s the whole essay, honestly. But it’s worth unpacking, because the implication is bigger than it sounds. I’m not a design-systems lead and I haven’t run one professionally, so if you do that for a living and you think I’m getting some of the mechanics wrong, please let me know.
The Figma-only problem
For the last decade, a design system was a thing that lived in Figma. You had a library file, maybe a shared one. A page of tokens (colors, type, spacing). A page of components. A page of patterns. If the team was mature you had docs in Zeroheight or a Notion page. If the team was really mature you had tokens syncing to code through Tokens Studio or a custom pipeline. But the artifact, the source of truth that designers actually opened every day, was the Figma file.
That worked when the only consumer of the system was another human designer. A new hire could open the library, see the button, drag it onto a canvas, read the usage rules in the sidebar, and produce work that matched. The system was a manual for a person. The person read it, internalized it, executed.
By mid-2025 the consumer of the design system stopped being only another designer. It started being a model. Claude, Cursor, v0, Figma’s own Make tool, and a dozen smaller players were all generating UI on behalf of product teams. Those tools couldn’t open a Figma file. They couldn’t read a library. What they could read was text. Markdown. JSON. A Storybook build. A token spec in a public format.
If your design system lived in Figma and only in Figma, the model hit it like a wall. It had no way to see your tokens, your components, your usage rules. So it made up its own. The result was what I started calling “airport UI” around August. Interfaces that looked like every other LLM-generated screen, because they were drawing from the model’s general training rather than your system.
If your design system lived in a format the model could read, the opposite happened. The model generated work that looked like your product. Buttons matched. Spacing matched. Tone of copy matched. Not because anyone copied your system by hand, but because the system was legible to the tool doing the copying.
That’s the split. It’s not subtle. It’s not a gradient. It’s a hard line, and in 2025 it got drawn fast.
What does “model-readable” actually mean?
So what does model-readable actually mean in practice? I want to be concrete because the phrase is slippery. It doesn’t mean “I have a readme.” It means the system’s core assertions are encoded in formats that survive ingestion by an LLM without human interpretation. Three formats did most of the work in 2025.
First, the Design Tokens Community Group format. This is the W3C-track spec for expressing color, typography, spacing, and other primitives as a JSON tree with a stable schema. It’s been around since 2022, but the adoption curve steepened this year because every generative tool started consuming it. If your tokens are in DTCG JSON, a model can read them and respect them. If they’re only in a Figma variables panel, they may as well not exist from the model’s point of view.
Second, Storybook. Storybook 8 shipped in early 2024 with MDX-first docs and a much cleaner introspection API. What that means in practice. If you have a Storybook for your components, a model can read the component props, the usage examples, and the written rules in MDX. It has real documentation to pull from. Teams that already had Storybook got an unearned tailwind this year, because the investment they’d made for humans turned out to also work for LLMs.
Third, plain Markdown docs for each component, co-located with the code. Not a shared Notion. Not a Zeroheight page. A button.md next to button.tsx in your repo, with usage rules, accessibility constraints, do-not-use patterns, example invocations. This sounds almost insultingly simple. It is. And it turns out to be the single most useful format, because the model reads the whole repo anyway when it’s generating code. The docs get absorbed for free.
Stack those three together and your design system becomes a machine-readable contract. The model can generate work that conforms without anyone writing a prompt that reiterates your rules every time.
The workflow change
The old workflow was: designer reads the system, produces a comp, developer reads the comp, produces code, system gets enforced at the code-review layer by whichever senior engineer cared enough to push back on the wrong shade of blue.
The new workflow is: designer writes a prompt, model reads the system directly and generates code that conforms, designer reviews the output for judgment-level decisions (which of these three variants is the right one, is the information hierarchy right, does the empty state handle the case we care about), developer reviews for correctness. The system gets enforced at generation time, not review time.
The design system used to be documentation for the people doing the work. Now it’s a substrate the work grows out of.
That change looks small until you really sit with what it does to where value lives in the process. In the old workflow, the designer’s value was execution. How fast and cleanly they could produce a comp that conformed to the system. In the new workflow, execution is, frankly, free. What’s left is the system itself and the judgment about the output. If the system is tight, the output is tight without anyone pushing pixels. If the system is loose or lives in a format the model can’t read, every generation is a coin flip.
Who compounds
The designers I watched win this year were design system practitioners. Not the people with the shiniest portfolios. Not the design leads with the biggest Twitter followings. The quiet ones who’d spent the last three years writing token specs, owning component libraries, fighting for documentation time, and putting Markdown next to their TSX files.
Adobe’s Spectrum team. Shopify’s Polaris team. GitHub’s Primer team. The Atlassian design system group. Salesforce Lightning. The big in-house systems were already mostly model-readable because they’d been publishing public documentation for years. That investment, which probably looked like a cost center in 2022, paid off in a way nobody could have predicted.
Smaller teams that had prioritized design system work also benefited, even when the system was modest. A startup I talked to in October had a design system of exactly twelve components, all documented in Markdown in the repo, tokens in DTCG JSON. They told me their PM was generating usable first-draft screens by typing one-sentence prompts at Claude Code. The designer’s job had shifted to review and refinement, which she said she actually preferred.
Who gets squeezed
The designers who got hit hardest in 2025 were the ones whose primary deliverable was a Figma file. Not a design system. Not a set of specs. A Figma file, usually a polished one, representing a screen or a flow.
That deliverable used to be defensible because producing it well took skill and time. Clean layers, named frames, working auto-layout, decent prototyping wiring, proper hand-off annotations. Those are real skills and they used to have real market value. The market value collapsed this year because the Figma file stopped being the thing the team actually needed. The team needed code, or at minimum a working prototype, and the generative tools could produce either directly from the design system without a Figma file in the middle.
I don’t love writing this because several people I genuinely care about are in this bucket. The craft is real. The skill is real. But the economic role the craft used to play is evaporating fast, and pretending otherwise doesn’t help anyone.
What to do before the year ends
If you’re a designer and you can spend any time between now and January on this, here’s what I’d do.
Audit where your design system actually lives. If the answer is “in Figma” and nothing else, that’s your problem. Pick one of the three formats above and start the move. Style Dictionary is a decent way to get tokens out of Figma into DTCG JSON if that’s your starting point.
Write Markdown docs for your five most-used components and co-locate them with the code. Don’t try to document everything. The five that get used most will carry the weight.
If you have Storybook, make sure it’s current and the MDX docs are populated. If you don’t, it’s worth the setup weekend.
Then test it. Pick a generative tool you trust, feed it your system in whichever format you landed on, and ask it to produce a screen. See what comes back. If it looks like your product, you’re in good shape. If it looks like airport UI, your system isn’t being read, and you need to figure out why.
Looking forward
I don’t think 2026 is going to be kind to designers whose systems still live only in Figma. The generative tools are going to keep getting better, the teams that can feed them are going to keep compounding, and the teams that can’t will keep getting the generic-looking output that makes their product feel like every other LLM-built thing.
The good news is that the fix isn’t a new tool or a certification or a bootcamp. It’s a format change. A weekend of work, sometimes two. The design systems practitioners I know have already done it. The ones who haven’t still can.
See you in 2026.
Jameson