Converge is easily my favourite conference of the year. The design system community is hands down the most fulfilling community I have ever been part of and this event brings all those incredible people together in a single place in the UK each year to mingle, knowledge share and learn.

This year the location was The Glasshouse in Newcastle. Nine talks, too much coffee and more hallway conversations than I can count. I also had the personal pleasure of sneaking in a lightning talk at the Redwoods-organised opening party.

I love a wrap-up, so here it is. Each talk, what stuck with me, my favourite quotes and some musings about the common threads I saw running through the whole day (both on and off the stage).

Jerome de Lafargue: What will still be true in 2036

Jerome, the Zeroheight founder, opened the day by flipping the question that’s been melting a lot of our brains recently. Instead of what will change, he asked what will still be true in ten years. He had two answers… Real conversations are irreplaceable. And every new wave of tech unlocks roughly ten times more solutions than the last one.

The first came with a brilliant story. Back in 2016 Zeroheight tested an early prototype with a designer. The feature they were super duper sure would sell it (auto-synced navigation) turned out to be wrong. Users wanted control over their doc structure. The real USP feature was the Sketch integration, and they only found that out by sitting down and talking to someone. Without that one conversation, he reckons they’d have run out of money six months later.

The second was a whistle-stop tour from mainframes to PCs to the cloud to AI. Each wave improves what already exists, then opens up problems nobody even thought of as problems. His challenge to the room: what’s the problem your users never expected you to solve? Zeroheight’s answer is agentic design system management. Their agent spots Figma changes and proposes doc updates, and a human approves them before anything merges.

Action beats anxiety. That’s the line I wrote down and underlined. A lot of us are anxious right now. Will AI solve all the problems? Will we still have any work to do? Universal Basic Income aside, what does our future look like? Jerome’s take is a great reminder of the reality that with new technology comes new problems and new opportunities for solutions. We got this.

TJ Pitre: AI Without the Chaos: Context-Based Design Systems in Practice

TJ brought the first practical talk of the day, and I’m a sucker for practical. He also operates in a realm very close to my heart: workflows, drift and context. He started with something every one of us has lived through: design and code drift apart. Five releases in, the corner radius is off, then the button colour, then the spacing, and then you’ve got two different products. Nobody did it on purpose. It’s just communication breaking down.

His answer is to make the design system AI-legible by upping context. Yes please. Token data with proper aliases, so no hard-coded values. Component data, so every variant and property. Org-specific rules, so product policy and engineering standards. And the non-visual stuff, like ARIA labels and motion intent.

Then he walked through the whole pipeline, from ideation to deterministic linting (Figma Lint and Check Designs, no AI needed) to MCP from design into code, then engineer review, validation and iteration with Story UI and Figma Code Layers. The live demo took an alert component from Figma into Claude Code, with the Figma description field fed straight in as context. Clean source in, aligned output out. He called it the cascade of context, and he made a strong case for the context engineer as a role.

This was such a practical talk and speaks right to where a lot of us our in our day to day work. And he crammed so much useful, applicable information in there. I loved “code for the big picture, Figma for the details”. It’s a really tidy way to split the work and something I have been feeling myself. I’ve also come away from this one with homework.

Frances Szweda: Why you need a Design System advocate more than ever

Frances talked about design system advocacy, drawing on her work at Tesco. Her starting point was that design systems have more users than ever. Between AI tools and everyone being able to generate UI, the volume of output is bigger than it’s ever been, and so is the drift.

So advocacy matters more than ever. People need teaching, supporting and bringing along, and that takes time. One of her slides said it takes 8 to 12 weeks for a user’s behaviour to change. And it’s not just the consumers, the advocacy needs to reach all levels of the organisation, the buy-in needs to be cultural.

Omg, this one is important. “We are all having to be advocates right now” felt like it was written for the whole room. It also kicked off a conversation I kept hearing for the rest of the day, about who actually owns adoption. “0% improvement? You had ONE job!” speaks to the pressure that design system professionals feel in their day to day. If only every team could have a Frances.

Hannah Clarke: Adapt or die!

In a talk reminiscent of Johns Robertson’s The Dark Room, Hannah’s talk was a choose-your-own-adventure insight into the world of a DS professional navigating the turbulence of AI and the organisational demands. The setup was that the rapid uptake of AI across design, development and product has thrown any idea of standard usage out of the window. As a design system team you either figure out how to adapt or you face the consequences.

The point that landed hardest for me was that AI empowerment can mean less design system usage. People can generate their own thing now. So the answer is to give the agents your design system context, which means getting your docs together. Knowledge base plus MCP. Meet people where they’re at and respond to what they’re actually doing, then put safeguards in with scripts and clear bounds. Easy peasy! Right?

Another great talk with clear, practical and applicable information. I arrowed this one in my notes as a theme, and it turned out to have one, if not two threads (more on that). It’s a very honest framing of where a lot of us are right now, and the format made it super engaging.

Dan Donald: Navigating friction

Dan stepped in for Amy Hupe, and his talk built on the one he gave at the opening party the night before, “We’re all doomed… but it’s okay” (turns out, it’s not okay).

He started with how we actually feel about AI. Excitement, fear, guilt, grief, FOMO, hope, overwhelm, sometimes all at once. Then he went straight at the costs most of us either don’t look at, try to ignore or are embracing the cognitive dissonance of. By 2030, AI data centres are projected to use 945 TWh of electricity and 9.3 trillion litres of water a year. The kicker was that 80 to 90% of that energy goes on everyday use, not training. He asked who this future is for, too. Who built it, whose work trained it, who pays the costs and who can afford it.

Then he brought it back to us. Design systems have always lived with friction. Consistency vs flexibility, control vs adoption, speed vs quality, central vs federated. None of it ever got resolved. We just got good at navigating it. And his model for working with agents was really clear. Rules are musts, and agents follow them and get checked. Guidelines are shoulds, and agents use them while humans review. Decisions are the why, and humans own them, with a name attached. I also appreciated the brief mention of the CRD.

Some of this is pretty close to my heart. As a strong advocate for AI use in responsible ways, the human element, responsibility and judgement sits at the heart of the philosophy I am circling with my own work. This one got me thinking about how we can use AI to slow down, connect with each other more. AI is complicated, but it is still ours to shape.

This was not a light-hearted talk, but it’s something we all needed to hear. Thank you Dan for stepping up to tackle the elephant in the room.

Nikki Plyem: Patterns Over Parts: What Makes Your System Unique, and Who Holds the Answers

A welcome departure from AI and a very cosy return to the heart of design systems, the actual design bit. Nikki’s talk was about shared language. What we actually want from a design system, she argued, is a language everyone understands, and patterns are where that lives. Patterns are composites, and they work a lot like genre. She related these patterns back to the shared visual languages of movies. We all know what sci-fi looks like. We all know a fantasy movie at a glance. And we definitely all got post-apocalyptic zombie imagery down without anyone spelling it out. I’d never heard of the Zombies, Run app before and now I definitely want to try it out.

She also showed how context decides the pattern and walked through some of the nuances in day to day UX pattern design. It was comforting to spend a while just thinking about the actual day to day design work again.

Also a special shout-out for how smooth she was through the tech difficulties. Total pro.

Daniel Yuschick: From Codebase to Community: Rebuilding Trust in Legacy Design Systems

Daniel’s talk was about rebuilding a legacy system that people had stopped believing in. But really it was about trust. He named the problem brilliantly: trust debt. Multiple silos don’t make a system, and if people don’t trust it, they won’t use it.

His way back was steady and unglamorous. Stability over speed. Build trust by showing up, with frequent, reliable communication. Then the operational backbone that makes a system dependable: canary releases, a clear support policy, version support, migration docs, knowing when to cut a release, and keeping docs in step with what ships.

“If they don’t trust it they won’t use it.” Yes. Another very poignant and actionable talk. This one left me wondering where the time for all that communication comes from when teams are already stretched. The organisations that need it most, the ones carrying organisational trauma from past attempts, are usually the ones with the least space to give it.

Leo Vogel: Sleight of Frame: Practical Figma Tricks for Components That Warn, Vanish, and Explain Themselves

Bring on the true Wizard of Figma. Leo’s talk was a magic show in three acts, and it was an entertaining combination of attitude, humour and mind-blowing Figma prowess. Leo has gone above and beyond to hack ways around Figma limitations. He also pulls no punches in his critique of Figma’s historical feature roadmap, something he and I have in common.

Act one was smoke: hiding zero-width spaces in component names, so “Radio Button” behaves exactly how you want it to in search. Act two was invisible ink and hidden mirrors. Shift+G is all or nothing (grievance #77, for those keeping count), and slots are new, so make them visible, so nobody has to ask “where can I customise this?”

Act three was deprecation. A deprecated component should be safe to keep, hard to find in search, invisible until you’re ready to upgrade, easy to find in projects and visually marked in the asset panel. Then he gave us the checklist. Rename it, add a layout guide, add zero-width spaces, remove the docs link, write the note, move it to a Deprecated page, put it in a section and fill that section red.

This was a talk I had been looking forward to all day and it did not disappoint. I thought I was good at Figma until Leo got on stage.

All of it is backed by his Book of Grievances, his running list of Figma feature requests, which you can see here. I’ve got a couple of things to add myself.

Lauren LoPrete: Design Systems Anarchy

The incredible Lauren LoPrete closed out the day with punk, and what a way to finish.

Punk resists definition, and it didn’t know what it would become. Her metaphor really stuck: the design system is the punk venue, product designers are the bands, and the product is the music. I also just personally enjoyed seeing the Hacienda up there, I studied Saville at design school and the principles resonated. Her argument was that design systems have drifted towards more control, more oversight and more constraint, and that we’ve started measuring output in PRs. But AI can be the next Xerox machine, and that doesn’t mean buying into the tech bros “I just cooked up a design system in five minutes,” distractions.

Her answer was to stop gatekeeping. Contribution models are gatekeeping models, so how do we lower the barrier to contribution? Enable experimentation rather than controlling outcomes, and encourage evolution, because deviation is the point. Set structural principles that get out of the way. Build the stage, bring the curation and taste, and create the space. Trust over control. No big deal.

“Design systems work is human work” was the perfect closing thought for the whole day and was one of the bigger threads. Building together is human.

The threads:

Humans make the calls

This is the biggest one for me. I am circling a bigger piece personally around this, but it sits at the heart of most of the work I have been doing. This came up in nearly every talk. Jerome’s conversations that can’t be reasoned into existence. Dan’s decision layer, with a human name attached to every why. Nikki’s patterns carrying good judgement forward. Lauren’s curation and taste. However much the agents do, somebody still has to decide. Humans still need to take responsibility and it’s so easy to let that slide with AI. How can we use AI to slow down, connect more and capture human judgement better?

Who owns adoption?

This one came up again and again. Design system leads feel totally responsible for adoption. “You had one job!” came up specifically in two different talks, but more in the coffee chats. But wouldn’t it be so much easier with leadership pulling alongside us? Frances’s 8 to 12 weeks for behaviour to change is a really useful number to take into that conversation as well as the steer to cater enablement at all levels of the organisation, not just the direct consumers.

Guardrails for agents, space for people

TJ, Hannah and Dan all want firm, deterministic rails for agents: linting, rules, scripts. Lauren wants the opposite for people: lower barriers, more experimentation, deviation as the point. I think these fit together. If the agents have clear rules to follow, the humans get more room to play.

Context, context everywhere

TJ’s layers of context. Hannah’s “get your docs together”. Leo’s components that explain themselves. Jerome’s agent needing the why. Documentation is having a real moment, because it’s what the agents read. This was also a huge theme in the recent Config India.

This one is close to my heart, for whatever reason my work and philosophy seems to be circling the human element, AI workflows, context and how these three themes can fit together.

And that’s a wrap.

Thank you, Zeroheight, for another incredible conference. And I can’t wait to see what you pull out of the bag for next year.

Oh, the feedback:

Beanbags.

Humans, humans everywhere. Notes from Converge 2026 was originally published in Design Systems Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

And I have questions.

15 Oct 2026 · @Cassie

Figma’s Config India landed this week in Bengaluru (recap here) and the message is clear. Design systems are shit hot right now (finally). Figma has done away with Schema, its design systems mini-conference, and rolled design systems into the main event. We’ve been begging to be taken seriously for years. If it takes the threat of AI powered challengers to make that happen, I’ll take it. Sure.

Code layers, Specs, guidelines, code sources, Payload. It’s pretty juicy and we can see Figma is making a play for a full-stack product suite (didn’t Adobe do this with uhh.. Dreamweaver?).

I’m only really here for the design system stuff though, so.. without further ado…

The design systems bits in short

• Code sources (closed beta). Add a GitHub repo or npm package to a library and the agent builds components and code layers from your real code instead of guessing. Set it up once and everyone using the library gets it. Cool beans.
• Centralised design systems (preview). One place for design libraries, code libraries and guidelines. A system map tracks changes and dependencies. System check flags gaps like missing descriptions and interactive states, across components and tokens. This could be a game changer, and it backs my bet that Figma becomes the DS hub. Fingers crossed it’s not gated behind Enterprise, because the teams who’d benefit most are often the smaller ones.
• Code layers (open beta, all plans). Code-backed prototypes on the canvas and a whole new consumer of your system. Paired with code sources they build from your real components. There’s still a gap here between design and code, but it’s closing. This feels like the awkward, in-the-middle evolutionary step.. like the mudskipper. But I presume we are going to see a convergence.
• Figma agent went GA the week before. It’s the thing reading your guidelines, and Figma pitches it for generating components from your variables and auditing your system for inconsistencies. Both a contributor and a consumer. Basically what we’re all using Claude Code for now.. So testing output and token economics here will be interesting.
• MCP got an update to support all the shiny new features. Agents can now read, write and create specs from whatever tool you already use (there’s a figma-spec skill for it) and generate code layers on the canvas. Two new tools: html_to_figma and generate_image to play around with. Add Weave workflows, fewer errors, fewer tokens and 20 new integrations. The DS angle here is probably the spec access.

Guidelines

Guidelines actually landed a week earlier, when the Figma agent went GA. Config India put them centre stage as part of the design systems story, and they’re worth looking at next to Specs.

You upload .md, .txt or .json files to a published library. Figma suggests three to eight focused files, under 100 KB combined. Whenever someone asks the agent to design with that library, it reads them in the background. These are the context and instruction files you’ve been feeding your outside-of-Figma skills.

Figma’s advice on what to put in them: anti-patterns, scenario-based dos and don’ts, and the reasoning behind each one. Their suggested drafting prompt tells the agent not to invent component names or rules, and to mark missing information as a question (hello Ruled out, hello [open] markers).

Two things niggle me. During beta you write the files and upload them by hand, and changing one means uploading it again. So your rules live in the repo and in Figma, with nothing keeping them in step. And Figma Make has its own guidelines, managed per Make file, which library guidelines don’t feed into. That’s two guideline systems inside Figma before my repo even gets a look in. This alone makes me uncomfortable. This is where drift happens.

Then Specs

Ok, if we can all just ignore how incredibly awkward the name of this feature is.. we can move on to actually talking about it. Markdown on the canvas, multiplayer. Press D. Embed a FigJam board, a frame or any node right in the text. Drag an existing .md onto the canvas. Pull context in through connectors like GitHub. Let agents read, write and reply to comments. Hand the finished thing to a coding agent over MCP. Open beta on paid plans, rolling out over the next few weeks.

Figma pitches it as a native home for context that moves into, out of and across Figma. Their problem statement is that markdown files have no relationship to each other or to the projects they belong to.

I’ve been writing context-first markdown next to components for ten months. So…this one definitely got me thinking.

The question

Specs is where these announcements cross over with my work the most. So the question that frames everything for me is simple. Would I move my CRDs off GitHub and onto the canvas or not? And what would Specs need to do to beat what I already have?

Quick recap if you missed the last article. The CRD (Component Reference Document, renamed, still CRD) is one structured-prose file per component. PMs, designers and devs co-author it, agents maintain it, and everything downstream reads it. Requirements before design, specs after, implementation decisions before dev, usage after ship. One origin per fact.

Where they overlap

• Prose as the medium for intent. Figma just shipped a whole surface betting that what humans write for agents can be markdown. Probabilistic isn’t a dirty word over there either, apparently. But there is little guidance around structure, and what the last ten months have taught me, is that you need to meet in the middle.
• Text and design side by side. My CRD and Figma are partitioned. Variants and states start in the CRD, spacing and visual spec start in Figma, and neither repeats the other. Embedding a node instead of describing it is that partition made visible. I currently use Claude and sticky-tape to glue them together.
• Agents in the loop. My build agent stops on an [open] marker and bounces back to a human. An agent replying in a spec thread is the same loop with a nicer UI. Figma even suggests agents write decisions and discoveries back into the spec as they work. Similar to my decision log in action.

Where they split

• Who can see what. When I write a CRD, my agent in Claude Code can see every other CRD in the repo, the built components, Storybook and the component designs and variable architecture in all the library files in Figma. That’s how a new menu item inherits the MenuRow rule: fifty-eight documents of precedent to read before it writes a word. Then everything downstream reads the CRD back out of the repo. If the CRD moved into Figma, I’d worry on both ends. Specs can draft from a codebase through the GitHub connector, but would it see the other CRDs, Storybook and the decision history? And would the build, docs and page agents still read it as easily? Moving the document is the easy part. The question is whether every agent still sees what it could before.
• Structure. Ten months of CRDs taught me that context-first is the easy bit to agree with. What makes it work is the content and the structure: atomic, ID’d requirements an agent can cite, [open] markers it has to stop on, anatomy nouns it can’t wander outside of, a Ruled out section so Bob’s no stays a no. Specs gives markdown a nicer place to live. So far it isn’t saying how structured it wants you to be.
• Git. My CRDs live in the repo. Decisions get captured in the same commit as the work, lifecycle lives in frontmatter, and the history is the history. I don’t know yet what versioning a spec has. Maybe it doesn’t?
• Origins. Specs makes it very easy to drag .md files onto the canvas. A lot of what we’d drag in is the context docs and skills our agents already run on (Figma’s own demo has a skill.md on the canvas), and those live in the repo next to the code they describe or they live locally on someone’s desktop. Once a copy sits on the canvas, which one gets maintained? Add library guidelines and Make guidelines and that’s a lot of places for one rule. Drift is two origins for one fact and no way to tell which is stale. Figma just gave us more places to put facts and more drift to try and keep under control.
• After ship. Figma’s framing is loopy and honest about doubling back, which I like. But Specs as shown still ends at the coding agent. A CRD’s most interesting readers turn up after ship: the docs agent, the page-building agent, the next CRD that inherits a precedent. Nothing yet says what happens to a spec once ‘the thing’ is built.

And code layers

Here’s my current loop. I design the component in Figma. It gets built in the repo. Then, I guess… with code layers, it comes back into Figma so we can prototype with the real thing (they really want to keep us out of VS Code huh?). Design it, build it, bring it back. Three trips, and technically a different artefact each time.

After that post, I was told component development can happen from the canvas. Code layers can clone a connected GitHub repo, the agent can build and edit components using your code sources, and changes can go back to the codebase (I assume). It just wasn’t demonstrated, because the Config India demos leaned on prototypes. Figma’s own framing explains a lot: building to think vs building to ship, with code layers pitched as the thinking kind for now and more complex codebases coming “over time”. Components need to be sturdier than that. They also often need to be multi-platform.

So the question shifts from can I build the thing once to would I, and where? If a component gets built on the canvas and pushed to the repo, which one is the origin? Do the CRD, Storybook and the decision history come along for the ride? I have a bet riding on the component layer being the last thing to leave the design tool (because I unapologetically love using Figma, okay?). This week made that bet harder to call, in both directions.

What it would take

For me to move CRDs onto the canvas, Specs would need:

• One origin. A spec backed by the .md in the repo, synced both ways. A copy doesn’t count.
• Full sight. The agent writing a spec in Figma sees what my Claude Code agent sees now.
• Easy reach. Build, docs and page agents read and write specs from outside Figma as easily as a file in a repo. MCP gets part of the way there.
• Structure that holds. Frontmatter, IDs and required sections an agent can rely on.
• History. Decisions versioned and traceable, the way a commit is.
• A life after ship. Specs that stay current once the thing is built.

And where it could genuinely win:

• Embedding the actual frame instead of describing it.
• PMs and designers co-authoring without opening a terminal. That’s what I built (and then killed) the CRD Editor for. I lowkey love Terminal too though, especially with my Matrix theme.
• Agents commenting right next to the design.

The CRD Editor died because it couldn’t see anything outside itself. Specs can see the canvas. Can it see the repo too?

Open questions

1. Does the GitHub connection go both ways, or is it import-and-copy?
2. Can a spec attach to a main component, the way guidelines attach to a library?
3. Can anything outside the Figma agent read library guidelines, and can they sync from a repo instead of being uploaded?
4. What does system check measure “missing” against? A CRD’s state requirements would make a pretty good checklist.
5. If a component can be built on the canvas and pushed to the repo, which one is the origin? And what context does the agent building it actually have?

I haven’t had my hands on Specs yet, so all of this comes from the announcements and the help docs. The minute it lands in our org I’m dragging a CRD onto the canvas to see what works and what breaks. Will report back. I expect we will start to see Spec templates in the community at some point soon, so maybe I will throw up a v2 of CRD there too.

Context, context everywhere. A DS focused round-up of Figma’s Config announcements. was originally published in Design Systems Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Eight months, head down, tinkering. I come up for air and everyone's talking about context-first, human judgement and decision capture in design systems. The perfect time to show you what I’ve been working on.

I committed my first CRD to the Resin repo on 15.12.25. I spent the Christmas holidays that year "vibe coding" the CRD Editor (much to my mother's chagrin), a tool that would let the non-tech, non-DS PMs and designers edit and contribute. (I later killed it…more on that…)

Since then: 1,714 commits, 58 documents.

So wtf is a CRD, I definitely hear you ask? It is the very creatively named Component Requirements Document (I really need help with names). But it is so much more than that. It answers questions like "how do design systems remember the decisions that make them?" and "what the fuck am I supposed to be doing here?" (that last one is a direct quote from Claude). It is the one document to rule them all. And it's not even in JSON.

Things it is not:

• It is not a component contract or spec. It's upstream of both (but complementary)
• It is not a way to replace PMs, designers or devs in the pipeline
• It is not a way to escape the canvas (I love the canvas)
• It is not just a list of requirements (seriously, who can I pay to help with naming?)

Things it is:

• A document that evolves through multiple component lifecycle stages, from "someone asked for this" to "it shipped and now an agent building pages needs to know how to use it"
• One file, co-authored by PMs, designers & devs and maintained by the agents that work from it
• A process of working with agents where human expertise is integral at every stage: the requirements, design, pre-dev research, usage notes
• A capture of human judgement and intent: what was decided, what was rejected and why
• Read by every step downstream, each of which co-authors for the next: design, build, theming, page-building agents, docs & search and (shockingly) humans
• An amendment protocol for changing a component that has already shipped

There's eight months of production experience demonstrating what worked, what didn't and what needs tweaking. Which is why there's a version 2 coming in hot and why it was time to write this piece.

A single guiding principle

One origin per fact.

A fact is stated once and captured where it originates. It’s realised downstream and is checked against the original capture. Variants are dreamed up in the requirements section of CRD, get realised first in Figma (yes, still) and then in code and the CRD is what informs the tests. If design changes a variant, the change goes back to the CRD, because that's the spawn point. Token bindings are born in Figma and realised in code so the CRD never mentions them.

The same fact can exist in several places and that is okay. That’s the pipeline working. Drift is something else: two origins for one fact, with no way to tell which is stale. Every duplicated spawn point is a future potential contradiction. Nearly every change in v2 is about finding those opportunities and removing them.

It is also why it's one document and not several. The obvious move is to split by stage: a requirements doc, a design spec, a dev handoff, a CMS doc. Each stage genuinely needs different things (sort of). But the overlap between them is significant. A variant is named in the requirements, built in Figma, listed in the properties table, cited in the tests and documented in the usage guidance. Four stages, one fact. Split the document and you have signed up to keep four sources aligned forever. One document absorbs the lot. The cost: every reader skips sections that aren't relevant and every skill carries a bit of extra context to use a piece of it. Considered. Intentional. More affordable than drift and stale knowledge sources.

The same applies to the canvas. Figma plus the CRD is the source of truth heading into the build, and yes, that is two sources. They are partitioned, not duplicated. Variants, props and states originate in the CRD before the designs exist, so Figma mirrors them. Spacing and visual spec are spawned in Figma, so the CRD does not repeat them. Stuff in the CRD does not get duplicated in annotations on the canvas.

So what actually is this CRD thing?

A living document that travels with a component through its whole life: requirements before design, specifications after design, implementation decisions before and during dev and usage after ship.

It is not a spec dump. Its job is the gap: everything that Figma, the codebase and the agent rules cannot tell you. Behaviour, accessibility intent, rules, edge cases, decisions and the reasons behind them. Where those other sources communicate satisfactorily, the CRD can link to it. Where they say it only partly, the CRD carries the missing information.

It's not documentation either, but it can be part of the solution if we want it to be. Usage guidance gets captured as quick notes and, when we can be bothered, the pretty docs get generated from them. Until then a docs agent can just query it directly and meet DS consumers where they are at. Bonus: it can also answer the ‘whys’ that docs usually leave out. The traditional doc workflow can rely on the CRD as its origin: when a CRD changes, the docs that came from it get reviewed too. Stale documentation stops being a thing that can happen (that one probably deserves its own article).

Human-writable, machine-readable

Everyone's heading one way right now. Determinism. Machine-readable. Codify it, contract it, JSON-ify it. I get it. I'm not against it (the CRD sits upstream of all that and definitely feeds into it). But the field's word for what humans produce is probabilistic, said like it's a flaw. Judgement doesn't happen in JSON and LLMs happen to speak pretty good human.

The CRD goes the other way on purpose. Structured prose. Enough structure that an agent can find a requirement, cite an ID, stop on an [open] marker. Enough prose that a PM can write it on a Tuesday and a designer can read it without opening a terminal.

The “requirements” (seriously, help)

Section 1 opens with Purpose and Scope, then Anatomy, then the numbered statements: F for functional, S for states, B for behaviour, C for content, A for accessibility, I for integration (primed for a DS segment in Sesame Street). If a line has an ID, it's a requirement and it gets tested.

Everything around the IDs is doing a different job: Purpose and Scope carry the intent. Anatomy names the parts (container, label, leading icon, spinner) and every statement sticks to those nouns and no others. If you need a word that isn’t in the anatomy, the anatomy is incomplete. Ruled out tells us what not to bother considering again, Bob said no, okay? Its job is stopping re-litigation, and it matters a bunch for agents doing best-practice research, which will otherwise excitedly propose the option Bob rejected six months ago like a cheerful puppy. Out-of-scope (different from ruled-out) defines functionality or use cases that belong to (or will belong to) other components. That’s the context an agent reasons with. The IDs are what gets verified. The rest is what gets understood.

Every ID’d statement is atomic and testable. "A button has a leading OR a trailing icon, never both" passes. "Icons should feel balanced" does not. A bullet that could be half-satisfied is two bullets. Anything that can’t be machine-tested gets a [review] prefix and is eye-balled by a human. A failing test points back at the statement that required it.

Pre-design a CRD is partly a brief, and briefs get to contain hunches. They just have to look like hunches: enter from stage-left the [open] prefix. Design closes every one by answering it, moving it to usage guidance, or cutting it with the reason or resolution noted. A build agent that finds an [open] marker stops and bounces back to its human. We all know by now what happens when we let AI fill in the gaps through guesswork.

Everybody loves a loop

Let me be clear, none of this is a straight line. Requirements go into design as a brief, with ideas marked [open], and design interrogates them. A variant turns out to be two. A state nobody imagined reveals its importance in the Figma Make prototype. An [open] gets cut because it sounded fine in the PM’s head but looked wrong on the artboard. All of that goes back into the CRD in the same session, as the designer works.

Then it happens again before dev. Pre-dev research reads the requirements and the design spec, looks at how the rest of the codebase does it, checks the other CRDs for precedent, ventures out into the big bad world for industry standards and comes back with implementation decisions and usually a question or two. Those go in too.

So by the time a CRD is ready for dev it has been interrogated twice, by the two people best placed to do it and their trusty AI sidekicks. Co-authored.

Let’s take a look at the different stages

The document evolves in one direction and is never "finished and filed". Frontmatter tracks two things: `lifecycle` is about the component: requested, backlog, active, built, deprecated; `status` pertains to the document, per section: how much of it exists yet.

A component can be built with a half-written CRD (whoops), or fully written and never built. "Ready for dev" is neither. It's a condition, computed in the moment: requirements and design specs complete, the joint designer-dev review done, no [open] markers, no open questions. Computed rather than stored because a stored flag can be true in the frontmatter and false in reality.

Who really reads this thing?

The obvious reader is the build agent, but the interesting consumers show up before, after and forever.

A docs agent consumes it when someone asks when not to use the flashing under-construction banner and what to use instead. A PM reads it to check what got agreed before asking for a change. A page design agent reads it before placing the component, for the usage context nobody put in the props. The dev reads it before the build; test generation reads the IDs during. A designer reads a sibling CRD to see how the last component handled focus. The conversion skill reads v1 to write v2. And whatever your system has bolted on reads its own section: in Resin that's brand tooling deciding which token pairs to validate for a11y in runtime and when, and the CMS deciding which properties are safe to expose to a self-serve client. Most design systems won't have those last two. Yours will have something else.

The reader I care about most (besides myself) is the one that shows up before a component even exists. The CRD writing skill goes looking through the CRDs already in the repo before drafting a new one. Not all of them, just the relevant ones. A new menu related item reads MenuRow. A new card variant reads other cards. That's where things like "the Divider lesson" and "the MenuRow rule" come from: a decision noted once becomes a precedent the next document inherits without anyone needing to restate it. The first CRD was spawned from thin air. The fifty-ninth is written with fifty-eight before it to inform in. Every ruled-out possibility, every implementation decision, every argument that got settled (with Bob) is context the next component can start with. It compounds.

Judgement, captured at its spawn point

Design and implementation decisions are dated one-liners with the why, captured in the same commit as the work itself. A decision that only lives in a prompt shapes a single build and then evaporates. Set in the CRD it shapes every rebuild, refactor and audit.

The bar for logging one: could someone plausibly propose the opposite? If yes, log it. If no, it's a commit message. If something shows up enough times that it's a generalised rule? Time for promotion into the agent rules.

Section 1 only ever states what is true right now. Superseded requirements are removed; the reasoning is captured and stays in the decision logs and Ruled out, adjacent to the requirements but not woven through them.

A reflection on v1 after eight months of production

Everything above is v2. Before saying what changed, here is what the Resin corpus looked like when I stopped to check (it’s been hectic).

58 CRDs, 28,297 lines. Mean 487, median 455, biggest 1,132.

v1 stored lifecycle as a folder: `active`, `backlog`, `requests`, `archived`, because the editor browsed by folder and no other reason. I knew frontmatter was the better home even then, but that meant editing YAML in a repo, and I wasn't ready to teach PMs Claude Code. Moving a file was a drag and drop. Then the URL changed, and every link pointing at it was wrong until someone pestered me enough to fix them, which was usually after someone hit a dead link. Manual step, human error, broken links.

It had already drifted. One CRD existed in `active/` and `requests/` at the same time. Two copies, two states, nothing to see here. Move along.

Amendments were separate documents. Eight of them, with their own parallel structure. The requirements and their revision lived in different files. The biggest file in the collection is one of these. This needed to go.

A ton of duplication had snuck in.. somehow. 👀 Acceptance Criteria existed in 57 of 58, basically restating the requirements above it. A changelog existed in 55 (why did I do this? It’s already in git). Code properties in 49 and Figma/Code mapping in 48; essentially a third copy of the API that was always slightly wrong. Even section names drifted. “Colour Contrast Pairings” in 45 files, “Colour Contrast Validation” in 3. Rogue characters from the editor's export scattered throughout.

Despite all of that, it worked. Mostly because the devs are awesome, partly because Claude loves a bit of chaos. When I interviewed the devs before starting v2 I was given the gift of pre-dev research mentioned in the loops above. They'd been doing it the whole time. And putting the results in the prompt, never to be seen again.

So v2 has a home for it. Section 3 is there because they were already doing the work but essentially throwing the results away. Into the forever memory it goes, yes please.

The interviews also killed the code props table and the Figma to code mapping. Nobody used them. Dev owns the API, Storybook documents it. Again, what was I thinking?

The new, shiny v2 and what changed

Pretty much everything that changed is the one origin per fact rule applied to the evidence above.

• Lifecycle moved from folders to frontmatter. Moving a file breaks every link to it, that is an insane mechanism to have even considered. Everything lives in one directory now, and nothing ever moves. Babies are born knowing how to use Claude Code now, it’s fine.
• Amendments moved inside the document. We add a block at the top, above section 1, so anyone reading the requirements knows they're under revision before acting on it. Design closes it, it gets folded in, it gets deleted. A separate amendment file was very silly.
• Acceptance Criteria & the checklist went bye bye. The discipline stays, in fact we get more disciplined throughout. The enumerable list is now section 1 itself, so there's one copy, one, and the checklist can't drift from what it checks. Happy place.
• Cross-component content left. Token wiring, global a11y, naming, responsive handling: true of every component, restated in every CRD. Moved to the build skill and agent rules, written once. Seems obvious now.
• Anatomy, Content & Ruled out arrived. We’ll see what v3 does with these.
• The CRD Editor got sunset, sniff. It shaped v1: section-heavy, form-like, checklist-driven. And it could see nothing outside the CRD folder. v2 is authored via Claude Code generally, in sessions that can see the CRD, Figma and the repo at once and keep all three aligned in the same session. Magic.

And some things intentionally weren't added: no stored ready-for-dev flag, no per-CRD definition of done, no verification results written back into the document, no version tied to the package version.

Migrating without migrating

So I want to shift the whole system to a new version. Fun. What do I do with all the CRDs I already have?

The 58 v1 CRDs just stay as they are until touched. Any substantive update converts one, a typo doesn't. Bulk migration is a whole lot of work that we don’t really need to do. Convert-on-touch means the format converges on whatever is actually being worked on. And hey, both AI and human consumers are flexible enough to be able to consume two different versions without too much pain, because we haven't locked into a deterministic format.

On conversion nothing new gets invented. A new section with no v1 source is left empty and that’s okay. Empty is information, guessed content presents as approved and that’s not okay. That matters most when a model is doing the converting. No naughty AIs wildly filling in gaps with their imagination and no oversight. Behave yourself, Claude.

Conversion isn't free, though. CTA Button is 664 lines of prose that have to become atomic statements, which is why it stays v1 until something forces the issue (the button is built; fingers crossed we never touch it again.. ha). Mostly, convert-on-touch makes my brain happy.

Running on anecdotal fumes

v2 has barely run in production. It's a new design informed by eight months of v1. It's certainly not the end result.

And the evidence for v1's value is, to be clear, devs saying they’d literally die without it now (direct quote, honest) and me agreeing with them (I’d die too). Eight months, 58 documents, 1,714 commits, and not one number that says the builds are better. And everyone loves a good number. The feedback isn't nothing. But it's also not “proof”.

So, coming soon to an article near you, is a proper test, scoped to the dev phase. Build quality scored against a rubric, across components of increasing complexity. The rubric covers stated requirements, which any spec gets you, and unstated ones, which is often where agents miss. Anatomy, Ruled out and the decision logs exist to supply reasoning for the unstated half. If they do, the score holds as the components get harder. If it holds on a badge and falls over on a more complex component, then structured prose didn't scale and I'll hold my hands up.

It was never actually a document, was it?

What eight months and writing this article has actually made me realise.. v1 was a document plus an editor. The document decayed because there was no system to keep it fresh; the editor couldn’t see Figma, couldn’t see the repo beyond the CRDs, couldn’t see anything outside its own form. Humans were the only maintenance, and humans really suck at keeping documents updated. And they shouldn’t have to.

v2 is the document plus the skills and agents that do the suuuuper boring updating work and then build from it. Lifecycle, status, conversion, the test IDs, the docs: all of that is derivable from, or a consequence of, human input, decision or judgement. So it’s the machine’s job. What’s left for the human to own is the part that was always theirs. Requirements. Intent. Decisions. Judgement. Taste.

Which is why the thing humans write can afford to be prose. Everyone’s codifying, and they should, downstream. But judgement doesn’t arrive as a schema. It arrives as a sentence from a PM, a note from a designer after a round on the canvas, a dev explaining why the MenuRow rule really does apply here too, trust me, Bob.

So what is it really? The beginning of a shared brain, the design system’s memory and knowledge, readable and writable by both species (or less pretentiously.. it’s a doc and some skills). This is the system that multiplies us instead of replacing us (because who doesn’t want more me). It still doesn’t have a name and CRD isn’t it.

Suggestions welcome, seriously.

Probabilistic isn’t a dirty word… was originally published in Design Systems Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

🎉❤️ → 🤔 → 💡 → 😐

It wasn’t excitement. It was that particular kind of relief-slash-validation that comes when something finally works the way it always should have.

TLDR: So WTF is an Extended Collection anyway?

Extended Collections let one variable collection inherit from another. You define your base tokens once, then create child variations that override only what needs to change. When the parent updates, everything downstream updates too, unless you’ve explicitly broken the chain.

It’s neat. It’s efficient. It’s obvious.

For anyone maintaining multiple brands, product themes, or white-label systems, this isn’t some shiny new toy. It’s the practical fix that turns an irritating, fragile workflow into an obvious one. A way to keep the structure predictable and drain some of the cognitive load out of managing it all.

A workflow that used to rely on discipline and sheer grunt work now finally has the scaffolding it always should have had.

This already works in code…

In the dev world, this isn’t new thinking. It’s common practice.

Multi-brand systems are already typically built around inheritance. You define a base theme containing all the shared design tokens… Then each child theme alters that base, overriding only what’s unique.

Change a core token (say, a neutral grey or a spacing value) and every child inherits that update automatically. Nothing breaks unless it’s meant to. It’s a clean, scalable pattern that’s been proven across frameworks, platforms and build tools.

So Extended Collections don’t introduce a new idea. They just bring Figma in line with the logic developers have been able to use for years. Finally, design and code speaking the same freaking language (sort of).

Faking it…

Before this, anyone running multi-brand or theme-based systems in Figma had to fake inheritance with willpower, duct-tape and ice-cream.

Multiple tiers of Collections. Duplicated modes, bloated with redundant variables. Syncing updates by hand. Tracking overrides manually. Headaches (literally). Avoiding drift with hope and a prayer. It worked, but only because the people running it were meticulous. It takes the kind of focus that can melt less determined brains (hence the ice cream).

Extended Collections don’t unlock new creative potential. They simply remove the administrative drag and the constant risk of human error. Which is why the community’s reaction was less “Wow!” and more “Finally.”

Followed closely by…

“…but wait”

Because here’s the twist: Extended Collections are an Enterprise-only feature.

I’m sorry… what the what now?

Figma’s positioning is that complex variable inheritance is mostly an Enterprise need. But anyone who’s worked in design systems for more than a hot minute knows that multi-theme functionality is the actual bread and butter. Multi-brand, multi-theme, multi-everything complexity isn’t exclusive to global corporations. It’s baked into the day-to-day of smaller teams, SaaS platforms, design studios, and agencies managing white-label products or serving enterprise clients.

These are often the same teams doing the most rigorous systems work, not because they have huge resources, but because they can’t afford to be sloppy.

So the gate isn’t about who needs the feature. It’s about who can afford inefficiency. At scale, manual syncing translates to wasted hours and real cost, so Enterprise clients can justify paying to remove that friction. But smaller teams, running tighter governance with limited budgets, will be left patching the gap with the same fragile workflows they’ve valiantly hacked together for years, not because they lack maturity, but because the fix has been priced out of reach. (But don’t worry! You’ve got more modes to hack with now!)

The bigger issue…

This one feature might be small (and in the lens of all the fixes we need, it really is tiny), but it’s part of a pattern. Figma’s core system infrastructure (the stuff that underpins serious design system work) still feels neglected. Variable management, component property surfacing and memory, library governance, publishing logic, token referencing… it’s all just wobbly and half-broken. Functional enough because we have no choice, but rarely solid enough to trust completely.

Designers and developers have been papering over those cracks for years. Building their own workarounds, patching gaps with plugins, writing documentation to make up for missing guardrails. Waiting patiently for inevitable fixes. For years.

Extended Collections fix one of the bigger paper cuts, but it also throws a spotlight on how many more still exist. And while Figma continues to chase high-gloss(/glass) features and AI headlines, the foundations remain awkward, inconsistent and unreliable.

AI doesn’t make those cracks less important. It makes them critical. Because if design systems are becoming the deterministic foundations needed to wrangle the stochastic AI into submission, the strength of those foundations determines whether automation accelerates quality or propagates slop.

The strategic risk

Other platforms are already paying attention. Penpot is quietly doubling down on design system fundamentals (native tokens, theme support for brand variants, shared libraries, dev-ready exports). It’s not chasing hype. It’s building the proper scaffolding to serve system designers in earnest.

And over in plugin-land, Tokens Studio is making its own play, evolving from the plugin that started it all into a genuine source-of-truth platform. The goal? To make design systems truly platform-agnostic, living beyond any single tool (even Figma).

Figma still has the lead, sure. But we’ve all been here before. We know how fickle the design industry can be when a new tool steps up and proves itself robust, time-saving and well-designed. So treating structural reliability as a luxury for the Enterprise tier is more than short-sighted. It’s an insult to the designers who’ve poured their support into making Figma the industry standard platform it is (right now). The credibility of the tool within the professional design community rests on its ability to support the reality of how modern teams actually work. All teams.

Extended Collections is a smart, long-overdue fix. But if it feels like a leap forward, that says more about the fragility surrounding it than the feature’s own merit.

—

P.S. While we’re here… can we talk about the name? “Extended Collections”? Really? It inherits. Feeds from. Branches out. Sub-collections. Child-collections. Can we just say what it does on the tin please? Maybe I’m the only one still hung up on semantics, but words matter, especially when you’re naming a feature about structure.

P.P.S. A shortlist of other “inevitable” fixes still missing: copy/paste variable values, move variables between collections, search/filter by collection, annotations on variables, computed variables (colour mixing, formulas, transforms), surfacing nested component properties, nested component properties that actually remember overrides, component colour props, letter-case and line-height % support, project duplication without breaking aliases… what else can you think of?

Extended Collections are here. And you can’t have them. was originally published in Design Systems Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Design systems ‘performance improvements’

A massive rewrite of the design systems architecture (the tech debt that’s likely been blocking progress and bug fixes in the DS realm). Right now this means 30–60% faster variable updates and mode switching (heavy state swaps dropped from 3500ms to 350ms), but more importantly it’s got to be the foundation for hopefully fixing all the other annoyances…eventually…right? Live “now” (they actually shipped something!).

Extended collections

Finally, a sensible way of handling themes with parent-child relationships and proper inheritance structure that removes grunt work. Shipping November 2025, but only for Enterprise (because of course). More on this here.

Slots, baby, slots

Add custom layers inside component instances without detaching. Too little, too late, buddy. Most design systems already have slot workarounds built in that they’re not keen to refactor. And since it’s still in early access with no launch date, teams building systems now will continue using the hacky workarounds, then probably won’t want to refactor again when this finally ships. Currently in early access (aka “soon™”, still no launch date, classic).

‘Check Designs’

Cool, you made a linter? But how do we make sure designers actually use it? There are already optional plugins for this. It’s neat, but it needs to be enforced (or at least give us the option to enforce it). Early access for org/enterprise plans (another “we’ll tell you when” situation).

Code Connect UI

A GUI for connecting Figma to GitHub where AI suggests which code files match your components so devs can see code in the inspect panel. But wait, don’t you already have code in your repo/Storybook/docs where devs actually work? Seems like a lot of setup overhead for a handoff problem that maybe doesn’t even exist? Rolling out now to org/enterprise.

Figma MCP

Brings Figma context into AI coding tools, you already know this, it’s been in beta for ages. The news? It’s now GA (general availability). Cool beans.

npm package imports + Make Kits (for Make)

Import your actual React components via npm packages directly into Make (this is what you actually want.) Don’t have an npm package yet? Make Kits will generate React/CSS from your Figma libraries as a backup. Make only gets context from the package itself though, no usage rules or guidelines… so wouldn’t Cursor/whatever (which gets your npm package AND design system context) still be the better choice? npm imports TBD, Make Kits in early access.. so who knows when?

Variables import/export (for realsies native)

Native import/export using the W3C DTCG 1.0 spec that just hit stable release. Finally aligning with community standards and ditching plugin workarounds. Concerning it took this long to add export, but better late than never. Shipping November 2025.

Variables authoring UX QoL

See all subscribed collections in the authoring modal, create variables inline, modal opens full-screen by default. Very slightly less painful variable authoring with less menu clicking. Coming to a Figma near you… November 2025. Ish.

More variable modes

Pro plans get 10 modes (up from 4), Org gets 20. Finally enough modes for your multi-theme, multi-brand, multi-everything, less hacky workarounds. Wonder if this required the code refactoring? Honestly, about time anyway. Available now.

tl;dr of the tl;dr

Figma is trying to make design systems work better (honest), multi-brand is slightly less painful, and some things are actually shipping in November. Slots? Don’t hold your breath. Early access for everything interesting.. and you can only apply for one.

Schema 2025 TLDR: The “We Promise We Didn’t Forget About Design Systems” Edition was originally published in Design Systems Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Guys, can we please stop calling everything a “comp analysis”?

Honestly, it’s starting to make us look like amateurs. We’re mangling terms, creating confusion and making it seem like we don’t actually know what we’re talking about.

The origins of “comp analysis” in business strategy

Competitive analysis originally comes from business strategy, introduced by pioneering early MBA programs. The method involves deeply evaluating:

• Market positions and share
• Pricing strategies
• Financial performance
• Marketing and promotional tactics
• Overall strategic positioning

It’s not about UX at all. It’s about assessing the full competitive landscape to inform high-level business decisions and overall company strategy.

The adoption into ‘UX competitive analysis’

As UX design became a recognised discipline, designers adopted the principles of competitive analysis but tailored them specifically to UX. UX competitive analysis evaluates how competitors, actual bonafide competitors, design their products, with a focus on:

• UI design
• User flows and interaction
• Functionality, features and products
• Information architecture
• Content design
• Accessibility
• All the other stuff

This rigorous process benchmarks your entire product offering against other players in your actual industry, breaking down exactly where you stack up in terms of usability, functionality and user satisfaction. You’ll clearly see what’s working, identify gaps or weaknesses and uncover specific ideas or opportunities. It also reveals exactly where you’re falling behind, getting ahead or diverging from industry norms. Essentially, it’s about determining exactly where your product stands and where it could go.

But here’s what most product designers are actually doing

When designers casually toss out a “comp analysis” in a case study or discovery wrap-up, they’re typically not doing true UX competitive analysis, let alone a strategic business competitive analysis.

Usually, they’re looking at specific design patterns, flows and interactions across different products. Sometimes these products are actual competitors, but oftentimes they’re totally unrelated products that have just solved similar problems, developed useful patterns or employed similar user journeys.

That’s not competitive analysis.

Introducing the Pattern Audit

So let’s clearly call this what it actually is: a pattern audit*.

A pattern audit involves:

• Studying design patterns: How are others solving similar UX problems?
• Evaluating user journeys: Identifying intuitive, frictionless or delightful interactions.
• Digging into the details: Are there any obvious wins or fails in the micro-copy or micro-interactions?
• Analysing interaction flows: What’s effective, what’s cumbersome?
• Cross-industry inspiration: Drawing on ideas from outside your industry bubble.

Why does this matter?

Language creates clarity. As designers, we’re supposed to be the communicators. Mislabeling this activity as “comp analysis” muddies expectations, confuses stakeholders and, frankly, undermines our credibility, making us look like we don’t know what we’re bloody blabbering on about.

So can we not?

Language fix-up cheat sheet:

• Doing a deep dive into your competitors’ full product offering and UX? Great, that’s UX competitive analysis.
• Evaluating the broader competitive landscape for strategic business insights (or readying up your investor pitch deck)? Perfect, that’s business competitive analysis.
• Reviewing design patterns across multiple products (including non-competitors) to inform UX decisions? That’s a pattern audit*.

Clear terms mean clear understanding. Let’s stop confusing ourselves and start communicating effectively.

My sanity thanks you.

*open to other suggestions. Also considered ‘pattern benchmarking’ but I feel like that suggests a more metric driven evaluation.

Product designers, can we please stop calling it “comp analysis”? was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.