Most design systems run on the opposite compliance-style model: Learn the tokens, the naming conventions, the review process, before you’re allowed to contribute — a credentialing system of its own, even when nobody says it out loud. Lauren LoPrete has spent her career inside that logic — leading design systems at Expedia, Dropbox, and Block’s Cash App, and now heading up Design Foundations (working across design systems, brand-in-product, and AI tooling) at Mercury. But a decade before any of that, she was running an independent record label with her husband, releasing vinyl and cassettes, and organizing punk shows.

Lauren sees that same do-it-yourself instinct — shrugging off credentials, just showing up — resurfacing right now in online spaces. “So many people are vibe-coding their own hobby projects,” she says. “There’s that early-internet vibe again — GeoCities, customizing your MySpace page — where you just spend a couple hours and make this cool little tool you like to tinker with. It’s very expressive; it shows your interests.”

Ahead of her talk at this year’s Converge design systems conference — an evolution of the one she gave at Config earlier this year — we spoke with Lauren about earning trust on a systems team, why she now sees people-pleasing as a design systems occupational hazard, and how she decides, day to day, when a system should hold the line and when it should let go.

Note: This conversation has been edited for length and clarity.

On finding the throughline

You had a different life and career before finding design systems. Was there a specific spark that inspired the move into design, or did it build up over time?

If I look in hindsight at everything that came before, there’s a theme around the work I choose and the way my brain works — I’m very much a pattern recognition slash systems thinker. Before I worked in tech, I worked in exhibition design, publishing, and branding. All of those things were design work you had to think about at a system scale — like how a visitor walks through a science museum, and all the visuals and graphics that play into that and build that story.

On contribution without an ivory tower

In your talk, you reference 924 Gilman as an example — an all-ages venue where one of the only rules was that you had to get up on stage, and you had to care. No credentials needed. How does that way of thinking help a systems team when it comes to contribution?

How I think about contribution in terms of 924 Gilman is more about mutual aid. Everyone has a voice. The systems team is not in an ivory tower.

I value all opinions from anyone using our system. I don’t think there are bad ideas shared that aren’t worth considering. It’s important to take that feedback as a signal; to find out if (and why) the system isn’t flexible enough, if something is unclear, or hard to use. There are many systems teams that choose that ivory tower mentality — we make the rules, you follow them — and that just breeds a system nobody wants to use.

On people-pleasing and finding an opinion

I really appreciate how you wrote about this in your Substack post titled ‘The biggest threat to your design system is your need to be liked’. What changed about how you actually make decisions now that you’re aware of that pattern?

I didn’t come to the people-pleasing realization naturally. I hit rock bottom with burnout and had to dig myself out. Through deep work on myself, I realized a lot of the negative behavior that was burning me out was attributed to people-pleasing.

This spans beyond work, but I noticed that in a design systems role, you’re this support person — your customer is your best friend/co-worker, or your co-worker/enemy. It’s really easy to get caught up in the opinions of everyone else. And when design systems lack opinions, what’s the point of even having one?

For me, that shift meant coming to a point where I have strong opinions, loosely held — enabling people to challenge that, while also being able to sort through challenges that are just people being upset versus real ones. 

There will always be people upset, or people who really like something, and you have to decide if you want to take the easy path and support the thing they like. Ultimately, we’re humans building systems for other humans, and the rigidity that comes with design systems is often not well-matched with the basic mental model of what it means to be a designer.

You’ve also written about figuring out your values and defined your personal core values as an individual. Is there an opportunity in sitting a team down and saying: We don’t have values, maybe we should define them?

Again, I was in a terrible state of burnout last year. I had to come to terms with why it was so hard to be there. It connects back to authenticity and who I am — even the punk ethos playing into that. I have this mentor in the back of my head who told me a long time ago: Don’t run from something, run to something. So I did the values exercise as a way to see what values stuck for me, and what I was looking for in another job.

I formed the team that was building out the system cross-functionally, and part of that effort was a values exercise. It was a half-day, in-person moment where we really talked about our values and then applied them to the way we operate — running through examples of how we support internal customers, so we could move from spiritual alignment to genuine belief.

On knowing when to hold the line

Thinking about day-to-day — when a certain pattern doesn’t exist, and someone says they need this specific component because their use case is special, but then you realize creating it might actually be a bad idea — how do you know when to take a stand and when to accommodate people?

Over time, I’ve realized design systems can get so hyper-focused on building the machinery and components that we over-index on that and forget about the end customer. So I go back to first principles: We’re actually designing for the end customer, and let’s make decisions based on that, not systems purity — though those often end up in service of the system anyway.

Sometimes you’ll meet a product designer who’s very deep in one vertical team, and they don’t think about the horizontal nature of the product — that a user experiences many features in one sitting. They’ll say, for my niche product need, I need this exception. And I’ll say: Our users upload documents in 15 different places across the UI. I understand your specific one is a very particular type of document, in a very particular flow. But users just want to remember how to upload a document, not relearn it every time. So sometimes it’s pushing toward the system, being more rigid.

But other times — we’re announcing a brand-new feature; we want it to feel very special, more immersive, push the brand forward — and it’s: yeah, break the system. Let’s go completely bespoke, because we want that step change for the end customer.

That sounds like what you’re describing with enforcement — forcing people into a way of working that isn’t naturally how they think or do things. Which can breed a lot of resentment.

There’s a really easy way to detach a component, which breaks it away from the main system. People on the systems team used to get so frustrated that people were detaching components. Engineers would often be like, oh my God, can you just tell designers to stop detaching components? 

That’s like telling a burlesque dancer she’s not allowed to wear sparkles. That’s just how designers work. The design process is messy and iterative. Please go wild. I don’t care if you don’t name your layers.

On seasons, craft, and where to spend your attention

You’ve talked about design systems moving through seasons — enforcement, enabling, embedding — and that the right season depends on a team’s maturity. How do you know when it’s the right time to go all-in on one particular phase?

I’ve been lucky to lead three major brand refreshes in product, and I’ve noticed this pattern — when you need to bring everyone together and rein in the system, versus when you can be expansive and push its boundaries.

At Cash App, there was essentially no system before I got there — everyone was copying and pasting, making their own decisions, and every page felt a little different. So the system was developed to bring consistency. We weren’t doing major visual updates, it was more like: Here’s the new header size, here’s the button hierarchy. That was a very intense enforcement moment. People didn’t love us, but we worked really hard to embed with teams and help them understand the value of getting on board.

Once everyone was closer to full adoption, we could pull a lot more visual levers — typography, color. But then you also have to release some control, because the system wasn’t designed to support every use case — it was designed to raise the quality bare minimum. So we’d say: If you don’t see something in the system, build it yourself. Then we’d watch what organically got built outside the system and figure out the standard from the best of what we saw.

At Mercury right now, the system never really had any opinions — it organically formed. I know there’ll be a redesign at some point, but right now it’s: You do you, and our team will find the patterns.

A former head of design systems once told me about a practice she called “design detention”, pairing designers and engineers to sit next to each other, work on the same thing, and turn to each other mid-process to share things like, “I’ve built this component, how are you going to use it?” Rather than working separately on their own screens. How does that look on your team?

Yeah, I think that’s huge. All of our design crits are now just cross-functional crits — all of our engineers are in our design crits. Engineers are able to ask questions from the very beginning to understand the design intent behind something. 

They’re also learning to expand their way of thinking — they know we’re not actually implementing this today, so they can zoom out and understand the core user problem first, and give feedback on that. As you get closer to fidelity, engineers’ questions evolve, and designers get more granular into the engineering details too.

In your talk, you also mention Factory Records [a Manchester-based British independent record label co-founded in 1978 by Tony Wilson and Alan Erasmus] as an example — they made die-cut record sleeves and had very uncompromising standards. What trade-offs do you make day to day in a systems role when you have high standards for craft?

It’s a daily thing you navigate. I think it’s kind of the locus of control — I can control the craft of my team more or less; I set the standard for my designers. When it comes to product teams overall, I index on value and velocity balanced with craft. 

Are we focused on raising the craft on the right experiences? Do I care if a settings page seven layers deep has legacy components on it? No. But if we’re releasing a new product, I want that to push the craft beyond what currently exists — my team will spend more time there.

We’re always balancing velocity and quality — we have dates to hit and engineering timelines to meet. Those are levers we pull to figure out where and how to push the craft to maximize it. But I’m very grateful to work at a company, and to have worked at companies, where design has the ability to block things from shipping if they don’t meet our craft standard.

On letting go of the weight

How is the environment different for design systems at a startup versus a larger corporation?

It’s hard to talk about in a vacuum, because so much has changed and so much is different that I can’t compare them one-to-one. But I basically went from a company ten times the size — Block was 12,000 people, Mercury is 1,200. I went from steering a team of about 60, with a pretty legacy design system (at Square), to a world where there wasn’t really a systems team, or even a clear definition of what the system was — just a set of components.

At Block, in this new AI-native way of building, people saw the system as slow, not up to standard with how we build products now — just a massive platform that couldn’t change quickly. So many teams were trying to blame us, or trying to go around us — we became a bit of a scapegoat. There were also other teams working on the agentic future of the company, and we weren’t necessarily in lockstep. I picked up all of that.

So when I went to Mercury, I thought, “All those challenges are now my responsibility.” Design systems and AI enablement, one team, one job. The system here is very nimble — yes, we have legacy code, but we can move so much faster, so much more frontier-oriented, because we’re establishing from zero in a lot of ways. 

So the way we position design systems here is: This is how we build for the future, how agents build. If you use the system, people and agents can build the highest-quality on-brand products together, quickly, instead of having to catch up.

It reminds me of what you’re saying about building for the future — because the future is something that doesn’t exist yet. So it’s open.

Something that’s been so liberating for me in this moment — I used to worry so much about tech debt. As a designer, I felt like Atlas [the Titan from Greek mythology who was condemned to hold up the sky] at times, carrying the weight of tech debt on my shoulders. 

I’ve just abandoned that thought completely. My team’s not responsible for tech debt. Is anyone responsible for tech debt anymore? Who cares? You can build. Anything’s possible. You can have a bunch of agents rebuild it overnight.

On taste as the new differentiator

Something you’ve talked about before is documentation and artifacts as a way of showing people the standard, rather than telling them how things should be. You’ve also said tastemaking attracts other tastemakers — people with similar standards to your own. How does that show up day to day, in the way you put together documentation, or the artifacts you create?

In a lot of ways. The way we announce new components or features has a certain level of rigor before it gets publicly shared. Typically that means I expect my designers to have a well-crafted animated GIF — a before and after — showing off the thing they’re releasing. That inspires other designers, because they might not even know how to make an animated GIF look like that. Every part of the release should be so considered that it makes them want to use the system, learn from us, and be part of something that makes them proud.

The other side of it is cultural. We have a design inspiration channel in Slack, and what I push my designers to do is not just share inspiration, but share why — show off some of the taste and conviction and judgment that goes into why you like something, and why you’re sharing it. That generates conversation, and it builds the kind of social equity that gets more people to see you as a visual design leader — a tastemaker.

On having the nerve to have an opinion

If you had to boil it down to one piece of advice — tastemaking can be scary, especially in larger environments, where it can feel risky to stand out. What might encourage someone to take that leap?

I think it starts outside of work. Get off the internet. Find things that you love. Find safe places to talk about why you love them, or why you dislike something, and build that voice and confidence. It doesn’t need to be in your day job, because there’s so much risk in politics and things like that at work.

Why do you love the dishware you selected? Why do you love a piece of art in a museum? Why do you love a record you just bought? Why do you hate the new foldable iPhone? Finding people to talk to about those things builds the confidence to then go into more challenging spaces, like work, to actually express those opinions.

Lauren unpacks and expands on that punk ethos and collaborative instinct — creating low barriers to entry, genuine listening, trusting that a system earns its way into adoption rather than mandates it — in her Converge 2026 talk on Design Systems Anarchy. Stay tuned for the video!

We consider adoption a success when we can point back to the codebase and see that a large percentage of the shipped components tie back to the system, and that designers aren’t detaching component symbols in their files. These are the signs of a healthy and mature system. We’ve built the product and documented what it is, so we shift our focus to governance and growing the system.

What we often overlook is arguably one of the most crucial parts of the system: the patterns that provide the context for when and where to use these components. Patterns are the bridge between the system and feature teams. They capture the work product designers have done while giving the system a point of view, thus making it unique. 

Why design system patterns get overlooked

It makes sense that patterns fall through the cracks. As system designers, we often don’t need to think about business cases, restrictions, or feature needs. We live in a world of best practices and technical correctness. We conduct in-depth research and precisely build things, then hand them over the fence to be implemented in the “real world.” 

For a while, that division of labor works fine. The pain of an undocumented pattern only shows up occasionally: for example, when onboarding a new designer to the company, or when the design system team gets stuck in the middle of a product manager and a product designer debating what counts as “part of the system” and what’s up for interpretation. 

It’s easy to think of these as one-offs rather than a gap in the system. But the things we leave unwritten create uncertainty and leave room for different interpretations of what the product provides and how it provides it. Documenting patterns helps explain why we’re building things the way we are. It preserves the context that led us to make the choices we see in the product UI. And it helps guide new teams when they face similar challenges in the future. 

By not capturing patterns, we accidentally throw our product design partners under the bus. They’re the ones left holding the reasoning nobody wrote down.

Now that AI is a consumer of design systems too, that gap is becoming more obvious.

Patterns give AI the context it needs

AI needs context to create with consistency. As a prediction machine, it doesn’t have the ability to understand what isn’t written down. We can package our tokens, components, rules, and guidelines all we want, but if we don’t also define clear patterns for agents to follow, they’ll make a new guess every time. 

In an environment where building has become faster and cheaper, we need to make sure we’re still creating cohesive products. If we tell our AI to design us a screen for doctors that lists patient details in a panel, we need to provide the existing rules around our approved features, or the AI will drift from our product reality. This can quickly turn into a death-by-a-thousand-cuts situation, where our product no longer feels like ours. 

The AI can reproduce something that looks like an approved design but if we look closer, we’ll see that details are off: tag radii are different from the system, toggles are missing control indicators, fields are in the wrong order with the wrong labels, etc. If we hand these incorrect designs off to developers who build them into the product, we create design and technical drift that degrades the product over time.

Get closer to the people building the product

Design system teams now have a real opportunity to change our perspective from enforcing the system with a policing mindset to partnering closely with our product design counterparts. Let’s take the time to understand why they’re making the decisions they’re making. How does our system support or limit those decisions? Knowing these answers will make their jobs easier, strengthen our work, and improve the product. 

Here’s an example: Imagine you have two components — a checkbox and a checkbox tile. The checkbox has its selector control on the left, and the checkbox tile has it on the right. Individually, these choices make sense, and we can write rules that tell designers not to put them on the same page, because the different control positions can look inconsistent or cause confusion.

But then you get into a situation where there’s already a checkbox on the page due to previous decisions that can’t be changed right now, and the tile is genuinely the correct choice for the designer to make — what do you do with that?

That’s a real problem your coworkers are actually trying to solve. It’s an actual challenge for the system team to look at.

Where the real work begins

So, as we identify and understand the patterns that already exist, and start working with the people who understand why things are being built the way they are, we can take our two disciplines — system and product designers — and really complement each other. We can elevate each other’s craft.

The system might say: We don’t have disabled buttons. We use progressive disclosure, and we use in-field errors to indicate when something is wrong because, for our users and clients, we feel disabled buttons aren’t ideal.

Or the system might say: Buttons stay disabled until the user completes the required fields, because the tools we’re using are really high impact. We don’t want users to make an error, so it’s better to disable the button given the tasks they’re trying to achieve.

Either way, we’ve landed on a strong opinion based on the business and user needs our product is trying to solve.

How to start capturing your own patterns

Join in on some of your product designers’ dailies, or their cross-functional critiques, to understand the real constraints they’re dealing with. See how your design system supports them, or where it doesn’t. Notice the things you thought were obvious but were never written down, so nobody flagged them or fully understood them.

Ask your designers if you can partner closely with them on a feature they have coming up — not to tell them what to do, but to take what they do, capture it, and codify it. That way, their work has a longer shelf life and doesn’t accidentally get forgotten about or undone somewhere because an AI prototype did the opposite.

Turn pain points into patterns

What’s the biggest pain point you keep running into? Is it data tables? Do you have a very data-table-rich product where sorting behaves differently from screen to screen, filtering works one way here and another way there, and quick actions are inconsistent? 

Or maybe you’re at a B2C company, and there are a lot of AI chatbots now? What does your AI look like? How does communicating with users look, both visually and functionally? Where do the chats pop up?

Whatever it is, pick the biggest one, the one you keep seeing designed differently, or where existing patterns unintentionally contradict each other, and capture it all. Define when to use each pattern, document it clearly, and show people how disconnected things actually are right now.

Get buy-in, then document it

Then make your best pitch of what you, as a system designer, think should be done — based on your knowledge, your skill set, your best practices, and everything you know inherently from working so closely inside the system.

Next, run it by your design team. See what they say. See what the product designers say, what the product managers say, and what the product owners say. Once you get buy-in and everyone’s aligned, document it, circulate it, and turn it into a skill so your AI can know it moving forward.

Become the ally, not the gatekeeper

Start becoming the ally who helps support your product designers. Remember that a design system team’s first user is its product designers. Our job is to make our coworkers’ jobs easier, and in this rapidly changing world of AI, that’s never been more important. 

Capturing patterns helps solidify the work that product designers do every day, enabling cross-functional teams and AI tools to truly understand how all the pieces fit together. 

So, which pattern feels most important for your design system to capture? 

Nikki is delivering a talk about this topic at Converge, zeroheight’s design systems conference, this week, on October 22, 2026. Stay tuned for the video!

Most documentation was written for people. People skim, infer, ask whoever sits next to them, and fill the gaps with whatever they remember from the last project. An agent does almost none of that (it does the inferring bit, which is part of the problem). It reads what’s on the page and works from there, a bit like a very literal new starter on their first day who has never met anyone on the team.

So we built a tool that lets you watch that new starter try. It’s called DS ARC, the Design System Agent Readiness Checker, and it’s free at zeroheight.com/arc. This post covers why we built it, what it does, and the slightly ridiculous amount of testing it took to make it something you could trust.

Why did we build it?

The honest answer is that we had a problem of our own. It’s hard for a team to see the value of an MCP server when their docs aren’t in good shape, and getting docs into good shape takes real effort. If you can’t see how far off you are and you can’t picture what good looks like, that effort looks enormous and never makes it onto a roadmap.

The obvious fix was a framework, a document that sets out what agent-ready docs look like (there was even talk of one internally). I think a framework like that would be perfectly fine, and almost nobody would read it. DS ARC is something that happens to your docs, with transcripts you can forward to whoever controls the purse strings, and that’s a much harder thing to ignore.

What does DS ARC actually do?

You point it at your docs and press Run. A few minutes later (most of that is the agent doing its thing) you get a report. In between, four things happen…

1. It reads up to 40 pages. We choose them rather than crawling in order: index pages, tokens and foundations first, then a couple of components from each of seven families (actions, selection, text input, overlays, feedback, navigation and data). For each component it picks, it also reads up to three sub-pages, because a lot of systems keep the real detail on a Code or Usage tab. Pages are fetched the way an agent fetches them, with plain HTTP and no browser, so a page that only renders with JavaScript comes back empty. That’s annoying, but it’s also what an agent would see.
2. It scores those pages against 12 machine-readability guidelines drawn from the Design System Documentation Spec. Whether a component’s API and your token values exist as data rather than as pictures carries the most weight. Others look at things like whether rules say how strong they are and whether invalid combinations are written down. There’s no AI model in this part, so the same pages always get the same score.
3. It writes eight questions tailored to your system, emulating the kind of thing a developer or designer would ask an agent. Which component fits this need? When should I use this one instead of that one? What’s the exact token for error text? What props does this take, with types and defaults? What keyboard interactions does it support? One of them is a trap. It asks about a non-existent component, and we want it to say that the component doesn’t exist.
4. It hands those questions to a real agent (Claude Sonnet 4.5) with two tools, search the docs and read a page, and no web access. It gets eight tool calls per job, then it has to answer with a link to where it found the answer or say it isn’t documented. Anything with a single right answer gets asked up to five times, because a different answer each time is a problem in its own right.

When a job goes wrong, it lands in one of three buckets: a gap (the answer isn’t there), ambiguity (the same question gets different answers), or hallucination risk (the agent answers but can’t point to a page that exists). None of those need us to know the ‘right’ answer for your system, which is what makes it possible to run this against any docs at all.

The report leads with three numbers: how many pages we read, your machine-readability score, and how many of the eight jobs passed. Below is every job and what we asked, plus your single worst failure in full, with a transcript included. Behind an email gate, you get the rest of the failing transcripts, what each guideline was missing, and fixes you can make to your docs. The report link lasts 14 days, and if you fix things and come back, the report shows your score history.

How we built it

I started with the questions rather than the tool, because the question set (we call it the battery) is the bit that makes or breaks the whole thing. Generic questions produce generic results, and a weak battery makes a tool like this look like a gimmick.

Two rules went in on day one. First, there’s no judge model. Every score is a check that code can do on its own: does the cited URL exist, did five runs give the same answer, did the agent refuse the trap. If something needs an opinion about ‘quality’, it doesn’t get scored. Second, the agent runs at default temperature. It would be easy to pin it down so the results look stable, but nobody’s agent runs that way in real life, and variance is something you’d want to know about.

Training the battery

To be clear, we didn’t train or fine-tune a model. What we trained was the test.

In early September I set up an unattended loop against four public design systems: Salesforce Lightning, Uber Base, Shopify Polaris and eBay Playbook. Each cycle, a model tailored the eight questions to each system, the agent ran them, and code assessed the results. When something failed, the loop pinged me and kicked off an agent with the findings so it could fix the battery, then went round again, up to ten times or until every system passed.

Every fix was logged in a decision log in the repo, with the reason for it. The rule for the log is to read it before changing the battery, and any change that contradicts an entry must explicitly supersede it rather than override it. That mattered more than I expected, because without it the fixes started undoing each other within a day. By launch, the log had 165 entries, and the battery was on version 112, which gets stamped on every report alongside the model and the spec version.

We left this running for just shy of 1000 runs. A few things came out of it that I didn’t expect:

• Short-answer jobs are effectively deterministic. Asked for a component name, a token name, or about a component that doesn’t exist, the agent gave identical answers across every system and every cycle.
• Prose answers vary in what they say, not just how they say it, with 28 to 61% word overlap between runs of the same question.
• Three of the four systems couldn’t answer a props question at all, each for a different structural reason.
• All four refused invented components, 20 runs out of 20.
• On one occasion, an identical prompt against identical docs returned a full answer and then, on the next run, ‘not documented’, even though the agent had read the page holding the answer.

The most useful lesson was about the model writing the questions. Every time we added a guardrail, it found the next hole along. Stop it making the props question a trap, and it would ask about the props of an invented ‘Kanban board’ component instead. Require keyboard evidence to name a key, and it quoted a list of icon names, because ‘arrow-up’ contains a key. Close that, and it discovered that ‘enter’ is both a verb and a key. The conclusion I came to is that model-written prompts need a closed set of legal shapes that fails closed. A list of banned shapes just keeps growing.

Turning a test harness into a tool

The loop was a scrappy local app. Then it was time to turn it into a full-blown public app.

There are five ways in, and they all turn into the same bundle of pages, so the battery only ever sees one thing and adding a source is just adding an adapter. The two that touch private docs got the most care. Signing in with zeroheight uses read-only scopes, and the token is held for the length of one crawl and then cleared, whether the crawl worked or not. For private GitHub repos we built a GitHub App rather than a classic OAuth app, because classic OAuth can’t do ‘read-only’ for private repos. The only scope that reads them can also write to every one of them, and a promise that we’d only ever read was really important in building this.

The big thing we wanted to do was bring down the cost of each individual run, as we’re covering that burden. From testing to production, we managed to cut the cost by 400%. There are limits so it can’t run away with us (three checks a day per person, eight a day per docs site, and a daily ceiling across everything), the email gate is enforced on the server so locked content never reaches your browser, and crawled docs and transcripts are deleted after 14 days.

What happens when the tool grades itself?

The part of the build I’m proudest of is also the most uncomfortable one. More than once, a metric turned out to be measuring our harness rather than the docs in front of it.

The biggest was a guideline about whether content could be read by a machine at all. It looked fair until we checked where the pages had come from. Every Base and Lightning page had arrived through zeroheight’s documentation API as clean, structured text, and every eBay and Polaris page had come from scraped HTML. So the guideline was comparing our own API’s output with other folks’ raw markup, and it rewarded the two systems hosted on zeroheight. A benchmark published by zeroheight can’t ship with that in it, so it came out. How we reached your content is now reported as context (which route we used, and what we couldn’t test, like an MCP server) and never scored. Taking it out flipped the bottom two systems in our test set, which tells you how much it had been skewing things.

A few others:

• Early reports cited spec clauses like ‘component.api’ that don’t exist. They’d been written from a memory of the spec’s shape rather than the spec itself. We pulled every citation, rebuilt the audit against the real schema (v0.20.0), and later turned it into the 12 guidelines, because the spec is an authoring format that not many people have authored their docs in yet.
• The root URL you paste turned out to matter more than your docs. Submitting Polaris’s components page discovered two pages, which would have graded a very large design system on two pages. So there’s now a free pre-check that shows what would be read before anything is spent, and refuses a source that’s too thin to test.
• A bit of regex was treating a bolded link (trailing asterisks and all) as a made-up URL. Fixing it moved one test report from a 60% grade to an 80% grade, with the underlying findings byte-for-byte identical, which is a good reminder that a grade can be wrong for very boring reasons.

Every one of these turned up from opening a real report and reading the transcripts behind it. If you’re building anything that grades other people’s work with an LLM somewhere in the loop, that’s something to keep in mind.

Testing it with real teams

Before launch, we put a test build in front of practitioners from a bunch of big and small companies with mature design systems. Between them, they covered every way in: public URLs, Markdown uploads, GitHub, Storybook and the zeroheight connection.

We asked each of them to do one thing before they started: write down a guess. A number out of ten, or a one-line gut feeling about how agent-ready they thought their docs were. It only works if it’s written down before you see a score, and it meant we could ask the question we cared about afterward: did the result match your gut, and which one do you trust more?

Real docs broke things our four test systems never had. Just Eat’s first runs failed on both the public site and GitHub. Because every run is logged, I could see exactly why and fix it while the test was still going, and it’s also why we now review failed runs every day rather than waiting for people to report them (most folks will just leave). A good chunk of the decision log from late September came from real systems like this:

• Some systems keep a component’s substance on Web, Code or Usage sub-pages behind a thin overview, so the sampler now follows those sub-pages instead of reading a pile of landing pages.
• Sites built with web components ship their content inside declarative shadow DOM, which the parser now unwraps.
• A Storybook your docs link to is now read for the sampled components, and the report says which facts came from it, because an agent connected to your docs can’t follow that link.
• A system whose components were called Navigation and Popover (rather than Menu or Dialog) used to fail the keyboard question outright. It now falls back properly and reports the actual finding: the docs said ‘keyboard accessible’ everywhere and never once specified which key does what.
• If one or two questions can’t be written for your docs, we now skip them and say so, instead of stopping the whole run.

The other big change came with the grade we initially gave everyone. We started with an F to A grading, but borderline systems could flip between a B and a C on a rerun purely from agent variance, and a letter is exactly the kind of thing people screenshot. So the letter moved off the top of the report, and the three numbers replaced it. The report also moved to plain language, with the technical detail tucked behind a ‘see more’, and it says up front that small movements between runs are noise.

What it can’t tell you

I’d rather you hear the limits from us than find them in someone’s screenshot.

• It reads a sample of up to 40 pages, not your whole system. Which components get sampled changes the answers, so treat a job result as being about that component rather than about everything.
• Scores wobble a bit between runs, because the questions are rewritten each time and the agent isn’t pinned down. A few points of movement is noise. A change in the number of jobs passed is worth paying attention to.
• If your site only renders with JavaScript, we see an empty shell (so does any agent crawling it). We try an crawl it the best we can, but it doesn’t always work. Point us at your Storybook, your repo, or an upload instead.
• We can’t see your MCP server, llms.txt, or internal API unless it’s the route you gave us, so the report tells you what we couldn’t test rather than marking you down for it.
• Hidden text in a set of docs could, in theory, steer the agent and flatter a score. It can’t reach anything outside the pages we read, but it’s a limit we’ve accepted and written down.

It’s also worth noting that a good result doesn’t mean your docs are good for people. DS ARC records what happened when an agent tried to use them, and that’s all it claims to do. In saying that, the whole ethos of the design system documentation spec, which we based it all on, is that machine-readable and human-readable docs should be the same thing. So it should still be good docs for everyone.

Try it, but write your guess down first

DS ARC is free at zeroheight.com/arc. It takes about five minutes, and you’ll only need a work email if you want the full set of transcripts and fixes.

If you do run it, do what we asked our testers to do and write down your guess before you press Run. Then tell me which one you ended up trusting more, the score or your gut. Get in touch with us on Bluesky or tag us on LinkedIn to let us know!

MCPs have made it possible for an agent to inspect the anatomy and variants of a new component in Figma, then generate useful documentation in Markdown. We can now build automated processes that check designs against documentation standards, identify gaps and even suggest improvements.

However, one last manual step usually remains at the end: getting the output into your design system tools.

When documentation needs a large, repetitive update, like a naming convention change or a set of component pages needing to follow a new template, we face a similar challenge. Although the work is straightforward, applying it consistently across a styleguide is a manual drudge, and our automation tools are unable to make changes directly.

The missing link is an MCP that can both read and write back to the styleguide.

What MCP-Write makes possible

Until now, MCP has enabled tools and agents to retrieve design system context from zeroheight. AI could consume your documentation to understand your standards, then use your context in the apps that Designers and Engineers work in. MCP-Write builds on this by adding the ability to create and edit styleguide page content directly via MCP.

This means that for styleguide maintenance, an authorised AI tool connected via MCP and a user signed into the app now have read and write parity. Like a signed in user, AI can now create and edit the pages used to document components, patterns, foundations and code.

For styleguide maintenance, MCP-Write directly mirrors existing zeroheight permissions: if you can do it in the app, you can do it via MCP. New pages and edits are created as drafts first; this adds a layer of governance as nothing gets published before you’ve had an opportunity to review and approve. That said, merging can also take place via MCP-Write, so bulk automations that don’t require manual reviews are not blocked.

The scope is focused on styleguide content. MCP-Write cannot currently create new styleguides, change settings, manage tokens, create releases, add new Figma or Storybook files, and so on. Its initial focus is to give AI tools and agents a way to work with the documentation inside an existing zeroheight styleguide.

This update opens up two new types of workflow: agentic processes that can maintain documentation and keep it current over time, and high-impact tasks that make occasional but manual documentation work much faster.

Let’s go through some real-world examples that harness MCP-Write to make design system documentation maintenance more efficient.

Agentic workflows

Documentation maintenance invariably involves regular, recurring tasks such as keeping change logs current, component page updates and accessibility audits. Many of these tasks can be delegated in part (or sometimes fully) to agentic workflows that are able to write back to the styleguide.

Turn design-system decisions into documentation

In an organisation that holds a weekly design system review, designers, engineers and product stakeholders bring new challenges and updates for discussion. The meeting is recorded, creating a useful backlog of changes that need to make their way into the styleguide.

An agent can read the meeting notes, identify the documentation changes that follow from those decisions and draft the relevant updates to zeroheight. It might propose new component pages, update guidance, revise an existing pattern or change a token value.

Before MCP-Write, the agent could identify and describe the required changes, but someone would still need to translate them into zeroheight manually. With MCP-Write, the same workflow can write those proposed changes into the styleguide as drafts, ready for the team to review and merge.

Keep component pages aligned with source-system changes

A designer makes a change to a component in Figma. A dedicated watcher agent detects the change and automatically reflects it in the corresponding component page in zeroheight. The relationship is one-to-one: one source component, one corresponding documentation page.

Once configured, the workflow can respond to changes without someone having to initiate each update manually (Using something like Claude Scheduling). This is different from generating new documentation: the documentation already exists; the agent’s job is to keep it aligned with the source system as the design evolves.

The same pattern could apply to changes originating in Storybook, a code repository or another system connected to the documentation workflow that has an MCP or a webhook.

Audit and fix documentation gaps

Documentation quality can also be checked systematically, with minimal effort from design system owners.

An agent can routinely inspect a styleguide against a set of rules or an established page template. It might check that every component page includes Do/Don’t rules, a complete properties table, accessibility guidance or that the required tabs and blocks types have been used. If the agent identifies missing or inconsistent content, it can apply the appropriate fixes directly, saving valuable Designer time.

This type of agentic quality-control loop offers high return on investment: once set up, it helps design system teams keep a styleguide consistent as it grows with minimal maintenance.

Maintain localised documentation

For teams working across languages, MCP-Write can also support localisation workflows.

When the primary version of a page changes, an localisation agent can identify the corresponding translated pages and update them in the other language, while preserving the structure and tone of the styleguide.

That completely automates the localisation part of the documentation workflow and replaces a separate manual exercise whenever the source page changes.

High-impact tasks

Many useful agentic automations run continuously or on a schedule, but sometimes the most valuable ones come from making a substantial one-off task much easier.

If you don’t want to review and manually publish every single change made by the agent, you can ask it to automatically merge any drafts it creates. If you decide to do this, make sure to run some tests on a subset of your data to make sure you’re happy with the output before making bulk changes.

Migrate documentation into zeroheight

Whether your documentation was kept in Figma, Confluence or Markdown files stored in your repo, moving from another design documentation approach almost always involves a large amount of repetitive, manual setup.

Whatever the format, an agent can help transform existing material into zeroheight’s page and block structure, using an existing page as a reference and creating a consistent starting point for the new styleguide. This is a one-off workflow, but it can significantly reduce the effort required to get a new styleguide up and running from potentially weeks down to less than a day.

Apply a bulk documentation update

Some changes are known in advance and need to be applied across many pages. For example, a team might change its component naming convention or migrate designs to a new Figma file, meaning Figma embed references need to be repointed.

An agent can find the relevant content in the styleguide and apply the update consistently through a single focused prompt, rather than requiring a designer to open and edit every page manually. MCP-Write makes this type of high-impact, one-off bulk updates possible.

Update zeroheight from the tool where work happens

MCP-Write can also remove context switching from smaller, occasional tasks, by letting you make changes and updates to your styleguide without having to sign into the zeroheight app.

A designer working in Figma could ask the Figma Agent (which is connected to the zeroheight MCP) to update the relevant component page in the styleguide. A frontend engineer building out a component could use GitHub Copilot to retrieve component documentation in context, then add an entry to the styleguide’s documentation change request log without leaving their editor.

MCP-Write lets the user make the styleguide update from the app they are already working in. They no longer need to leave that context, open zeroheight and manually transfer the information. While these scenarios may not happen every single day, they remove the little points of friction that when combined over time, cause documentation to fall behind.

Get started with MCP-Write

The addition of MCP-Write to zeroheight means you can implement any of the examples above on your own design system. We’ve also built a pre-packaged agent skill to get you started immediately for a use case that’s helpful to many teams: monitor changes to components in Figma and code, identify documentation gaps and inconsistencies, then automatically create or update pages in zeroheight using your team’s preferred structure, ready for review.

This example lets you start with a common repeatable process that keeps documentation closer to your designs and code.

To try MCP-Write:

1. Choose a specific workflow or high-friction task to automate.
2. Connect the zeroheight MCP to your AI tool using MCP via Login.
3. Connect the source systems required by your use case (e.g. Figma, Storybook, etc.)
4. Provide any additional guidance or items required, e.g. templates.
5. Use a pre-packaged skill or create your own prompt.
6. Review the resulting draft in zeroheight and merge when it meets your requirements
   Note: for bulk repetitive task automations, you can ask the agent to merge for you once you have tested it on a subset of your data.
7. Refine the instructions and expand the workflow when it is reliable.

You don’t need to automate your entire documentation process on day one. Experiment with a single useful workflow to learn how MCP-Write can save time and improve consistency, the build from there.

What changes when AI can write to your design system?

MCP-Write extends design-system context beyond something AI tools can consume. It gives design system teams a way to connect documentation to the workflows that create and maintain it. Tasks like generating new component pages, keeping existing pages aligned with Figma, checking a styleguide for gaps and applying bulk updates across hundreds of pages can now all be done through agentic workflows.

Some workflows will run continuously while others will be occasional, focused tasks. In both cases, AI can now move documentation work forward inside zeroheight, which is a huge step change over simply consuming documentation to generate recommendations or content to be added to the styleguide by hand.

Explore some MCP use cases or check out the docs to get started.

This is why, when I took on a new role to lead and renew a legacy design system, I didn’t start with its technical or design debt. I started with its community.

Its trust debt.

I spoke with different teams, design and engineering leads, and stakeholders throughout the organization to learn how they used the system, and to what extent, if at all. Some products had pinned themselves to years-old versions and refused to update. Others had copied components into their local codebase and bypassed the system entirely. Still others had removed the dependency altogether and recreated the components locally. Approximately, of course.

At the center of this drift was a lack of trust in the system, and specifically, its releases. So if we were going to renew the design system and its community, we had to start there.

Releasing chaos into a void

To better understand where the communal distrust was coming from, I scrolled back through the history of our “Releases” channel in Slack. After only two flicks of the mouse wheel, I got it.

At that time, the system was a single, monolithic package on v89, and Slack showed a flurry of chaotic releases with no changelogs or migration guides. It was impossible for teams to keep up, and with documentation that was little more than an empty Storybook instance, there was little support even if they did manage to do so.

Next, I turned my attention internally to our team. I found no deprecation policy. No governance oversight. One person from one team could make a request, which then became the new top priority, and even if it resulted in a breaking change, we released it as soon as possible. 

The idea was that if the design system served a team as quickly as possible, that would create trust. But the same way that you can’t trust a raging bull, you can’t trust a system that’s just as chaotic and unpredictable. By attempting to build trust with one team at a time, we’d break it with the others until there were no bridges left to burn.

I didn’t blame the community for the drift. I understood it. And if we were ever going to stop the bleeding and rebuild those bridges, we needed to shift from frantic, chaotic releases to a more predictable and reliable way of working.

Predictable release cycles

In Josh Clark’s article “Ship Faster by Building Design Systems Slower,” he goes deep into managing different pace layers within design systems. We weren’t helping anybody by churning out chaotic, short-sighted releases. To enable other teams to ship faster, our team needed to slow down and redefine our releases.

We identified our three release categories, then defined each.

1. Hotfix
2. Minor & Patch
3. Major

While our primary focus was on the major releases, we needed structure at each level.

Hotfix releases

The severity of the request and the visibility of the end product determined whether a hotfix release was warranted. For example, if a layering bug on our flagship, customer-facing application prevented its login form from being submitted, it needed to be fixed. Immediately. Release cycles be damned.

Thankfully, most requests were less urgent, so we bumped them into the next tier.

Minor and patch releases

Most requests were general fixes, improvements, or features that we lumped into a minor or patch release. We decided to release these versions at the end of every sprint. However, this did require us to update our sprints to run from Wednesday to Wednesday, so that every second Tuesday around lunchtime, we’d publish that sprint’s release.

At the start of each sprint, we created the new release branch. We merged all of our work into it, which automated the release of an updated canary version, providing teams with the latest work at the potential expense of stability. This allowed teams working on a faster layer to adopt the latest changes without waiting until the end of the sprint.

In practice, the benefits of this change far outweighed the change itself.

Sprints now had a purpose. As we applied a level of governance to requests, we began planning, prioritizing, and refining releases, not sprints. And for the community, we now had a predictable release cadence to plan around.

You build trust by showing up when you say you will and doing what you say you will. And when we released at the end of every sprint with documentation, changelogs, and links to Jira tickets, that’s exactly what we did.

Major releases

To truly rebuild trust within the community, minimize drift, and begin migrating away from ancient, pinned versions, we needed to overhaul how we handled breaking changes. 

That meant taking ownership of the design system, its roadmaps, and its vision. We decided to move to an annual major release cycle, breaking each cycle into phases for planning, developing, testing, documenting, and releasing. This gave us a clear structure to keep the work focused and on track.

Planning and scoping a release

Before jumping straight into work, we needed clarity on what to build. We planned each release with internal and external sessions aligned with our overall design system roadmap.

We began with the external session with the design, development, and team leads of core products (shoutout to Sophia Levens for the inspiration from my short time at SAP). It opened with an icebreaker in which each person rated their own product’s level of design system adoption, which doubled as a really rough (and overly optimistic) baseline for us to communicate to stakeholders and measure over time.

Then we asked the teams to identify their upcoming needs in buckets of “Immediate (1-3 Months),” “Soon (3-6 Months),” and “Eventually (6-12 Months).” This gave us visibility into shared short- and long-term needs and helped us plan specific features, even if they stretched across multiple buckets.

After that, everybody took notes on what they thought was working well in the current system, what wasn’t working, and their wildest ideas for improvement. Again, it provided an open space to discuss specific issues and ideas for the system from multiple teams’ perspectives at once, as well as identify anything we should keep as-is, or at least have strong reasoning before replacing.

Lastly, with all the notes in place, everybody voted on them, using a set number of votes to create a general, high-level consensus of the overall needs across products.

Turning feedback into a release roadmap

From there, we had a fairly clear list of short- and long-term needs and preferences from the community. We then brought all of that into our internal planning session, where we merged the feedback with our own goals and backlog for the release. We prioritized specific areas, merged others, and bumped the remaining ones out of the release window. 

By the end, we had a Jira release with epics defined, each with an ‘owner’ to serve as the point of contact, and a structured release roadmap in Markdown with links to epics to share. We also added an asterisk next to every note that came directly from the community to highlight its impact on our work and ensure they understood they had some control over the system and, in turn, their own work as well.

We made the release roadmap our most visible asset by pinning it in the Releases and General channels in Slack, publishing it in our documentation, and reviewing it in our monthly info sessions.

Building a release

Just as we did for our minor and patch releases, at the start of each major version release cycle we created a release branch and automated every merge into it to publish an updated release candidate version, along with a separate Figma release project to keep the current UI library clean of ongoing work. This allowed us to more easily review across design and development, record demos for the monthly info sessions, and trial the changes ourselves.

This phase is also where we implemented our new deprecation policy. Instead of creating tiers of deprecation severities, we went with a single, blanket policy. Deprecations would remain for two major versions before being removed. So anything deprecated in v1 would be removed in v3. Having a clear policy made deprecating not only easier for us but also less chaotic for the community.

As work progressed, we documented breaking changes and their migrations as basic bullet points in a Markdown file. We weren’t yet worried about writing comprehensive migration guides or code mods. Then, in our monthly info sessions and bi-weekly office hours, we previewed upcoming breaking changes and demoed ongoing work. All the materials were available afterward in our dedicated Info Sessions channel.

This phase of the release is the bulk of the work, and with a clearly defined roadmap, ownership of epics, and community engagement, it flies by before you know it. Trust me.

Testing, documenting, and iterating a release

This is when the release became real. With our release candidate versions generally stable, we shared them with core contributor teams to install, migrate, and test. At times, we did this through pairing sessions so we could experience any issues (or successes) firsthand. The process served as a direct line of collaboration, building trust in the upcoming release, while giving products working on a faster layer earlier access to critical features.

We also relied on zeroheight and Storybook to present multiple versions of documentation. This was a common theme for teams that didn’t trust the system, so by supporting the latest version and two previous versions of documentation, similar to our deprecation policy, we didn’t abandon teams if they weren’t always up to date.

Once we’d tightened the release candidates, we were ready to release.

Releasing a release

Using the info sessions as our primary form of communication, we announced release windows for the next version throughout the year and gradually tightened them until they became specific dates. The goal was to give the community as much lead time as possible heading into a major version change.

And when that day came, we released.

For the next month, we didn’t plan. We reacted. We lived in the support channels and updated our office hours from bi-weekly to weekly to give the community more opportunities for hands-on pairing. Our only priority was to get as many people migrated as possible.

And once we did, we took a breath, celebrated, and started all over again.

Breaking the cycle

It’s safe to assume that when I joined, the system didn’t have any adoption or usage metrics or survey results for us to properly measure as we moved from v89 to v1, so the results here are anecdotal and far more vibes-based.

But the vibes were good. I swear.

In the months leading up to and following the release, activity in our Slack channels picked up. Questions like “When will this be fixed?” became “Will this be fixed in next week’s release?” — my favorite shift because it shows a growing predictability and reliance on our minor and patch releases. Meanwhile, average attendance at our monthly info sessions and office hours slowly increased, as did interest from teams wanting early access to the release candidate for the next release.

As a team, we had found a better balance between reactive and proactive work, which improved morale after the grind of constant, thankless bug duty. Having a clear plan and roadmap for the design system allowed us to work backward by defining one release at a time. It allowed us to govern requests more clearly, prioritize work, and move in a unified direction.

There was still work to do

But the release cycles didn’t immediately fix everything. Some teams didn’t trust that the renewed approach would stick. Others, with old pinned versions, still couldn’t easily migrate, even when they showed renewed interest in doing so. Without more advanced AI migration agents and skills, these products likely wouldn’t update without loads of painful, manual refactoring.

Our work became predictable. Reliable. Steady. Collaborative. Release cycles let us refactor not only design and technical debt, but also the trust debt within the community. Slow and steady. Over and over. One release cycle at a time.

The greatest design systems aren’t always the most technically advanced ones. They’re the systems that people use. The systems that people trust. The systems that enable people to move fast and experiment with slow, stable predictability.

Daniel is speaking about rebuilding trust in legacy design systems at Converge, zeroheight’s design systems conference, on October 22, 2026.

Recent pieces from Anna E. Cook and Eric Bailey on this blog both cover accessibility gaps between design systems and the products they support. Anna’s article looks at what happens when a base system is extended into a product system, and the accessibility guidance doesn’t carry over. Eric’s article looks at the limits of what a design system can guarantee on its own.  

There’s another point, after both of those moments, where accessibility intent can get lost: during real product work, where small changes stack up. Teams adapt components, and their behavior slowly changes in ways the design system never planned for. The resulting drift is one place where accessibility issues can emerge, even when the design system itself is solid.  

This article explores why that happens and uses a real component example to make that drift visible.  

What happens after the design system? 

Design systems do a lot of good work for accessibility. We add the right rules, test the components, and things pass. But once those components leave the system and land with real product teams, they start to change.  

People adapt them, mix them, fork them, or fix them under pressure. Automated tests still say everything is fine. Even a manual review might say everything is fine. But the behavior has already drifted away from what the design system planned. 

I use the word “drift” to describe how a component’s behavior shifts away from its original intent as teams adapt it during real product work.

The first signs of drift 

A design system sets the rules for how components should work, and it defines the accessibility intent behind those rules. It shows teams the right patterns, the right behavior, and the right way to use each component. It also gives clear tips from design, engineering, UX, and accessibility so people can build with confidence. 

What a design system can’t do is control how teams adapt components in real products. It doesn’t control how people combine them, fork them, wrap them, or hotfix them. It also doesn’t control the choices teams make when deadlines are tight and compromises feel harmless. 

This is the moment drift begins. A team needs something slightly different from what the system offers and assumes the system has already handled accessibility. They make a small change to solve a local problem. They don’t check how that change affects the original behavior. By the time the product ships, the component can behave in ways the design system never planned for. 

Some organizations introduce additional layers of components between their core design system and the final product. These layers can help teams adapt shared components to their needs, but they don’t necessarily protect accessibility intent. By the time a component reaches another layer, teams may already have changed its behavior during product development. Without a deliberate check, those changes can allow accessibility intent to drift. 

Where drift shows up 

I recently reviewed a live user journey that used several components from a design system. Before the review, the automated browser checks showed no issues, and nothing in the UI suggested deeper accessibility problems. The team had clearly considered accessibility at some point, and on the surface, everything looked stable. 

Designers, UXers, and developers do incredible work getting components to a solid starting point. Good patterns and good instincts cover the common interaction paths, but they only take you so far. The deeper accessibility behaviors only show up when you test an interface through the eyes of people who use it differently than you do. In the UK, around one in four people are disabled, so understanding how an interface behaves across these different ways of interacting is an important part of assessing whether it really works for people. 

What manual review reveals 

Manual review is where you explore that space properly. It gives you the chance to check how the interface actually behaves rather than assuming the system covered everything. WCAG 2.2 provides you with a framework for that work. It doesn’t cover every situation, but it’s a solid foundation for judging how your UI holds up under real use.  

The interesting part is seeing how the product behaves when all the interaction details come together and learning how to build something that works for everyone without breaking anyone’s experience. 

A component that drifted 

One of the components I reviewed was a combobox. 

To make the behavior easier to illustrate, I’ve represented the component here as a country selector. The example focuses on the accessibility behavior rather than any specific product or journey. 

It was supposed to be an editable combobox with list autocomplete, pulled straight from the design system: you type into a field, and the matching results update as you go. Instead, the team had built a plain text field and styled it to look like the real component.  

It almost looked fine visually, but it exposed none of the information assistive technologies rely on. Screen reader users didn’t get any announcements. They weren’t told what the field was, what it did, or what options were available. And once the list of options appeared, they couldn’t navigate it. To them, it still behaved like an ordinary text field. 

And that’s where the drift showed itself. When I tried to trace the issues back to the source, I couldn’t tell where the component came from. I didn’t know if it was the design‑system version, a product variant, a fork, or something old that had been patched over time. In the screenshot above, I call it a “product custom combobox” for convenience, but in reality, its lineage was gone. 

Drift isn’t about whether a team used the official design‑system component. It’s about whether the behavior in the product still matches the intent the system defined. If a team builds something that’s meant to act like the design‑system version, then it belongs to the same family. When the behavior diverges, it has drifted, no matter where the code came from. 

What this case study reveals about drift 

By the time this component reached production, blind customers couldn’t predict what the field was supposed to do, and customers using voice control couldn’t reliably reach it at all. A basic interaction — pick a country from a list — had become unpredictable for the people who rely on predictability the most. 

That tells you something went wrong long before the audit. Somewhere between the design system and the product, the original combobox didn’t fit the team’s visual needs, and rather than adapt the component, they broke out of the system. It probably wasn’t one bad decision, more likely a slow accumulation that built up over time until the behavior drifted far away from what the design system intended. 

Product teams move fast, adapt things, and solve local problems, and those choices happen out of sight. When each group stays inside its own box, drift becomes normal because nobody is responsible for protecting the intent behind the component. 

This case study shows what that looks like in practice. Small changes built up until the original behavior slipped away. Even though the design system shipped the right component, the importance of using it properly faded as teams made quick fixes and local adjustments. 

Accessibility in design systems is just code and process. If nobody watches the quality of that code, and there’s no process protecting the intent behind it, drift is inevitable. It’s what happens when quality and intent aren’t checked anywhere in the lifecycle. 

What we can do about it 

We can’t put an accessibility expert on every team. We can’t expect every team to run a full accessibility review at every stage. But we don’t need to go from zero to perfect. We just need to catch drift before it grows. 

One practical idea is to borrow the principle behind accessibility champions. In accessibility, champions help teams stay aware of quality and keep intent alive during busy deadlines.  

I’m not proposing a full champions program with training, meetings, and structure. For drift, a lighter approach is enough: someone within each team who notices when a component’s behavior no longer matches the intent the design system defines. It’s not a full accessibility audit or a specialist role. It’s simply a point of awareness that catches behavioral changes early. 

Catching drift before it grows 

The text field example shows how this works in practice. If the text field was never designed to become a combobox, someone can spot that straight away and ask a simple question: Is this the behavior the design system intended?  

Even if it sits in a gray area, they can raise it early and talk to whoever built it before the drift grows. It’s a quick check that stops small behavioral changes from turning into real problems. 

Most teams never get this view: how drift looks from an auditor’s perspective. In real product work, you’ll be part of discovering drift at some point, and it’s rarely a tidy moment. Someone has to trace how the component’s behavior changed and figure out why it no longer matches the original intent.  

When you understand how drift forms and where it hides, you’re not walking into that discovery unaware. You can spot issues earlier, protect the original intent, and avoid finding out too late that a critical interaction people depend on has quietly broken. 

Let’s get to know him a little better:

What do you do at zeroheight?

I’m a Product Marketing Manager! Essentially the translator between our product, our market, and our customers. I help our customer-facing teams turn what’s happening with the product into compelling commercial narrative, and I help our product teams by feeding in insights from customers and the market to help shape where we’re heading.

What’s your favourite thing about working at zeroheight?

The people, without a doubt, but also the culture they’re embedded in. zeroheight genuinely understands that happy, supported employees do better work, and I have felt that every day. Talented, friendly colleagues and a company that treats wellbeing as more than a talking point is a rare combination.

How would you describe zeroheight in three words?

Human. Stimulating. Real.

If you weren’t doing this job, what would you be doing?

Definitely building things. I have a technical background, so software is the easy answer. But part of me would happily trade the laptop for the workshop and spend my days building race cars 🏎️

What’s the best piece of career advice you’ve received?

Your career is a marathon, not a sprint. Take the time to build genuine experience and expertise. Luck aside, it’s the only way to achieve real, high-impact results.

What’s a fun fact about you that people might not know?

My only car is a 20-year-old Subaru Impreza: a loud, fast and wildly impractical rally car that has absolutely no business doing the nursery run. I’ve been told this is an unexpected choice. I prefer ‘characterful’.

One thing you can’t work without?

It has to be a proper desk setup. Good screen, good chair and everything in its place. Great tools don’t make you great, they get out of the way so you can be.

Hidden talent?

I’m fluent in English, French and Spanish. I don’t know whether that counts as a hidden talent but it does mean I can eavesdrop in most European countries!

Most unusual job you’ve ever had?

A long time before tech, I worked at the Aston Martin factory. By day, maintaining the IT systems keeping the production line running; by night (well, also by day), giving tours of the facility to customers flying in from around the world to watch their dream car come to life.

Quick fire round 🔥​

Tea or coffee? These days, coffee ☕ Tea is nice too.

Early starter or late finisher? Both 😅

Podcast or Music? Music. Preferably consumed on vinyl 💽

Early bird or night owl? Night owl. Just one more task… 🥱

Remote work or office buzz? Remote first 💻 (with the occasional office day to reconnect)

Cats or dogs? Dogs 🐕 (I like cats too but they make me sneeze)

Winter or summer? Summer: don’t like cold, don’t like wet 🥶

Sweet or salty? There is a time and a place for both 😋

Email or slack? What is email? 🤔

A small team had to ship fast, a rebrand got bolted on later, perhaps a framework migration got half-baked, and then … team changes and company reorganizations. Months or years later, nobody remembers who owns the button component or why it has 36 variants (yep, it’s always a button component). 

The first few weeks are where most of the important work starts.

This is where you should build the client’s confidence that you actually understand their mess, and where you build your own understanding of a design system you didn’t have a hand in creating. 

Get the start right, and everything else should get easier. Rush it, and you could spend the next few months fixing all of the wrong things.

Before you touch anything: set expectations

One of the biggest mistakes at the start of a design system audit isn’t missing something in the audit; it’s letting your client believe that you’re already going to be fixing things. 

You’re not. 

You’re rummaging around, investigating, and documenting as you go while wearing Columbo’s trench coat and wielding Miss Marple’s magnifying glass.

I tend to say something like this explicitly, usually in the kickoff call: “For the first couple of weeks, I’m not going to be shipping components or updating documentation. I’m going to be asking questions, reading files, and talking to your team.” The output is a clear picture of what’s actually going on, and a prioritized plan … no fixes yet.

Stakeholders who greenlight this work are usually under pressure to show progress fast. Don’t name the discovery phase out loud, and someone will ask on day two why the card still looks broken. 

I also clarify scope up front. Is this a design-files-only audit, or does it stretch into the code, the documentation, the tooling, the governance, and the adoption too? Legacy systems usually have rot in more than one of them, but the client often only knows about (the most obvious) one.

Defining the fuller scope early avoids a scope-creep conversation in week three.

The to-do list(s)

The actual work. 

I treat this all as six parallel pieces of work rather than a sequence of things that follow one after another, and I’d often be doing two or more of these on the same day. Running underneath all of them, from the start, are conversations. That’s not a seventh to-do list so much as the thing that tells you how to work through the other six.

Stakeholder interviews, throughout

As mentioned, running alongside all of this, we need to have conversations. Not just with the head of design and the engineering lead, but also with the person who has quietly maintained the design token pipeline as a side project, the PM who’s been fighting for design system investment for two years, or the contractor who built half the current components and left. 

Legacy systems generally have informal owners and blockers who don’t show up on an org chart.

Finding them in week one saves you from making recommendations that quietly die later on because you didn’t know who actually needed to sign off.

Audit the design files

Open the library and look for signs of neglect and parts that need some care and attention (and love). 

The components with an unexplainable amount of variants, similar components with slightly different names, text, and color styles that were never migrated to tokens (or variables), and orphaned assets that are no longer linked to anything live. 

• Naming conventions. Are they consistent, or is there evidence of multiple people or eras with different conventions?
• Variant sprawl. Components with lots of variants are almost always a sign that the system tried to solve every edge case for everyone instead of saying no.
• Detached instances. This is a strong indicator of adoption friction. Folks will detach when the component doesn’t do exactly what they need.
• Styles, variables, and design token coverage. How much of the file still uses raw hex values or a manual type scale instead of design tokens?

Audit the coded implementation

Design file health means nothing if the code has drifted away from it. I compare the shipped product against the Figma source, and, critically, I don’t stop at the “official” component library. I go into the local codebases of individual product teams, too, because that’s where the real story usually is. 

Leadership can tell you what the design system is; they usually can’t tell you what 15 different teams have quietly built around it.

• Production drift. Is the production UI in sync with the current design system, or have parts been forked and frozen in time for two years?
• Token drift. Are the design variables and the CSS/Sass equivalents in sync, or is someone maintaining both by hand?
• Framework and version sprawl. How many versions of the component library are live in production at once, and is that number higher than the client thinks?
• Snowflake components. Local, unofficial rebuilds of things the system already claims to offer, usually built quietly under the design system team’s radar.

Audit documentation

Documentation is the fastest tell of institutional decay.

• Does it exist at all, and where does it live (Storybook, Notion, a wiki, a stale zeroheight site)?
• Is it current? Do the screenshots and code snippets match what’s actually shipping?
• Is there a listed owner, or has ownership silently evaporated?
• Do usage guidelines exist, or is it just a visual gallery with no “when to use this” guidance?

If nobody can find the right component or understand how to use it, they’ll rebuild it.

Audit governance

This is where the technical problems reveal themselves as organizational ones:

• Who can currently contribute to or change the system? Is there a review process, or does anyone with Figma edit access just change things?
• Is there a request/contribution model for product teams that need something new?
• Who actually has decision-making authority when there’s a disagreement about a pattern, and does that person know they have it?
• Has the design system team been resourced, or is it “20% time” for someone with a full-time product role?

This is often the most sensitive area of the audit. It inevitably touches politics and past decisions made by people still in the room.

Audit adoption

The system might look perfectly healthy in Figma and still be functionally dead if nobody’s using it. I talk directly to product teams, not just design leadership, and ask:

• Do you use the design system components, or do you work around them?
• What’s the most recent thing you built from scratch because the system didn’t cover it?
• What’s your honest opinion of the system, off the record?

These conversations often contradict what leadership believes is happening. A system can be adopted on paper and abandoned in practice.

Audit tooling

Finally, the plumbing: linting rules, token pipelines, CI checks that catch drift, Figma plugins the team relies on, and any automation that keeps design and code in sync (or is supposed to). 

Broken or absent tooling explains a lot of the manual drift you’ve already found upstream.

Turning the audit into a deliverable

By the end of the discovery phase, raw findings aren’t useful on their own. A 40-item bug list just overwhelms people who are already demoralized about the system. 

I put this all into three tiers:

• Quick wins. Low-effort, high-visibility fixes that build momentum and trust (killing three duplicate progress bar components, for instance).
• Structural fixes. The token pipeline, the governance model, the documentation rebuild, and bigger investments that need roadmap time.
• Organizational issues. Resourcing, ownership, decision rights, and things that need executive buy-in, not design work.

I usually present this as a short report plus a live workshop, rather than just dropping a document in Slack or via email. The workshop matters because it lets stakeholders react in real time, ask defensive questions, and, critically, hear each other’s perspectives on problems they may not have realized were shared. That workshop is also, quietly, where the next phase of the engagement tends to get scoped.

What I’ve learned the hard way from auditing legacy design systems

A few lessons from doing this more than once:

• Don’t lead with the design file mess. It’s tempting because it’s the most visible evidence, but if you open with “your components are a disaster,” you’ll put folks on the defensive before you’ve built any trust.
  
  Lead with adoption interviews instead. They usually validate what leadership already suspects, which makes the harder findings easier to accept later.
• Governance findings are the ones people resist most. Nobody wants to hear that the real problem is “nobody’s actually in charge of this.” Frame it as a resource gap, not a blame game.
• Watch for the hero maintainer. Almost every legacy system has one person holding it together through sheer wanton will, which is usually unrecognized. If your recommendations don’t account for what happens when that person leaves, you’ve built a plan with a single point of failure baked in.
• The audit itself is often the most valuable deliverable. Clients frequently already sense something’s wrong. What they’re actually paying for is a structured, external, and importantly, non-political confirmation of it. One they can use to get budget and buy-in internally.

Auditing a legacy design system isn’t really about finding broken components. It’s about mapping where design decisions, code, documentation, governance, and the people around all of it have quietly drifted apart, and giving the client the language and evidence to start pulling it back together again.

Who is part of the DEI Committee?

Our current committee is made up of Jiyoung Suh, one of our Full Stack Product Engineers, and Ellie Booth, our People Engagement & Culture Specialist. You’ll hear more from both of them in the Q&A below!

Why does the DEI Committee exist?

The DEI Committee helps us keep building a workplace where everyone feels included, respected and able to be themselves. It brings different perspectives into conversations about how we work, listens to feedback from across zeroheight, and helps turn that feedback into meaningful action. It’s one way we make sure our culture continues to grow with our team.

What does being a member involve, and what has the committee worked on so far?

There is no set time commitment for committee members – it’s as much as they want to and are able to help out!

So far, the team has helped run our annual DEI survey, turn the feedback into action plans and follow up on areas where we need to improve. They’ve also reviewed our hiring process and recruitment data to help make sure opportunities are fair and inclusive, organised Pride and International Women’s Day celebrations, shared colleagues’ experiences and perspectives, and reviewed policies to help everyone feel safe and supported at work.

Committee Q&A

What made you want to join the DEI Committee?

Jiyoung: The annual DEI report was actually one of the things that made me want to join zeroheight in the first place. I remember seeing it before I joined and thinking that if a company was willing to be this open about DEI, it was probably something they genuinely cared about. I believe that DEI helps make sure everyone feels respected and safe at work, so I wanted to get involved too.

Ellie: Making people feel included, heard, seen and supported is very important to me, throughout every part of my life. I wanted to help create that feeling at zeroheight too, and make sure we’re listening to people who might need more support or whose experiences might often be overlooked.

What is one initiative you are particularly proud of?

Jiyoung: One of my favourites was this year’s Pride Month tote bag design competition. People submitted their own designs and everyone got to vote for their favourite. I love the idea that just carrying something with a Pride symbol could be a visible sign of support and help someone feel more welcome and safe. It was really fun to see everyone’s creativity and then see the winning design come to life! My partner and I use it as our everyday bag.

Ellie: I’m going to choose two 😇. I’m proud of our annual DEI survey because people are willing to share their experiences with us, including where we need to do better. That honesty helps us focus on the changes that will make the biggest difference. I also love our International Women’s Day celebrations. They shine a light on experiences that are important for everyone to hear and give us another chance to celebrate the wonderful women on our team.

What does belonging at work mean to you?

Jiyoung: I think it’s when you feel comfortable enough to ask for help, or say you don’t know something without feeling nervous. Most importantly, it’s being able to have fun and build good relationships without feeling like you need to be more outgoing or social to fit in. I’m grateful that that’s something I’ve felt at zeroheight from day one.

Ellie: It’s when you’re able to share your thoughts, ask questions and be yourself without worrying that you need to fit a particular mould. It also means feeling that your perspective matters and that people will listen, even when your experience is different from theirs.

What is one small workplace behaviour that can make a meaningful difference?

Jiyoung: Being curious rather than judgemental. When someone has a different perspective or does things differently from you, ask questions instead of making assumptions. We all have different backgrounds and experiences, so what feels normal or obvious to one person might be completely different for someone else.

Ellie: Making space for people to contribute. That could mean asking someone what they think, giving them time to finish their point, or checking in with them afterwards. Small moments like that can help people feel heard and more comfortable speaking up.

What advice would we give to other small companies looking to establish a DEI team?

Jiyoung: We’re still learning, but one thing we’ve learnt is to start small and not feel like you need to do everything at once. DEI isn’t just the DEI team’s responsibility. It’s important to find ways for everyone in the company to get involved.

Ellie: Start by listening to your team and understanding what matters most to them. You don’t need a huge programme straight away, but you do need to follow through on what people tell you 😊

We often rely on complex libraries and frameworks to define our design systems and apply them during development and in production. However, every additional dependency is another thing to manage. A contained system, without the threat of external variance, goes a long way toward ensuring a design system is the asset it should be, rather than the burden it can become. 

The web platform is stable and well established, so we can trust it to work as we need it to and to treat our design systems with grace and poise.

Sibling functions

sibling-index() and sibling-count() are CSS functions that have recently reached support across all three major browsers and which allow us to style elements based on the number of siblings or the position of an item among its siblings. 

There’s a good chance that just hearing that as a possibility conjured up a million and one ideas in your mind about how you could make your design system dynamic and adaptive to how it’s used. A design system is just that — a system. One that might house any variety of content. 

CSS’s sibling functions thankfully give us the ability to make our styles more reactive to how they’re being used. sibling-index() returns the position of an item relative to adjacent (sibling) items. sibling-count() returns the number of sibling elements an element possesses, including itself.

Take the example below, where there are three lists: one with few items, one with many, and one with an amount in between. We can use sibling-count() to automatically increase the spacing based on the number of list items present:

See the Pen sibling-count() dynamic list spacing by Declan Chidlow (@OuterVale) on CodePen.

This lets us define components that adapt to the application. We can shrink heading sizes if there are many in use, or enforce a consistent progressive disclosure pattern based on the number of children present. That means we can define and apply a design system that naturally adapts to context, something that has traditionally required hard coding, a build-time step, or JavaScript to achieve. Having this functionality natively in CSS is not only simpler, lighter weight, and more resilient, but it can also be more style-aware.

:has

:has is a pseudo-class that has reached Web Platform Baseline and allows us to apply styles to an element based on its parent, or to a parent based on its child. To target a div only if it contains an image, we can write this selector:

div:has(img) {

There are endless possibilities here for implementing a design system that adapts to the content and application. We can use it in a similar way to the above sibling functions by applying styles to a parent based on its children, such as targeting an ordered list only if the fifth child is a list item:

ol:has(> li:nth-child(5))

The limitation of this approach is that we need to handle each number of items independently, unlike sibling-count(), which is dynamic.

But :has is more than just a parent/child selector. It allows full relational selection, meaning you can also use the next-sibling combinator (+) and the subsequent-sibling combinator (~) to target and apply styles to items. 

Like with sibling functions, this provides us with an opportunity to change styles based on context. For example, we can use :has with the next-sibling combinator to modify the position of a badge based on its placement in a card:

See the Pen :has next-sibling combinator demo by Declan Chidlow (@OuterVale) on CodePen.

If it appears directly after the heading, it’s displayed next to the heading; otherwise, it appears on a new line.

@custom-media

The ‘source of truth’ is a sacred principle in design systems. Ideally, everything is managed with tokens in a central location, and nothing is hard-coded. One place where values have often had to be hard-coded, or required a pre-processor, is media queries.

Whether you’re defining breakpoints for certain display sizes, styling for certain media types, or handling varied user input methods, media queries are indispensable for making a design system adapt to its context. 

Different modalities come with different considerations, and media queries are integral to addressing that. Even beyond hard-coded values violating our love for tokens, they’re also rigid and inflexible. Changing a component’s breakpoint could break the layout of a screen if you don’t update it everywhere else, too.

Thankfully, @custom-media is bringing an end to that. With @custom-media we can define media queries and reference them like CSS custom properties (commonly referred to as CSS variables). With custom media queries, both can adapt to a single source of truth, keeping them in sync and allowing dynamic adaptation without breakage.

We can define a custom alias for our media query:

@custom-media --medium-screen (500px <= width <= 1000px);

And then use it as we would a normal media query:

@media (--medium-screen) {
/* Styles for screens that are between 500px and 1000px in width. */
}

The custom media query above also shows an example of a range media query, which lets us set upper and lower limits concisely. That’s another relatively new feature that’s valuable for ensuring our systems adapt to the relevant case.

Custom media queries haven’t quite been finalized yet, but we can use them via a build step such as PostCSS Custom Media in preparation for when they do get full browser support.

Popovers

The popover attribute is a new but rather well-supported feature that lets us create content that appears on top of other page content. For example, dialogs, popups, and tooltips.

Elements opened as popovers are always placed on the top layer, so they’ll never appear behind another item. This helps avoid the z-index battle that can happen when multiple conflicting components from a design system are used together.

They’re easy to style, too. The ::backdrop pseudo-element is placed behind popovers and takes up the whole screen, which gives us opportunities like darkening the background when a popover is open.

The :popover-open pseudo-class lets us target the popover state, so we can tell when it’s open or closed. As popovers are completely native to the web platform, they can also seamlessly inherit all our CSS styles, custom properties, and more.

In their simplest form, all we need to do is give the element we want to turn into a popover an ID and a popover attribute. Then, we give a button a popovertarget attribute that references the popover element’s ID, and the popover is ready to trigger when the button is pressed. 

You can see this basic approach here, complete with ::backdrop to darken the area behind the popover when it’s open:

See the Pen Simple Popover Demo by Declan Chidlow (@OuterVale) on CodePen.

@scope

It doesn’t matter how great your design system is if the styles designed for one part leak into another and cause problems. 

Encapsulating styles so they don’t have unintended consequences has always been part of writing CSS, and it’s a major consideration when implementing design systems where many different parts need to work together in a wide variety of combinations.

A design system goes out the window as soon as its different parts start fighting. You don’t want styles defined for a card to start interacting with your carefully designed navigation or vice versa.

Thankfully, the @scope at-rule, which browsers recently gained support for, allows us to encapsulate components without the risk of styles leaking out and causing unintended consequences elsewhere.

You don’t have to write complex selectors, which can be hard to overwrite, just for the purpose of scoping. Instead, you can define the upper and lower bounds of the scope. One of the most useful parts of this is commonly called ‘donut scope,’ where you only apply styles to part of an element without the style continuing all the way down the cascade, like this:

/* Scopes .card but excludes .content inside .card */
@scope (.card) to (.content) {
	img {
		border-radius: 8px;
	}
}

Here are examples of both a basic scope and a donut scope in use:

See the Pen Simple @scope Demos by Declan Chidlow (@OuterVale) on CodePen.

Text box control

Typography is complex, and the web has historically had middling typographic controls. One place where typography on the web has been particularly difficult is spacing around text. You can have great-looking type in your design software, but when porting it to the web, seemingly spurious padding can be added, making things look very mildly misaligned — just enough to throw off a design.

Paired with text-box-edge, the text-box-trim property allows us to control the spacing above and below text, something that has traditionally required hacky solutions involving negative margins or line-height, which often has negative effects on leading. 

text-box-edge specifies the amount of space to trim, while text-box-trim specifies whether to trim the top edge, bottom edge, or both edges. Both properties are Baseline Newly Available and degrade nicely if support is lacking.

You can see the difference these properties make in this demo:

See the Pen text-box-trim Demo by Declan Chidlow (@OuterVale) on CodePen.

Colors

CSS has particularly come a long way with colors in recent years: You can do a lot with variables, color spaces, color mixing, and inline light/dark theming, all of which have found their way into browsers. 

These features allow design systems to be more flexible with color than ever before, and they’re something that I’ve covered here on the zeroheight blog before.

Bringing modern web features into your design system

HTML, and particularly CSS, have some new tricks up their sleeves that design systems can apply to great effect. 

Sibling functions, :has, @custom-media, popovers, @scope, more text box controls, and greater color features all make the web platform better than it’s ever been, while unlocking many new possibilities and improvements for design systems. 

Browser support isn’t yet universal for all of these features, but it’s getting there. Most also degrade gracefully, so the impact when a user’s browser doesn’t support them is minimal. 

That said, you should still check support before using these features in production. As support continues to improve, they offer a great way to make your design system more flexible, resilient, and responsive without adding unnecessary complexity.

A friend of mine, Drew Herrema, has Attention Deficit Hyperactivity Disorder (ADHD) and autism. He’s an interaction designer and consultant on cognitive accessibility for organizations.

Recently, I interviewed him to find out which digital designs work best for his everyday needs and preferences across websites, software applications, and mobile apps.  

In this article, I’ll cover design best practices based on what I learned from my session with Drew. I’ll also suggest actions to take in your design system, so you can educate your team on ADHD, connect those ideas to the latest WCAG 2.2. compliance guidelines for cognitive disabilities, and how to avoid usability barriers. 

Introducing Drew

Drew is a tech enthusiast and global traveler based in Toronto. He uses device and software customizations to enhance privacy and security within operating systems (OS) and apps. 

Drew uses a Framework laptop (a modular laptop designed for easy self-repair) with Linux Mint, and a Pixel phone running GrapheneOS, a modified Android operating system that removes Google tracking.

Drew sets up multiple phone profiles — “main”, “isolation”, and “quarantine” — to separate trusted apps from ones that might track him, and he sources apps from open-source stores like the Aurora Store before resorting to the Google Play Store. 

He explained, “The ‘quarantine’ profile is where I have Instagram, WhatsApp, Facebook, and the apps that require Google Play to download and update.” 

Drew prefers apps that let him store files on his own device rather than forcing him to use cloud storage.  

He’s an avid notetaker who captures, tracks, and collates thoughts and ideas while working. Drew prefers programs like Logseq over Obsidian because Logseq uses tags instead of folders to organize information, which are easier to update if he changes his mind about how to tag something. Amplenote is another tag-based option.

Controlling Drew’s phone, his way 

Drew uses several tools and apps to customize his mobile phone experience.

Home screen and app launch

For security and privacy, Drew has a customized app launcher on his phone, which also reduces visual clutter and cognitive overload. 

“The lack of customization in Android phones was annoying,” he said. “I switched to an alternative launcher to get rid of that clutter.” 

Drew also uses a search tool called Blue Line Console to quickly find and open any app on his phone. He types in the first three letters of the app name, and it pops up.

App customization and settings

Drew’s favorite customizations include color adjustments (like dark mode and color inversion) and choosing where files are stored.

Drew shared key design approaches that support ADHD, as well as those that don’t.

Designs that support ADHD

1. Transparent pricing and feature details on websites

When evaluating a new product or service online, Drew wants unique features — including cost — stated clearly and up front, not hidden or buried. 

He calls out Speechify, a platform he was interested in paying for, as an example of hiding pricing and providing too little information.

“The site only has very brief descriptions,” he explained. “But if you want to learn more, or find a specific feature, it’s hard to determine easily whether the Speechify platform has that feature or not. In some cases, I’ve had to download the tool just to find out.”

That’s going to waste time and cause cognitive overload for any user. Plus, it also means they may have to uninstall something from their machine that they never wanted in the first place.

When providing product descriptions, content authors need to make them clear and distinctive from one another, at a glance.  

Then, designers should place this information as close to the top of the page as possible, creating a “meaningful sequence”. This provides essential information for users up front, especially people with learning disabilities or memory loss, and it helps everyone. 

“Meaningful sequence” is a fundamental WCAG 2.2 guideline at Level A because screen reader users navigate from top to bottom, and the sequence of page content has to be logical without any visual cues. Some users with cognitive needs also use screen readers to have content read out loud to them (not just blind users).

Clear descriptions, easier decision-making 

Be mindful of your content’s reading level. If text requires more than a secondary school reading level (or Grade 6 in North America, age 12) to comprehend its meaning, people may struggle to make a decision about it (like buying a product or registering). 

Describe things as plainly as you can. Aim for a Grade 6 reading level at most. Ideally, supplement content with illustrations or write text as step-by-step instructions. Avoid using cultural phrases and metaphors. This is crucial for people with reading or learning disabilities.

Avoid unusual words. These may be understood only at higher reading levels. If you must use technical terms, complex phrases, or specialized words, consider creating a glossary with plain-language definitions for each, along with an example. People with learning disabilities or limited literacy may not understand figurative or technical language.

When you use acronyms (or abbreviations), spell out the full words the first time. Put the acronym in brackets at the end, e.g. “Free and open source software (FOSS).” A reader may not be familiar with the shortened format. Then, use the acronym or abbreviation throughout your page or document.   

Be aware of pronunciation. When a word’s meaning depends on how you say it (like “lead” the metal vs. “lead” as in leadership), write this into your content. Provide a separate pronunciation guide if you think it’s necessary.  

Actions to take in your design system:

• Content authors:
  
  Work with business stakeholders to write clear, detailed descriptions of product features.
  
  Confirm users can quickly distinguish one product from another.
  
  Include essential information for decision-making, like product cost. 
  
  Create a glossary or pronunciation guide as part of your design. 
  
  Document reading level, expanded acronyms, glossaries, and pronunciations as part of your content strategy in the design system.  Place them in brand guidelines as accessibility requirements for cognitive accessibility.
• Include the WCAG requirements in your documentation:
  
  1.3.2 Meaningful Sequence (A)
  3.1.3 Unusual Words (Level AAA)
  3.1.4 Abbreviations (Level AAA) 
  3.1.5 Reading Level (Level AAA) 
  3.1.6 Pronunciation (Level AAA) 
• Test your content’s reading level with a tool like Hemingway App.
• Reference the W3C Supplemental Guidance for WCAG 2 for cognitive accessibility:
  
  Help users understand what things are and how to use them.

2. Make filtering and search options robust

Drew calls out the website for cinema chain Cineplex as a poor search example. The information structure is rigid with limited search and filtering options. Movies currently showing are listed in a location-first browsing path only. You must know your location first, then drill down into their menu instead of searching all locations to find the one showing the film you want to see.

Drew prefers the ability to filter by his own criteria (like date range, multiple locations, and movie type). His design recommendation: Use the filter pattern with categories and values, as seen on most retail websites.

It can be highly frustrating for people with ADHD, memory loss, or learning disabilities if a search algorithm is too broad. That means keywords can be sourced from anywhere on the site, like outdated blog posts or unanswered forum threads. Often, a results page displays these first, and product information pages are buried further down.

As a result, Drew loses interest in the product, gives up, and leaves the site. 

Create structured, quality support resources

To address this, Drew suggested providing a well-maintained wiki or Frequently Asked Questions (FAQ) page for visitors searching for products or help. These types of pages are structured to contain the relevant information and keywords needed. Ideally, they are easier for the search algorithm to detect and prioritize in search results (especially if page traffic is high).   

“Depending on the complexity of the service, having a quality wiki or FAQ is helpful for me,” Drew said. “With blogs or articles, information might be for marketing or publicity purposes and not really helpful or relevant for a product search.”

Actions to take in your design system:

• Content authors: Consider creating an information wiki and or FAQ page for users who need product, service, or company information quickly. Build a template into the design system.
• UX designers: Consider using a filter element with category selections in your design. 
• Include the WCAG requirements in your documentation:
  
  1.3.1 Info and Relationships (A)
  1.3.2 Meaningful Sequence (A)
• Reference the W3C Supplemental Guidance for WCAG 2 for cognitive accessibility:
  
  Help users find what they need.
  Provide help and support.

3. Support dark mode and accessible contrast

Drew uses dark mode in certain situations to reduce eye strain and visual noise. It helps him focus, read, and comprehend text more easily. 

He expects websites and apps to support this built-in feature in Microsoft Windows or on iOS, i.e., color inversion.   

At a bare minimum, Drew expects websites to meet WCAG 2 accessibility contrast standards so that text is easy to read.

Actions to take in your design system:

• Visual designers: Consider creating a dark mode palette for your website or mobile app. Test it with people with cognitive needs and low vision.
• Include the WCAG requirements in your documentation:
  
  1.4.3. Contrast Minimum (AA)
  1.4.11 Non-text Contrast (AA)
• Reference this article: Why Dark Mode Matters for ADHD Focus

4. Make email threads feel more like a chat

Drew receives lots of emails through his email client, like most of us. However, he finds managing multiple email threads with the same person “clunky” and wishes more email clients (Gmail, Outlook, Yahoo) would design and present conversations in a chat-like, linear format. 

“It can be annoying to try to keep track of multiple email threads and who’s involved, and it’s hard to see this at a glance,” he said. “Or, if you have multiple email threads with one person.”

I shared my frustration too: “Gmail does this thing where they stack the emails on top of each other, so the entire thread sits behind a single email, and the rest of them are ‘hidden’. I can’t find an individual email easily in the stack, so I waste time using Outlook’s poor keyword search feature trying to locate it.”

Drew suggested that email clients provide an option to extract all the text (and the gist of the emails) into one single linear ‘chat’ on a screen or in a downloadable document. 

Actions to take in your design system:

• Email client designers can take this into account in their design system.
• Authors and UX designers: Create email templates and guidelines for accessibility: plain language, low character counts, and a descriptive subject line. Write the most important information in the first sentences of the email.
• Reference this article on Spike AI email summaries.

5. Customer support is a last resort

Drew tries to solve customer experience problems on his own first. 

When forced to call a phone number for help, he’s often frustrated by long wait times, being redirected back to the website, and the perpetual “higher than expected call volume” message, which he sees as dishonest communication. There can’t always be a queue!

Similarly, AI chatbots are a barrier for him. When Drew opens a support chat and realizes it’s AI only, he closes it immediately. He can’t trust the accuracy of the responses and would rather email or call a real person.

In this way, email and telephone options are essential alternatives to chatbots for Drew and for people with other disabilities or impairments. But this doesn’t mean phone support has to be a time-sucking dead end. 

WCAG 2.2 introduced a new guideline with cognitive users in mind called Consistent Help (Level A). It’s telling designers that if a site offers help (contact form, email, phone, chat), make sure that all help options appear in the same place on every page. When someone is confused and looking for help, they need to be findable and predictable. 

I agree with Drew: Focus on creating a robust, detailed support structure like an FAQ or wiki. That way, fewer users will have to resort to relying on customer support services in the first place. 

Actions to take in your design system:

• Review customer support options at your organization and the user journeys available. As a team, create guidelines, templates, and accessibility specifications around each format — email, chatbot, phone number.  
• Include the WCAG requirements in your documentation:
  
  3.2.6 Consistent Help (A) 
• Reference the W3C tutorial for carousels:
  
  W3C – Carousels Tutorial
• Reference these iOS and Android features:
  
  Apple iOS: Turn on and practice VoiceOver
  Android: Turn on TalkBack

6. Convert PDFs to web pages

Drew doesn’t like being forced to download a PDF to access information. He prefers not to clutter his devices with downloaded documents. 

Many times, the page link isn’t labeled as a PDF, for example, “2026 Parking Prices and Schedule (PDF),” so he expects a web page instead.  

PDFs also breed distrust; the content may not be up to date and fresh. They can get old and neglected on a website as they take more effort to manage. PDF accessibility quality can also be poor or non-existent.  

Drew recommends converting PDF content to simple web pages instead, if the content doesn’t need to be secure.  

Actions to take in your design system:

• Content authors:
  
  Review the existing PDFs on your site. Do they need to be in this format, and is the content still relevant? Work with business stakeholders to assess, clear, and convert content, add it to existing web pages, or build new ones with the UX designer(s).
  
  Create a guideline for PDF use at your organization.  
• Reference the WCAG requirements for PDFs:
  
  PDF Techniques for WCAG 2.2

Designs that don’t support ADHD 

7. Visual distractions and animations

For Drew, constant syncing indicators, flashing “buy now” buttons, and other animated elements like parallax break his focus on a web page or app screen. So much so that the experience once caused him to leave the website completely, and the company lost a customer.  

“The worst is buying things on websites,” he said. “I was looking at an e-ink tablet, and every five seconds the ‘Buy now’ button, near ‘Add to cart’ would wiggle back and forth.”

And on parallax pages: “Fancy scroll effects are just annoying.”

Before implementing animations, ask: Can a designer describe the need for movement as a selling feature? Is there research that shows that movement aided the average visitor in making a decision or a sale?

Oversized sticky navigation

Sticky navigation bars, or menus that stay fixed on screen as you scroll, are distracting and can sometimes take up too much screen space. For Drew, they make it hard to see the actual content, especially when sticky navs don’t scale well on smaller screens.

Pop-ups and cookie consent friction

Drew instinctively closes pop-ups without reading them. Multi-step cookie consent, where opting out of tracking takes several clicks, is a particular annoyance, as he landed on the page to get something else done.

For Drew, these are all distractions that break his focus and concentration on the task at hand. “If there’s a pop-up to subscribe to a newsletter or something, I’ll instinctually just click out and exit it before even thinking about it.”

I shared my experience with a Universal Currency Converter (UCC) on xe.com. “There’s a field where you enter the first currency before you select ‘convert’ to show the converted amount. As soon as users interact with the widget, an advertisement banner pops up and covers the widget completely. 

I’m completely distracted by the interruption and have to fumble to close it (with a small Close button, I might add!). It’s surely a marketing tactic, but it makes me want to dismiss the pop-up immediately and not engage with the ad.”

Actions to take in your design system:

• UX designers:
  
  Consider the timing of pop-ups, ads, and cookie sequences. Provide design templates and specifications about when they appear to minimize distractions for cognitive users.
  
  Cookies are legally required, so if they must appear, make the experience as short as possible, with additional selections available only if the user chooses to engage.   
  
  Ensure the pop-up can be closed with the keyboard alone, and make sure the Close button target size is large enough to be tapped with a finger on mobile or mouse-click on desktop.
  
  Ensure sticky navigation menus don’t jump or bounce by design, or cover any other content on the page. Keyboard users need the focus outline around content to remain visible at all times.
• Include the WCAG requirements in your documentation:
  
  2.1.1 Keyboard (A) 
  2.1.2 No Keyboard Trap (A)
  2.4.11 Focus Not Obscured (A)
  2.5.8 Target Size Minimum (A)
• Reference the W3C Supplemental Guidance for WCAG 2 for cognitive accessibility:
  
  Help users focus.

8. Login disruptions mid-task

Drew said being forced to log in halfway through a task (like on a library site or a food-ordering site) is frustrating, especially when it resets his progress or restarts the journey. 

He will open a second tab to log in just to avoid losing his place. 

Multiple logins on the same platform

Having one login for an application and a separate login for a form on that same platform is a pain. Drew said the reason for it should at least be explained to the user.

Location and preference persistence

Drew finds having to repeatedly confirm his location or re-enter preferences across sessions is tedious. He’d rather the system remember those choices.

There are new WCAG 2.2 guidelines that address these concerns:

3.3.7 Redundant Entry (Level A). Information a user has already entered or provided is auto-populated or available to select rather than requiring them to type it again. Re-entering information is a memory burden and a common source of frustration and errors.

3.3.8 Accessible Authentication, Minimum (Level AA). Logging in doesn’t require a cognitive function test (like remembering a password or solving a puzzle) unless an alternative is available, such as pasting a password from a manager or using a passkey. A passkey is a passwordless login method that uses your device’s fingerprint or face recognition. Otherwise, a one-time code is sent to the user’s email. 

These are major cognitive accessibility additions to the standard that benefit everyone.

Actions to take in your design system:

• UX designers and content authors:
  
  Map the user’s journey where logins are required because your internal systems are set up this way. Work with business stakeholders to change this if possible. Design an alternative.
  
  If the system model must stay in place, provide a statement to users on the page or screen that explains why logs are needed, and when and how frequently this action will be required of them.
  
  Write content specs for the statement and page templates for where and when they appear.
  
  Consider having the login page open in a new browser tab or window so users don’t lose their place in the main flow, and remember to warn screen reader users with “opens new tab”. 
• Include the WCAG requirements in your documentation:
  
  3.3.7 Redundant Entry (Level A)
  3.3.8 Accessible Authentication, Minimum (Level AA)
  3.3.9 Accessible Authentication, Enhanced (AAA)
  3.3.5 Help (AAA)
  
  Incorporate the design principles outlined in the WCAG guidelines (ease of use, warning, help, clarity). 
• Reference the W3C Supplemental Guidance for WCAG 2 for cognitive accessibility:
  
  Ensure the process doesn’t rely on memory.

How to embed accessibility in design system documentation

Drew recommends that accessibility requirements live in two places: 

1. Within each individual component’s documentation (so a designer looking at a “button” also sees how to label it properly), and
2. In a dedicated accessibility section, with links connecting both.

Design for a person with ADHD — Summary

As a person with ADHD, Drew’s design needs are pretty simple: 

1. Make content easy to understand, and put information up front in a meaningful sequence on the page, and in one familiar place.
2. Provide contact options to reach humans (email, phone) who will listen and understand users with cognitive needs.
3. Provide a summary for email threads and conversations at a glance (which is a good use of AI).
4. Don’t use moving, flashing, or half-hidden content on a page or screen. It distracts users and causes eye strain. 
5. Don’t make users break concentration when they’re in the middle of a task. For example, don’t ask them to log in halfway through an application or purchase. 
6. People forget things sometimes. Provide plenty of help and auto-complete options for online forms. 
7. Make sure designs have sufficient color contrast between dark and light colors on the screen, with muted light colors to avoid eye strain.

Resources

• W3C Diverse Abilities & Barriers: Cognitive and learning
• W3C User Stories: Ian, data entry clerk with Autism
• Hey Nova: Designing for people with ADHD
• Drew Herrema: Using CamelCase for hashtags
• GrapheneOS
• Tom’s guide to the best Android app launchers
• Notetaking apps:
  
  Logseq
  Obsidian
  Amplenote

Tokens are mostly solved: We have a spec and lots of tooling. Props are left ungoverned without the same rigor.

A design token gets a name that describes its meaning, along with a review process when someone proposes a new one. Props sometimes get invented on the spot, in Figma or the codebase. We found that the button variant is named outline, and that the chip variant is named outlined. A dev can get confused by this and lose time trying to figure out why the component isn’t rendering correctly. The prop surface is a pile of synonyms: similar words describing the same meaning.

What makes a component API

A component API is the contract a component exposes: the controls a consumer uses to configure, style, and drive it. Fernando Ruiz frames what a properly built API should answer cleanly: What does it receive? (e.g., props like label, icon, and size). What can it do? (e.g., events like onClick, onChange, and onDismiss). How does it look across scenarios? (e.g., variants like primary, secondary, and ghost).

Designers have gotten good at the third question. Variants are visual, so they live where we already work. The first two are where the drift hides, because their vocabulary and grammar don’t come from us.

What you inherit vs. what you author

Props come from the codebase stack, but how much you inherit depends on the combination of framework and libraries. These are abstractions built to make development easier by handing you solved decisions, and every solved decision is one you inherit instead of authoring. That sets a ratio. A React library inherits most of its vocabulary and grammar from what sits underneath. A web component library, on the other hand, lets you author almost all of it. The less machinery you build on, the more of it is yours, and the more there is to get wrong with no framework to fall back on.

The grammar you do inherit is legible once you read it. Booleans announce themselves with is, has, or should: isDisabled, isLoading, hasIcon. Finite options are enums with mutually exclusive values: size="sm | md | lg". Data-carrying props say what they carry: label or text, never data. None of this is taste. It’s the contract that the implementation already addresses, and when the Figma property diverges from it, the design describes a component the code won’t build.

Design tools never surfaced any of this, so designers author prop names as if the naming space were empty. It never is, and it is emptiest — and most in need of governance — exactly where inheritance is lowest.

Properties define logic

A prop describes state and behavior. It carries a type, a set of accepted values, a default, and sometimes a handler or a slot. isLoading is not a pointer to a value; it’s a state the component can occupy.

What transfers from tokens is the discipline, not the shape. One name, one concept, no synonyms. That single rule is why outline and outlined can’t both exist, and it’s the rule prop surfaces have never had applied to them.

The asymmetry is visible the moment you audit. In one system with React and React Native libraries, there were 214 distinct props, but only 14 shared axes with canonical values, such as size, variant, color, and radius. The other 200 are booleans, event handlers, slots, and component-local props.

Build a prop map

So audit props the way you already audit tokens, and write the result down. A prop map is a generated glossary and lookup table: every prop, its type, its accepted values, and the components that use it, with divergence flagged.

• Axes are the system-wide vocabulary with canonical values (size, variant, color).
• Booleans are is/has/should flags.
• Handlers are events (onDismiss).
• Slots take nodes (title, trigger).
• Local props belong to one component.
• Platform props come from the runtime (testID).

Only the axes get canonical values and an anti-synonym glossary. The rest just need to stop duplicating each other under different spellings.

An axis is a small, structured record. This is what makes it queryable by a person or an agent:

json{

  "size": {

    "concept": "One ordered scale; each component exposes a contiguous subset.",

    "values": ["2xs", "xs", "sm", "md", "lg", "xl", "2xl"],

    "default": "md"

  },

  "variant": {

    "concept": "A component's named look. Per-component, but values must come from the glossary.",

    "values": "per-component (glossary-constrained)",

    "aliases": { "outlined": "outline" }

  }

}

The aliases field does the work. It’s a machine-readable record of which spelling won, so the wrong one can be caught instead of relitigated.

Underneath the axes sits the value glossary, which is nothing more than one spelling mapped to one meaning:

• outline: Border only, transparent background. Canonical, never “outlined”.
• neutral: The neutral/default semantic color. Canonical, not “base” or “default”.
• soft: Tinted or translucent background, medium emphasis.

Keep the first pass descriptive. Resolve nothing, migrate nothing. You document what exists and annotate the drift, so the output is a backlog you can review, not a migration you never agreed to. The drift report is where the value shows up immediately:

Spelling drift (anti-synonyms)

•   Card: value outlined → canonical outline
•   Chip: value base → canonical neutral
•   Button: value rounded → canonical full

Prop-name drift (right axis, wrong name)

•   IconButton: prop sizeVariant is the size axis under a non-canonical name
•   Typography: prop textColor is the color axis under a non-canonical name

Every line there is a bug a developer would otherwise have hit at render time, surfaced before it shipped.

How to build it

Point an agent at the component source or the defined framework and library combination to catalog props and values and emit the map. The audit that used to be manual reading is now close to free. 

You can ask the agent to build a script that runs it, so the process is deterministic. The rule the agent enforces is: one prop, one name; one value, one spelling.

How to use it

When you spec a new component, you start from use cases and lay out the states it needs. With the map open, that step changes shape. You query it. 

Is there already a canonical axis for this behavior? Reuse the name and its values. 

Is the value you want in the glossary, or are you about to coin outlined next to an existing outline? Point an agent at the requirements and the map, and it returns a prop table or builds the component against the contract directly. 

It does not matter whether you work in Figma or in code. You are enforcing one language across both, which is the only thing that produces real parity between them. For Figma, you’ll need a bridge: It can be the native Figma MCP, TJ Pitre’s figma-console-mcp, or Sil Bormüller’s figma-cli.

The contract is the artifact

Load the map from the repo if you’re on the team. Expose it through your design system MCP, or publish it as a documentation page that any teammate or agent can fetch. The mechanism isn’t relevant.

The interesting part is that a design system is its contracts, and until now, the prop half of that contract was unwritten. Tokens made your visual decisions queryable. A prop map does the same for your component vocabulary and turns naming that used to live in individual memory into something the system can enforce.

It wasn’t always like this.

Documented governance was always advisory. You wrote a rule down somewhere: a wiki page, a Notion doc, a paragraph in the Figma file nobody scrolls to. Someone read it once and remembered a rough version of it. When someone broke the rule, another person sometimes caught it in review. A reviewer caved and approved it anyway. Someone senior overrode it because the deadline couldn’t move, and the rule felt like it could wait. The rule was there the whole time, and it still lost, regularly, to whoever was in the room.

Review-based governance is a negotiation with a document attached, but the document doesn’t get a vote.

How instruction files work

Instruction files for coding agents aren’t hypothetical anymore. AGENTS.md is one such format, an open standard that Google, OpenAI, Cursor, Sourcegraph, and Factory rallied around in 2025. It sits at the root of a repo, and the agent reads it automatically at the start of every session, so nobody has to remember to point it there. The closest file in the directory tree typically takes precedence over anything further up. It’s now stewarded by the Linux Foundation, alongside the Model Context Protocol and Block’s Goose framework, donated in the same announcement. 

Even Claude Code, built by one of the companies backing that standard, still doesn’t read AGENTS.md natively as of this writing. It needs a manual import just to see it, which says something about how easily presence slips even when everyone involved agrees it should be automatic. Design systems have their own version now, too: Google Labs’ DESIGN.md, still in alpha, pairing machine-readable tokens with the reasoning behind them in one file.

It helps to separate this from the validation layer I’ve written about before — ESLint rules, type constraints, schema checks running in CI. I still think that layer matters, but it isn’t what this piece is about. What’s happening here comes a step before validation: whether the rule is in the room at all.

The mechanical difference is what makes it binary. Read your contribution guidelines once, and six months later you’re running on nothing but a memory of it. Memory fades. People misremember things, or push them down the list when a deadline shows up. 

A model doesn’t carry any of that between sessions. Everything it knows about your rules for a given generation lives in the text sitting in its context window at that instant. The system feeds that content back in fresh every time, because the model can’t reach back into a document it was never shown. Either the rule made it into the file the agent loaded, or it didn’t, and there’s no partial credit for having documented it somewhere else.

Undocumented rules don’t survive

The binary shows up hardest around tacit knowledge: the rules a team never wrote down because everyone already knew them. A designer writing up their experience on Design Systems Collective described an agent that kept rebuilding buttons and cards from scratch instead of importing the library, getting the tokens right but never the actual component. Nobody on the team had ever written the constraint down. They all knew it by feel, but the agent didn’t, since nothing in its context could tell it, and there was no way to infer a rule that only existed as consensus in people’s heads.

A new human contributor in that same situation gets it wrong once, a teammate corrects them, and they pick up a feel for the system over a few months of working inside it. An agent doesn’t get any of that, and it never picks up that same ambient familiarity across sessions the way a person does. Every session starts from the same file, and if the rule isn’t in it, the rule doesn’t exist yet, no matter how obvious it is to everyone who actually built the system. The argument I made two years ago was that agents need explicit contracts because they can’t infer purpose from implicit visual convention. Turns out governance is the same problem, one level up. 

Contracts used to describe what a component does. Now they need to describe what’s allowed around it, too.

Every design system carries a backlog of governance debt: rules that never felt urgent enough to write down. Debt like that used to be a slow, survivable liability until an agent starts generating against the system, at which point it becomes something the agent trips over on day one.

Stale rules, followed anyway

The other side of that same binary is a lot less comfortable. A missing rule fails loudly, or at least visibly, as soon as someone notices the output is off. A wrong rule doesn’t fail that way at all.

In an instruction file, name a specific path, a deprecated component, a token someone renamed months ago, and the agent will follow it exactly as written, no hesitation, because it has no way to know the file no longer matches reality unless the file itself says so. As one guide to writing these files puts it, document a structure that later changes, and the agent will confidently look in the wrong place. A person working from the same outdated doc usually has some instinct that something’s off: a component that doesn’t quite match the description, a path that throws an error along the way. The agent doesn’t get that instinct. It gets the file, and the whole design rests on trusting it.

Advisory documentation decayed in a way people could live with. An experienced reviewer routed around the parts that had gone stale, using judgment the document itself never had. An encoded file doesn’t get that same grace. The agent follows it with total confidence regardless of whether it’s still true, and the errors spread as fast as it’s generating.

Whether an agent actually complies with a rule you’ve given it is a separate, harder problem, the kind you need evals for rather than a better file, and I’ve written about that here. I’m covering the step before that one: whether the rule was in the room to begin with, and whether what was there was still true.

Who owns the file now

Once governance moves into a file that a model loads automatically, maintaining it becomes a different job. Reviewing Figma files and PRs still matters, but it isn’t where governance primarily lives anymore. The file is. A file nobody owns goes stale the same way a wiki page nobody owns goes stale, except now the cost of that staleness lands on every generation instead of on whoever eventually notices.

Give the file an owner and a review date, the same way you’d review a contract rather than a wiki page. That’s the actual job now: checking that the rules you’ve already written are still true, not just writing better ones. 

Two things make that easier. Write the reasoning next to each rule, not only the constraint, so whoever reviews it later can tell whether it’s still defensible rather than just re-reading the same sentence. Keep the file scoped, too, since a few thousand lines of instructions cost real context on every generation, most of it irrelevant to whatever the agent’s actually doing. Split by concern instead of building one file that tries to cover everything.

zeroheight’s own MCP layer is part of the same change, serving structured guidance directly to agents rather than waiting for someone to open a styleguide page first. I’ve watched teams treat these instruction files exactly like the wiki pages they replaced, writing them once and never coming back to them. It’s the failure mode to design against, because a wiki page can carry that sort of neglect for years. A file a model trusts completely can’t.

A person used to stand between a rule and the outcome, bringing judgment the document itself never had. Take that person out of the loop, and the file doesn’t get the same benefit of the doubt. The agent believes it.

Generative UI might be different: not because the hype is smaller, but because parts of it are already shipping. The question worth asking isn’t “is this real,” it’s “what does it actually mean if it sticks,” especially for the people building and maintaining design systems.

Three concepts worth separating

A lot of the confusion around this topic comes from mixing up three related but distinct ideas.

Generative UI is a front-end approach where an AI model or LLM dynamically builds or assembles interface components (cards, forms, charts, maps, whatever’s needed) in real time, based on the user’s context and intent, rather than relying on fixed, pre-coded screens.

Declarative UI is the older of the three, and predates AI entirely. It’s a method of building interfaces where you describe what a screen should look like based on the underlying data, and a framework figures out how to render and update it. AI hasn’t invented this concept, but it has supercharged it.

Probabilistic UI (or probabilistic UX) is a concept gaining traction that’s less an architecture and more an approach: one that accepts and communicates uncertainty and variability, rather than assuming an interface will look identical every time it’s generated. It’s the mindset shift that generative UI ultimately demands.

This isn’t hypothetical: it’s already running

Some version of generative UI happens every time you use a chat-based AI tool. Ask it for a chart or a table and it gets built on the fly, styled according to whatever platform you’re in. That part is standard now.

What’s newer is AI tools serving up someone else’s interface, hooked up to that company’s own API, from inside a chat window:

• ChatGPT Apps work through an open SDK and a plugin model. Add the Booking.com plugin, for example, and you can describe what you want conversationally (dates, budget, “somewhere hot and sunny”) and what comes back isn’t just text, it’s Booking.com‘s own interface, pulled live from their API.
• Claude takes a more locked-down approach with what’s currently a partner-only interactive UI capability. It’s not something anyone can opt into yet — it’s limited to a small number of partners (roughly 10–15 at the time of writing, including tools like Figma, Asana, and Jira), and typically requires an MCP connection.
• A2UI (Agent-to-User Interface), an open framework from Google, is one of several emerging kits built specifically to let an LLM assemble UI from a constrained set of components, rather than generating markup from scratch. It’s not the only one, and more SDKs from other providers are expected.

The common thread: none of these tools let an AI invent interface elements freely. They all work by calling into a limited, defined toolbox, which is exactly why design systems matter so much here.

The real shift: ceding control

For as long as digital product design has existed, the job has largely been about defining things precisely: this is what the screen looks like, this is the copy, this is the flow, and here’s what happens if a user does X. Generative UI asks teams to give some of that precision up, and hand it instead to a system that decides, case by case, what to assemble and how.

That’s an uncomfortable trade for a lot of designers, and it’s fair to be uneasy about it; plenty of attempts at this kind of flexibility long predate AI, and used to require enormous manual effort to account for every possible scenario, without ever fully solving it.

The constraint that makes it workable is the design system itself. Frameworks like A2UI don’t let an LLM build UI from nothing, they let it pull only from an approved toolbox. So the model can’t go off-system unless the system itself allows it. That reframes the anxiety: if your foundations, patterns, content guidance, and accessibility guidance are strong enough, what an LLM assembles from them should still be recognisably of the system, even if no human specifically designed that exact combination.

What this means for design system teams

If generative UI becomes a meaningful part of how products get built (inside your own product, or inside someone else’s chat interface), a few things follow:

Flexibility becomes non-negotiable. Complex, prescriptive components that only work one way become a liability. The job shifts toward providing composable parts and clear rules for combining them, rather than polished, single-purpose components.

A good real-world example of this is Newskit, the design system behind several major UK news publishers. The team shipped what they considered the definitive audio player component, and nobody used it. It turned out each product had its own audio player already, because the single “correct” version didn’t fit every context. The fix wasn’t a better audio player; it was breaking the component down into its parts, so teams could compose the version that actually fit their needs.

Flexibility doesn’t only mean “more props,” either. Some systems need a different kind of flexibility altogether: compliance flexibility. A system built for use inside third-party platforms, where you can’t hand over your actual components or code, might only be able to guarantee brand colours and tokens. That’s a much narrower form of flexibility, but it’s still a deliberate design decision rather than a compromise.

Content guidance stops being optional. If UI is being generated on the fly, nobody is writing the copy in the moment. You can’t be fully prescriptive about wording any more than you can about layout, but leaving it completely open is risky too. Most design systems today are thin on content patterns precisely because they’re harder to pin down than colour and spacing: that gap becomes much more visible once generation is involved.

Tracking and accountability need a home. When AI is assembling both interface and content, someone needs a way to check what’s actually being produced, even a sample of it, the same way design critiques and retros work for human-made decisions. This isn’t only a design system team’s job to solve; it sits alongside broader company processes (an ethics or review committee, for instance) for anything AI is generating on a company’s behalf.

The middle ground

Not every team is going to leap straight into full probabilistic UI, and that’s a reasonable response. A middle path getting attention is reactive progressive disclosure: the designer still defines the sequencing and the available patterns, but the system adjusts UI complexity based on a person’s experience and usage over time. It’s a transitional step between rigid, fully declarative interfaces and fully probabilistic ones, and it’s a much smaller leap for teams not ready to hand over control entirely.

Where this leaves things

Nobody involved in this conversation is claiming generative UI is guaranteed to become the standard way people interact with software: it might settle into something narrower, used well in specific contexts rather than replacing interfaces wholesale. But the parts of it that already exist are real, not speculative, and the direction of travel puts a lot more weight on the things design systems are supposed to be good at: strong foundations, clear patterns, and guardrails flexible enough to be composed in ways no single person explicitly designed.

The hardest sell in design systems has always been the long game: the foundations you invest in now pay off downstream, even if the returns aren’t always immediately obvious. Generative UI might be the thing that finally changes that. When an AI is assembling interfaces from your system in real time, the quality of what you’ve built stops being a philosophical argument and starts showing up directly in what users see. If this is where things are heading, then the case for doing the foundational work properly has never been more concrete.

Want to be part of the full conversation? This article covers the highlights, but the discussion goes much deeper. Watch the full Design Systems WTF episode on demand. 

A great design system is only part of the solution — you also need a scalable method for onboarding new users without overwhelming them.

Without a structured onboarding process, your design system is set up to fail because users will:

• Not understand the importance of the system
• Misuse tokens
• Spend time recreating solutions that already exist
• Promote individual solutions instead of rallying behind yours

All of these pitfalls lead to inconsistency, misuse, and technical debt across teams. The longer these problems persist, the less value your organization will get from your meticulously crafted system, and the more likely teams will abandon your system in favor of their own. 

Onboarding matters in design systems because it connects people to the content they need in the right way. This guide offers a phased approach to implementing onboarding for your design system, regardless of which type of user you are onboarding.

Setting expectations

Onboarding works best in 1:1 or small-group scenarios. In smaller organizations, the process may be led by the design system team or leaders from product teams that consume the system. Larger organizations may have dedicated onboarding or training teams.

If this kind of more personalized training is not feasible, async onboarding is still a worthwhile endeavor, and this article offers tips for adapting the process accordingly.

Phase 1: Introduction and tooling

Access credentials

Ensure that newcomers have access to all the tools necessary to understand and use your design system. For everyone, that typically includes access to a documentation site. 

Each area will have other role-specific tools. For instance, designers will need access to component libraries, foundations, assets, and plugins. Engineers will need access to the corresponding code repository and any demo applications they can use as references.

Design system overview

With access and credentials ready, define who owns the design system and establish a baseline understanding of what a design system is and why it’s used. While some users may already be familiar with the concept, many others likely won’t be. 

Focus on the benefits, such as:

• How consolidating component development within the design system team can save consuming product teams time and allow them to focus on more complex product features
• How a shared design library and code repository enable consistency
• How frequently the system is updated and how those updates impact teams

Tips

• This phase should take place within the first week of onboarding to the system.
• This content can live on your documentation site in an “About our design system” or a “Getting started” section. 
• At this stage, keep content high-level to avoid overwhelming your users — you can always add internal links for those who are more curious.
• For an async approach, consider recording a video introducing the concept of a design system.

Phase 2: Design system tour

Tour contents

After explaining the concept of a design system, give a tour of the system specifics. This part will likely differ by role, but should cover basics like:

Acronyms, phrases, and naming conventions

Every company has its own language. Define any important terms related to your system. For instance, does your design system have an abbreviated name? Do you use dashes or camelCase? While these details may seem easy for a veteran to understand, newcomers can get tripped up here and abandon their efforts to learn more.

Tokens

Explain how design tokens are structured and how to read them. Set expectations for where tokens are used (ideally everywhere), and explain if you have a tool in place to scan for token misuse. Visuals are useful during this part.

Foundations, such as grids, color, typography, and elevation

Explain the “why” behind the structure of these items. What breakpoints are used, and are they based on research? Were colors based on mathematically defined color ramps or picked from a limited palette? Does the spacing scale translate into typography, or are there separate scales? 

When the intent behind these decisions is understood, your users can internalize them more easily.

Assets, such as logos, icons, and illustrations

Share when to use which type of asset and if there are any defined sizes for each.

Components, patterns, and accessibility content

Don’t dive into every component. Pick a few simple ones and one more complex example to illustrate different features of your system. Showcase properties, variants, structure, and where to find accessibility information. 

Explain how patterns differ from components. Give examples of how both promote flexibility and predictability. 

System owners and help

Be sure to include information about who owns what part of the system and where to reach out for help — you don’t want to leave your new users without support!

Structuring your tour

Depending on your onboarding audience, the structure of your tour may take different forms. 

• One-pagers might be great for users who minimally interact with your system, such as interns or product owners. They might also be great for events that need to quickly onboard users to your system, like a hackathon. 
• Formal presentations are great for new leaders guiding teams that use the design system. In these situations, focus on topics like where to find rationale or usage guidelines.
• Anyone working closely with the system would benefit more from viewing this content where they will be referencing it repeatedly: your documentation site.

Two birds, one stone

Much of this content is already written on your documentation site, so use that to your advantage. Craft meaningful example imagery and optimize your content for scannability so you can reference pages directly as part of the onboarding process.

Tips

• This phase should take place within the first two weeks of onboarding to the system.
• Doing async training? Create a list of the top pages for new teammates to bookmark — or better yet, create a page directly on your documentation site with the most helpful quick links.
• Ensure all important topics are keyword-optimized and easy to find via search on your site.

Phase 3: Short exercise

Before setting newcomers loose, create a short exercise to test their skills. This exercise should vary by role and be led by immediate peers. 

Here are a few examples based on the team the person is joining:

• Design system team: Try an exercise where they apply tokens, practice building a component, or implement small bug fixes.
• Design teams that consume your design system: Set up an exercise to build a simple form page using the design system and its documentation. 
• Project management roles: Create an exercise to practice identifying how to integrate design system documentation into product requirements.
• Engineering roles: Develop an exercise focused on file setup, architecture, or accessibility compliance testing.

Tips

• Set expectations for how long this portion should take and who should review it.
• While this part of the onboarding process should be done with another peer, it could be completed asynchronously through comments or a pre-recorded video that outlines the expected outcomes.

Phase 4: Engage your community

Since a design system is always evolving, ensure that your community has multiple places to connect with others. 

Office hours

One of the best places for newcomers to learn about the design system is an informal office-hours setting with cross-team oversight and no predetermined agenda. Send invites to these sessions and encourage participants to come prepared with questions.

Message boards or channels

Utilize approved company tools to create places for public conversations. For instance, a ticket-based system can be used to ask questions or report bugs. Tools like Slack or Microsoft Teams can support discussions where everyone can chime in and help advance design system maturity across your organization.

Direct connections

Create a list of people to build relationships with who know the system inside and out — peer influence reaches farther than most documentation ever will. 

Encourage making connections both inside and outside of the design system team because there’s something to learn from everyone.

Tips

• This phase should take place for the first time within three weeks of onboarding to the system.
• Meet your new users where they are by having various avenues for communication.

Phase 5: Send a follow-up

After they have had some time to acclimate to the system and engage with your community, send your new users a follow-up message. This phase has a dual purpose. 

First, you want to encourage your new users to feel like their opinions are valued. Now that they’ve become more acquainted with the system, give them instructions for how to contribute to it. New components and patterns are major contributions, but even suggestions for improving documentation or small bug fixes are important. A sense of shared ownership will help your system scale.

Second, use this time to gain feedback on your onboarding processes. This part can be a linked survey or a few questions in your message. Ask questions like:

• On a scale of 1–10, how proficient do you feel compared to where you expected to be at this point?
• What confused you when learning the design system?
• What is one thing we could have done better when you started?

Tips

• Depending on the complexity of your system, this phase should take place about 60 to 90 days after the individual started their onboarding process.
• Onboarding is a journey — expect continuous feedback and refinement.

How to onboard newcomers to your design system — summary

Onboarding to your design system isn’t about simply reading every page on the documentation site or completing a checklist within a week. It’s about building a relationship with your users.

When there’s a clear onboarding process, adoption becomes easier, and the community becomes deeply entwined. Now your design system isn’t static documentation, but a shared commitment between teams. 

This is when you’ll see less friction, greater adoption, and deeper collaboration.

I do it too, usually in the first five minutes of onboarding a new stakeholder:

“Design system components are like LEGO bricks: modular and reusable. Snap them together, and you can build almost anything.”

Both LEGO and design systems offer a small set of standard pieces that can be recombined into a virtually unlimited range of shapes and ideas. Follow the guidelines the way you’d follow an instruction booklet, and the thing you build will look and work as it’s supposed to.

Why the LEGO analogy only goes so far

It’s a good elevator pitch. It’s also, I’ve come to realize, a metaphor we inherited from somewhere convenient rather than somewhere accurate, because what you’re usually after is more than pieces snapped together. Deliberate design imposes limits and creates a sense of unity, which a pile of interchangeable bricks doesn’t have to account for.

Every metaphor works the same way: It highlights certain features of a thing and hides others. That’s what makes it useful in the moment, and it’s also what makes it dangerous over time. A metaphor is a tool built for a narrow job. The trouble starts when our profession keeps reaching for it long after the job has changed.

LEGO is the clearest case of this happening to design systems. It explains the component library well, but it explains almost nothing about the discipline of maintaining one.

A tale of two objects

A LEGO set is a finished consumer product. You buy it, you open it, you follow the instructions, and you end up with something complete. The box has an end state, and once the model is built, the relationship between you and the product is essentially over.

A design system doesn’t have a box. It doesn’t have an end state or a moment when the instructions are finished being followed. It has to keep working as the browsers, frameworks, accessibility standards, and product UI around it keep changing.

A LEGO set asks to be completed once. A design system asks to be maintained indefinitely.

These are two different object categories, and no amount of careful language closes that gap.

The system around the system

When practitioners describe design systems using LEGO, we tend to describe the part that looks like LEGO: discrete, reusable pieces that snap together into something bigger. That is true, but it’s also the smallest part of the job, and treating it as the whole job is where the metaphor starts doing damage.

Why components get messy fast 

Start with the technical layer. LEGO bricks don’t have opinions about context; a 2×4 doesn’t care what it’s sitting next to. Real components do. A button inside a modal inside a toast creates z-index conflicts, focus-trap conflicts, and accessibility conflicts that no brick would ever generate, because composability in software is never free the way it is in plastic. 

Bricks don’t age, either: A piece from 1987 still snaps into a piece from this year. Components rot constantly, entangled with dependencies that update on their own schedule. And bricks arrive equally finished, while components live on a maturity spectrum — some stable, some experimental, some deprecated but still load-bearing. The metaphor has no vocabulary for any of that.

It’s more than just components

Then there’s what the product actually is. With LEGO, the instructions are secondary, and the bricks are the thing. With a design system, the documentation, the usage guidance, and the tokens are arguably more the product than the components themselves. Governance is the deliverable, not an afterthought. 

LEGO pieces are interchangeable in a way components never are: Swap a red brick for a blue one, and nothing happens. Swap a TextInput for a SearchInput, and you’ve introduced semantic and behavioral differences a passing resemblance can’t paper over. And where a LEGO set has a finish line, a design system doesn’t. It behaves less like a build project and more like a city’s road network — never done, only kept up.

A design system has more than one audience

And then there’s who’s affected, and how badly. LEGO has one audience: the person building. A design system has several at once: the team maintaining it, the designers specifying with it, the engineers implementing it, and the end users experiencing it. The metaphor collapses all of them into a single builder, erasing most of the actual stakeholders. 

That collapse matters, because the stakes are wildly different. A wonky LEGO house is a private disappointment. A misused component repeated across 40 product surfaces is an accessibility problem, a broken mental model, and a compounding maintenance bill.

None of these gaps is exotic. Each one is just what happens when a metaphor built for a toy gets stretched across a job with dependencies, audiences, and consequences the toy never had to account for.

Every brick is a decision

The LEGO metaphor implies that components arrive pre-made, much like bricks from the factory floor. Of course, they don’t. Every component a design system team ships is a decision with a long tail attached. It must be designed, documented, tested for accessibility, and adapted as the context around it shifts. Once it’s out, it’s a commitment the team is making to every team that adopts it, for as long as they depend on it.

A brick, once molded, requires nothing further from anyone. A component requires governance, support, and maintenance for its entire life. Those are materially different kinds of objects. Treating them as equivalent is how design system teams end up over-investing in the making of components and under-investing in the documentation, relationships, and stewardship that actually determine whether those components get adopted, trusted, and kept working.

The escape hatch is always open

Here’s the difference the LEGO metaphor obscures most completely, and it has nothing to do with plastic versus pixels.

With LEGO, the boundary between using the system and making your own pieces is a wall almost nobody crosses, because it requires injection-molding equipment. Once someone has the bricks, their use of the official ones is close to guaranteed.

With a design system, that wall doesn’t exist. The alternative to using the system’s dropdown is always one afternoon of custom code away.

That changes the entire nature of the work. Adoption is never secured once and then finished.  It has to be continuously earned from every engineer and designer who touches the system, because the local alternative — forking a component, writing a new one, skipping the request queue — is often genuinely faster, and frequently rational. 

A design system team isn’t just producing components. It’s in a permanent, mostly implicit negotiation against the default instinct of competent people to solve their own problems. That’s a harder job than snapping bricks together was ever going to prepare anyone for.

It’s also why “quality,” for a design system component, means something a brick never had to worry about. A brick only has to be a brick. A component has to be good enough, resilient enough, and well-documented enough that people don’t reach for the escape hatch, because the escape hatch is never locked.

What the metaphor hides

The LEGO metaphor hides that design systems are primarily social and political infrastructure, not technical infrastructure. The real work is negotiation, trust-building, and ongoing persuasion — none of which a brick has ever needed, because nobody has to convince an engineer that a brick is worth using.

It hides cost, too. Bricks are already made. Every real component has to be designed, documented, maintained, and re-tested as the ecosystem shifts, which makes the work look like assembly when it’s closer to legislation: writing rules that people can choose to follow.

What the metaphor causes

That hidden framing has consequences. It causes organizations to treat design system work as a build project with a finish line, funded like a LEGO set: Build the library, ship it, done. Maintenance goes chronically underfunded, because once the bricks exist, there’s nothing obvious left to pay for.

It causes teams to over-invest in producing components and under-invest in the governance and relationships that drive adoption. And it causes leadership to measure success by coverage — how many components exist — rather than by the harder questions of adoption, health, or responsiveness. 

What the metaphor prevents

Most importantly, the metaphor prevents an honest conversation about why people don’t adopt.

If a design system is just a set of free bricks, declining to use one looks irrational. But the alternative is always available, and often locally reasonable, and the metaphor has no room for that fact. It can’t explain why a thoughtful senior engineer might reasonably roll their own. And it can’t generate the right response, which is to make the system more trustworthy and flexible, not to mandate compliance.

It also prevents teams from treating deprecation and evolution as core work. LEGO bricks get released and forgotten. Real systems have to retire patterns and manage migrations — work the metaphor renders invisible, and which ends up belonging to no one.

The deepest thing it prevents is the correct self-image. A design system team is not a factory producing bricks. It’s an internal product team serving other product teams — a reframe that changes hiring, incentives, success metrics, and how feedback loops with adopters get built. The LEGO metaphor keeps design system teams in the factory long after the job has moved elsewhere.

The metaphor we can afford

None of this means LEGO was a bad metaphor to reach for. It’s vivid, it’s familiar, and it explains the component-library layer of the work well enough to onboard a stakeholder in one sentence.

The problem was never that the metaphor was chosen. The problem is what happens when a metaphor built for a one-sentence explanation gets asked to carry an entire discipline’s worth of nuance.

This is true of borrowed language generally, not just LEGO. Every metaphor is a trade: It makes something easier to explain by making something else easier to forget. That trade is fine as long as you remember you made it. It stops being fine when the metaphor becomes the mental model an organization plans around; when funding, staffing, and success metrics get built on the assumption that the work is assembly rather than legislation.

No single metaphor holds for long

If you’re looking for a better metaphor, thinking of a design system as a city’s infrastructure gets closer, and even that eventually breaks down. That’s probably the proper conclusion: Design systems are complex enough that no single metaphor holds for long. The discipline is better served by practitioners who treat every metaphor, including their favorite one, as a temporary and partial tool rather than a description of the work itself.

Instead of looking for the perfect replacement image, we need to stay aware of what any given metaphor is asking us to forget.

Designers worry they’ll be replaced.
Engineers wonder if they’ll still be writing code in five years.
Product managers quietly wonder if they’ll still be writing Jira tickets (I certainly do).

But I think we’re asking the wrong question.

The question isn’t whether AI replaces design systems.

It’s whether your design system is ready for AI.

Because AI is incredibly good at moving quickly.

It’s also incredibly good at scaling whatever you give it.

Good or bad.

AI is only as good as the system behind it

For years, we’ve described design systems as consistency tools.

A faster way to build.

A nicer developer experience.

A way to avoid 20 shades of blue.

All true.

But AI changes the conversation.

AI doesn’t know your product.

It doesn’t know your brand.

It doesn’t know why one button should be destructive and another shouldn’t.

It only knows the information you give it.

Which means your design system is no longer just documentation.

It’s becoming the instruction manual.

If the manual is clear, AI becomes incredibly powerful.

If the manual is messy…

Well, AI just gets really good at making inconsistent interfaces incredibly quickly.

AI loves structure

This is where tokens become even more valuable.

We’ve already seen how tokens make rebrands easier.

Now they do something else.

They give AI structure.

Instead of telling AI…

“Use the blue button.”

…you tell it…

“Use Button.Primary.”

Instead of asking it to guess spacing…

It references your spacing tokens.

Instead of inventing typography…

It references your typography scale.

The more structured your system becomes, the less AI has to guess.

And that’s a good thing.

Consistency stops being a nice-to-have

When humans build products, inconsistency creeps in slowly.

One engineer chooses 20px.

Another chooses 24px.

Someone copies an old component.

Eventually, you tidy it up.

AI doesn’t work like that.

If your system is weak, AI can repeat the same mistake hundreds of times before anyone notices.

The problem isn’t AI.

The problem is that AI scales inconsistency just as efficiently as it scales consistency.

The real job doesn’t change

There’s a narrative that AI means designers and PMs will spend less time making decisions.

I actually think the opposite.

The tactical work gets faster.

The strategic work becomes more important.

Someone still needs to decide:

• Should this become a component?
• Should this pattern be deprecated?
• Is this accessible?
• Does this fit our product principles?
• Does this improve the customer experience?

Those aren’t AI questions.

Those are product questions.

And I don’t see them disappearing anytime soon.

This is why adoption is suddenly even more important

One thing I keep coming back to is adoption.

A design system is only as good as the people using it.

That was true before AI.

It’s even more true now.

If half your teams use the system and the other half build their own patterns, AI doesn’t know which version is the right one.

Suddenly, adoption isn’t just about consistency.

It’s about trust.

Can people trust what AI generates?

Only if AI can trust the system.

Documentation is becoming product infrastructure

For years, we’ve treated documentation as something you eventually get around to.

AI doesn’t have that luxury.

It needs documentation.

Clear APIs.

Usage guidance.

Dos.

Don’ts.

Examples.

Intent.

Not because humans can’t work without it.

Because AI can’t infer what isn’t written down.

Good documentation is becoming part of your product infrastructure.

How teams can prepare today

The good news?

You don’t need to reinvent your design system.

You just need to strengthen it.

I’d start with five questions.

• Are your tokens complete and well-structured?
• Are teams actually adopting the system?
• Are components clearly documented?
• Can you identify duplicated patterns?
• Would a brand-new engineer know exactly how to build your UI from the system alone?

If the answer to any of those is “probably not”…

That’s your roadmap.

AI doesn’t replace design systems

If anything, it raises the bar.

For years, we’ve justified design systems because they improve consistency and help teams move faster.

Those benefits still exist.

AI simply amplifies them.

Strong systems become stronger.

Weak systems become more obvious.

Maybe that’s the biggest shift AI brings.

It doesn’t replace design systems.

It exposes the ones that were never really working in the first place.

Charlotte MacInnes was a guest on our webinar “Trends in design system processes and management“, alongside Michelle Chin and Taylor Cashdan. 

She finds the right page and starts filling in the form. But her kids need help with something. So she deals with it, then comes back to the screen. The form has timed out. Everything she entered is gone.

She starts again. Gets further this time. Then her phone rings. When she comes back, the same thing happens.

She closes the tab. Her insurance doesn’t get renewed.

Every component on that page probably passed its accessibility audit. The contrast ratio was right. The labels were present. The ARIA was clean. And still, Amy — who has ADHD, and who is also just a person with kids, a phone, and a life — couldn’t complete the task.

Amy doesn’t file a bug report, though. She just leaves. And somewhere in your product analytics, her session is recorded as an abandonment with no further detail.

How undocumented decisions become user problems

Here are the design systems questions Amy’s experience raises: Did the system that built that form document what should happen when someone steps away mid-task? Did any documentation specify that progress should be saved? Were there guidelines for what the timeout message should contain — and how to help someone start again without losing everything?

If that documentation didn’t exist, that failure wasn’t a developer decision. It was a design systems gap. And it will happen on every form built from that system, by every team, for every user who needs a little more time.

That’s the cognitive accessibility problem. And it’s not accidental — it’s structural. Not caused by individual failure, but by the absence of decisions that should have been made in the system and weren’t. Those gaps don’t announce themselves. They get filled anyway — by team turnover, new teams building from the system without context, and AI tools defaulting to whatever pattern appeared most frequently in their training data.

Why gaps in design systems create gaps about people 

Carbon is IBM’s open-source design system — actively maintained, rigorous on accessibility for visual, auditory, and motor categories, and the foundation for every digital experience IBM builds. Product software. IBM.com. Internal tools. Conversational agents. An entire ecosystem of experiences, all consuming Carbon assets and guidance.

That foundation has three sentences on cognitive accessibility: Avoid complex language, avoid autoplaying animations, and pass usability heuristics.

This isn’t a criticism of Carbon or the team that built it. Carbon represents the current baseline: what a well-resourced, carefully maintained design system looks like when a team takes accessibility seriously. But the current baseline isn’t enough for cognitive accessibility.

Not every decision is made equally

When Carbon doesn’t answer a question — for example, what should happen when someone steps away from a form mid-task, what an error message should specifically contain, or how navigation should behave consistently across every product in the ecosystem — that question doesn’t stay unanswered. 

The answer gets decided by each team independently, under a deadline, with whatever judgment is available to them. Across IBM’s entire product portfolio and every external team building from the open-source layer, AI tools increasingly fill those gaps with inherited patterns.

Undocumented decisions don’t stay undecided. They get decided badly, at scale, by whoever or whatever is building next. And the cost of those decisions isn’t shared equally — it falls on the people who don’t fit neatly into your average user profile. The ones who close the tab and don’t come back. The ones your analytics records as an abandonment with no further detail.

Like Amy.

Why should we care?

However, before a design system can answer the questions cognitive accessibility raises, someone has to argue successfully that those questions are worth asking. Eric Bailey — who has written about cognitive accessibility on this blog — names the gap that comes before the documentation gap:

“The hardest cognitive accessibility question our team gets asked is ‘Why?’,” he says. “It’s never asked directly. Instead, it’s indirectly asked as ‘Why should we care?’ There are a few factors at play: unconscious ableist attitudes, incentive structures that don’t reward what is perceived as the unglamorous parts of the work, and the myopia of people designing and building for their own immediate biases and preferences.”

In many organizations, that argument is still being lost. Which means the documentation gap never gets a chance to close.

The questions your design system doesn’t automatically answer

Cognitive accessibility can’t be validated by a checker or guaranteed by a component. Whether someone can find their way back mid-task, whether an error message is clear enough to act on under stress, and whether navigation is consistent enough to build a mental model — these are all emergent properties of how a whole system behaves. They can only be committed to in documentation and governance — and commitments that aren’t written down don’t hold up later.

Eric Bailey describes a recent service launch at his organization — built by highly technically literate people, geared toward a wide general audience:

“User testing revealed many less technically literate peers struggled to onboard, understand interaction paradigms, or recover from corner case situations and error states,” he explains. 

“All too predictable, yet a lesson that apparently needs to be learned over and over again. On the upside, this learning did communicate the value of speaking with the actual people who use your product. The research team is now actively supported and engaged — I hope this momentum is carried to other areas of the product, as well.”

The system was built by people who knew exactly how to use it. It wasn’t built for the people who needed to.

Translated into the specific questions a design system should answer:

What should happen when someone steps away mid-task?

Most design systems document what a form component looks like. Almost none specify what should happen when someone with ADHD, a memory impairment, or just a demanding life gets interrupted and comes back 20 minutes later. 

Should progress be saved? For how long? What should the interface tell them when they return? This decision is made by every team that builds a multi-step flow — or it gets filled by AI with whatever pattern appeared most frequently in the training data.

Some government design systems are beginning to answer this question explicitly. The DWP Design System’s session timeout pattern includes a principle that directly addresses Amy’s situation: “Consider if your users might need long periods away from the screen, for example to collect documents or look up information.” 

The UK Home Office pattern goes further — so that people using a service are told whether their information or progress will be saved, and are taken back to the page they were on when they sign back in. These patterns demonstrate examples of documented answers to a question that most design systems leave open.

What should an error message actually say?

Most design systems show what an error state looks like. Very few specify what it should contain. “Invalid input” is not an error message for someone with a reading disability or a traumatic brain injury trying to recover from a mistake. This is a documentation decision that belongs in your component page — and if it isn’t there, every team and every AI tool will write their own version.

The stakes of getting that language wrong are higher than most documentation currently acknowledges. 

“When someone in crisis comes across content — any content — we have to remember that their brain isn’t working as well as it normally does,” explains Rachel Edwards, a lead content designer and the editor of Designed With Care: Creating Trauma-Informed Content. “They are flooded with stress hormones that make it harder to think, reason, make decisions, and understand information or actions. Doing something that they might find easy on a good day becomes incomprehensible, or even impossible.”

Rachel points out that this is something most people have experienced without naming it:

“Ever said, ‘Slow down!’ or ‘Just tell me what I need to do’? That’s us being overloaded, stressed, and unable to take in and process information.”

And the implication for how design systems encode language is even more specific than most documentation currently reflects:

“Sometimes the kindest thing you can do for someone who is stressed and overwhelmed is to just tell them clearly and simply what they need to do — rather than trying to empathizse or tell them how they feel, “ Rachel says. “Technical jargon that makes its way in front of the user — it happens! — can risk causing confusion and even harm to someone.”

How should navigation behave consistently across every product?

Instructional design also doesn’t have to predict outcomes to be useful. It can simply act as in-the-moment scaffolding to make a situation easier, and that same principle works for navigation consistency across every product. 

Because consistency isn’t a component property. It’s a system property — it emerges from how your entire product ecosystem behaves, across every team, every surface, every release. For someone with memory difficulties or dementia, an interface that behaves differently from one product to the next isn’t just frustrating. It’s a barrier that compounds with every interaction.

Rachel recommends going back to basics — subtracting, even — rather than adding to what already exists: 

“When we design for cognitive accessibility, we’re usually not talking about adding a whole lot of new things to our design practice. Many best practices already work really well for people who are in crisis. Things like short sentences and simple words are great. So are things like one question per page, lots of white space, and letting someone know where they are in your service.”

Why cognitive accessibility for design systems is urgent now

WebAIM’s 2026 Million report recorded the first reversal in six years of web accessibility progress. A stunning 95.9% of homepages now fail WCAG — up from 94.8% in 2025, with errors per page jumping 10.1% in a single year. WebAIM attributes this directly to AI-assisted coding — what they call, without irony, “vibe coding.”

AI was trained on a web that was already failing. When teams started shipping with AI-assisted coding tools, those tools didn’t fix that — they learned from it and reproduced it at scale.

As systems and platform designer Anna E. Cook argued in her axe-con 2026 keynote: “If our system is accessible, it’s structured. If it’s structured, it’s parseable. If it’s parseable, AI can interpret it and create from it. When the foundation is wrong, no layer on top can fully compensate.”

AI inherits your design system. The questions it doesn’t answer, AI fills with pattern. And the pattern it learned from was never designed for Amy.

What shared responsibility looks like in practice

Cognitive accessibility in government services rarely fails because nobody cared. Often, these initiatives fail because the questions that need answering don’t belong to any single role — and without a clear home in the system, even the best questions don’t get answered consistently at all.

Designing beyond individual components

Stéphanie Krus is a senior service designer in the UK’s public sector, where she helped develop the DWP Accessibility Manual’s guidance for the service designer role. On the mid-task interruption question, she points out why documenting this type of guidance can be harder than it initially looks:

“If the information people are entering is sensitive — which is the case most of the time in government — we need to reduce the risk of someone accessing this, whether it’s in a public area like a library, or at home, where it might be dangerous if someone else knew they were doing it. Should we save each step? If so, do people need to create an account? Having yet another account can have a cognitive cost, too. If the person is told ahead of time what they will be asked for, they can prepare the information we might request — or decide that now is not a good time to start.”

Stéphanie mentions the GOV.UK exit page component as one example of a design system encoding a response to a specific human safety need — a component that exists precisely because someone asked what happens when a person needs to leave a service quickly and safely.

The governance challenge extends beyond documentation into how teams test and collaborate across the whole service.

“Designing a time-out involves the tech people,” Stéphanie argues. “Designing an upload functionality involves interaction, content, user research, and tech — can we help people ensure they are uploading the right file? Can they preview it once uploaded? If they struggle, are we providing good error messages, and at what point in the interaction? It’s hardly ever about just one role.”

Cognitive accessibility isn’t a component problem, a content problem, or a developer problem. It’s a systems problem — and it only gets solved when everyone on the multi-disciplinary team knows their part.

“We need to test whole journeys, not just steps in the end-to-end journey and across different channels, to understand where we might be inconsistent, where we might have gaps,” Stéphanie recommends. “When we do accessibility testing, we need to go beyond screen reader users or visual impairments and make sure we also test with people with various cognitive disabilities, so their issues can be surfaced.”

Why cognitive accessibility is also about safety

That testing imperative connects directly to a broader point about what it means to design safely — not just accessibly.

“The most important thing a system or service can be is safe — yet safety is often left out of the design process, either through a lack of understanding or a belief that it’s designing for too narrow an edge case,” says Kieran Cutting, a service designer in the UK public sector who has written about how safety and accessibility are inseparable in digital public services. “In reality, the people who most need a service are often the same people most likely to be harmed by it if safety isn’t designed in.”

“Design well for cognitive accessibility, and you’re often already designing in a trauma-informed way: being as transparent as possible, building in choice throughout someone’s journey, and keeping their safety at the forefront.”

That consistency isn’t just about usability — it’s about giving people the conditions to feel safe enough to continue.

“Recurring service patterns help people prepare to engage with them. When an organization asks for my address history, I already know it’ll want the past five years, because I’ve seen that pattern before. Patterns like these help people feel prepared, anticipate what’s coming next, and pick back up where they left off if something becomes too difficult to continue in the moment.”

And the stakes are highest precisely when the information being requested is most sensitive.

“Cognitive accessibility matters even more when you’re asking for information that might be difficult or retraumatizing to give,” Kieran points out. “You need to be certain you’re only asking for what’s actually necessary — both to minimize the chance of that becoming a harmful experience, and to make sure people can safely and accurately recall or access what you’re asking for.”

Why advocacy matters even when it isn’t always rewarded

None of this is easy to argue for inside most organizations — and the practitioners doing it know that better than anyone.

Eric Bailey speaks to how the work can often feel unofficial, or driven by personal initiative:

“Cognitive accessibility issues are difficult to quantify, hence WCAG not having much coverage of the concern. Without a measurable metric, most organizations won’t invest the resources needed to do the work. You won’t get rewarded for making cognitive accessibility considerations more visible. However, doing this quiet future-proofing work does go a long way — especially when you consider the actual human impact.” 

The wins are invisible, and the case has to be made over and over. But the decisions that get made in your system — the questions you answer, the intent you document, the consistency you govern — are the ones that travel. The ones that hold. The ones that shape real people’s lives.

Every decision encoded in a design system is a decision made on behalf of every person who will ever use a product built from it. Most of those people will never be in the room. They’ll never be consulted. They’ll never file a bug report. They’ll just experience the consequences of decisions made without them — or feel, sometimes without knowing why, that something was made with them in mind. 

The current reality is that cognitive accessibility isn’t easy, and there isn’t a templated checklist that solves it systematically. Questions need to be asked out loud, answered as a team, and documented widely enough that the answers survive — across roles, across sprints, across the whole organization. That’s harder than a checklist. It’s also the only thing that actually works at scale.

People are the point. The system is how you reach them.

Amy is a composite persona drawn from W3C cognitive accessibility research. She represents documented patterns of real experience, not a specific individual.

And for a deeper dive on how accessibility intent gets lost between base and product systems — and what to do about it — Anna E. Cook’s piece on this blog explores when to stay within a system, and when to deviate from it.

But no system can cover everything.

New product requirements appear that nobody anticipated. Edge cases surface that sit a bit awkwardly between two components. Teams face the same problem with two equally valid solutions and no clear way to choose. At some point, every design system runs out, and someone still has to make a call.

This is one area where design systems can painfully fall apart. Not in the parts they define, but in the gaps between them.

Where decisions still happen

Every design system has its edges. These edges aren’t a sign of failure; they’re expected and inevitable.

The most common example is the extend-or-create decision. The design system has a card component. The new design needs something card-ish shaped but different enough that using the existing one means accepting compromises. Do you adapt the component and absorb the inconsistency? Do you build in some technical complexity into the overall component to make it simpler to use? Or introduce a new one and absorb the overhead? The system doesn’t tell you.

Then there are pattern conflicts. Two established patterns both solve the same problem in slightly different ways. Both are documented. Both have precedent. The system offers them without ranking them.

And then there are edge cases: scenarios that weren’t anticipated when the system was built, with no documented guidance and no obvious parallel to draw from.

In each case, the system has run out. Someone somewhere still has to decide.

When decisions aren’t guided

We’ve all been in those meetings. A decision needs to be made, more and more people get invited, and the discussion goes nowhere. It’s not because the people in the room are indecisive. Everyone has a piece of responsibility, but nobody owns the decision.

Without anything to guide those decisions, teams reach for whatever’s available.

Usually, that’s consistency. Sometimes it’s precedent. Sometimes it’s whoever has the strongest opinion in the room, or whatever the deadline pressure demands. One-off exceptions get quietly built into the product and never reviewed. Debates get resolved not by good reasoning but by strong opinions or external pressures.

These aren’t failures of process. They’re failures of guidance. They’re what happens when the system doesn’t give teams anything better to work with.

When principles guide decisions

Most design principles in design systems don’t guide anything. They sit in a Notion or Confluence doc, get printed as a poster, referenced in a kick-off meeting, and then quietly disappear from actual work. Sometimes teams document them inside the design system itself, but do they actually ever turn to them when gnarly decisions come up?

You’ve seen them. “Be consistent.” “Accessible design for everyone.” “Keep it simple.” They sound right. Everyone loves them. They’re easy to agree with. They make people feel good. But when a team is looking at two valid options and needs to choose, these kinds of principles don’t help.

How do they resolve trade-offs? How do these principles guide any kind of decision? Are these values and ideals, rather than principles?

A principle that’s actually doing its job looks different. It shows up in a design review. It gets referenced when someone is deciding whether to extend a component or create a new one. It gives a team a shared reason for a decision, not just a shared outcome.

The test is simple: If your principles aren’t helping teams choose between options, they’re not doing their job.

The decisions principles should be making

Think about the scenarios in a typical design system where teams get stuck.

Should we extend this component or create a new one? A principle around coherence over completeness points you toward an answer; better to have fewer, well-defined components than a sprawling system that covers every edge case or a verbose one-size-fits-all complex component.

Which pattern do we use when two valid options exist? A principle around user familiarity over internal consistency points toward the pattern users already understand, even if it’s not the one the system prefers.

None of these decisions are difficult in themselves. What makes them slow and inconsistent is the absence of anything to guide them. Principles don’t remove the judgment; they give the judgment direction.

Why principles rarely do this

The same problems come up again and again.

Principles are too vague to apply. “Prioritize accessibility” doesn’t help when accessibility should never be up for debate in the first place. Accessibility is too important to be a principle. If you treat it as one, it becomes something that can be weighed against other principles and deprioritized. It’s a standard, and standards shouldn’t be flexible.

Principles duplicate what the system already enforces. If your components already use an 8px grid, “be consistent with spacing” isn’t a principle. It’s a rule the system handles automatically. And principles don’t show up where decisions are made, not in design reviews, not in contribution discussions, not in the conversation about whether to extend or create.

When principles do work, the difference is visible. They get referenced in discussions. They’re used to justify decisions, not just validate them after the fact.

One practical starting point: Add your principles to the documentation for the components they most directly affect. Not as a header or a footnote, as a reason. “We made this decision because of this principle.” Do that consistently, and principles stop being a document and start being part of how the system thinks.

Principles are for the gaps

A good design system doesn’t eliminate decisions. It handles the ones that don’t need judgment, so the ones that do can get it.

Most systems do the first part well. The second part, giving teams a way to make good decisions in the gaps, is where design principles should be doing the work. For most teams, that space is just empty.

Recently, I interviewed her to find out which digital designs work best for her needs and preferences for when she uses websites and mobile apps day to day.  

In this article, I’ll cover design best practices based on what I learned from my session with Victoria as a JAWS and Braille display user. I’ll also suggest some actions to take in your design system to help your team understand blindness-related needs, what’s required for WCAG compliance, and how to avoid usability barriers. 

Introducing Victoria

Victoria is based in Toronto, Canada, after living in Texas for 13 years, where she earned a Master’s degree in Education. She holds her CPACC certification from the International Association of Accessibility Professionals (IAAP) and now educates organizations on designing for blind users by conducting screen reader demos.  

Tori is trilingual, fluent in English, Chinese, and Braille. She uses JAWS and a keyboard on a PC laptop to browse websites. 

For mobile, she uses an iPhone SE 2020 with iOS 26.5.

1. Make page content sequence logical and meaningful

Whether it’s on a desktop, tablet, or mobile, Tori usually first interacts with a page or screen by starting at the top and working her way down. She navigates the content in sequence, listening to the screen reader output to understand what’s on the page.   Once she has all the information, she decides what to do next. 

Tori said: “For me, it’s easier if the design is more linear and I can just go down the screen using my arrow keys. It flows a lot better.” 

Set structure and meaning with headings

Some screen reader users navigate differently. They press the H key in JAWS or NVDA first to find all the headings on the page and see what content sections are present. This is why a proper nested heading structure, starting with H1, is critical for so many.  

Here’s a good example of the importance of sequential order: In 2013, I was a user researcher at a prominent bank. We began testing our digital product designs with people with disabilities, including blind screen reader users. The banking website had all of the required information to open a bank account, like age, country of citizenship, and location on one page. That sounds helpful, right? Not so much for the non-visual user. This content was placed underneath the “Open bank account” call-to-action button.  

In the study, blind users selected the button to start the application process without hearing this information first. That caused frustration when they got several screens into the application, only to be rejected when they didn’t meet the basic requirements. Designers stepped in and resolved the issue by moving the information above the CTA button. 

In fact, they moved it to the top of the main body content. Sighted visitors saw it right away, and screen readers announced it immediately.

On mobile, screen readers use swipe gestures

On a mobile or tablet device, when the built-in screen reader is turned on, users navigate by swiping left and right. This is similar to using the Up and Down Arrow keys on a keyboard to move through a web page on desktop.

On iOS, the built-in screen reader is VoiceOver, and on Android, it’s TalkBack. 

Tori said: “I’ll turn on VoiceOver and then browse the main screen on my phone. I’ll swipe left and right, and it reads out the names of all my apps. Then I’ll open an app by double-tapping on it.”

This is a good reminder for designers who want to build a rotating image carousel using swipe gestures to navigate the slides. Sometimes people will access that carousel on a mobile device. Sometimes a blind person will access it with a screen reader, in which case the swipe gesture gets overridden.

Include navigation controls on carousels and interactive wizards

For this reason, designers should add previous and next button controls to move the carousel slides back and forth (keyboard users need this too!). When the screen reader is on, users can double-tap to activate the buttons.   

Similarly, keyboard users can press Enter or the Left and Right Arrow keys to move through the slides. 

Actions to take in your design system:

• Turn on the screen reader on desktop (VoiceOver, JAWS, NVDA, Narrator) and use the Up and Down Arrow keys to move down a web page. Listen to the screen reader output. Next, turn on the screen reader on mobile and swipe your finger back and forth to navigate.
  
  In both cases, does the sequence make sense if you can’t see the screen? 
  
  Is there any important information that’s below major calls-to-action that should be higher on the page and more prominent so it’s not missed if you can’t see the screen?
  
• Include the WCAG requirements in your documentation:
  
  1.3.2 Meaningful Sequence (A)
  
• Reference the W3C tutorial for carousels:
  
  W3C Carousels Tutorial
  
• Reference these iOS and Android features:
  
  Apple iOS: Turn on and practice VoiceOver
  Android: Turn on TalkBack

2. No sudden moves

When Tori is navigating with the Up and Down Arrow keys, she’ll come across a navigation menu list or combobox. She will press the Tab key to access the element, and then use the Up and Down Arrow keys to interact with it and hear the selections inside it through her screen reader.

Interacting with it alone, that is, simply browsing through the menu items, should not suddenly select an item for you! This kind of behavior feels unexpected. Selecting an item can cause an immediate change to the page’s content (or even goes to a new page), which isn’t visible to a blind user, leaving them confused and lost.

To ensure this doesn’t happen, developers and UX designers can work together to select a basic HTML element and design a combobox with a “Select” button next to it, respectively. WCAG has some pretty fundamental guidelines against this as well: On Input and On Focus.

Tori said: ”Just have the buttons available separately so that the JAWS user can press Enter in order to select the options. It’s a lot better if the web designer thinks about these things in advance.”

Her expectations:

• Press the Enter key inside a menu list to activate it. 
• Select an item in a combobox, then use a separate button to trigger the action. 

Similarly, keyboard focus on the element should not trigger it immediately either. 

Actions to take in your design system:

• Include the WCAG requirements in your documentation:
  
  3.3.2 On Input (A)
  3.2.1 On Focus (A)
• Reference the W3C tutorial for menus:
  
  W3C Menu Structure Tutorial 

3. Ensure tables announce the column header

Victoria knows the pain of navigating a large, complex data table on a website, or worse yet, websites that still use tables to create the structure of the page!

“A website that is designed in a table and grid format is extremely frustrating,” she said. “I have to manually tab through each cell on the keyboard with my screen reader on, remember what was said in the previous cell, and it really doesn’t flow.”

This is similar to navigating spreadsheets in Excel or Google Sheets. 

It’s a lot to take in and remember as you try to track the relationship between the column header and the individual cells underneath it, across several columns and rows. 

For this reason, users rely on tables being coded properly so screen readers announce the column header each time the user moves into a new cell. This keeps the context in place, so they’re never lost. Developers can make sure this happens. 

UX designers can also avoid using data tables whenever possible. Ensure the information absolutely needs to be presented in a table, which means the content relationship is most efficiently shared in a structured way across columns and rows. Screen reader users have to understand this relationship between data points without visual context, relying on speech output alone.

See if there’s a way to present the information in a more linear fashion, for example, a heading with the key subject and data points listed below. That’s easier for everyone. 

Actions to take in your design system:

• References this Medium article about whether tables are the right UX choice.
  
  Align UX and content on table use and document the guidelines.
• Include the WCAG requirements in your documentation:
  
  1.3.1 Info and Relationships (A)
• Reference the W3C tutorial for tables:
  
  W3C Tables Tutorial 

4. Think beyond keyboard inputs

When she fills out forms online on a laptop, Tori quite often uses a Braille display device, or Braille terminal, for input instead of a keyboard, as it feels like a native language to her.  

If you haven’t seen one in action, it’s a board that connects to your computer with pins that move up and down to form Braille in real time instead of keys. 

On desktop, Tori describes the interface on screen as “a virtual keyboard, and it displays six dots on the left and six on the right. Then, I just type onto the Braille board.”

Tori can hook the Braille display up to her mobile phone. “When I’m inside an app, I’ll change the settings using a rotor in a dialog that pops up on screen,” she said. “I turn the rotor to ‘Braille’ to let it know I’m using Braille for input.”

Best practices for designing with Braille users in mind

Here are some helpful design tips from Megan Dausch, an accessibility specialist at Helen Keller Services:

• Avoid the “narrow window” problem. Because Braille displays show so few characters at a time, word choice in labels and menus really matters. Redundant text (like repeating a company name before every menu option) forces the user to scroll through repeated content before they get to the meaningful part. Keep content and labels concise. 
• Don’t manage keyboard focus. Allow the default. This is where the cursor or active spot on the page jumps unexpectedly, like bouncing to the top of a page after filling in a form field. It’s disorienting for all users, but even more so for someone who only has 12 characters of context to figure out where they ended up.
• Minimize dynamic content. This refers to parts of a page that update on their own, like chat messages arriving. A speech-based screen reader user might hear a notification pop in, but a Braille user might miss it entirely if it only briefly flashed across the display while they were typing. 
• Don’t assume audio is enough. If you’re developing something for blind users and default to audio-only design, you’re excluding Deafblind users and Braille users who rely on text output for privacy or precision.
• Include Braille users in testing. Braille users will have a different experience and give feedback that audio-only screen reader testers may not.

Actions to take in your design system: 

• Reference Megan’s design tips in your documentation:
  
  Between the Dots: What Designers Miss Without Braille Users
• Book a Braille display demo session with Tori!

5. Don’t lose good, old-fashioned contact methods

In the world of AI chatbots and seemingly streamlined online communication, a phone number and email address can sometimes still be the best way for blind users to connect with your business. For Tori, it’s also the fastest way to contact a company about a technical barrier on the website. 

“Phone is the best communication channel for me, because I prefer talking to a human rather than a bot,” she said. “It’s always easier to resolve a technical issue when you can converse with an actual person. Sometimes the problem can be lost in translation with email or chat, or in some cases, it takes longer for me to get the support I need. When I’m talking to a person, however, I know I’m always guaranteed support.  

Even if I don’t get my issue resolved right away, I feel better knowing that I at least spoke with someone.”

Tori said the Microsoft Disability Answer Desk team is able to access her computer remotely and fix problems in real time, which gets her out of a jam. 

Apple’s Support Line doesn’t operate mobile phones remotely, but you can send them screenshots, and they’ll review the problem. The team makes notes in a file and submits them directly to Apple engineers.

Actions to take in your design system:

• Encourage content and UX designers to include a phone number and email address in the footer where they’re expected to be and easy to find when a blind user navigates without visual cues.
• Offer an “answer desk” or feedback channel via email, and build guidance for content and UX designers, as well as customer service stakeholders, right into the design system. 
• Outside of the design system: Invest in disability training for customer support workers, and once there’s shared knowledge and collaboration internally, reflect these options in your interface design.

6. Look to banking apps for good accessibility

When asked which experiences really work for Tori, she answered that many native banking apps get it right. 

“I feel like financial institutions have accessibility in mind when designing these apps,” she pointed out. “The small-screen format is very accessible because I can navigate it quickly. I find that on the app, the experience is more organized and less cluttered.” 

Also, they are compatible with Braille display devices. “I can just press certain buttons if I want to do my banking and type using my Braille screen input.”

“If I need to do something quick and easy, like my banking, I prefer using the phone because I find it a lot faster and more convenient. Many banks pride themselves on accessibility and have worked to make apps accessible.” 

Summary of the basics

It was really interesting to speak to Tori and understand her navigation style using the Up and Down Arrow keys and a Braille display. 

Here’s a round-up of the basics to remember when designing for a wider base of blind screen reader users:

Structure and navigation

Use a clear heading hierarchy (H1-H6). This way, screen reader and keyboard users can jump between sections using the H key. 

Use descriptive link text (e.g., “View our return policy” instead of “Click here”). Screen reader software like JAWS and NVDA provides a quick list of all links on a page using shortcut keys (e.g., in NVDA, press Ctrl + F7). If all links in the list are labeled “Click here”, out of context, users can’t distinguish their purpose.

Use “skip to” navigation links. This is the shortcut at the top of a page that lets keyboard users jump past the menu and straight to the main content. It’s hidden until engaged with the Tab key. On each page load, keyboard focus jumps back to the top left corner, so being able to quickly skip to the main content is critical. Otherwise, the experience is incredibly tedious, especially for blind users. 

Define a logical Tab order sequence. Similar to ensuring meaningful sequence for the entire page when using Up and Down Arrow keys, keyboard users like Tori can also press the Tab key to move through interactive elements, like buttons and links. Keyboard navigation order should match the visual layout and not jump around randomly. 

Content and labels

Provide alternative text on all informative images. Those are the short descriptions that the screen reader reads aloud in place of the image. If an image or graphic is simply for decoration, however, developers can code the <img> with alt=””.

Use descriptive labels for buttons and interactive controls. The label should be short, concise, and define what the button or control does when the user selects it.

Label all form fields. That way, when a screen reader lands on an input field, it announces what to input, e.g. “email address” rather than just “edit field”. Include helpful instructions like the date format (DD/MM/YY). Put “required” in the label, or if you use an asterisk (*), ensure developers code the input field with “ARIA-required” so this is announced automatically by screen readers. 

Use HTML elements wherever possible. Screen readers automatically announce the element for what it is (semantically), for example, <button>, <nav>, or <list>. 

If that’s not possible, use ARIA labels on custom interactive elements. These are the invisible text tags that tell the screen reader what non-standard buttons, menus, or widgets do, and help distinguish them from one another. For example, if there are two <nav> menus, use aria-label=”Primary Navigation” on one, and “Secondary Navigation” on the other. 

Create meaningful page titles. It’s the first thing a screen reader announces when a page loads. Put the unique page subject first (for example, “About us”), followed by the site or company name (for example, “Journey Accessibility”). 

Interaction and feedback

Ensure full keyboard accessibility. Every action you can do with a mouse should also work with just a keyboard, since screen reader users don’t use a mouse.

Ensure error messages are tied to the relevant field. Consider using inline error handling so this is announced once a user interacts with a form field. Or, allow a user to complete and submit a form before errors appear. If they do, provide exact instructions on which fields need fixing and what information is missing. Then add a link that jumps the user to the first field that needs correcting. This is incredibly helpful for blind keyboard users. 

Make sure status updates are announced automatically. For example, “Item added to cart” can use an “ARIA-live region”. Live regions are coded as a designated area of the page that the screen reader monitors and then reads aloud when content changes.

Things to avoid

Avoid auto-playing media. This is an audio or video file that starts playing immediately when a page or screen loads. It’s entirely confusing as it interferes with the screen reader’s speech output at the same time, and without sight, a user may struggle to find where it’s located on the page to turn it off. 

Avoid content that only conveys meaning through color, shape, or position. For example, describing “the red heart-shaped button on the left” doesn’t help blind users. If you must, refer to the text label as that gets announced (like, “Select any footwear in the sale as a favorite”).

Avoid CAPTCHAs without an audio or accessible alternative.

Avoid time limits without the option to extend. Screen reader users often need more time to navigate forms and content.

Resources

• W3C Abilities and Barriers: Visual
• W3C Stories of Web Users: Lakshmi, a senior accountant who is blind
• W3C WAI-ARIA Authoring Practice Guide (APG)
• TetraLogical: Designing for people who are blind
• WebAIM.org Screen Reader Survey #10
• Lucy Greco: Video interviews with blind users (YouTube)

The fix isn’t “automate everything” or “write everything by hand.” It’s knowing which parts of your documentation are facts you can pull from a source of truth, and which parts only exist because a human made a judgement call. Get that split right, and you can automate the first group with confidence and stop worrying about the second.

Start by sorting your docs into three buckets

Before automating anything, split your documentation into three categories.

• 1. Mirrored. Content whose source of truth already exists elsewhere: props, token values, component status, version numbers. If the docs and the source ever disagree, the docs are wrong by definition — the truth lives somewhere else, and the doc is just a reflection of it. This is the easiest category to automate, because it can be fully regenerated on every change with no judgement involved.
• 2. Distilled. Content where the raw material exists, but the deliverable doesn’t. Commits exist, but a readable changelog doesn’t. A pull request discussion happens, but a migration note doesn’t. A machine can draft a first pass here — turning diffs into narrative, or usage data into a “most used variant” summary — but a human should still set the tone, decide what to include or omit, and sign off before it ships.
• 3. Authored. Content that only exists in someone’s head: why a pattern was chosen over another, when not to use a component, accessibility intent, taste and judgement calls. There’s no upstream source to pull this from, so a machine can only fabricate it if you ask it to generate this content unassisted. This should stay human-written, with machines helping only at the polishing stage.

The rule of thumb: automate the facts, write the story.

How the automation actually works

The mechanics are simple: connect zeroheight to your repo — and let markdown files sync directly into it rather than being manually copied and pasted across. Once that connection exists, engineers can write documentation in their IDE using markdown — a format they’re already comfortable with — without touching a separate authoring tool. Better still, scripts can generate that markdown for them automatically.

A practical setup looks like this:

• On commit, scripts run and generate the relevant markdown files.
• On pull request, CI validates those files and runs any additional scripts — for example, building a changelog from the commits in that PR.
• On sync, the documentation tool pulls in the updated markdown so the published docs match the repo.

Within that pipeline, markdown files tend to fall into three types: handwritten (for the rare things that genuinely can’t be automated, like a note on who owns a component), generated (information pulled straight from the repo and reformatted, no AI involved), and AI-assisted (generated content run through an LLM to turn something raw into something readable).

Five things worth automating:

• Props and API tables. Using your TypeScript compiler, a script can pull every prop’s name, type, default, required status, and any JSDoc description, then output a props table and API spec automatically. There’s no AI in the loop here — this is pure “mirrored” content, so it’s deterministic and hard to get wrong. Build the check into CI, and if someone forgets to regenerate it after a code change, the build fails rather than the docs quietly going stale. And because the finished tables land in zeroheight, they’re visible to designers, engineers, and the AI tools reading your design system documentation — where accurate props tables are especially valuable as AI context.
• Changelogs. This sits in the “distilled” bucket. A script reads the Git log, groups commits by release, and sends the diffs to an LLM to turn commit messages into readable, categorised release notes (fixes, additions, internal changes). The output can feed three places at once: a changelog tab on each component, an aggregate changelog at the top of the documentation, and a CHANGELOG.md file at the root of the repo itself. Run this at the pull request stage rather than on commit, so it reflects what’s actually shipping rather than lagging behind.
• Token reference tables. If your token source of truth lives in code, a script can output a markdown table showing the platform-specific variable name, its alias, and the resolved value — closer to what a developer actually sees in CSS or code than an abstract token name.
• Accessibility conformance reports. Run an accessibility testing tool against your rendered components (ideally the live product, though a Storybook instance works too), then pipe the results into markdown and surface them directly in the documentation. It’s a low-effort way to make accessibility status visible and build trust in the system, rather than relying on people to go and check separately.
• Contributor and ownership information. Declare ownership in a file in the repo (often called a “CODEOWNERS” file) — it can double as your CI ownership config, so it gets maintained as a side effect of normal code review rather than needing separate upkeep. Contribution stats can then be derived from the Git log, excluding commits that only touch generated docs (otherwise whoever runs the docs pipeline becomes the “top contributor” to everything). Components with no assigned owner show up as unassigned, which makes ownership gaps visible instead of hiding them.

What should stay human

Usage guidance, rationale, migration notes, do’s and don’ts, why an API looks the way it does, what was tried and rejected, what a breaking change actually means for the team using it — none of this can be pulled from a source of truth, because the “truth” is a decision someone made, not a fact sitting in a file.

Watch for two failure modes:

• Automating the narrative produces confident-sounding noise — plausible text with no real decision behind it, because there was nothing to distil it from.
• Not automating the facts leaves you back where you started: manually maintained tables and specs that quietly drift from what the code actually does.

The fix isn’t picking one approach over the other. It’s letting generated tables and curated guidance live side by side on the same page — the facts refreshed automatically, the story written deliberately.

zeroheight is built for exactly this split, with automated content and human-authored guidance living side by side in one place for the whole organisation.

What makes automated docs trustworthy

Three properties separate documentation automation that holds up from automation that quietly erodes trust:

• Deterministic. No AI involved in anything treated as fact, so the same source always produces the same output.
• Idempotent. Scripts know when to create, update, or skip a file, so changes only appear when reality actually changes — keeping pull request diffs reviewable instead of noisy.
• CI-enforced. Every generation script has a corresponding check. If someone updates a component and skips the docs step, the build fails. Drift becomes a visible build error instead of something that rots quietly in the background.

None of this is tool-specific — the same principles apply whether your documentation lives in a wiki or plain markdown files. But a dedicated platform like zeroheight goes further, making that content available to your whole organisation and the AI tools building from it.

You can learn more by watching our webinar on Automating Documentation – Markdown Syncing.

Most design systems are organized around what they produce. Tokens. Components. Documentation. Maybe a little bit of educational material, but if you ask any systems team what their design system is, they’ll hand you a list of deliverables. A library of parts, a set of illustrations, a heap of icons — all neatly cataloged and shipped.

That answer, that list of deliverables, holds up right until the moment it matters most. It crumbles at scale. As a system succeeds, demand on it compounds. More products adopt it, more components get requested, more teams depend on it; meanwhile, the headcount of the team doing the work stays flat. 

The real problem runs deeper than headcount. When you’ve defined the system as deliverables, everything that surrounds them (teaching, communicating changes, documenting decisions, sustaining the team) stays invisible and unowned. It lands on the same few people, on top of their “real” output, with no structure to carry it. Thus, the work doesn’t just outgrow the team. It outgrows them in directions nobody ever named. 

When deliverables stop being enough

The design system buckles under the pressure of adoption. Many teams quietly assume that if you build it, they will come. That if components are available, then teams will just use them because they are there, but shipping a component and getting a team to reach for it are two different jobs. A designer reaches for a component when they know it exists, trust it’ll hold up, and believe it’ll save them time over creating their own. 

All of that is teaching, communication, and credibility. It’s connective work the deliverable-based teams never assign to anyone, so the library fills up while the products drift. Teams quietly rebuild what already exists. Shadow versions multiply in the gaps. A shelf full of components gets mistaken for a system people actually use, until someone audits the products and finds the system was never really in them.

The executive conversation breaks hardest of all because it’s where the work meets the budget. If you describe the team by its output (this many components, this many tokens shipped) leadership hears a parts factory. And when you run a parts factory, your ROI is based on how many parts you can produce. Parts aren’t outcomes, though. Nobody approving a roadmap is moved by inventory; they’re moved by velocity, consistency, risk reduced, hours saved. 

When the system can only account for itself in deliverables, it can’t connect to any of the business outcomes leadership actually cares about, and at budget time, it reads as unnecessary overhead and inefficiency. Which is likely to be the first line item to get cut when numbers tighten. The system fails you precisely when you most need it to hold: the moment someone with a spreadsheet asks what this team is worth.

How the Design System Blueprint changes the conversation

With that said, the fix isn’t more components. It’s a different mindset. A design system is not just a deliverable. It’s also an operating model. An operating model brings structure and organization to the team. It brings standardized processes, and it clearly communicates what the system is and what it does to both the design systems team and every team that consumes the system. An operating model translates high-level strategy into day-to-day tasks that actually move the needle. It transforms an ordinary parts factory into a strategic business hub. I call this operating model the Design System Blueprint.

The Blueprint came out of running and maintaining real systems, where these lessons were learned the hard way. Where I had to teach my team and the organization what the complete picture of a design system is, and how just producing more and more components will never deliver on the promise that design systems sell. The output was never the hard part. The hard part was structure and awareness. Who owns what, how the work moves, and whether anyone outside the team understood why it mattered. Once I stopped organizing around what we made and started organizing around how we operated, everything else got easier to defend.

The six pillars

The Blueprint organizes a design system around six pillars. Five describe the functional work. The sixth describes the conditions that work needs to survive. Each one is a real area of ownership; a point of contact, a body of deliverables, and a strategy someone is accountable for driving, not just executing.

1. Core Systems

Structurally, Core Systems is the foundation. This is the layer that defines color, typography, spacing, dimension, corner radii, motion, and content, then binds them into the tokens the rest of the system inherits. Get this layer right and every component above it starts from a coherent base. Get it wrong and no amount of component polish will save you; you’ll be patching symptoms forever.

What Core Systems produces is the system’s vocabulary: foundation ramps for color, type, spacing, and dimension; the design tokens that make those decisions portable; motion tokens and the guidelines that govern how things move; content standards that treat words as part of the interface rather than a layer added at the end. It also writes the best practices and the cautions. The “here’s how to use this, and here’s where it bites” guidance that turns raw foundations into something a product designer can build on without guessing.

When a team needs to design something the system doesn’t cover yet, Core Systems supplies the raw material to do it right. This pillar doesn’t just hold the floor. It hands everyone else the tools to build their own rooms on top of it.

2. Components

If Core Systems is the vocabulary, Components are the sentences. They’re the reusable building blocks teams actually reach for. This pillar owns the full lifecycle of each component: the research that justifies it, the design that shapes it, the specs that define it, and the testing that proves it holds. It’s the primary point of contact for anything component-related, which means it sets the standard the rest of the company designs against.

The deliverables are the spec and the system around it. Things like a Component Spec Template that make every component legible in the same way. The specs themselves. Usage guidelines that say not just how a component works but when to use it and when to leave it alone. It also serves — and this is the part teams most often skip — a real methodology for the design-to-engineering handoff, so what gets designed is what gets built, intact, without a game of telephone in between.

This is where craft and rigor have to coexist. A component that’s beautiful but unspecified is a liability. A component that’s specified but untested is a guess. The work here is making sure every building block is all three at once: well-designed, fully documented, and verified before it ever ships into someone else’s product.

3. Design Tooling

A design system that doesn’t live where designers work doesn’t exist to them. Design Tooling is the pillar that closes that gap. Its center of gravity is Figma: building and maintaining the libraries, owning their structure, and steering the strategy behind how they’re organized. It’s the translation layer that takes the abstractions from Core Systems and the specs from Components and turns them into something a designer can pull off a shelf and use in seconds.

The output is everything that makes the system usable in practice: the libraries themselves, sticker sheets, recipes that show how pieces combine, a “What’s New” surface, and a changelog that keeps everyone honest about what moved. Behind those sits a library-structure methodology. The unglamorous discipline of naming, organizing, and versioning that decides whether the library feels effortless or impossible.

This pillar also looks outward. It researches new tooling and pays attention to how components actually render downstream (understanding how they show up in a CMS, for instance) because a component that’s perfect in Figma and broken in production helps no one. Tooling is where the system meets reality. It’s the difference between a system that’s documented and a system that’s reachable.

4. Education & Communication

You can build the best system in the company and watch it sit unused because nobody knows it exists, how it works, or why they should care. This pillar solves the adoption problem before it becomes one. It owns how the system travels. Both the teaching and the telling.

On the education side: onboarding that gets new designers productive in the system fast, plus the ongoing trainings and workshops that keep the current team current. This is what turns a system from something available into something fluent. 

On the communication side: the plans and strategies that keep stakeholders aligned instead of guessing. This refers to the channels, the cadence, and the messaging that make sure the right people hear about the right change at the right time.

It’s easy to treat this as soft work. It isn’t. Adoption is the entire point of a design system; a system nobody adopts is just an expensive library. This is the pillar most directly responsible for whether everything the others produce ever actually gets used. Communication isn’t decoration on top of the system. It’s the system reaching the people it was built for.

5. Research & Documentation

This pillar is the system’s memory and its evidence. It’s the pillar that makes sure everything the others produce is captured, findable, and provable, so the system survives turnover, scales past the people who built it, and can defend its decisions when challenged.

The work is twofold. Research grounds the system in reality: usability studies, accessibility standards, and the evidence that tells you whether a component works for the people using it, not just the people who made it. Documentation makes all of it legible: the content, the templates that keep it consistent, the changelogs that track what changed and why, and the documentation site that serves as the single knowledge hub for the team.

This pillar acts as an intermediary. It sits between the other areas and makes sure nothing important lives only in someone’s head. That’s the quiet superpower here: knowledge retention. The hardest cost on any systems team is the institutional memory that walks out the door when a person leaves. Done well, this is the pillar that keeps that loss from ever becoming catastrophic. It’s how a system remembers itself.

6. Culture

The first five pillars describe work. Culture describes the conditions that work needs to survive, which is why it’s the only non-functional pillar, and the most easily neglected. 

Initially, I even neglected it in this Blueprint. The original Blueprint only had the five functional pillars, and in the beginning it worked. The team shipped and the system held. The structure did its job, but something kept nagging. Even with the five pillars locked in, even with ownership clear and the work moving, a team can still produce a system nobody wants to contribute to. You can do everything right on paper and watch participation quietly die. The components were sound. The energy around them wasn’t.

That gap is what Culture names. Its focus areas are the ones that never show up in a library but decide everything around it. 

• Design decision-making: frameworks that help teams navigate ambiguity and prioritize impact instead of freezing or defaulting to whoever’s loudest. 
• Psychological safety and growth: an environment where feedback is a gift and people have a reason to keep getting better. 
• Recognition: making the unglamorous maintenance work visible, because the people who keep a system alive rarely get the credit the people who launch it do. And a shared design ethos — the values that keep decisions consistent even when no one’s in the room to enforce them.

Even though this is the only non-functional pillar, there are still tangible deliverables, including but not limited to a Design Culture Playbook, culture metrics that actually measure whether the environment is improving, recognition programs, and the workshops and discussions that keep the team learning together. 

Culture is structure, not decoration. It’s the studs that you can’t see behind the drywall. Strong and necessary but also hidden. Skip it, and you can do everything else right and still build a system nobody wants to contribute to. Make it a pillar, give it an owner, and hold it to the same standard as everything else.

How the Blueprint scales for any team size

Here’s the part that makes the Blueprint portable: the pillars don’t change with team size. The way a team uses the pillars and interacts with the blueprint changes based on team size.

On a small team, sometimes a team of one, the Blueprint isn’t a staffing chart. It’s a prioritization guide. It tells one person where to spend a finite week, and, just as importantly, it shows leadership the true scope of design system work. When all six pillars are named, “the design system person” stops looking like someone who draws buttons and starts looking like someone holding up six distinct functions at once.

On a medium team, you assign pillar owners. Each area gets a name attached to it, someone who drives the strategy and process within the pillar, while everyone still contributes across all six. It’s ownership without isolation. Cross-training and optional quarterly rotation keep the seams from hardening into silos.

On a large team, pillars become pods. Dedicated groups go deep, specialize, and build real depth in their area. Then the culture pillar becomes the connective structure that keeps the system one system instead of six adjacent ones.

The principle holds at every size: Define ownership, distribute responsibility, prevent silos. The shape adapts to your team. The logic doesn’t.

Mapping pillars to business outcomes

The fastest way to lose an executive is to describe your team by its activities. The fastest way to keep one is to describe your team by its results. Every pillar maps to an outcome the business already wants.

• Core Systems is brand consistency and platform scalability. One coherent surface across every product. 
• Components are development velocity, measurable in the hours saved every time a team reuses instead of rebuilds. 
• Design Tooling is team efficiency, the compounding cost of friction removed. 
• Education & Communication is onboarding speed and adoption. The difference between a system that’s available and one that’s actually used. 
• Research & Documentation is reduced support load and knowledge that survives turnover.
• Culture is retention itself, because turnover on a systems team is devastating in a way most leaders underestimate until they’re rebuilding institutional memory from scratch.

So reframe the conversation. Don’t describe what your team does. Describe what your team makes possible for everyone else. That’s the sentence that gets a design system funded.

From team structure to team identity

The Blueprint is a framework, not dogma. The six pillars are the operating model. The part that stays fixed. The size of your team dictates how you adopt the model. It’s meant to be something you bend to fit your reality.

What you end up with is more than an org chart. It’s an articulation of what your team stands for and how it operates. A system that, at its best, vanishes into the products it serves and the people it empowers. The team isn’t the components. The team is the conditions that make good components inevitable.

This is your starting line. Take this Blueprint and create your own operating model. Name your pillars. Name your owners. Name the culture you’re actually willing to defend. Then build the system whose value speaks for itself.

Something genuinely interesting is happening in design right now. AI tools are lowering the barrier to entry in ways that would have seemed implausible until recently. A product manager can prototype. A developer can iterate on layouts without waiting for a designer. A researcher can mock up a concept during a session and test it on the spot. The blank-canvas problem — that particular friction that slows teams down before the work even starts — is largely gone.

For teams that have never had dedicated design resources, or where design input has traditionally come late in the process, this changes the dynamic. Everyone can prompt. The conversation starts earlier, with more of the team involved. That’s a real shift in who gets to participate. Whether design outcomes improve depends entirely on what happens next.

But the question this series has been building toward isn’t whether AI can democratize design. We already know it can open the door to wider participation. The real question is whether that participation translates into design that actually works for more people. Right now, there’s still a significant gap between the two.

Wider collaboration isn’t the same as wider inclusion

When I talk about democratization in the context of AI and design systems, I mean two things that are easy to conflate but are genuinely distinct.

The first is participation: more people contributing to the design process, earlier and more often. AI helps here. The tools are accessible, the outputs are a credible starting point, and the friction between having an idea and being able to express it visually has dropped significantly. Teams that were previously bottlenecked by design resources can move faster. That’s real.

The second is inclusion: whether the design that gets made actually serves the full range of people it’s meant to reach. More voices in the room doesn’t automatically mean more people are served by the output. The goal is to include, not dilute. And collapsing participation into inclusion is where the argument for democratization starts to break down.

Scale amplifies whatever is already present. If the output reflects only a narrow slice of the population, reaching more people with it isn’t progress.

AI optimizes for patterns. Not people

This is the part of the democratization conversation that tends to be glossed over. AI doesn’t make design more inclusive by default. It reproduces whatever is most prevalent in its training data, at scale, with confidence. 

The defaults it reaches for — such as Western aesthetic conventions, English-language interface patterns, desktop-first interactions, and the exclusion of users with disabilities — aren’t neutral. They reflect the data the models were trained on, and that data was never representative to begin with.

The consequences aren’t theoretical. Voice assistants that struggle with accents. Facial recognition that underperforms on darker skin tones. Hiring algorithms that screen out names that don’t fit a particular cultural pattern. Design tools that default to visual and interaction conventions built around the dominant Western digital market, leaving behind users whose experience of technology bears no resemblance to the assumed baseline. 

These aren’t edge cases. They’re the system working exactly as designed, on data that was never built to reflect everyone.

I’ve written about this directly in my piece Mirror, Mirror on the Wall: Does AI See Us All?, which tracks how AI image generation consistently fails to reflect the diversity of the real world. The pattern holds across tools and use cases. Research from Charles Sturt University found that AI-generated images of medical professionals depicted 91.2% as having a light skin tone, despite the profession being considerably more diverse in reality. That’s not a random error. It’s a systematic one. 

When exclusion is built into the training data, scale makes it worse. Faster output means more people encounter the same blind spots, with greater reach, with no flag and no friction.

Carry that logic into a design system. If the AI generating your UI components, layouts, and patterns is trained on data that doesn’t reflect your actual users, and your design system is the source it draws from, then every interface it produces inherits that skew. At that point, democratization isn’t inclusion. It’s scale without representation.

The design system is the inclusion infrastructure

If AI generates UI from your design system, your design system’s values become the inclusion layer. Every accessibility standard, every token decision, every component constraint, and every edge case the system was or wasn’t designed to serve are all reproduced in whatever the AI produces. A design system that doesn’t treat inclusion as a core principle won’t become more inclusive simply by being used more widely. Scale doesn’t fix the gap. It widens it.

This connects directly to the role shift described in Part 2. The designer’s leverage is no longer primarily in the artifact they ship. It’s in the foundations the AI is allowed to draw from. The most consequential design decisions in an AI-assisted workflow aren’t made at the point of generation. They’re made at the system level, before a prompt is ever written.

Democratization needs direction. Wider participation without inclusive foundations simply means the same exclusions reach more people.

What this looks like in practice

Getting this right starts before AI is ever involved. The decisions about your design system’s foundations — what it prioritizes, whose needs it reflects, and what constraints it enforces — determine what every AI-generated output inherits. That’s where the work is.

Start with an honest audit of whose needs your design system is built around and whose are absent. Ask directly: If an AI generated an interface from your existing components and tokens today, which users would it serve well, and which would it fail? That answer tells you where to focus.

From there, make inclusion a requirement, not a final check. Accessibility belongs in component specifications, not in QA sign-off. Contrast ratios, screen reader behavior, and touch target sizes should be conditions the system enforces, not details verified at the end of a delivery cycle. Get the requirements right, and inclusion is built into every output. Get them wrong and so is the exclusion.

The more useful question isn’t who your system was designed for. It’s who was in the room when it was built and who participated in the research behind it. Users with a visual impairment, low digital literacy, a non-standard device, or a first language other than English aren’t edge cases. If they weren’t part of the process, the system reflects that, and so will every output it produces.

Treat prompt strategy as a design discipline. When non-designers use AI against your design system, they’ll gravitate toward what’s easiest to describe: the standard scenario, the typical user, the happy path. 

Teams that build deliberate prompt guidelines, ones that lead with user diversity and name underrepresented users as starting conditions, are the ones who ensure that wider participation actually produces wider inclusion in the output.

A practical starting point

Before your next design initiative, ask these questions at the system and team levels:

Does your design system reflect inclusion, or merely assume it? Audit your components, tokens, and documentation to identify whose needs are built in and whose are absent. The answers reveal where the gaps are and where to start.

Is accessibility a requirement or a final check? If it’s reviewed at the end of a delivery cycle, it will be skipped when time runs short. It belongs in the component specification, not the QA checklist.

Who was included in the research and testing behind your design system? If the process didn’t include users with disabilities, low digital literacy, or non-standard devices, those gaps are built into every output.

What do your prompt guidelines assume? Default prompts produce default outputs. Without deliberate guidance toward diversity, AI will reflect whoever was easiest to describe.

Are AI-generated outputs reviewed with users from underrepresented groups before they ship? Internal review is designed to catch consistency and quality. They aren’t always structured to catch exclusion. Bringing in users from underrepresented groups closes that gap.

Does your governance model assign accountability for inclusion outcomes? Inclusion accountability shouldn’t sit with a team in general. It should be a named responsibility within your governance model, with the same visibility as accessibility compliance or brand standards.

Where this series lands

AI is transforming what enterprise design teams can produce. But AI doesn’t carry values. It carries patterns. And those patterns reflect the world as it has been documented: imperfectly and unequally, with most of the interesting edges smoothed out.

Part 1 raised the guardrails question. Part 2 raised the accountability question. This article raises the democratization question. And the answer to all three lies in the same place: the decisions made before AI is ever involved.

Those decisions live in the design system. In what it enforces and what it ignores. In whose needs shaped it and whose didn’t. In whether inclusion was treated as a principle or an afterthought. Getting that right doesn’t guarantee perfect outputs, but getting it wrong guarantees the opposite.

AI will democratize whatever your design system is built to value. Build it to value everyone.

A spec for the messiest part of design systems

I’ve been following PJ Onori’s work on the Design System Documentation Spec (DSDS) since he first started writing about it. What convinced me early was how precisely it named a problem the whole industry had been working around since design system documentation came into existence… design system documentation has no agreed-upon shape.

Tokens have a format, components have code, but the documentation lives in whatever structure each team invented for themselves. That’s always been a quality problem, and we’ve managed it by copying each other and making small tweaks to suit our needs. Now that AI agents are consuming design systems, the problem is surfacing even more, as it comes down to quality, access, and usability.

DSDS fixes both at once. It defines a machine-readable format for design system documentation, organized into seven entity types — components, tokens, themes, foundations, patterns, guides, and chunks — each built from a standard set of document blocks covering things like guidelines, API details, states, and accessibility. Two things make it genuinely useful:

• It makes docs readable by agents without making them worse for humans. One of the spec’s founding goals is serving humans, parsers, and AI agents from the same source. Documentation written for people stays written for people; it just gains a structure that machines can navigate too.
• It gives every team a proven structure. Every design system team reinvents the way it documents a component. A shared spec means you inherit a structure that’s been argued over by people who’ve done this many times, and the baseline quality of documentation rises across the industry.

How we’re approaching this at zeroheight

Since we learned about the spec, it’s gone from a neat theoretical concept to something we use in practice. First, it guides how we think documentation should be authored. DSDS’s entities and block types map remarkably well to how good documentation already works, so we use them as the model for structuring content. Our internal test system, Baseline, has been entirely built using DSDS as the spec for how design system documentation should look.

Second, it’s become the framework for customer conversations. When teams ask us how to make their docs better-structured and AI-ready, we point them to the spec and work through what conformance looks like for their style guide. We even built a Claude plugin that uses the DSDS to audit a user’s docs and return meaningful improvements.  

Third, it’s informing our roadmap. Where the spec is heading and where zeroheight is heading are increasingly in the same direction. With some upcoming product work we’re building around auditing your documentation, we’ve used the DSDS as the foundation for our audit criteria to ensure standardization and the best results, especially when using the zeroheight MCP.

Why the W3C move matters

On 30 July, PJ proposed the Design System Documentation Community Group at the W3C, with a mission to “lower the burden of design system management by developing an open format for structuring design system documentation.” It’s now been approved, and while it’s early days, some of us from zeroheight have already signed up as active members.

Why is this a good great thing?

• A neutral home. However good a spec is, it’s hard for an industry to invest in one person’s or company’s project. The W3C is neutral ground where competitors can safely build on the same foundation.
• A proven path. The Design Tokens Community Group showed this exact route works… tokens went from every-tool-for-itself to a stable spec the whole industry now ships against. Documentation can follow the same road.
• It gets vendors to the table. W3C status is what makes documentation platforms, design tools, and AI companies willing to sit down and align. Nobody wants to bet their product on a format that might vanish, and a community group makes that less likely.
• Longevity. Governance, IP policy, and institutional process mean the spec can outlive any individual maintainer or company. That’s exactly what you want from something your documentation quality depends on.

And the deeper reason documentation deserves this treatment is that docs are where the knowledge lives. Tokens carry values, but documentation carries meaning. It’s also the last unstandardized layer of the stack, and AI has made closing that gap pretty darn urgent. Agents are consuming design systems today, and without a standard, every team hand-rolls its own approach, and every tool ends up spitting out different results.

The path is long and winding

Tokens were, in hindsight, the easy case. I mean, they’re structured data with values and types. Documentation, on the other hand, is prose, opinion, and context. A huge amount of what makes design system docs valuable is inherently not standards-shaped. Standardizing the container without flattening the opinions inside it is a pretty thorny problem than the one the tokens group faced, and it’s the challenge I expect to define the group’s early work. The document block model is a promising answer (structure the shape, not the opinion), but proving that across thousands of real-world design systems is the work ahead.

What you can do today

Join the community group. It’s brand new, the important decisions haven’t been made yet, and it needs voices from people who actually maintain documentation, not just people who build tools for it.

And audit your own docs. Read the spec and hold your styleguide up against it. If you’re a zeroheight customer, check out the audit tool and get a prioritized list of exactly where you stand. Now, let’s get this baby standardized.

But while many teams understand the value of tokens, fewer realize that managing them effectively requires dedicated tooling and workflows. In this article, I want to share five excellent tools for token management, along with the trade-offs that come with each one.

What makes a good design token tool?

Before diving into the actual tools, it’s important to define the criteria of effective token management tools. Here are the key capabilities I look for in a good design token management tool:

• Cross-platform export: Generating outputs for web (CSS/SCSS), iOS (SwiftUI), and Android (XML/Compose).
• Versioning and governance: The tool allows you to treat design data like code, with branching, merging, and rollbacks.
• Seamless Figma integration and sync: This makes a designer’s life more comfortable as they don’t have to leave their primary workspace to author tokens.
• Documentation capabilities: A large part of design system success depends on documentation. Not just the fact that the team can create documentation, but how easy it is to keep it in sync with the source of truth.
• Theming and dark mode support: Visual theme switching is by far one of the most common UI functionalities; that’s why aliasing tokens to easily switch contexts is a must-have feature. Modern tools handle this through “modes” or “themes” that swap entire sets of values without changing the token references in your designs or code.
• Automation and Continuous Integration (CI)/Continuous Delivery (CD) support: Triggering automatic updates to codebases via GitHub or GitLab actions.
• W3C-DTCG standard compliance: Supporting the emerging Design Tokens Community Group (DTCG) format to future-proof systems and prevent vendor lock-in. 

1. zeroheight

zeroheight is best known as a design system documentation platform. It has expanded well beyond documentation in recent years and now ships a dedicated Design Tokens Manager that can import Figma Variables and Figma Styles, store tokens centrally, and export them as DTCG-compliant JSON or directly through Style Dictionary.

Key features

• Design system documentation with excellent design-to-development communication
• Stakeholder-friendly presentation of the documentation 
• Automated pull requests to GitHub or Bitbucket when tokens change in Figma

Pros

• Industry-leading documentation experience
• Excellent onboarding experience
• Strong governance and discoverability that helps improve organizational alignment
• Code automation that goes directly from Figma through to your code repo

Cons

• Limited ability to edit code automation output directly in zeroheight. You’ll need to stack with custom scripts or Style Dictionary
• Not intended as a primary token management platform

Best for: zeroheight works best for organizations scaling design systems across multiple teams and departments that need a single source of truth for both documentation and token distribution.

2. Tokens Studio

Tokens Studio is arguably the most widely adopted design token solution within the Figma ecosystem. It lets teams create structured token hierarchies, manage themes, and synchronize token data with external repositories.

Key features

• Token hierarchies (so you can define token relationships, inheritance, and conditions before syncing to any tool)
• Multi-theme support via Token Sets
• JSON export
• GitHub and GitLab synchronization
• A standalone web “Studio Platform” beyond the Figma plugin, for teams that need token management outside the design file

Pros

• Excellent Figma integration
• Very flexible architecture with strong support for complex design systems
• Large community

Cons

• Requires governance discipline, and the learning curve can be steep for non-technical designers
• The plugin interface can feel overwhelming in large projects
• Some of the most useful workflows, like token automation and branching, are gated behind paid tiers

Best for: Tokens Studio works best for seasoned product teams that are heavily invested in Figma and have built, or are building, a mature design system.

3. Knapsack

Knapsack is an enterprise design system platform that treats tokens as living data linked directly to production code. It focuses on automating the flow from design decision to shipped artifact: importing Figma Variables, Collections, and Modes, transforming them into platform-specific code, and opening pull requests back to your repos.

Key features

• Token import from Figma (Figma Variables and Figma Styles, with Collections and Modes preserved), plus Style Dictionary or Token Studio
• Export to 10+ code formats, including CSS, SCSS, JavaScript, Swift, and Kotlin
• W3C DTCG v1 compliance for portability across tools
• Inline editing of tokens (HEX, HSLA, RGBA) by non-engineers, with reference-aware updates that cascade through aliased tokens

Pros

• Strong design-to-code automation without requiring designers to write JSON or use a command-line interface (CLI)
• Tight integration between tokens, components, and documentation in a single workspace
• DTCG-compliant exports keep you portable
• Enterprise-grade governance and support

Cons

• No free plan or free trial period
• Enterprise pricing, with the most useful capabilities living on the higher plans
• Heavier setup than a plugin-only tool; best when paired with dedicated design system staff
• Smaller community than Tokens Studio or Style Dictionary

Best for: Knapsack works best for enterprise organizations managing a design system across many product teams, especially those that want token editing, component documentation, and code delivery to live in one platform.

4. Style Dictionary 

Style Dictionary is one of the foundational tools in the design token ecosystem. Created by Amazon and released as an open-source product, it remains one of the most flexible token transformation engines available.

Key features

• Platform-specific code generation (CSS variables, SCSS, JavaScript, TypeScript, iOS Swift/SwiftUI, Android XML/Compose, JSON, and any custom format you write)
• Open-source architecture
• DTCG forward-compatibility

Pros

• Ultimate flexibility (no vendor lock-in)
• Excellent developer experience
• Supports virtually any platform (if you can write a formatter, you can ship to it)

Cons

• Developer-first experience (requires engineering expertise)
• No visual interface

Best for: Style Dictionary works best for engineering-led organizations that need complete control over token transformation and deployment, and it’s typically paired with an upstream authoring tool like Tokens Studio or Figma Variables rather than used in isolation.

5. Figma Variables

Figma Variables represent Figma’s native approach to managing token-like design data directly within design files. For many teams, they serve as the entry point into token-based workflows.

Key features

• Figma native token creation for individual variables (color, typography, strings, and boolean)
• Supports modes and collections

Pros

• Built directly into Figma (minimal setup requirements)
• Easy adoption for designers (no need to switch to any third party tool)
• Great for teams already standardized on Figma

Cons

• Still evolving compared to dedicated token platforms (variables for typography, gradients, and complex composites are limited or unavailable today)
• Developer synchronization remains limited without the REST API (Enterprise tier) or a third-party plugin
• Enterprise-scale workflows can become challenging (governance, branching, and code export are not native and require additional tooling)

Best for: Figma Variables work best for startups, small-to-medium product teams, and teams beginning their design system journey. They also work well as the upstream authoring layer in larger stacks.

Stack tools for max efficiency 

One of the biggest misconceptions about design token tools is that they compete directly with one another.

In reality, the most successful organizations combine multiple tools into a cohesive workflow.

A common setup might look like this:

Figma Variables → Tokens Studio → Style Dictionary → zeroheight

Each tool solves a different problem:

• zeroheight for documentation and governance
• Figma Variables for authoring and previewing
• Tokens Studio for token management and synchronization
• Style Dictionary or Knapsack for platform-specific transformation

That’s why, rather than searching for a single perfect tool, focus on building a workflow that supports your team’s needs.

The best token stack is the one that creates a reliable bridge between design decisions and shipped products.

Bonus: Cheatsheet for choosing the right tools

The starter stack (Figma Variables + basic handoff workflows)

Best for:

• Startups
• Small product teams
• Early-stage design systems

The scaling stack (Figma Variables + Tokens Studio + zeroheight)

Best for:

• Growing product organizations
• Cross-functional collaboration
• Teams investing in documentation

The enterprise stack (Tokens Studio + Style Dictionary or Knapsack + zeroheight)

Best for:

• Large organizations
• Multi-platform ecosystems
• Teams prioritizing automated token delivery across web, iOS, and Android

Moodle LMS is a 23-year-old open source learning platform with over half a billion users. That scale is only possible thanks to our global community of contributors whose work has sustained the platform over two decades. But that distributed, community-driven growth also means Moodle has evolved without a shared design language. Until recently, we had no formal design system to speak of.

So when the opportunity came up and the team was in place, we were pretty much starting from scratch. This gave us the rare chance to decide what we wanted the design system to be before we built a single component. To make it future-proof, we knew it had to be AI-first. What we didn’t know yet was what that meant.

Defining AI-first

Before building anything, we set out to understand what it actually means to build an AI-first design system, and how we would operationalise that.

We understood the outcomes our teams needed from AI. We had two concrete goals: AI-assisted prototyping and AI-assisted development handoff. The question was how to build a design system that could actually support them. We sent our Lead UX Designer, Boris Basque, into research mode.

We discovered that there wasn’t really an established playbook. Nobody had set out a clear framework for what AI-first meant in a design system context when we began. That meant we needed to start working from first principles, pulling together what threads existed and bringing it back to the team for discussion.

Out of that work came 15 Principles, grouped largely around two clusters: Clarity and Parity.

• Clarity: a component should only have one single, unambiguous interpretation.
• Parity: design and code should speak the same language at all times.

We landed on Clarity and Parity because they address the two places ambiguity enters a system. Clarity is about making sure there is enough information for a component to be understood correctly. Parity is about ensuring that information stays consistent as it moves between design, code, documentation, and tooling.

We found that many of our Principles weren’t completely new – they were design system practices that aimed to remove ambiguity, which we already believed in. The difference was the standard they needed to be implemented to. We also defined some genuinely new Principles, which were not required before the AI-first focus.

This foundational work mattered beyond our internal teams, as Moodle’s community contributes extensively to the platform through plugins, integrations, and new capabilities. We needed the design system to serve them as much as it served us.

Machines have zero tolerance for gaps and ambiguity

On reflection, people are surprisingly good at filling gaps. For example, a designer sees a component labelled inconsistently, but knows what was meant. Or a developer encounters a property name that doesn’t quite match the spec, but works it out from context. Teams build shared understanding over time that lets them compensate for things like gaps in documentation, inconsistent naming, or states that were never fully defined.

Machines don’t do this.

An AI agent consuming your design system needs explicit information – about everything. It needs consistency across every component, every property, every state. When there’s ambiguity, it might try to infer intent. When there’s a gap, it might hallucinate a fix. At best, it might work some of the time. And if it only works some of the time, your system has failed.
People can infer a lot of things and don’t need as granular a level of documentation as a machine does. Design for the machine first, and humans will have more than they need. This is why many of our AI-first Principles turned out to be existing best practices, held to a stricter standard.

For example, semantic naming over descriptive naming is not a new idea, but it’s no longer something you can be approximate about. Token coverage for every value is already the goal, but now it’s a hard requirement with no exceptions. State completeness is the kind of thing teams often say they’ll return to, but which we just couldn’t defer. Or take design-to-code parity: something designers and developers have always agreed on in principle, while accepting gaps in practice.

Mathew May, our technical lead, described it as:

Turning principles into practice

Our AI-first Principles are the foundation of the Moodle Design System (MDS), but they don’t ship components. We needed mechanisms to ensure the Principles were actually followed.

Some were extensions of existing practice, taken further than we would have otherwise. We invested heavily in Figma component descriptions: comprehensive behavioural documentation that tells an AI agent how many states a component has, what each variant means, and how elements interact. Previously, we might have written a brief description, or perhaps nothing at all. Now, this is a substantive piece of work for all of our components, one that wouldn’t be in our workflow without the AI-first goal.

As Boris put it:

We implemented Code Connect to enforce design-to-code parity, mapping Figma property names to their code counterparts. Where naming genuinely can’t align (as designers and developers sometimes arrive at different conclusions), Code Connect lets us bridge the gap without abandoning the Principle.

We also made agent instructions a formal part of the pull request checklist. When a new component introduces a new pattern, the instructions get updated in the same PR. According to Boris:

The end-to-end checklist lives in Confluence, linked from every component’s Jira ticket. It covers the full lifecycle from initial evaluation to release, and every item either passes or has a documented reason for being non-applicable.

And we built the MDS Linter, a custom Figma plugin that uses the Claude API to automatically assess whether components comply with our 15 Principles. First runs always surface issues, sometimes lots of them, but we expect that now. We fix the issues and run again, until the components meet the standards we’ve defined.

As Mathew put it:

The Linter generates a score for the component, but we’re not aiming for a perfect score from the start. The goal is a process that makes the Principles visible enough to act on, every time.

What surprised us

We didn’t have to abandon established design system practices to build AI-first; we had to apply them more consistently than we ever had before. Two examples illustrate this well.

On one occasion, a designer used a dashed border to outline a component frame in Figma for visual clarity, never intending it to ship. Its colour wasn’t a token – the Linter picked this up and generated warnings. It was right to flag it: agents don’t make exceptions for readability cues or working notes, and without the flag, a coding agent would have included the border in the first pass of the component build.

Separately, designers and developers now routinely spend time aligning on naming decisions that, in the old world, we would likely have let slide. With the AI-first approach, that shortcut is no longer available: a naming mismatch breaks machine consumption, so these debates are now necessary.

In both cases, the machine can’t reason about context the way designers and developers would. Total correctness and completeness is now the baseline.

What we’d tell a team starting today

Not everyone is starting from scratch, but every team with a design system will face the same challenge: AI surfaces all the little gaps (and the big ones too) that human teams have been compensating for, and it surfaces them faster than you’re used to.

Here are the ideas we’d pass on to teams embarking on their own journey to make their design system AI-first:

Start with strategy before tools. Before you reach for an AI tool, understand your team’s workflows. What does AI-first mean in your context? How will you operationalise it? A shared definition of quality, established before adoption scales, is what stops standards from slipping through the cracks as usage grows.

If you’re building from scratch, start with tokens. We launched our foundations before a single component existed. It gave us early traction and helped us understand how we work as a team: how we communicate change, build momentum, and engage our users. This was critical for when we moved into components.

Use AI to help build the system. We build for AI as the consumer, but we also use AI to generate component scaffolding (file structure, boilerplate, test files, Storybook structure) as well as for auditing components against our AI Principles. That gives us more time for work that requires human judgment like the edge cases, the small details that get missed under time pressure, and the designer-developer conversations that produce better components. And while AI handles the setup, we make sure the craft stays human.

Get your Figma hygiene right. Proper layer names, descriptive property names, and notes that explain how each element behaves across its configurations. AI works with what you give it. Well-structured, well-annotated designs produce meaningfully better results.

Invest upfront in agent instructions and prompts. The time spent defining how your agents should behave and building a set of repeatable prompts for common tasks saves disproportionate effort later. A solid starting prompt for a component review means time goes to edge cases rather than capturing the basics again.

Keep humans in the loop. Whether it’s an initial build, a maintenance update, or checking that implementation matches design intent, human review needs to be the final check. It’s one of our 15 Principles. AI accelerates the work, but it doesn’t replace accountability.

Document from day one. Don’t wait for the library to be “big enough” to write documentation properly. We use zeroheight as the public face of MDS; it’s where contributors go to understand the system, gives us visibility into adoption, and serves as the source of design system context that our machine-readable exports are built from. The earlier you start, the fewer components you have to retrofit later.

Final thoughts

Building MDS taught us that the hardest part of an AI-first design system isn’t strictly the new AI requirements. Sure, we had to introduce some new practices to support AI specifically. AI also speeds up our implementation – like our linter that audits our work against our AI Principles.

But perhaps the most important parts of our findings relate to the fundamental goals of design systems themselves: to be complete, consistent and unambiguous sources of design truth. The standard machines need is the standard we should have been holding ourselves to all along. To be truly AI-first, we can’t ignore them any longer.

Here’s what nobody tells you about AI design tools: The hardest part isn’t learning them. It’s knowing when to stop trusting them.

Tools like UX Pilot, Visily, Figma Make, and Flowstep can generate wireframes, layouts, and working code in minutes. The output looks credible. It follows established patterns and aligns with your design system’s conventions. And that’s exactly where the risk lies. Something that looks right isn’t the same as something that is right. 

An AI tool might generate a checkout screen that aligns perfectly with your UI guidelines but overlooks key requirements, such as accessibility labels for screen readers, which results in an interface that looks flawless yet excludes users with disabilities. Or it could faithfully reproduce a layout that inadvertently reinforces a bias in the training data, thereby excluding a segment of your actual users. The distance between “looks right” and “is right” is where accountability either exists or doesn’t. 

I’ve written about this pattern before in my piece Mirror, Mirror on the Wall: Does AI See Us All?, which tracks how AI-generated imagery consistently fails to reflect real-world diversity. The pattern holds across tools, sectors, and use cases. In design, where output directly shapes what users see and experience, the stakes are high.

The temptation is to treat AI-generated output as the win. It isn’t. It’s the start of the work.

Speed isn’t strategy. AI won’t fix weak thinking

When I presented this thinking at Next25, one frame I kept returning to was this: AI reflects your strategy. It doesn’t create one.

AI-generated wireframes are useful early on, when the aim is to explore rather than refine. They surface options quickly and remove the blank-canvas problem. But they’re not a shortcut to good design. Speed without strategy is drift, not progress. And the designer who mistakes the volume of output for the quality of thinking isn’t curating. They’re just processing.

This matters especially at the design-system level. When AI draws on your token architecture and component library to generate interfaces, it’s not making design decisions. It’s pattern-matching at pace. It can produce rapid wireframes and layout variations, intelligently fill content, and quickly apply template-based solutions. What it can’t do is understand journeys shaped by user psychology, read trust cues and emotional resonance, or navigate the edge cases and critical moments where design decisions carry real consequences for real people.

That’s where the designer’s judgment earns its place.

From creator to creative strategist

The shift AI forces on designers isn’t a demotion. But it does require a different kind of discipline.

In the pre-AI workflow, the designer was the creator: the person who made the thing. In an AI-assisted workflow, the designer becomes a creative strategist: the person who decides which thing to make, interrogates whether it’s the right thing, refines what the tool produces, and directs the process toward something that actually serves users.

That’s not a passive role. It’s a more demanding one. Curation without interrogation is just approval, and approval without accountability is an ethical failure waiting to happen.

The irreplaceable skills in this new model are synthesis, judgment, empathy, and understanding. AI processes data. Designers turn research into actionable insight. AI generates options. Designers question what works and ask what could work better. AI produces interfaces. Designers guide those interfaces toward solutions that resonate with the people using them. 

Teams using AI effectively still need someone who deeply understands users. That person is you.

You’re the system’s compass. AI is the accelerator.

The accountability gap

Here’s the question most teams haven’t answered yet: When AI generates the output, who owns what it produces?

It sounds straightforward. The designer reviewed it, so the designer owns it. But review is not the same as responsibility. If a designer accepts an AI-generated layout without interrogating its assumptions, without asking who gets excluded, what biases the training data carries, or how this scales to users who weren’t considered when the prompt was written, then “reviewed” is just a synonym for “approved quickly.”

The accountability gap opens right here. When no human genuinely owns the decision, no human can be meaningfully held responsible for any harm it causes. And at enterprise scale, where design systems generate UI across hundreds of product surfaces simultaneously, the consequences of that gap compound quickly.

Salesforce has made this concrete in their AI development process: More than 350 responsible AI reviews, each requiring a named human to sign off on AI-assisted decisions before they ship. That’s not a governance tax. It’s an accountability structure. It means there is always a person, not a process, attached to what the system produces.

Most design teams don’t have an equivalent. And most of them don’t realize they need one until something goes wrong.

What responsible curation actually looks like

Responsible curation isn’t about slowing down. It’s about being deliberate about what you let through and being able to explain why.

In practice, it comes down to four habits that should be non-negotiable in any AI-assisted design workflow.

Interrogate before you accept. Don’t treat AI output as a starting point to be polished. Treat it as a proposal to be challenged. Ask: What assumptions does this make about the user? Who does this exclude? What would happen if this reached a hundred thousand people who weren’t in the room when the prompt was written?

Refine with intent. The gap between AI output and the finished design is where your judgment lives. That gap should never close to zero. If you’re shipping AI output without meaningful refinement, you’re not curating. You’re forwarding.

Direct the process, don’t just react to it. The designer’s leverage in an AI-assisted workflow is upstream, in how you frame the brief, structure the prompt, and set the constraints. AI reflects your strategy. If your strategy is unclear, the output will be too.

Name a human. Every AI-assisted design decision that ships should have a person’s name attached to it. Not the tool that generated it. Not the team that used it. A person who reviewed it, interrogated it, and consciously chose to ship it. That accountability has to be personal to be real.

Governing AI outputs at the design system level

The accountability question doesn’t rest solely with individual designer behavior. It has to be structural, built into how the design system itself manages AI-assisted outputs.

That means documentation standards: a clear record of which decisions were AI-assisted, what the human review involved, and what was changed or rejected. It means an audit trail that travels with the component, not just the component itself. And it means a governance model that treats AI-generated output differently from human-generated output. Not because it’s inferior, but because the accountability chain is different and needs to be made explicit.

This is the layer most enterprise design systems are missing. The infrastructure exists in some organizations. The equivalent layer at the design system level, where the work actually happens, is largely absent.

The design system is no longer just a library of components. In an AI-assisted workflow, it’s the source the tool draws from, the standard the output is measured against, and the place where accountability is either built in or skipped entirely. How it’s governed now determines what it ships at scale.

The curator who doesn’t ask hard questions

I’ll end where this conversation usually stalls.

The shift from creator to curator feels like progress. It is. But curation is only as valuable as the judgment behind it. A curator who accepts everything that arrives isn’t curating. They’re just moving things along.

The accountability gap in AI-assisted design isn’t a technology problem. The tools are improving faster than our governance of them. It’s a practice problem. It’s about whether designers and design teams are willing to slow down just enough to own what they ship, rather than merely process it.

Speed is not strategy. AI won’t fix weak thinking. And a design system without an accountability layer isn’t just a risk. At enterprise scale, it’s a liability waiting to be found by a user.

Next: Part 3 – the inclusion promise: Can AI-augmented design systems actually democratize design?

This is the first of a three-part series on AI ethics in enterprise design systems. Part 2 will examine the accountability gap in AI-assisted design, and Part 3 will ask whether AI-augmented design systems can genuinely democratize design.

Here’s a number that should stop you in your tracks. According to PwC’s own research, 79% of large enterprises are already running AI agents in production. And fewer than 20% have a mature governance framework in place to manage them.

Read that again. The organizations deploying AI at the fastest pace are also the least prepared for what happens when it goes wrong.

This is the paradox sitting at the heart of AI adoption right now. And for design teams specifically, it’s not an abstract risk. It’s a live one. Enterprise design systems are increasingly the foundation from which AI generates UI: components, layouts, flows, and production-ready code assembled in minutes from your token architecture and component library. 

When that process runs without an ethics framework in place, the design system doesn’t just enable speed. It enables scale. And at scale, the cost of getting it wrong multiplies fast.

The problem isn’t the technology. It’s the pace

Companies like PwC, HSBC, Morgan Stanley, CommBank, IBM, and Salesforce aren’t naively rushing into AI. They’re cautious, compliance-heavy organizations that have largely reached the same conclusion: Public AI tools carry too much risk for their data obligations, so they’ve built their own. 

PwC, Morgan Stanley, HSBC, and CommBank have all deployed private GPT environments, keeping sensitive data inside their own walls. IBM built watsonx specifically to provide a secure, governed AI infrastructure for the enterprise. Salesforce’s Agentforce ships with what they call “Mindful Friction”: deliberate pauses built into the product to ensure a human reviews AI decisions at critical points.

What’s telling is why they built these things. Not because ethics governance is a nice-to-have. But because the public alternative couldn’t be trusted inside their organizations.

But here’s the gap: Those governance structures exist at the platform and infrastructure level. Most design teams operating within these organizations don’t have an equivalent layer at the design-system level. 

According to IBM’s Cost of a Data Breach Report 2025, one in five organizations has already experienced a data breach through shadow AI, with employees feeding sensitive data into unsanctioned public models outside any formal approval process — costing an average of $670,000 more than a standard breach. Without clear protocols for what can go into a prompt, who reviews what gets generated, or how AI-assisted outputs get documented, the risk compounds with every sprint.

The guardrails are missing where the work actually happens: inside the design system itself.

AI doesn’t create bias. It amplifies it

This is the uncomfortable truth that often gets skipped in conversations about AI and design tooling.

AI optimizes for patterns. It’s trained on datasets that reflect the world as it has been documented, which is to say, a world that skews white, male, Western, and able-bodied. It doesn’t introduce new biases so much as reproduce and accelerate existing ones. And when an enterprise design system becomes the source that AI draws from to generate interfaces, those biases don’t stay in the tool. They get encoded into the system’s components, tokens, and outputs. From there, they ship to every user who encounters them.

Research from Charles Sturt University made this concrete. Using DALL-E 3 to generate images of medical professionals, researchers found that 92.3% of AI-generated medical students appeared white, despite 54.3% of real Australian medical students being female and the profession being far more diverse than the outputs suggested. This isn’t an edge case. It’s a systematic failure of representation, repeated at speed.

I’ve written about this before in my piece Mirror, Mirror on the Wall: Does AI See Us All?, which tracks how AI-generated imagery consistently fails to reflect the diversity of the real world. The pattern holds across tools, across sectors, and across use cases. And in design specifically, where the output directly shapes what users see and experience, the stakes are high.

Voice assistants that struggle with accents. Facial recognition that underperforms on darker skin tones. Design tools that default to Western aesthetic norms. Financial interfaces that discriminate based on location. These aren’t hypothetical. They’re happening. And when design teams ship AI-generated outputs without an ethics layer, they become part of the chain that delivers them to users.

The speed that makes AI so attractive to design teams is also what makes unchecked AI dangerous. You can ship 50 wireframes in the time it used to take to sketch five. But failures, at that pace, ship just as fast.

The designer as a human firewall

The framing I keep coming back to is this: Between AI efficiency and user harm, there is exactly one checkpoint. The designer.

That’s not a burden. It’s a position of genuine influence. But it only holds if designers are equipped with the right questions and the right frameworks for answering them.

Before any AI-assisted output ships, these are the questions that should be non-negotiable:

Who gets excluded? Does this work for users with disabilities, different cultural contexts, and limited tech literacy? AI tools are not designed for the margins. Designers have to be.

What assumptions are baked in? Does this assume smartphone access, a stable internet connection, and standard English? These are not universal conditions, and AI will not flag when it’s made them.

How could this cause harm at scale? Not “could one user misunderstand this?” but “what happens when this reaches a hundred thousand people who weren’t considered when the prompt was written?”

Would I stake my reputation on it? If this decision fails publicly, am I comfortable defending it? That question should feel sharp. If it doesn’t, the output isn’t ready.

These aren’t academic exercises. They’re the practical work of ethical curation. Without accountability, curation is just approval.

What guardrails actually look like

This is where the conversation usually stalls. Design teams know they should think about ethics. What they often lack is a structural way to do it that doesn’t add 10 hours to every sprint.

The good news is that guardrails don’t have to be elaborate. They have to be consistent.

At a minimum, enterprise design teams need four things embedded into how they work with their design systems: 

• A tool vetting protocol: a clear list of which AI tools are approved for use with your design system, under what data-handling conditions, and what’s off-limits. 
• A data classification policy: explicit guidance on what can and cannot go into a prompt (user research transcripts, client data, and proprietary component specs should never be fed into a public AI tool). 
• An accessibility review requirement for AI-generated outputs: not an optional QA step, but a mandatory gate before anything generated from the design system ships. 
• Documentation standards for AI-assisted decisions: ensuring there’s always a human name and a human rationale attached to what the system produces.

IBM’s research found that 68% of CEOs believe governance for generative AI must be built into the design phase. Not added afterward. Governance bolted on at the end of a process doesn’t govern anything. It audits damage.

The real competitive advantage

There’s a version of this conversation where ethics governance is framed as the responsible, slow, cautious path. AI adoption without it is the bold, fast one. I’d push back on that pretty firmly.

IBM and Salesforce are among the enterprises moving fastest with AI, and both have embedded governance into their work. The Einstein Trust Layer isn’t a constraint on Agentforce. It’s what makes Agentforce deployable at scale. Built into the Salesforce platform, it’s a set of security controls and data protections, including data masking and zero data retention, that ensure no sensitive information is stored or exposed when AI processes a prompt.

The same logic applies to design teams. Ethics frameworks aren’t what slow you down. They’re what let you move fast without leaving users behind.

The question about guardrails isn’t whether you should have them. It’s whether you’ll build them into your design system before or after something goes wrong.

Next: Part 2 – From creator to curator: the accountability gap in AI-assisted design. When AI generates your design system’s outputs, who is responsible for what it produces?

That’s the problem we set out to fix with our Design System Maturity Model: a free assessment that charts your system across six independent axes rather than giving you a single score on a single line. Here’s where it came from, why we built it the way we did, and what the results hopefully tell you.

It starts with Sparkbox

Mapping your design system maturity onto a model is definitely not something we invented. We’ve been recommending and using Sparkbox’s Design System Maturity Model for years. The work that Ben and his team did with their four-stage framework has been quietly shaping how the community talks about system growth for years.

Sparkbox’s four stages describe a system’s life like a product’s life. Stage 1 is V1: the first real release, usually driven by a passionate few. Stage 2 is Growing: the system is gaining users and the cracks of informality are starting to show. Stage 3 is Teenage: the awkward middle, where the system has real reach but the processes, funding, and team around it haven’t caught up with what it’s become. Stage 4 is Healthy Product: the system is run, funded, and trusted like any other product in the org.

A simple model works really well to recognise where you are and put words to the feelings you have about your design system. As I said, we’ve been using it since they first wrote it. However, we felt there was space for a more expanded approach to truly understand where you are.

Why one line wasn’t enough anymore

The limitation of any single-track maturity model is baked into the format, as it assumes a system matures as one coherent thing. In practice, the systems we see through zeroheight mature all over the place.

A grassroots system built by craftspeople can hit Stage 4 on component quality while its governance is still one person doing it alongside their “real” job. A top-down, well-funded system can have Stage 4 process ceremony wrapped around a Stage 1 component library. Collapse either of those into a single number and you not only lose the detail, but you also potentially hide the areas you need to grow in. The gap between the strongest and weakest axis is where your next move lives, and a single score hides it by design.

There’s also the big ol’ elephant in the room that made this a bit more pressing… AI. The maturity models the community grew up on were written before AI-assisted design and development were part of anyone’s daily workflow. Today, whether your design system is the default context AI tools build from is a maturity question, and arguably the one that matters the most.

The six axes

So we took Sparkbox’s four stages and ran them across six independent axes:

• Foundations — tokens, components, and the reliability of the substrate consumers build on.
• Documentation & Knowledge — how much of the system’s knowledge lives outside people’s heads, in a form others (and machines) can find and use.
• Governance & Team — the people, funding, and processes that keep the system alive as the org changes.
• Adoption — how much of the org’s product work actually flows through the system, and whether using it is the path of least resistance or a has unnecessary theater around it.
• Measurement & Impact — whether you can answer “is this system worth it?” in the language of whoever’s asking.
• AI Readiness — whether your system is the context AI builds from, or the thing it works around.

Each axis gets its own four-stage journey from V1 to Healthy Product, so you not only get a score along each line, but also get the overall ‘shape’ of your design system and the team that drives it.

How we built the tool

We started by writing the stage definitions themselves. It ended up with a full matrix, six axes by four stages, each cell describing what that stage concretely looks like. Stage 2 Documentation isn’t “docs need improvement,” it’s “the what is documented, but the why still lives in Slack threads and people’s heads.” We thought it was important to try and capture both the stage you’re at, but also what’s driving that stage.

Then we wrote the questionnaire. It’s a tough one, because the fewer questions the better. We settled on 29 questions, which takes about eight minutes. We’d prefer fewer, but this was the minimum we thought we could do while still getting the information needed to give a good diagnostic. The diagnostic core is four questions per axis, each with four graduated options mapping to the four stages. We deliberately framed questions behaviourally rather than artefactually wherever we could (not “do you have contribution docs?” but “what actually happens when someone wants to contribute?”). Artefacts are easy to have and easy to ignore, but behaviour is where maturity actually lives.

We also collect a bit of context (org size, governance model, and so on) which never touches your scores but does tune the recommendations. “Formalize your governance” means something very different at a 40-person startup than at an enterprise, and the advice should know the difference.

Why the shape matters more than the score

Because the axes are independent, your results aren’t a grade per se. Instead, they act more like a diagnosis. The spread between your strongest and weakest axis tells you where the risk is and where the next investment should go.

The clearest example: a system with high Foundations, high Adoption, and Stage 1 Measurement is genuinely excellent and the most likely thing to get cut in a reorg, because nobody upstairs can see its value. It highlights the storytelling vs quality problem, so you can get an accurate read of how your design system is actually doing. A single-score model would call that system “pretty mature” and completely miss that it’s in danger.

The archetypes

Once you start charting systems as shapes, you notice the same shapes recurring. We curated nine of them, and the assessment tries to match your profile to the nearest one.

A few favourites:

• The Art Student: beautiful library, thin everything else. Usually built by craftspeople, almost always grassroots, and the highest-risk archetype in a downturn because the team can’t justify itself even though the work is real.
• The Edifice: The mirror image of the Art Student. It presents as ceremony wrapped around a thin library, usually born from a top-down mandate where leadership bought the idea of a design system before practitioners built one.
• The Invisible Asset: The one you should have a cry about. It’s a genuinely good system that earned its reach through quality, with a team too close to the work to tell the story upward.
• The “Humans Only” System: The typical mature system in 2023. It’s high on every classic axis, built properly in the pre-AI era, now being routed around by tools that don’t know it exists.
• The “AI Will Build It” System: The opposite of the ‘Humans Only’. Wired into AI tools before the knowledge layer existed, producing on-system code without on-system reasoning. Output that looks right while masking the documentation gap underneath.

The others, The Green Bud, The ‘Use It Or You’re Fired’, The Dashboard Darling, and the rare Healthy System, you can meet in the tool. None of them are report cards or a judgement. Instead, each one comes with what drives the pattern and where its particular tension lies, because the point of an archetype isn’t the labelling, it’s what you do next to get towards the healthy system.

Find your shape

The assessment is free, takes about eight minutes, and gives you shareable results in both webpage and PDF form.

I’d genuinely love to hear which archetype you land on, and whether it rings true. Find me in the zeroheight Slack community, or on Bluesky, and tell us your shape!

This article explains how product systems can structure documentation so that deviation doesn’t quietly become accessibility debt.

Two levels of system, two levels of responsibility

I see this most often in enterprise design system teams, where there are multiple layers to the system: base systems (e.g. Fluent, Material) intended for use in product systems (e.g. Outlook, Gmail). Base systems can’t account for every unique pattern a product will need. Their job is to offer ubiquitous, reusable components that work across a company, not to anticipate every product’s specific patterns.

In product design system teams, our job is to extend the base system into our context, not replace it. In atomic design terms, the base system handles atoms, molecules, and some organisms; we take those and build the product-specific organisms, templates, and pages our context requires.

That extension work follows a consistent sequence: We assess what the base system already offers, figure out how those pieces combine for our specific use case, then build and document it.

Let’s take errors as an example. A base design system might offer errors on inputs, but it doesn’t require a specific pattern for multiple input errors. This raises questions the base system may not be built to answer: How do we handle input errors across a form? How do we summarize those errors for the user? How might we handle errors in a multi-step form?

The base system gives us error guidance at the component level, such as how a single input should look and behave when it’s invalid. It doesn’t tell us how those errors behave in concert, across a form. That gap is ours to define and document.

Definition and documentation

When we define product components and patterns, we have to gather requirements from three places: the base system, accessibility standards (WCAG), and the product itself.

Let’s extend our error example:

• The base system has given us error handling on individual inputs, with guidance on multi-input forms, but no explicit requirement.
• Accessibility standards such as WCAG 3.3.1 (Error Identification) and 3.3.3 (Error Suggestion) give us requirements, recommended techniques, and known failure patterns to check our approach against.
• The product teams share the common scenarios we have to account for, such as a single-step form versus a multi-step form. Research data adds to this: common pain points users, particularly disabled and neurodivergent users, experience with this kind of scenario.

In these situations, we often look to other products, in our company or elsewhere, to see how they’ve handled it. GOV.UK’s design system offers a well-tested pattern for our example here: error summary. We check that it’s consistent with the base system’s guidance and directly addresses frustrations disabled and neurodivergent users commonly report when finding errors in long forms. We can use an error summary to show multiple input errors, and link to specific input errors to reduce the burden on users to find them.

From here, it’s on us to decide how we extend the base system for our context. We can build a component that pairs an error summary with the individual input errors it links to. Beyond building it, we still have to document when to use it, how to implement it, the required content structure, and the accessibility requirements it must meet.

Accessible defaults and reduced decision fatigue

Once we’ve gathered those requirements and decided how to extend the base system, the real work begins: turning that decision into a default our product teams can rely on, specific enough to be useful without burying them in detail they won’t read.

Take the error summary from our example. The base system gives us a starting point: An error summary can be used to surface errors, with focus moving to it on submission. That foundation holds as we extend the pattern, but it can only take us so far.

In a product system, our guidance can be more exact, since we’re solving a narrower problem. We have to document how the pieces interact: that the error summary links to each individual input error, the minimum and maximum number of errors it should handle, and the edge cases in between.

This is where defaults matter most for accessibility. There’s a common tension in documenting it: too little guidance, and designers don’t know what’s expected of them; too much, and they get overwhelmed, skip it, or apply it inconsistently. The way through is to be precise about what’s already handled versus what’s left to the designer.

In practice, this means our documentation states the default and the deviation cost in the same breath. Something like this:

This confirms the pattern is accessible, what the default behavior is, and what they should do if they change that. Teams don’t need to know WCAG in depth to use the pattern correctly; they only need to know what they’re choosing if they step outside it.

This precision matters because of how designers actually behave when asked to “annotate for accessibility” without it: most default to annotating focus order, often incorrectly, with no clear sense of what else to annotate, and eventually give up trying. Naming the decision points explicitly, and pairing each one with its exact required annotation, closes that gap.

The deviation contract

Defaults work when teams use them as designed. But not every team will, and when a team decides to deviate, the documentation needs to tell them exactly what they’re now responsible for.

Take our error summary example. A team might decide they want errors to “pop up” more assertively, and reach for a toast notification instead. It’s an understandable instinct, but a poor fit: Toasts are transient, often disappearing before users can process them, with no way to recover the list of errors short of resubmitting the form. 

This is exactly the kind of decision the deviation contract exists for. The system can’t stop a team from making this choice; it can only tell them what they now own by making it. Our documentation should make clear that they:

• have moved outside the base system’s validated guidance, and now own the accessibility approach for this pattern
• must provide their engineers with thorough accessibility annotations for what they’ve built
• must run accessibility testing with far more rigor and more frequently than the default might require

The point isn’t to forbid deviation. Sometimes a team has a genuinely good reason to diverge. If we don’t offer that option, teams will do it anyway.

Divergence without a contract is how accessibility debt accumulates quietly: months later, as a bug report. Naming the cost up front, in the documentation itself, is what keeps that debt from being invisible.

Carrot over stick

Over the years, I’ve been asked many times how to motivate teams to prioritize accessibility. This is a small piece of how to do that.

Every design system team needs at least one accessibility specialist to define the system’s contracts and defaults. Without one, accessibility becomes everyone’s job in theory and no one’s job in practice.

That single investment pays off across every product team consuming the system. When teams know the default will be accessible if used as intended, and know exactly what their part is when they deviate from it, they don’t feel like they have to learn everything about accessibility in a single sprint.

This also reduces the testing burden. Accessibility testing will always be a factor requirement, but when the system is accessible and the decisions required to use it are clear, teams can test their work more easily, understand how it should behave, and spot where things might have broken rather than starting from scratch each time.

That clarity cuts both ways: Stay within the system, and accessibility is faster and easier to deliver. Deviate from it, and that same testing and bug-fixing effort lands back on you.

Design systems can’t automate away all of your accessibility considerations, but small actions like these reduce risk. They show teams, concretely, that straying from the system costs time and that the system itself is the easier, faster path.

Design leaders post their conference talks about governance frameworks and adoption metrics. Companies showcase their component libraries as evidence of design maturity. The narrative is polished, aspirational, and outcome-focused.

Then there’s the version that lives on Reddit at 11pm on a Tuesday.

“I dream in nested components now,” wrote one designer on r/UXDesign, earning 500+ upvotes. “I whispered ‘atomic design’ in my sleep last month.” The replies poured in – some offering practical advice, others defending the practice as necessary, and a few echoing the frustration: admitting they found the work to be a “soul sucking exercise,” and struggling with “the monotonous, banality of it.”

These brutally honest conversations are happening – on Reddit threads with hundreds of comments, in YouTube video responses, in Slack channels, and in Discord servers where practitioners vent after hours. But they rarely make it into official publications. The gap between what we say publicly about design systems work and what we say to each other in semi-anonymous forums? It’s gotten wide enough that maybe we should talk about it.

This article isn’t a critique of design systems as a practice. It’s an attempt to surface patterns from these unofficial conversations – the ones that get 100+ upvotes because they articulate something everyone recognizes but rarely sees in print. Think of it as a PostSecret for design systems work: the truths practitioners know but assume aren’t worth sharing officially.

What they say when no one’s watching

On what the work actually feels like:

“You will be working like a janitor, cleaning other teams’ works. Make decisions that will not satisfy everyone, and get a lot of heat in the process.” (Source: Would you switch to a design systems team as a junior? on r/UXDesign)

“Because DS teams are small and poorly funded, it means having to be a product designer, engineer, content writer, service designer, educator, evangelist, program manager, account manager, community manager, user researcher, and production designer all at once.” (Source: Leaving design systems on r/UXDesign)

“It’s honestly less creative, and if you’re like me, you need to be able to scratch that itch. I’ve found my hobbies have gone from passive enjoyment of things – movies, exercise, video games – to more creation due to this void.” (Source: Anyone work as a lead designer on a designs system as a product? on r/UXDesign)

(Design systems work so creatively draining that it changes how you feel about what you do for fun? That’s… not great.)

On corporate incentives:

“In my experience in a large corporation, no designers or business people want to reuse anything. They want brand-new, never-seen items that they had a hand in because that’s how you get promoted. Efficiency and recycling are NOT sexy.” (Source: Why most design systems implode on r/javascript)

“You’ve now created a second product to maintain. A component library has its own bugs, backlog, documentation needs, release cycles, and operational overhead – often doubling the workload.” (Source: Building a Design System in 2026 on r/DesignSystems)

On career concerns:

“I’m worried it would hurt my career growth. It’s a lot easier to switch companies if you’re a ‘general’ product designer, vs if you are a ‘design system’ product designer, then it kind of paints you into a corner.” (Source: Anyone work as a lead designer on a designs system as a product? on r/UXDesign)

“There were so many people who were interested in design systems a while ago. Now the pendulum is slowly swinging back.” (Source: Leaving design systems on r/UXDesign)

On who gets replaced:

“Design systems let computer scientists build ‘good enough’ interfaces without having to suffer conversations with artists and designers, whom they feel superior to. It gives them a tool of efficiency to remove us.” (Source: Are design systems a threat or an opportunity? on r/UXDesign)

“For talented designers: massive opportunity. For untalented designers: massive threat. For the people who only know how to crank out a pretty-looking mockup, with no critical thinking regarding how it works within the grand scheme of the site or app, it’s a serious problem.” (Source: Are design systems a threat or an opportunity? on r/UXDesign)

The patterns beneath the complaints

Read enough of these threads, and something becomes clear: This isn’t just frustration. There’s a structure to it. The design systems discourse, it turns out, is also having a conversation about power dynamics.

Experience as privilege

When senior designers dismiss process as unnecessary (“just use your intuition”), they’re making an argument from a position of accumulated capital. Commenting on the YouTube video of Don’t trust the process, a talk by Anthropic design lead Jenny Wen, one post nailed it: 

“Intuition is compressed experience. But juniors don’t have the experience yet. So what are they supposed to rely on? If success of design is framed as intuition-based, it’s a mentorship bottleneck. Also, in cross-functional teams, intuition-based approaches lead to gatekeeping and politics disguised as craft.”

Another: “I feel she’s forgetting the years of experience she has accrued following this process is the reason why she’s even able to lean into an intuitive and quicker design process in the first place. This way of thinking and designing doesn’t work as well for junior designers who are new to the craft and need guidance.”

Senior designers often frame systems as constraints on creativity. Junior designers see them as necessary scaffolding. Who’s right depends entirely on where you sit on your company’s org chart.

But it’s not just about an individual’s career stage – it’s also about whose context gets centered. The most upvoted critical comment (553 likes) on Jenny Wen’s talk made this explicit: 

“Maybe okay when copying mature competitors like Google Docs or Miro, but not okay when you’ve got real problems requiring design thinking, like improving safety in hospitals…This approach only works in highly mature categories where the design goal is surface-level differentiation.”

Another designer: “[Wen] clearly works in corporate and undermines a lot [of] experience other designers have in different industries… my intuition did not work some of the time. Because a) I dont have a rich background like her, and b) I was not familiar with those industries.”

“Trust your intuition” works if you’re designing Figma for designers. It’s a different proposition entirely if you’re designing warehouse management systems, hospital safety tools, or point-of-sale software for frontline staff like nurses or legal aid workers. The advice reflects whose problems we think we’re solving.

Process as protection against power

Without structure, politics fills the vacuum. One person commented: “If intuition is the standard, then any stakeholder can claim authority based on gut feeling, and we are back to design being dictated by whoever speaks the loudest.”

Another one (153 likes): “Intuition without accountability can drift into bias, skipping steps works for experts, not novices, while process artifacts often exist to support organizational memory and governance. HCD protects against power asymmetries, not inefficiency… ‘Trust yourself’ does not scale safely across organizations.”

This reframes the entire debate. It’s not about creativity versus constraints. It’s about whose voice wins when there’s disagreement. Process – including design systems – creates a layer of oversight on power asymmetries. Remove it, and you’re back to “whoever speaks the loudest.”

The ten-jobs-in-one problem

Design systems teams are chronically under-resourced, creating a specific flavor of burnout. You’re simultaneously maintaining components, writing documentation, evangelizing adoption, training teams, managing stakeholder expectations, and debugging implementation issues.

The janitor metaphor landed hard because it’s accurate. You’re cleaning up everyone else’s mess. And the invisibility makes it tricky to dedicate yourself to – maintenance work doesn’t generate the kind of portfolio pieces that get you promoted. As u/pwnies, a PM for design systems at Figma, noted: “There is no ‘finishing’ a design system.”

But corporate incentive structures reward shipping new things, not maintaining old stuff. Product designers ship features that balance craft and business value for an external audience. Systems designers maintain internal infrastructure that’s only noticed when it breaks.

The specialization trap

Design systems work is specialized enough to pigeonhole designers but not prestigious enough to command premium salaries everywhere. 

You gain deep expertise in a narrow domain while your peers build portfolios of diverse product work. When it’s time to job hunt, “design systems designer” is a less transferable title than “product designer.”

One practitioner described it as “painting yourself into a corner.” Multiple people independently voiced the same concern about the field’s staying power: “There were so many people who were interested in design systems a while ago. Now the pendulum is slowly swinging back.”

The replacement anxiety – and who’s actually worried

The conversation around AI and workflow automation has added a new dimension. Multiple practitioners noted that design systems work – particularly the component-building, documentation-writing, consistency-enforcing parts – feels like exactly what AI might automate first. “It’s the kind of thing I see AI easily taking over,” wrote one designer.

But developers had a different take. And they weren’t gentle about it.

“I’m a frontend software engineer, and you clearly don’t do the implementation,” wrote one in response to a “design systems are a waste of time now” video. “It produces garbage code. Design systems are needed because they produce deterministic results… lost nearly all credibility when you think AI slop actually replaces all of this.” 

Another: “This falls apart very beautifully when one person is using Claude, and another is using Gemini on the same codebase. That’s when you’ll beg for a design system.”

Who’s right probably depends on whether you’re responsible for maintaining the codebase or just handing off mockups. When designers declare systems as dead without consulting the people or teams who implement them in reality, it’s another example of who gets heard when shaping what gets built – or in this case, who gets ignored.

Why the official channels stay polished

None of this is news to practitioners. So why doesn’t it show up in official publications?

Partly it’s selection bias. Conference talks showcase successes. Case studies highlight wins. LinkedIn incentivizes a professional stance that doesn’t always show the mess or chaos it took to get somewhere. Writing publicly under your real name while employed means self-censoring anything that might make your company look bad.

But there’s also a kind of collective imposter syndrome at work. The assumption that everyone else has it figured out – that your struggles are personal failures rather than systemic patterns – keeps people quiet.

Reddit and semi-anonymous forums break that silence. The upvotes serve as a signal that this isn’t an issue in isolation, or something to be embarrassed about: Other people feel this too. The janitor metaphor resonates because practitioners recognize themselves in it. The 10-jobs-in-one complaint can feel relatable because it’s a requirement that can follow people across companies and industries.

What the honest version looks like

The design systems community has created something genuinely valuable: shared vocabulary, reusable patterns, accessibility improvements, and inclusive design considerations built into guidelines and components rather than retrofitted later. None of the critiques above negates that value.

But when the polished narrative doesn’t match reality, practitioners feel isolated. When you’re burnt out from quiet maintenance work while conference talks focus on innovation, it’s easy to think you’re the problem.

What these online conversations reveal isn’t weakness. It’s the gap between what we’re told design systems work should be (strategic, impactful, scalable) and the reality of what it often is (political, high-effort, invisible).

The chef analogy from gob_magic on Reddit captures it: “Wrong analogy would be a chef keeping a pantry full of ingredients to cook dishes with. Somewhat right analogy is a chef cooking a list of dishes, iterating on them, keeping the final dishes on the menu. THEN creating concoction of sauces and spice mixes to speed up cooking the dishes on the menu.”

Design systems built before you know what you’re cooking tend to fail. Design systems maintained by one person doing 10 jobs tend to burn people out. Design systems in companies that reward novelty over reuse tend to be ignored or worked around.

These aren’t edge cases. They’re patterns.

Some thoughts on honesty

Naming these patterns doesn’t solve for all of them. But it does something valuable: Seeing these patterns as industry-wide issues reminds practitioners they’re not alone in sensing them – and that matters because disconnection or struggling alone is what keeps broken systems in place.

When you see your experience reflected back at scale, something shifts. The multiple-jobs-in-one problem stops feeling like a personal failing and starts looking like what it actually is: a resourcing failure. The creativity drain isn’t about you being weak – it’s about work that genuinely depletes a specific kind of energy. The career trap isn’t paranoia – it’s a hidden pothole other people are navigating too.

And here’s the thing: Burnout isn’t supposed to be part of the job. The fact that design systems teams are chronically under-resourced isn’t an unfortunate reality to accept – it’s a problem that deserves to be named and called out. The invisibility of maintenance work isn’t inevitable – it’s a choice organizations make about what they value and reward.

From recognition to response

So what becomes possible when we stop pretending? When we decide to bring these Reddit-at-11pm conversations into plain view?

For one, we can make better career decisions. If you know that design systems work drains creative energy in ways that reshape your free time outside of your job, you can plan for that. You can build in side projects. You can recognize it’s not a personal failure – it’s the nature of the work, and you can decide if that trade-off is worth it for you right now. Maybe you’ll change your mind later, and that’s okay, too.

We can also push back on under-resourcing. When one person voices the wearing-many-hats problem, it’s a complaint. When it’s a pattern across companies, it’s data. It becomes harder for organizations to frame it as “just how things are” when practitioners can point to these conversations and say: This is what happens when you under-invest in design systems.

We can have more honest conversations about who this work is actually for. Not everyone should do design systems work – and that’s fine! It requires a particular kind of mind and personality. Some people thrive on the details and the meta-level thinking. Other people might need the creative freedom of product work. Knowing which you are (or where you are in your career) helps you make choices that don’t leave you depleted and resentful.

And maybe most importantly, we can build better support structures. When a Figma PM says on Reddit, “there is no finishing a design system,” that’s not discouragement – it’s reality. But reality without resources is a recipe for burnout. Organizations that take that seriously don’t treat design systems teams as an afterthought. They staff them properly. They create paths for career growth that don’t require leaving systems work. They reward careful and considered maintenance, not just shipping shiny new things.

The value of actually being heard and taken seriously

The gap between LinkedIn and the rest of (semi-anonymous) social media platforms exists because we haven’t found a way to talk about these conditions honestly in official channels. But here’s what the unofficial channels show us evidence of: the people doing this work are thoughtful, self-aware, and capable of articulating exactly what’s hard about it. They’re not complaining for the sake of complaining – they’re naming patterns that organizations keep recreating.

That kind of clarity is valuable. Not just for individual practitioners trying to make career decisions, but for the field as a whole. Design systems work is still young enough that we’re still figuring out how to do it well, how to resource it properly, and what sustainable systems practices actually look like.

The practitioners having these conversations at 11pm on a weeknight deserve to see their experiences reflected in broad daylight. Not as complaints to be dismissed, but as patterns worth examining. Not as individual failures, but as collective truths that we’re finally ready to name – and maybe, actually address.

Because honesty isn’t the end goal. It’s the core foundation. And what we can build on top of that is up to us.

Open almost any design system presentation, and you’ll probably see charts, adoption percentages, component counts, and maybe a giant “98% consistency score” floating around somewhere, looking very proud of itself.

But here’s the thing: Not all metrics are useful.

Some metrics make us feel productive. Others actually help us make better decisions. There’s a big difference.

Because if we measure the wrong things, we risk optimizing for activity instead of impact.

Maya Hampton explores this brilliantly in her article, From basic adoption to meaningful measurement: How design system metrics evolve, where she talks about how metrics mature alongside the design system itself. That evolution is critical because the way we measure success early on should look very different from how we measure success once a system becomes embedded across teams.

And honestly, design systems are too important for us to measure them poorly.

They influence engineering velocity, user experience, accessibility, consistency, onboarding, brand trust, and product quality. They shape how teams build and how users experience products every single day.

So if design systems are products in their own right, we should measure them like products, too.

Adoption is hard. But it matters more than almost anything else

Let’s start with adoption.

Adoption can be frustratingly difficult to improve. You can build beautiful components, create pristine documentation, and run onboarding sessions until you’re blue in the face, but if teams don’t actually use the system, none of it matters.

A design system is only as good as the people using it. Low adoption doesn’t just weaken consistency. It weakens the return on investment of the entire system.

I always think about it like road rules. Imagine everyone learned to drive however they wanted. Different sides of the road, random traffic lights, no agreed patterns. Technically, everyone might still reach their destination, but the experience would be chaotic, stressful, and full of avoidable mistakes.

That’s what happens when products scale without shared systems.

Consistency creates confidence

Design systems create consistency, predictability, and efficiency. They help teams move faster because they are all referencing the same foundations instead of rebuilding solutions from scratch every time.

And users feel that consistency, too.

The same filters behaving consistently across products. Familiar form patterns. Predictable button placement. Shared navigation behavior. These things reduce cognitive load and help users build confidence in the interface.

Nielsen Norman Group has long emphasized consistency as one of the core principles of usability through heuristics like Consistency and Standards and concepts like Jakob’s Law, which state that users spend most of their time using other products and therefore expect familiar patterns and behaviors

That’s not just “nice design.” That’s measurable value.

Vanity metrics vs meaningful metrics

Now, let’s talk about the dangerous stuff: vanity metrics.

Things like:

• Total number of components
• Number of Figma libraries
• Number of documentation pages
• Number of contributors

These metrics are not inherently bad. They just don’t tell the full story.

A design system with 300 components isn’t necessarily better than one with 60. In fact, it might be significantly worse. Bloated systems become harder to maintain, harder to adopt, and harder to trust.

The real question is: Are people actually using the system effectively?

That’s where meaningful metrics come in.

Metrics like:

• Adoption across teams and squads
• Engineering velocity improvements
• Reduction in duplicated components
• Usage of predefined patterns versus custom solutions
• Reduction in support tickets
• Increased consistency across experiences
• NPS (Net Promoter Score) improvements tied to UX consistency
• Accessibility improvements over time

These metrics tell a much richer story about impact.

Engineering velocity is a business metric

One of the biggest mindset shifts I’ve seen is recognizing that design systems are not just design tools. They are operational tools.

A mature design system directly impacts engineering velocity.

Reusable components reduce duplicated work. Shared patterns reduce decision fatigue. Strong foundations reduce rework.

That means teams spend less time rebuilding the same UI and more time solving actual customer problems.

And this matters at a business level.

When leadership sees measurable reductions in duplicated effort, it changes conversations around investment. Suddenly, the design system is no longer viewed as a “nice-to-have.” It becomes infrastructure.

This can influence team growth, investment decisions, and organizational structure because the efficiency gains become measurable and visible.

And this is where metrics become incredibly powerful.

If you can show that using predefined components reduces delivery time by 20%, that’s a metric executives understand immediately.

Measuring duplication is hugely valuable

One metric I think teams often underestimate is duplication.

Custom components can be incredibly revealing.

If teams repeatedly create similar custom solutions outside the system, that tells you something important. Either:

1. The system has gaps.
2. Teams don’t know the component exists.
3. The component is too difficult to use.
4. The component doesn’t fully meet product needs.

All four are useful insights.

This is where dashboards become very valuable.

Tracking which teams use which components, which versions they are on, and which tokens are being implemented gives you visibility into the health of the system itself.

You can identify:

• Teams lagging behind on adoption
• Components nobody uses anymore
• Patterns being recreated unnecessarily
• Areas where documentation may be unclear
• Opportunities to expand the system strategically

Metrics should help design systems evolve. Not just report on themselves.

Version tracking matters more than people think

One of the least glamorous but most useful metrics is version adoption.

Which teams are on the latest version of the design system?

It sounds simple, but it’s hugely important.

A team running outdated components creates inconsistency, increases maintenance overhead, and can even impact brand perception during larger initiatives like rebrands.

The same applies to tokens.

Tracking token adoption ensures teams stay aligned to the same visual language across products. This becomes especially critical during rebrands, accessibility updates, or multi-theme support.

Without visibility, inconsistencies creep in quietly. Then suddenly you’re debugging six shades of “primary blue” across the same product ecosystem. Nobody wants that.

Metrics need context

Here’s another important point: Metrics without context can be misleading.

An adoption percentage alone does not tell you whether the system is healthy.

Maybe adoption is technically high, but teams hate using the components. Maybe teams are bypassing patterns with excessive overrides. Maybe the documentation is confusing.

Numbers should start conversations, not end them.

This is why pairing quantitative metrics with qualitative feedback is so important.

Talk to teams. Run internal usability sessions. Ask engineers where friction exists. Ask designers what slows them down.

The best design system metrics combine behavioral data with human insight.

The goal is better decisions

At the end of the day, metrics are not about dashboards looking impressive.

They exist to help teams make smarter, more informed decisions.

• Should we invest in this component?
• Should we deprecate this pattern?
• Which teams need support?
• Where are inconsistencies emerging?
• What is creating friction?

Good metrics create clarity.

And the best design system teams use that clarity to continuously improve the product experience for both internal teams and customers.

Because design systems are not static libraries sitting quietly in the corner of the internet. They are living products.

Products that shape how teams build.
Products that shape how users experience interfaces.
Products that quietly influence efficiency, consistency, accessibility, and trust every single day.

And when we measure the right things, we stop defending the value of design systems and start actually proving it.

For years, I heard that second line as: “The best laugh never leaves your lungs.”

Oddly, that also feels thematically right. To me, the song is about the gap between an artist’s internal life and how their work is ultimately experienced by an audience. Where does the “real” song live? In the writer’s intention? In the listener’s interpretation? In some Platonic ideal of the perfect song that no one ever actually hears?

These questions resonate with design systems work.

The reality of a design system doesn’t live only in its explicit artifacts: its code, Figma libraries, design principles, or documentation site. It also lives in the implicit, relational, and behavioral space around those things. The gaps between the notes.

We should make those implicit ideas explicit wherever we can, but that’s, of course, a Sisyphean task. What if no one fully reads, remembers, or correctly applies your guidance in practice?

At some point, “what the system is” may be better assessed behaviorally: by what its consumers actually do with it. The systems team can make the music, but product teams have to dance. If they aren’t dancing, that doesn’t necessarily mean the music is bad. They may simply not be the right crowd for it. Or, as Marty McFly suggests to the Hill Valley High Schoolers in Back to the Future: “I guess you guys aren’t ready for that yet. But your kids are gonna love it.”

Figma is not the thing itself

At BT, our design system team sits within a wider Customer Experience cluster. We have dedicated engineering resources to build and maintain the design system code. That means it’s fair to judge our success by real customer experiences: what people encounter in the browser, through coded components.

Our role isn’t to create components, cross our fingers, and hope they’ll be used exactly as intended. Our role is to do what we can to make intended use likely, understandable, and achievable.

One implication is that we should encourage designers to see Figma components as another form of documentation, rather than as the actual components themselves.

That applies to both systems designers and consuming designers on product teams. The mindset helps shift attention from outputs to outcomes: from polished prototypes and aspirational wireframes to what actually gets developed and placed in front of customers.

Too often, those polished Figma outputs only see the light of day in altered and compromised form once the scythe of engineering feasibility and delivery constraints has done its work. That can leave designers feeling dejected, unsatisfied, or undervalued by “the business”.

But designers should also challenge themselves to understand perceived constraints as design parameters. They should map the current capabilities of the design system, delivery timescales, back-end constraints, and stakeholder priorities. Then they should apply their creativity to the parts of the design opportunity space most likely to ship — not only to the ideal peaks of the fitness landscape.

The map versus the territory

Lewis Carroll’s Sylvie and Bruno imagines a country whose mapmakers create a map at a scale of one-to-one. The map is exactly the same size as the territory it represents.

A map is useful because it simplifies. It represents, abstracts, and leaves things out.

Figma components are just such abstractions. They document and represent the coded components they point toward. There is great value in thinking about them this way as we build our design system and help consuming teams work with our assets as intended.

In this framing, Figma components are primarily a kind of product documentation. They communicate to feature team designers and developers what they can assemble with the actual product being documented: the design system code as it exists today, with its current capabilities and constraints.

A caveat

Some organizations may reasonably treat Figma as the canonical truth of their design systems. In early-stage startups, research contexts, or companies exploring ideas long before a line of code exists, the Figma prototype may be the only thing being tested with users. In those cases, the Figma library is not documentation of something else. It is the thing.

That’s a perfectly valid approach for them.

In our own team at BT, we’ve moved from a more fixed and opinionated system toward one that emphasizes composability and flexibility. With simpler fixed patterns, the limitations of treating Figma components as the primary vectors of user experience are less pronounced.

But greater composability opens up the design space. It also shifts more responsibility onto consuming teams to understand what can actually be developed with the system. Designers need a much greater awareness of technical constraints, so they don’t misconstrue a system feature and specify something unachievable for developers who expect to use the system as is.

Composability is a great ability to give your system’s consumers, but “with great ability comes great accountability” — as Miles Morales’ dad puts it in Spider-Man: Into the Spider-Verse.

Why Figma can only ever be a representation

Figma is a great tool, but it has limitations. Despite efforts to make developer hand-off more of a handshake — through Dev Mode and newer linting tools such as Check Designs — Figma output still requires an interpretive act of translation into code.

I like to think of what exists on the canvas before development as its own category of substance: Figment. The product of a designer’s imagination, bearing the mark of its maker and the qualities of its material.

Components made from Figment don’t have the same conditional logic, responsive behavior, or interactive state management as React components. Often, Figma can simulate similar effects, but through conceptually different means. Something code handles with a single media query might require a new component variant, a set of auto layout tricks, or a complex Variables structure that simply isn’t needed in production code.

We recently developed an updated component for our content management system. The code handles a range of behaviors: two- or three-column grids, optional carousel behavior on tablet and mobile, card heights based on aspect ratios, and combinations that change across viewport widths.

If that sounds complex, it’s because it is. The React component handles it gracefully. But even with newer Figma features such as auto layout grid and slots, we haven’t been able to build a Figma component that covers all the options in the same way, remains fluidly responsive, avoids variant redundancy, and stays easy to use without detaching elements.

Maybe there is a way to do it. If you can show me how, I’ll buy you a beer.

Treating the Figma component as documentation — an imperfect but useful abstraction of the real thing — lets me sleep more easily at night. It also stops me from driving my team mad trying to perfectly replicate coded behavior in an intrinsically different medium.

Overengineering Figma components helps no one

The temptation to fully mirror the coded component in Figma is strong: every state, every restriction, every conditional rule.

But that approach quickly creates practical problems:

• Variant explosions
• Maintenance nightmares
• Bloated file sizes
• Slower design workflows
• Components that constantly need refactoring
• A false sense that Figma constraints alone can guarantee correct implementation

It can also risk limiting the ambition of the coded system to whatever can easily be modeled in Figma, given the tool’s limitations or the designer’s skill. Worse, it can encourage consuming designers to assume: “If I can configure it in Figma, developers can configure it the same way.”

That may not be true.

Teams should be explicit about what their Figma components are and what they are not trying to do. For example, we don’t treat ours as ready-made prototyping components with wired-up interactions and animated microinteractions, good to go from the assets panel. They are intended for high-fidelity static wireframes, journey illustration, and showing the states and indicative content users will see.

That means accepting that if a designer needs to build a high-fidelity prototype for usability testing or stakeholder management, it may be fine to detach a component and hack it locally — provided that modified instance is not expected to comprise a long-lived asset maintained in lockstep with the system.

Design intent versus Record Set documentation

In construction, architects’ drawings develop over time. They begin as concept sketches, become more detailed design drawings, and eventually mature into technical information used for procurement and construction.

But once the building takes shape, things happen. Site constraints surface. Late-stage client changes appear. Snafus require pragmatic responses. The “Record Set” captures what was actually built, not just what was originally intended.

Our UI design and development process is similar.

Early sketches, wireframes, and first-pass Figma components articulate design intent. But once development begins, constraints emerge:

• Edge cases designers could not anticipate
• Accessibility behaviors that impose new requirements
• Responsive constraints discovered through implementation
• Performance considerations
• Tokenization or theming limitations
• Features that are much harder to build than expected
• MVP scoping decisions
• Reasons to split a complex component into several simpler ones

All of these mean that the “final” Figma component ready for publication can only really be completed after the coded component exists.

That is our version of the Record Set.

For consuming teams, it’s an important part of understanding a component’s affordances, parameters, and constraints. But it’s not the whole story. They still need to read the guidance, inspect the coded component, test its behavior, ask questions, and understand the system in use.

Where should guardrails live?

Developers often want components to remain lean and composable. Designers often want guardrails that prevent unwanted configurations. There is a real tension here.

Overconstraining components at code level can limit reusability, reduce flexibility, and create a maintenance burden.

Some rules — such as “this list should only contain 3–5 items” — may not belong as hard constraints in code. They may be better expressed through:

• CMS content authoring rules
• Design system guidance
• Wireframed recipes and examples
• Reviews, consultation, and shared judgment

Figma components alone are rarely enough to enforce correct use. Designers can apply overrides, detach instances, or swap subcomponents into unsupported configurations. The design system team can make supported usage easier and more obvious, and avoid exemplifying undesirable combinations, even where they are technically possible.

But in our context, there is ultimately no substitute for setting the expectation that product teams own accountability for understanding and working within system constraints. They can consciously depart from those constraints, but they should also own the implications of doing so.

What this means for designers

So what does the “Figma components as Record Set documentation” mindset mean for feature team designers?

It means not taking Figma components at face value alone.

Using a design system well requires effort. Designers need to triangulate their understanding from:

• Coded components and tokens available to developers, as seen in Storybook or example apps
• Guidance on zeroheight and explanatory Figma playgrounds
• Knowledge of the system’s design language, breakpoints, and adaptive patterns
• Interaction details across mouse, touchscreen, keyboard, and assistive technology use
• What the design system team can tell them about capabilities and limitations — if only they ask early enough

This is less convenient than pretending the Figma file contains the whole truth. But it’s much closer to how mature system adoption actually works.

The bitter pill

Design systems may have been mis-sold as a panacea for digital product delivery. Plug and play. Lego bricks. Painting by numbers. Cost savings guaranteed. Great, accessible user experiences assured. Creative freedom unlocked.

Let’s not sugarcoat it.

Learning to adopt a system well can be difficult. It can slow teams down before it helps them speed up. Any designer working with a system needs to understand the qualities and limits of their medium. The digital realm is no exception.

That does not mean teams should never improvise. I love seeing a good Ikea hack on Instagram, and it’s just as satisfying to see a design system pushed in unexpected ways that benefit the end user.

But informed improvisation is different from accidental misuse.

Know what the system is for. Know where the guardrails are. Know which parts are code, which parts are documentation, and which parts are shared judgment built up through use.

Read the product documentation first, folks. Don’t rely only on the pictures on the box and brochure.

Know the rules before you break them.

Agents, Skills, and Connectors

What was announced

The Figma agent rolled out to everyone, and the more important news is what now sits behind and around it. Skills package your workflows and conventions into reusable instructions that the agent follows. Connectors let it reach into the tools already in your stack, like zeroheight, Notion, Slack, Granola, Hex, GitHub, and Atlassian, and send updates back. Attachments let you drop in briefs, research, or any artifact for context. They’ve also integrated agents in the multiplayer aspect of Figma, so everything is shared, visible, and able to be collaborated on. Soon, this will be across Figma products, like Design, Figjam, and Slides, too.

What it means for design systems folks

For design systems folks, there’s a lot that agents can do to shortcut tedious, repetitive, or manual tasks within the design process. However, being able to do this with skills and connectors allows you to automate creation, audit, and iterate while remaining on system. Using connectors to pull in live content from complex sources, hooking variables up to a quickly made design, componentizing snowflakes to get ready for contribution… There are endless flows that can massively save time.

What still needs answering

One of the biggest, obvious open questions with agents is token usage. At the moment, usage is unlimited, but as soon as it comes out of public beta, there’s a real chance that tokens are going to get expensive. That means that we probably need to really figure out where the real savings are with using agents, and which are better to still do manually or via other avenues. There will come a time when the cost of automating might outpace the value.

Code Layers on the Canvas

What was announced

You can turn any design layer into an interactive code layer with a single click or a prompt, duplicate it to explore directions side by side, and collaborate on it in the same file like any other frame. You can extract code back into editable design layers, and one click pushes design changes back into the code layer. It’s about to be in closed beta, so there’s less detail around what is possible with code layers, but from what we know, there’s some interesting use cases for this.

What it means for design systems folks

It feels like this is a major step towards the gap between design and development getting practically narrower. Because the code is real code, pulled directly from your repo with git-style functionality for managing it, the components on the canvas are your components and tokens. Translating between code and design modes stops being a handoff and becomes a round trip. Combine it with the agent and the connectors, and you can start imagining real auditing in-canvas: is this layer using the system’s variables, is it on the current component version, does it match what’s documented?

Why I think this matters so much to design systems folks is that this allows for more frictionless iteration on code for folks who think visually. Being able to pull from the repo, switch it to design to make tweaks, iterate, or explore, then push that back is great for a lot of designers.

What still needs answering

The big if for this that will be answered as soon as we get access to it is the quality of output. On the code to design side, whether the design generation uses components and variables from the design library will be important to minimize drift. On the design-to-code side, again, getting Figma to generate code that is on-system and follows your coding conventions is a big if when it comes to how useful this will be to production teams.

Generative plugins

What was announced

Up until now, plugins were the domain of engineers. Recently, we’ve been able to create Figma plugins using things like Claude Code or Cursor. Now, you can create them directly in-file using agents. The cool thing is that the generative plugins within Figma natively use the Figma controls and package them up without needing to host them. So, if you have an idea of something you want Figma to do, you can just prompt it into creation in a way that is reusable and sharable with your team. At the moment, those plugins exist within the file they’re created in. Soon, you’ll be able to share across teams and orgs. Later, you’ll be able to publish these generated plugins to the Community for wider use.

What it means for design systems folks

This isn’t design-system-specific, but is still something pretty powerful for design systems teams. Design systems and ops people are already the ones building bespoke tooling, and we usually pay a real engineering and maintenance tax to do it. Generative plugins significantly reduce that tax. The repetitive, system-maintenance work that never quite justifies a sprint can now be a five-minute tool. When it arrives, the publishing path is what turns it from a personal convenience into a system-wide capability, so I’d watch that closely.

What still needs answering

I don’t think there were many open issues from a technical point of view on generative plugins. I think the biggest thing will be a governance and maintenance layer, and how they’re especially handled at an organizational level. The concept of 500 different designers and PMs creating small, single-use plugins could lead to chaos.

Figma Motion

What was announced

Motion has just entered the chat. Keyframes, easing, transforms, presets, build-from-scratch, or agent-generated starting points directly in Figma Design. It’s basically Flash reincarnated, but with a great-looking user interface, can be tied to variables and componentized, and exports to loads of formats, including accessible web-based formats (and being surfaced in the MCP and Make). I genuinely think this is one of the most exciting announcements Figma has made in the last few years.

What it means for design systems folks

For me, this is one of the sleeper giants for design systems as an industry. Until now, we haven’t had good ways to hand off motion between design, creation, and code. The fact that almost everything can be tied to variables, and motion and interaction can be baked directly into components, finally makes motion systems a first-class citizen. We’ll now have a way to define and test interaction and motion on both the design and code side, with easy handoff.

What still needs answering

The two big open questions are: the inclusion of styles for motion so it can be easily packaged, and how standards-compliant the output of things like easing curves is. There are also some more export options that I’d like, but the ones out of the box cover most aspects. There’s also an existential question for design system folks around ‘just because we can have motion, should we?’ that will likely come up. Creating motion has become easy; we need to make sure we don’t saturate what we do with constant movement just for its own sake.

The rest of the goodies

Shader fills and effects. Describe what you want (or hand it a reference image), and the agent builds a shader to create some pretty stunning visual effects. Effects transform a layer, and fills act as a new layer. The design-systems-relevant detail is that they’re parameterized by default; parameters surface as on-canvas controls, stack with other effects, and convert to code and common formats. That parameterization is a tokenization question waiting to happen. If these become part of brand expression, can they be governed like the rest of the system, or do they become a new source of untracked visual variance? Interactive shaders are also coming once performance is sorted. However, one important thing to remember is that most of the shader effects are things that just aren’t particularly standard when it comes to the web, so implementation in code will likely require heavy JavaScript.

Figma Weave tools. Figma acquired Weave last year, which provides a way to create node-based workflows for working with generative AI tools. Weave now connects directly into the Figma canvas. You can build workflows and publish them as templates to remix, with team/org/community publishing coming. More relevant to content and brand/marketing creative than to component systems, but the same “build a reusable workflow and share it” pattern as plugins and shaders, so worth knowing it exists.

Worth noting the through-line across plugins, shaders, and Weave: Figma is betting on everyone building and publishing their own tools. For a design system team that’s both an opportunity (faster bespoke tooling) and a governance problem (tool sprawl), and it’s the same tension in three different wrappers.

The final word

The unifying theme of Config 2026, read through a design-systems lens, is that the canvas is becoming context-aware. Code, motion, agents, and custom tools all now live in the same file and can all, in principle, draw on your system. The upside is enormous: less translation loss between design and code, motion that finally behaves like a system primitive, and AI that explores within guardrails instead of around them. But almost every one of these wins is conditional on the same thing: the quality and machine-readability of the system underneath.

Similarly, because so many of these new tools lean heavily on agents, token usage is going to become a real talking point over the next 12 months. For now, it’s time to dive into the tools and see what they can do to make our work easier.

Contribution in design systems is like a mountain range.

There are many ways up, and many ways down.

Your skill level and experience should determine the path you take.

You may need someone with more experience to guide you.

It gets steep at the top.

Types of contribution

Before we get to the snowy peaks of Mount Contribution, I should clarify what type of contribution I’m going to be talking about.

When I think about contribution, I divide it into two camps:

Indirect

Indirect contribution is not necessarily about adding something to a design system deliverable. It might be sharing a component blueprint, code, user research, or gathering group consensus on patterns. This type of contribution is incredibly valuable and too often goes unrecognized.

When someone pulls you aside for the “contribution conversation,” it’s likely that they want a different type of contribution.

Direct

Direct contribution targets the design system libraries, guidance, or website with the intent that the work becomes an official standard.

Contribution does not speed up design systems – the benefits are more important

It’s been said many times, but I’ll say it again: Direct contribution does not speed up design systems. In my experience, the opposite has almost always been true. It usually slows things down.

Contribution often creates as much work for the design system team, if not more, as if they had made something themselves.

The real benefit of contribution is and has always been bringing the outside in: gathering knowledge from a more diverse group of people who work with users every day. We should consider the extra time contribution takes as a benefit. In short, we should be happy to pay extra for it.

Framework, not a flow

Every type of contribution is unique. The thing being contributed, the person contributing, and the situation they’re in are all variables, so your framework needs to adapt to these conditions.

I’ve based a framework around three main factors:

• Who and how
• Should and could
• Contribution category

Who and how

This is about the people involved, their experience, and their discipline.

Before you start anything, determine:

• How much work will it be for the contributor?
• How much work will it be for the design system team?
• What disciplines or platforms need to be involved?
• Who is making this contribution?
• Is the contribution coming from a recognized subject matter expert – for example, a login pattern from the team that owns that flow? 
• What needs to happen for the thing to be contributed?

Should and could

The amount of time it takes to accept a contribution will have a significant impact on the design system team. The contribution needs to be worth it.

Ask:

• Will accepting (or not accepting) this make a significant difference to users’ lives?
• How much potential does this contribution have to be reused by other teams?
• How much debate is there going to be around this contribution? (This affects the timeframe.)

Contribution categories

The category of contribution can heavily determine the process it needs to go through. The type of category can mean the contribution could be a day, a month, or a year’s worth of work (yes, really).

From smallest to biggest, here are the categories I use:

Ground work

Being a maintainer, helping out behind the scenes, adding tests, or cleaning up files.

Bug fix

Jumping in with solutions to specific issues that have been raised.

Content clarity

Making guidance clearer and easier to understand without changing the sentiment.

Visual asset

Adding an icon or illustration.

Content pattern

A pattern that outputs guidance only. These are of high importance, but require less orchestration with other elements if they don’t include code or assets.

Component feature

Adding a feature to a component that already exists.

Component

Building a whole new component.

Pattern (multi-disciplinary)

A pattern that requires content, code, and design assets to be created and distributed together.

Service pattern

A pattern to determine an entire end process. The output may be maps and flows, but they often require the generation of multiple patterns and components to support them, too. 

For more on service patterns, read Frances Whinder’s article, How does a design system fit into service design?

Back up the mountain

The grading of ski runs provides an interesting analogy for contribution complexity and skill level.

Ski runs combine slope and difficulty grade into categories, symbolized by colors and shapes.

For example, if you’ve never been down a mountain, you’d look for the slopes identified by a green circle. If you are a pro, you’d be straight down the double black diamond run.

At the start of the article, I said:

• Contribution in design systems is like a mountain range.
• There are many ways up, and many ways down.
• Your skill level and experience should determine the path you take.
• You may need someone with more experience to guide you.
• It gets steep at the top.

If we now apply this thinking to design system contribution complexity, you start to see a real-life “Mount Contribution”.

The green runs are a great place to start: They help you with bugs, maintenance, and providing assets. They take less time and require less interaction.

As we move up the mountain, things get a little bit more complex with component features and content patterns.

Beyond that, the mountain gets very steep as new components and multi-disciplinary patterns enter the black diamond territory!

The axes of the mountain – “Time and Effort” and “Value” – depict what we instinctively already know. Those big, valuable contributions are significantly more complex, require a lot more experience to navigate, can take much longer, but ultimately can provide more value.

Contribution in practice

The core idea of this framework is that there is no one process. It’s tailored by:

• Who and how
• Should and could
• Contribution category

That means the same component contributed by two different people should have a different process. The same person contributing two different components should follow a different process. A component feature should go through a different process than adding a whole new component.

Support, not gatekeeping

Contributing to a design system is a different discipline from product work. The benefit of contribution is that you get to learn from each other and understand what’s important to each individual practice.

My experience of running multiple contributions into design systems is that contributors tend to have very different expectations of what will be required compared to the actual reality of making a contribution.

Much like on a real mountain, everyone should start on the beginner slope, and the design system team will be there to teach and instruct. This grounds contributors in what the work entails and starts to expose the inner workings and standards of the design system on a deeper level than a consumer of the system may be used to.

When you have the experience and skill to head all the way up the mountain, the design system team might end up just taking on the role of a guide, showing you the best way to navigate the route instead of teaching the fundamentals.

There isn’t a ski instructor on earth who would let someone whack on a pair of skis and head down a black run. Equally, a design system team shouldn’t let someone attempt a date picker as their first contribution.

Designers spend ages making perfect mockups that match the design system guidelines. But by the time the product gets built, some things are lost in translation. The padding for the new card is 8px, not 12px. The primary button is using the wrong color token.

Everything still works as expected, but now there’s drift between what’s in the design output and what the end user experiences.

Tools like Figma MCP and zeroheight MCP are helping us to bridge this gap. Designers keep working in the tools they’re familiar with, and the MCP passes the context onto coding agents in their language.

Some designers are even braving the codebase themselves. I’m a design engineer, so I’m happy in an IDE, but AI has opened up frontend development to people who wouldn’t have dared to try before.

But now that means there’s someone else we need to think about in our handovers: AI agents.

How do AI agents do their work?

At the end of the day, AI agents are large language models. They’re effectively guessing what a correct response is, based on a massive amount of training data.

If you’ve used an AI agent to generate code before, you’ve probably felt this. What an agent can make on its own may look correct and functionally work, but it won’t feel right, because it doesn’t know what you want.

Here is a typical scenario.

A developer on your team needs to create a new form component, so they get their agent to generate one. It looks close enough to your other form components, and it works, so it passes a quick visual review and gets merged into the codebase.

But your design system has specific rules about form fields. Every field uses a shared style for the label. There’s a subtle animation when you hover over inputs. On the surface, the form fields look the same, but under the hood, there is drift.

A few months later, your design system goes through a rebrand. You’ve updated your color primitives. Your form fields are redesigned, and the custom tokens get updated. With tokens in place, this should be easy, but what happens to the drifted components?

Disaster!

The form fields where you used the custom tokens change as expected, but the one built without context doesn’t change consistently. The token color-label-fg changes work on the label, but because the rules for the hint text are different, the styling now breaks for the hint.

Mistakes like this happen when agents don’t have the right context, and the people using them don’t take the time to cross-check the outputs with your design system.

But agents do have the time to check. The bottleneck for design review is no longer after the product is built, but during.

Design system oversight at scale

When an agent is building a component, if you tell it what rules you need it to follow, it will do that. And it needs access to those rules as it generates an answer.

For a small team like ours, it’s easy to bake the context into the code itself using comments. This means that agents can reference it in the language they’re already writing in. We can then use a tool like Storybook to bring those comments straight into documentation for the wider team to see.

For teams that work with documentation tools like zeroheight, you can have this work in the opposite direction. All of your context lives in a place that suits your team, but you make it available to agents using an MCP.

The benefit either way is ease of access for an agent. It’s the missing block in the diagram from earlier, one that will help it make components that are consistent with what’s already there. If you want to learn more, Luke has already written a great article on how to write for LLMs. 

Documentation isn’t just technical, though. Both humans and agents make inferences from what you’ve written, and if there’s a conflict with their own judgment, you’ll still end up with drift. 

The missing context is ‘why’

Over time, a human will learn and remember certain weird edge cases in your company’s design system. It’s why an engineer who’s been with the team for two years usually makes fewer mistakes than someone who’s been there for three months.

When an agent generates new work, it’s pulling from the same context a new engineer gets on their first day. Every day. 

The knowledge you would share with your teammates through Slack messages now needs to be in your documentation. 

Here’s an example. At Vouchsafe, we use two different score dials, percentage-based and segment-based. This is because some results have discrete steps (like 3 out of 5), and some have a score (like 95%). Although we use the same component, the shape changes with the type of result it needs to show.

The GOV.UK design system does this type of documentation so well. They include all the edge cases and what to do about them, and even references to previous user research.

I’ve found this side of the documentation process to be harder than the technical side. Because it’s hard to know what isn’t obvious when you’re baked into the systems.

But that’s always been part of our work: making the rules of the system clear to everyone who uses it.

The responsibility of design has shifted

The back-and-forth of handovers has always come from human error: someone forgetting a rule or making an assumption based on old knowledge. And this is nobody’s fault, systems are complex, and often change without you noticing. Until now, we needed to rely entirely on memory and communication to bridge these gaps between us.

With the right documentation, we can create agents to act as that bridge. In the same way we’d ask a search engine to help us find answers instead of digging through webpages ourselves.

The work of designers has always been about more than the visuals. We’ve thought about the invisible things too: system rules, edge cases, user needs. And now we have a way to make this visible, usable, and accessible to everyone.

Design tokens help product teams manage and use a brand at scale. They live at the core of your design system. I won’t explain why you should use design tokens, but here are a few reasons they work for you:

• They make your design system scalable.
• They speed up development.
• They create tighter design-developer collaboration.

A design token system defines which design tokens you use, which platforms you target, their relationship, and how you should create and use them at scale.

This article will focus on helping a design system team, composed of at least one designer and one developer, create its first design token system for web application UIs. Together.

We’ll go through best practices for creating, documenting, versioning, and syncing design tokens.

I’ll refer to design tokens as design decisions that follow the DTCG format. Figma variables or CSS variables are not design tokens, since design tokens are platform-agnostic.

General tips

Design tokens are a team effort

Create your design token system as a team (with at least one designer and one developer). Design tokens must be created by the same people using them. You need them to make your UIs responsive, performant, and accessible. That’s why I strongly encourage you to create them as a team, not just as designers.

You must be able to understand and explain every decision about how your design tokens are used. That includes their names, types, values, units, relationships, and how they are synced, converted, documented, and versioned.

Keep it simple

I must admit, design tokens can feel overwhelming. This is exactly why you must keep it really simple when creating the system:

• Don’t try to cover everything at once. Only create design tokens at a scale you can control. Expand later.
• Work on a single context: one brand, one theme, one platform (the most important ones for the business).
• There are lots of details to cover, so start small, build confidence, and stay motivated.
• Organize yourself so your system creates value from day one.
• The simpler your system, the faster people will adopt and trust it.

Finally, creating a design token naming convention deserves its own article. But the most important rule is this: Name your tokens, so they stay agnostic to their context of use. Names must not contain anything related to what could change, like a value or a theme.

• Example
  • Don’t: heading1-bold
  • Do: heading1
• Example
  • Don’t: color-bg-dark
  • Do: color-bg-strong

Start with the design token types that matter most

You can start with the design tokens you might already have. Project Wallace can help you identify values in your existing website.

Or you can start from scratch with the design tokens that bring the most value for your organization.

For example:

• If your product is mostly about content, text styles may be the most important tokens to define before color.
• If your organization is working on a rebrand, get in touch with the people in charge of that work, so you can focus on colors first.

More generally, start with the tokens that actually make a UI: text, color, spacing.

Without them, your UIs are not usable and definitely not as intriguing as Kazimir Malevich’s White on White painting.

Start small with what you’re sure you need. Expand when necessary. Build trust and momentum over time.

Most teams try to cover everything at once and often get lost along the way. No finger-pointing, though. It’s not easy to get started. Design tokens can feel vague and complex.

Don’t create component tokens. Limit your design token system to two layers: core and semantic. Name your semantic tokens so they describe an intention, not the value.

Text styles

Cover the basics: 6 headings, 3 body styles, and 2 caption styles. Create the minimum amount of text styles, allowing you to create both a blog post and a login page.

Name them so they make sense for your team, whatever the platform, usage context, or values.

You also don’t control the background color behind your text. That’s why you should not include color in a text style.

Colors

Use a small number of color ramps (like red, blue, green, orange, and white to black), with 10 values max in each ramp.

Your app content has different intents:

• neutral (black/white)
• information (blue)
• warning (orange)
• errors (red)
• validation/success (green)

Define 10 values for each color ramp to give you the flexibility to iterate on your color system and improve text-background combinations color contrast.

Define core and semantic tiers (remember, no component design tokens).

Use a systemic color format like OKLCH. This great article will help you get started.

Understand the different layers that make up a UI (Open Source Color System will help you set up a simple system):

• background
• foreground (text/icon)
• border
• brand colors

Work with a single theme in mind. Iterate on it until it’s “good enough”. And only then, add more themes, like dark theme or high contrast.

Spacing

Define a single dimension scale you’ll use for spacing and sizing dimension tokens.

Start with a base unit of 4px and generate 20 values from it. That’s enough to get you started.

Example spacing scale (linear): space-1: 4px, space-2: 8px, …, space-20: 80px.

Take into consideration how to make those values responsive (Utopia can help with this). Using the CSS clamp function can be helpful to make your spacing or font sizes responsive. But it might be overkill when you’re just starting out. I’d suggest you keep that aside for later.

The process matters as much as the output, if not more

Create your design decisions in the tool of your choice, whether it’s a design tool like Figma or Penpot, or directly in the browser. I’d lean toward the latter because first, I’m a huge fan of the “Hot Potato Process”, and secondly, because making decisions on the same platform as our end users is beneficial in the long run.

Document every decision you make along the way by creating Architectural Decision Records. You must be able to explain how you ended up with one naming convention over another, or why you decided to keep using hexadecimal color values instead of OKLCH. 

Also, feel comfortable sharing this changelog publicly. Transparency is key. Your job as a design system team is to iterate on the system so it brings value to its consumers. Make it easy for others to give feedback, and embrace it as much as possible.

Your design tokens must exist in a JSON file that complies with the DTCG specification. You can generate this file automatically using various tools and plugins. For instance, you could use Terrazzo to generate design tokens from your Figma variables and styles. 

The most important part is to save your design tokens in this aforementioned format and version them in a code repository. That way, your design tokens are centralized, versioned and usable by any tools or APIs your team needs.

What you need to remember

Creating a design token system is a design system effort that requires planning. Focus on the design tokens that bring the most value from day one, and iterate over time. You’ll mostly work on text styles and colors first, which is already enough to get your team started and your consumers eager to get more from you. 

Make your design tokens agnostic by saving them in JSON files that follow the DTCG specification in a git repository. Document your work along the way so you’re sure your consumers benefit from the system as much as possible. 

Do this, and I assure you, everything will be fine.

This could be because:

• Adoption has plateaued.
• Nobody is contributing.
• Every new component added feels like an argument with the past.
• Decisions that once felt sensible now make the system rigid, brittle, or frustrating to update.

This moment can feel demoralizing, hopeless, and deeply existential for design systems maintainers. Many of the teams I’ve worked with have as good as ground to a halt at this point, unable to extricate themselves from past decisions and fear of future missteps. 

The case against “just starting over”

A common response is to want to start again, rebuild from the ground up, and relaunch bigger, better, and unencumbered by the existing constraints.

This instinct is understandable. Starting afresh promises freedom: no more legacy decisions, outdated tokens, or strange component APIs that made sense three years ago but now make everyone do a big sigh.

But in most cases, a full reset creates more problems than it solves.

The biggest of these is the enormous migration burden that starting over puts on our users. 

Every new component, naming convention, or documentation update introduces cognitive and delivery overhead for the teams relying on our system to ship products. If modernization becomes synonymous with upheaval, adoption slows even further.

Worse still, a big-bang rebuild rarely replaces the old system overnight. In reality, most teams end up maintaining two systems at once: the legacy one that still powers live products, and the shiny new one that isn’t yet mature enough to fully take over. 

So rather than treating modernization like demolition, it’s usually better to think of it as a series of incremental improvements: not flipping switches, but turning dials.

Start with an audit

Before deciding what to modernize, we need to understand what’s actually broken. 

That sounds obvious, but teams often move too quickly from discomfort to solution. We feel friction, so we assume the architecture is wrong. If contributions are slowing, we assume the governance model is defunct. If teams are bypassing components, we assume that trust has been lost.

But however familiar we are with the quirks of our existing system, there are likely still gaps in our understanding. Often, proximity to our system’s weaknesses prevents us from seeing its strengths. 

What’s working well?

It’s easy to become laser-focused on the pain points and accidentally throw out the parts that still create trust, speed, and consistency. 

A design system’s most valuable assets have a tendency to become invisible once they feel normal. Things like a strong naming model, reliable accessibility standards, a trusted review ritual, or excellent usage guidance are rarely commented upon when they “just work”. But those things are part of the foundation, and it’s important that we protect them.

What definitely needs to change?

Once we’ve identified the things that don’t need to change, it’s time to evaluate what does. At this stage, it’s critical to separate discomfort from real, structural problems.

To do this, we need to dig beneath the “what” to unearth the “why”. For example:

• Is adoption slowing because the system is hard to use, or because product teams no longer understand its value?
• Are new components hard to add because the technical architecture is too rigid, or because governance is unclear?
• Are legacy decisions causing friction because they were wrong, or because the organization has changed around them?

These distinctions are an important part of the foundations for any next steps. 

What needs to be true for the renovation to succeed?

Modernizing a design system is rarely about the artifacts alone. In fact, changing components and tokens is usually the easy bit.

The harder question is: What conditions need to exist for this change to stick?

The business case

Renovating a design system requires time, money, and people – both within the design system team and across the wider organization. 

Modernization efforts need sponsorship, and that means communicating value in the language of our sponsors. 

While engineering leaders may care about maintainability and reduced duplication, design management may care about quality and consistency. Product owners may care about speed to market, while accessibility, legal, or compliance stakeholders may care about risk reduction.

A good sell is less about proclaiming “our Figma library is a mess” and more about articulating the downstream impact:

• slower delivery
• duplicated engineering effort
• inconsistent customer experiences
• accessibility regressions
• rising support overhead

Modernization succeeds when stakeholders can clearly see what they’ll get in return.

Education

Arguably the most important part of system change is behavior change. If our users don’t understand what changed, why it changed, and how to work with it, the best architectural decisions in the world won’t matter.

This often means teaching:

• new contribution models
• updated component inclusion criteria
• token usage rules
• content standards
• migration expectations
• new quality assurance thresholds

Education isn’t simply a side task, it’s a core tenet of change management. 

Process

Renovating a design system often exposes processes that were built for an earlier version of the system.

It may be that our review workflow only works for simple component additions, our contribution model has turned out to be overly complex, or – a common complaint – our release cadence is too slow for product teams.

We need to be specific about what needs to change operationally, in terms of:

• contribution intake
• prioritization
• quality assurance
• release notes
• deprecation pathways
• escalation routes

Our modernization efforts can only succeed if we have the correct processes in place to keep our system running.

Documentation

When design systems evolve incrementally, documentation becomes the bridge between old and new. It helps teams to understand:

• what’s changed and why
• what’s stayed the same
• how urgently they need to act
• where legacy usage is still acceptable
• what support exists

This is especially important during phased migration, where multiple versions may coexist for a while.

Without excellent documentation, change creates confusion, atrophy, and inconsistency. 

Support

Even good change creates friction. Our users will inevitably need help interpreting edge cases, planning migrations, and understanding whether local variations should now become standardized.

Taking the time to host office hours, set up migration clinics and dedicated Slack channels, pair on implementation, and provide hands-on consultation can make the difference between dumping in a new system and offering a dependable service.

Above all, nurture trust

Design system renovation is rarely just about modernization – it’s about restoring trust.

For systems updates to be successful, users must be able to trust that:

• The system can evolve without creating chaos.
• They’ll be supported through the transition.
• Changes are purposeful, not performative.

That means resisting the catharsis of reinvention and choosing the slower, less glamorous path of careful recalibration.

Because the healthiest design systems don’t modernize through revolutions, but through a thousand well-judged adjustments.

The newly added AI-specific documentation layer got me thinking about how each discipline creates, maintains, shares, and consumes documentation, how siloed the documentation system has been within organizations, and where design systems could potentially help connect all forms of it.

Every product organization has a documentation problem. Most know it. Almost none have fixed it.

AI has no tolerance for bad documentation

For years, the problem was tolerable. We put up with low-quality, incomplete, and perpetually out-of-date documentation because we humans are forgiving. We collaborate, fill in the gaps with experience and intuition, and still arrive at acceptable outcomes.

That forgiving quality disappears the moment an LLM enters the picture.

When AI consumes documentation, it no longer resolves ambiguity through context and conversation. Instead, it amplifies it. Hallucinations happen often. Quality drift builds up in the background. And it scales fast, across every output the tool touches: product decisions, engineering work, design direction, and customer experience.

This question keeps circling in my head:

The industry response so far (and why it isn’t enough)

The first wave of solutions has focused on format. Structured content, skills, MCP integration… the technical infrastructure that helps AI systems find and consume documentation more reliably.

This work matters. But it addresses the problem at a surface layer.

Optimizing how AI reads documentation doesn’t fix what the documentation actually contains. You can structure noise beautifully. But the real problem is upstream:

• Who decides what good documentation looks like across disciplines?
• Who is accountable for its accuracy over time?
• And what governs quality when no single team owns the whole picture?

The problem sits at the organizational layer, it’s not related to format.

Every discipline documents. No one connects the dots

The problem isn’t that organizations lack documentation. They have more of it than anyone knows what to do with.

Design, product, and engineering each produce their own: component usage rules and token rationale, product requirements and roadmap reasoning, API contracts and ADRs. Then there’s organizational documentation, such as ownership matrices, ways of working, onboarding, and institutional knowledge.

And there’s an emerging category most teams are still improvising around: AI-specific documentation, such as system prompts, agent rules, RAG knowledge bases, evaluation rubrics, and MCP server configuration.

These forms exist across every product organization, produced by different disciplines, stored in different tools, maintained at different levels of rigor, and owned by no one collectively.

Each discipline treats documentation as a byproduct of delivery rather than infrastructure in its own right. The result is a fragmented collection of artifacts maintained inconsistently, deprecating silently, and deteriorating in accuracy the moment circumstances change. There’s no shared mental model connecting them, and no systematic practice assigning quality standards across types.

What changes when AI becomes the consumer

The traditional justification for documentation was knowledge transfer: writing things down so the next person doesn’t have to ask. That logic made documentation valuable in theory and optional in practice, because the next person had social tools to fill the gaps.

An LLM doesn’t. When it encounters ambiguity, it resolves that ambiguity internally and probabilistically, not contextually. Feed it incomplete, inconsistent, or contradictory documentation, and the outputs reflect that.

Most organizations are entering AI-assisted workflows without documentation infrastructure built to serve both humans and LLMs.

What systemization would actually require

For documentation to function as infrastructure, for human and AI consumers alike, the industry needs to move from ad-hoc production to systematic practice. That’s a significant shift. Not a template rollout. Not a new Notion workspace. It requires four things:

1. A shared taxonomy: Agreeing on what types of documentation exist, what each one is responsible for, and how they relate to each other. Most organizations don’t have this. Documentation types overlap, conflict, and exist in parallel without coherent relationships between them.
2. Cross-functional ownership: Accountable owners per documentation type, with quality standards that cut across disciplines. Not one team owning all documentation, which collapses into a bottleneck, but each discipline taking genuine responsibility for its domain, against a shared framework.
3. Quality criteria: Defining what “good” looks like for each documentation type so teams can evaluate and improve it consistently. Current standards, where they exist at all, are implicit and unevenly applied.
4. A governance layer: Something that maintains standards, identifies gaps, and prevents fragmentation from returning the moment attention moves elsewhere.

None of this is technically difficult. The barrier to systemization is organizational. It requires cross-functional trust, designated ownership, and leadership appetite to treat documentation as infrastructure worth investing in, not a hygiene problem for individual teams to solve when they have capacity.

Where design systems fit into this

Design systems are arguably the only cross-functional infrastructure in most product organizations that already operate across design, engineering, and product simultaneously. They’ve always been in the business of encoding standards in a way that serves multiple consumer types. That’s, fundamentally, what they do.

Which raises a pointed question:

The distinction that matters here is precise:

✔︎ A design system as the framework and standards owner for documentation across disciplines plays an enablement role, a natural extension of what well-run design systems already do.

✘ A design system as the owner of all content within those disciplines becomes a bottleneck that collapses under its own weight.

If design systems are to play this broader role, the teams that run them need to think differently about what they’re building. Not just tokens, components, and patterns, but a standards framework with enough structural integrity to hold documentation quality across the organization — and enough clarity about its own scope to resist becoming the place where every ungoverned problem gets deposited.

The documentation problem isn’t new. What is new is the cost of leaving it unsolved, and which teams are positioned to do something about it.

A good styleguide gives your team exactly what they need to build consistent, high-quality work, without second-guessing everything. This means clarity, practical examples, and just enough rules to keep things aligned, speeds up product design, and stops debates about button padding and font weights.

In this post, I’ll break down what to include in a styleguide, what to leave out, and how to make it easier for people to actually use. 

For a quick primer on the basics, see What is a styleguide? And if you need a broader system-level view, check out What does a design system include?

Start with a short mission

Before you list a single color or component, say why this styleguide exists. A quick, human sentence about goals always beats a 10-page manifesto. Answer this question: What does this design system and branding guide help the team do? 

Keep it clear so everyone — designers, engineers, content folks, product managers — know why they should care. If the purpose is clear, people will trust the doc. If it’s fuzzy, they will ignore it. 

Core brand and visual elements

These are the obvious pieces most people mean when they ask for a brand styleguide or a visual styleguide. Include them early because they cover what your design system should look and feel like. 

• Brand identity guide: a short overview of the brand’s personality, values, and what the brand stands for.
• Logo usage guide: show primary, secondary, and locked-up versions, spacing rules, minimum sizes, plus clear “do” and “don’t” examples.
• Color palette guide: primary, secondary, neutral, and semantic colors (success, warning, error). Include color tokens (hex, RGB, tokens for dev).
• Typography guide: font stacks, sizes, line heights, and when to use each type scale. Show examples for headings, body, and captions.
• Imagery guidelines: photography style, illustration treatment, crop rules, and dos and don’ts for stock images.
• Tone of voice guide: short, actionable examples for product copy, error messages, and marketing. (Yes, include a tone of voice guide.)

Each section should outline the rule, explain its significance, and provide copy-and-paste code or tokens that designers and developers can use. These are the styleguide elements people look for first, and for good reason. They set the tone for everything else.

Practical UI and UX rules

This layer of the design system documentation sits closer to the day-to-day product work than the brand-level rules. It’s the stuff teams use daily and answers how people actually use the system to build interfaces:

• Design tokens: colors, spacing, radii, shadows, and typographic tokens that the codebase consumes.
• Component library: catalog each component (button, input, modal, card), show anatomy, props, and responsive behavior.
• Usage guidelines: when to use primary vs secondary buttons, how forms validate, modal dos and don’ts. Plus responsive guidance so components behave properly across breakpoints. 
• Interactions and motion: micro-interactions, easing, and duration rules so animations feel cohesive.
• Accessibility rules: contrast thresholds, focus states, keyboard patterns, and ARIA examples.

Make sure the documentation links components to code snippets, storybook stories, or a repo, so people can see how they work in real contexts. That keeps the design documentation practical and usable.

How to make a styleguide actually useful

This is the part that turns a styleguide from a nice-looking PDF into something people rely on:

Content patterns and writing system

Document reusable copy patterns: headings, CTAs, help text, error messages, and microcopy. Add a small checklist for editors and translators. That reduces friction between design and content and supports consistent UX across products.

Imagery, iconography, and motion

Under imagery guidelines, detail how to crop photos, where to put subjects, and how to handle diversity and inclusion in photos. For icons, include grid rules and stroke weights. For motion, define how much motion feels right and keep examples short and reusable.

Accessibility and inclusivity

Don’t make this a checkbox. Include a clear accessibility checklist and examples that teams can copy. Document keyboard flows, color contrast, focus states, screen reader behavior, and examples of inclusive language and imagery, so designers and engineers ship better experiences that work for everyone.

See Geri Reid’s excellent article on how to annotate design system components for accessibility, with examples that teams can cut and paste directly into their documentation, and Jennifer Chadwick’s 5 effective ways to build accessibility documentation into your design system.

Practical examples: show, don’t tell

People learn rules by seeing them in context. Pair each rule with a real example. Instead of “use proper spacing,” show a component with correct and incorrect spacing. Add code snippets, Figma components, and a link to the working component in your repo. Real examples convert curiosity into usable patterns.

Must-have pages to convert non-designers

If you want people to adopt the system, give them quick wins and make the styleguide useful for people outside design, too. Add pages like:

• Quick start for engineers: how to install tokens and use components
• Quick start for content: copy guidelines and reusable snippets
• FAQ: common questions and how to get help
• Changelog: what changed and why

That kind of design documentation lowers the barrier to entry and helps more people use the system without pinging a designer every five minutes. 

How to keep it maintained

A styleguide is only helpful if someone keeps it current. That’s where governance comes in. Say who owns the docs and define:

• who reviews changes
• how to propose new components or tokens
• release cadence for design tokens and docs
• where to discuss breaking changes

Make governance light and actionable. Teams will follow a simple process more than a heavyweight one.

What not to include in a styleguide

A styleguide should help people move faster. While it’s tempting to document everything in one place, resist the urge to turn your styleguide into a dumping ground for every idea, exception, and half-finished debate.

Skip anything that doesn’t help someone make a decision or ship work consistently. That usually means:

• One-off project decisions that only apply to a single launch or campaign
• Deep brand history lessons that belong in a separate brand book, not the day-to-day docs
• Overly prescriptive rules that leave no room for context, especially for content and UX
• Internal process details like meeting notes, approval chains, or Slack threads.
• Duplicate documentation that already lives in product specs, code comments, or a component library
• Visual noise such as giant moodboards, long inspirational galleries, or pages of random examples with no explanation.
• Every possible edge case. Cover the common stuff well, then link out to deeper guidance when needed.

A good test: If a page doesn’t improve design consistency or help with using the design system in real work, it probably doesn’t belong there.

Instead, keep the styleguide focused on the contents people actually need: brand guidelines, design documentation, and the elements they use every day. That keeps the document easier to scan, easier to maintain, and much more useful for the team.

Measurement and success

Decide how you’ll measure design consistency and adoption. Track component usage, time saved, and design debt reduction. Small metrics help you justify maintenance time and show ROI.

For more on this, see Maya Hampton’s fantastic piece From basic adoption to meaningful measurement: How design system metrics evolve.

Make your styleguide easy to find and use

Documentation only helps when people actually use it. Host docs where your team already visits, give clear search, and add short “how-to” pages for common tasks. 

If you want to convert more stakeholders, create a short “how to use the styleguide” page for product managers and engineers.

Ready to stop arguing about fonts?

If you want a place to publish living design documentation that connects Figma, code, and content, try zeroheight. Put “Get started with zeroheight” on your team’s roadmap, or check out styleguide templates to bootstrap your docs. 

When you want people to actually use the styleguide, make it simple, practical, and delightful.

Sign up to zeroheight for free and start documenting in minutes.

Elizabeth is self-professed as legally blind, and in my role as a digital accessibility strategist, I regularly ask for her expertise as a usability tester on website, mobile, and VR projects I consult on. Recently, I interviewed her to find out which digital designs work best for her needs, as I feel it’s important for designers to also keep people with partial vision in mind when thinking about accessibility — not just blind people who use screen readers.  

In this article, I’ll cover design best practices based on the findings from my session with Elizabeth as a low-vision user. I’ll suggest actions to take in your design system to educate your team on low-vision needs, help them understand what’s required for WCAG compliance, and avoid usability barriers. 

Introducing Elizabeth

Elizabeth assists people with disabilities at zoos, cultural centers, and museums in Toronto, Canada. She loves teaching history and holds a Leadership, Accessibility, and Inclusion designation from Toronto Metropolitan University. 

Elizabeth has been using assistive technology “pretty much” her whole adult life, ever since computers and smartphones came along. A child of the 80s, she didn’t have the internet growing up, and in the early days of the web, experienced mostly inaccessible products and services that didn’t let her adjust or personalize the user interface to see it more clearly. 

These days, however, she says that having access to tools, built-in software, and browser settings makes life a lot easier for people with low vision. 

1. Take device preferences into account

Elizabeth uses an iPhone 16+ daily, for everything: texting, shopping, commuting, banking, etc. It has a bigger screen, almost like a tablet. 

She uses iOS’s built-in magnification feature to increase the size of the entire screen on her iPhone and MacBook (Full Zoom) or just part of it (Window Zoom) on her work computer, when browsing the web or using native apps.  

Elizabeth increases the font display between 140% and 200%, depending on what she’s looking at. She also pinches and zooms with her fingers to enlarge images and icons when using apps or the web on her iPhone.

“I wish more website and app developers would ensure that pinch and zoom operates properly,” Elizabeth said. “And for magnification settings, it only takes a minute to switch on these accessibility features in iOS or Android and test them when designing or coding a screen.” 

Her personal computer is a MacBook Pro, on which she uses the built-in zoom magnifier, and for work, she uses a Windows laptop with Microsoft’s magnification version. Most of the time, though, she hooks up to a large monitor.  

On the keyboard, Elizabeth uses the plus and minus keys (+ and -) to increase browser zoom up to 200%. With a mouse, she makes the cursor (pointer) larger and changes its color from white to yellow for better visibility.  

Occasionally, Elizabeth might also take a quick picture of something with her camera phone to zoom in and read text or view images later. 

Actions to take in your design system: 

• Guide teams to view a component in zeroheight at 150%, 200%, and 400% browser zoom. What does it look like? If the component includes text, does this increase at the same time? Does the component design break at larger screen sizes?
• Reference Windows’ mouse pointer settings. Encourage your team to check them out!

2. Consider font preferences

Elizabeth wants teams to know the distinction between font size and font resizing. Some designers forget that users may have their built-in accessibility font display settings at large or extra-large all the time on iOS and Android.   

All web browsers and apps that are coded properly to adopt font resizing will display it. Elizabeth recommends turning on this setting in mobile and on a tablet, increasing the font size display (large, extra large, etc.), and paying attention to how your design and layout flows to accommodate larger text sizes.  

For font types, Elizabeth likes Arial and Calibri — two sans-serif fonts that are popular with many low-vision users.

For a default font size on a web page or screen, Elizabeth prefers 14 to 16 points, though she can read a 12-point font and will increase the size if needed. Still, she says, it’s always good to be inclusive.

Actions to take in your design system:

• Include WCAG requirements for text size and reflow in your documentation:
  • 1.4.4 Resize Text (A)
  • 1.4.12 Text Spacing (AA)
  • 1.4.10 Reflow (A)
• Reference these iOS and Android features in your documentation:
  • iOS Zoom
  • iOS Display & Text Size
  • Android Magnification
  • Android text & display settings
• Include a minimum font size in your designs, e.g. 12 pt.
• Reference WebAIM’s research into typefaces and readability.

3. Light or dark mode?

Elizabeth prefers dark text on a light background on computers, mobile devices, and e-reader screens. For her, bright fonts (yellow, white) against a dark background irritate her eyes. 

However, she knows that other low-vision users sometimes prefer a dark-mode background (deep blue, gray, black) to make lighter fonts more distinguishable. Color inversion is a popular setting on Mac and Windows.

Actions to take in your design system:

• Draw guidance from this Smashing Magazine article on designing inclusive dark mode and themes. Recognize how dark mode may lessen fatigue and improve visual focus for some users. 
• Don’t make text too bright against the background color you choose. Softer tones with sufficient contrast can reduce long-term eye strain.
• Reference this study on 5 myths about dark mode — and the realities.
• Reference these iOS and Android features in your documentation:
  • iOS Dark Mode
  • iOS Invert Colors
  • Android Color Inversion
  • Android Dark Theme (11.0 and up)
• Invite low-vision users to provide feedback on your designs.

4. Understand how a low-vision user might navigate 

When Elizabeth lands on a web page, she looks at the top first, where she expects to find the navigation menu. Her eyes then move to the left-hand side of the page, scanning and taking in the content. “Center-aligned headings or body text mean I have to move my magnifier around to find them,” she said. “Left-aligned content works best.”

Elizabeth also checks the footer for menu links and items, specifically the contact options. “It’s a way to understand the organization’s information and priorities — for example, do they have an accessibility statement?” 

Actions to take in your design system:

• Include full-page templates and patterns, not just individual components. How do the header, footer, menus, and main body all work together as an experience?  
• Use plain language for links and text content. Ensure the purpose of icons and buttons is clear. Is there sufficient contrast for menus and calls-to-action?

5. Designing images

Elizabeth “absolutely hates” websites that are “cheaply” designed with text overlaid over images. “It’s so hard to read the text when it’s sitting on top of an image with background colors or patterns that have varying contrast levels.” 

To her, this is an immediate indication that the company is not employing WCAG standards.

Ideally, Elizabeth won’t have to zoom much more than 140% to read text. Text should be clean and clear against a solid background.

Actions to take in your design system:

• Avoid banner images with overlaid text, unless absolutely necessary.
• If you must overlay text, check that background color and text have been tested for contrast in all viewports (i.e., reflowing from desktop to tablet to mobile). 
• Don’t embed text in banner images. Low-vision users especially need image sizes to increase, and sometimes embedded text gets blurry and pixelated at larger sizes. 

6. Designing links, buttons, and controls

Elizabeth relies on strong color contrast and common button and link styles to ensure interactive elements stand out on a screen. Otherwise, she wastes time slowly scrolling through a page at 140% zoom, guessing which items are selectable.  

The same applies to light or dark mode designs. Text and interactive elements should be clearly distinguishable.

• Ensure color contrast is sufficient for low-vision users to see and operate. That’s a minimum of 4.5:1 for regular text, and 3:1 for larger text (headings), buttons, and interface object labels.
• If you design for dark mode, ensure the contrast ratio between text and user interface objects is sufficient too, but not so stark that it will cause eye strain.
• Use visible labels for buttons and descriptive link text.
• Ensure the text size increases when zoomed in a browser, or when magnification settings are applied.
• Provide a hover style for links — clean underline and color change is best, for example. Make it really easy to distinguish links from other text. 

Actions to take in your design system:

• Guide designers to provide an underline style for links, ideally in the active state, with a clear hover change — the most widely understood and distinguishable way to convey that it’s link text. (Another strong indicator is a solid background behind the link.) 
• Include WCAG contrast requirements for text and user interface objects in your documentation:
  • 1.4.3 Contrast (Minimum) (AA)
  • 1.4.5 Images of Text (A)
  • 1.4.6 Text Contrast (Enhanced) (AAA)
  • 1.4.9 Images of Text (No Exception) (AAA)
  • 1.4.11 Non-Text Contrast (AA)
• Include easy-to-follow accessibility do’s and don’ts examples. 

7. Designing to avoid cognitive overload

For her work in museum studies and event planning, Elizabeth gathers information from researchers via emails and documents. To read them, she uses the magnification tools, zooming in and adjusting font sizes. 

Elizabeth herself advises organizations on how content in museums is consumed by people with disabilities. Information is usually on a text panel attached to a wall or in a paper map, which aren’t adjustable.   

Digital map kiosks with a large screen and a few interactive buttons can be helpful, but they often have a lot going on, content is overwhelming, and on top of that, the bright screen sometimes can’t be adjusted. 

The bottom line: Simpler is always better for text, images, and button choices. Keep your visual layout and your language clear and plain. “If designers try to do too much and offer too many choices, it causes clutter on a website or an app,” Elizabeth said.  

She’ll put up with it, but it’s a major turn-off, and as a low-vision user, she may never use that site or service again. 

Actions to take in your design system:

• Guide content designers to simplify language, use fewer words, and organize content under headings and in sections.
• Encourage user experience and content designers to work together to create uncluttered interfaces.  
• Incorporate these guidelines into documentation aimed at HR, marketing, product designers, and UX designers. All channels of communication should have plain language, clear instructions, and an uncluttered view.  
• Include W3C best practices for inclusive writing into your documentation:
  • W3C Tips for Writing
• Reference accessible reading tools like ReadAble, a browser extension to customize text, colors, line height, and OpenDyslexia fonts. 

8. Designing dropdown menus

Elizabeth’s pet peeve is dropdown menus so sensitive to a mouse hovering over them, without much surface area (too long and thin), that they collapse easily and don’t stay open.

Large, wide dropdowns (sometimes known as mega menus) are preferred by people with limited mobility, tremors, and shakes. Keeping the mouse on one spot to hold a finicky menu open helps no one. 

For low vision, a large, page-wide dropdown menu is also easier to see when zoomed to 200%. It’s a better experience for all. 

Actions to take in your design system:

• Guide designers not to build long, narrow, column-like menus that collapse suddenly when the mouse rolls away. If needed, provide width restrictions in the specs. 
• For the same reason, mega menus need to be wide enough on hover, but not unnecessarily long — i.e., they mustn’t cover the entire page or screen and confuse low-vision users (is this still the menu, or part of the page?). 
• Reference this menu design checklist with 17 UX guidelines from Nielsen Norman Group that covers this and other accessibility tips. 

9. Designing notification pop-ups

It does irritate Elizabeth when she’s shopping on a website and a notification pops up briefly to indicate the item has been added to the shopping cart. 

Sometimes the notification (also known as a toast message) appears on the side or bottom of the screen, and Elizabeth doesn’t see it immediately or at all because she is zoomed into another part of the screen instead. 

Elizabeth doesn’t oppose this notification style, but as a low-vision user, she needs another indication. An icon on the shopping cart showing the item count, for example, is more permanent, along with a notification that pops up for a few seconds.

Actions to take in your design system:

• Test the notification placement at 200% zoom. Does it disappear out of view?  Does the location of the pop-up adjust accordingly?
• Guide designers to:
  • increase the display time for the notification, so low-vision users can notice it (consider a minimum of seven seconds). 
  • place a toast message or pop-up notification close to the call-to-action that triggered it instead of hiding it at the bottom of the screen. 
  • include a permanent notification, like an icon on the shopping cart that shows the number of items that have been added.
• Reference Sheri Byrne-Haber’s article on designing toast messages for accessibility. 
• Include WCAG requirements for content reflow in your documentation. It states that there should be no loss of content functionality, and to avoid  horizontal scrolling, when screen size is increased up to 400%, and this includes notification pop-ups:
  • 1.4.10 Reflow (A)

A best practice example: eBay

Elizabeth is a big collector of model horses. She researches listings on the eBay mobile app to see what people are selling, and at what price. Even though the app shows a lot of content all at once — text, images, buttons — there are separator lines and clear headings between content sections to make it easier to scan. She calls it a “seamless” experience.

Tips for designing software

Designers should think beyond web, mobile, and e-reader experiences to text-heavy documents (PDFs) and programs like Excel and PowerPoint, or Google Docs and Slides, which also need to work well with screen magnification. 

Elizabeth regularly exports PDFs to Word and back again for work, and she finds Adobe’s workflow not ideal for low-vision users — something software designers should keep in mind. 

Left-aligned text makes it easier for low-vision users to scan a document. Otherwise, Elizabeth has to depend on her manager to assist her with the final check over of the content. 

In PDF editors like Adobe Acrobat or graphics and design editors like Photoshop, InDesign, and Figma, there are toolbars on the left, right, and bottom. Elizabeth uses her screen magnifier to zoom in and find them. But she prefers consistent navigation bars and menus, items that draw the eye, at least one at the top of the screen.  

Designing more accessible experiences for low-vision users — and everyone

Implement these best practices, and never make assumptions about users and the technology they use. The best thing a designer can do is walk through exactly what Elizabeth does every day and understand her low-vision needs. 

Once you’re familiar with zoom, magnification, text sizes, and color choices, you’re well-equipped to improve the user experience and usability of the digital products and services you work on. 

Remember to design for people with some visual impairments, permanent or temporary, not just for blindness. Inclusive choices help everyone. 

Resources

• Designing for people with low vision — Ian Lloyd
• Location, location, location: Tweaking modern UX for users with low vision — Corbb O’Connor and Christina Adams
• Seeing blind: YouTube series about being a low-vision mom — Cindy Schaffner
• Stories of web users: Elias, retiree with low vision, hand tremors, and mild short-term memory loss — W3C

Every design system I’ve audited has the same problem hiding underneath the surface. It’s not broken components or ugly tokens. It’s that nobody knows the full picture.

Designers know what they designed. Engineers know what they built. But nobody knows whether those two things match. And the longer a system runs without that visibility, the wider the gap gets.

In my previous articles, I described the destination: radically adaptive, AI-generated interfaces built from complete design systems. And I described the check engine light: the persistent dysfunction in enterprise design systems that everyone can feel but nobody fixes. The root cause is always communication. Not just human communication. Structural communication. The kind that’s supposed to be encoded in the system itself.

The question is: How do you fix structural communication without just adding more meetings, more documentation, more process?

You build a diagnostic layer.

What a diagnostic layer actually is

Think of it like the OBD system in your car. The check engine light tells you something is wrong. The diagnostic port tells you exactly what. Without it, you’re guessing. With it, you can pinpoint the problem, assess severity, and decide what to fix first.

In a design system, the diagnostic layer sits between your design platform and your codebase. It watches for drift. It validates that what was designed matches what was built. It surfaces gaps in real time: missing tokens, undocumented components, properties that exist in code but not in design, or vice versa.

This isn’t a new concept in software engineering. We’ve had linters, type checkers, and CI pipelines for decades. But design systems have historically lacked equivalent tooling. The gap between design and production code has been a manual, trust-based handoff. And trust, as anyone who’s worked on an enterprise design system can tell you, does not scale.

The two directions nobody talks about

Design systems have a communication problem, but it’s not the kind that gets fixed by talking more. It’s structural. There are two distinct channels that need to work, and most teams only have one of them partially functional.

• Design to code. This is the direction most teams focus on. A designer creates a component. A developer looks at it, interprets the intent, and builds something. The problem is that “interprets” is doing enormous heavy lifting. Even with dev mode, design tokens, and detailed specs, the developer is making judgment calls about behavior, states, edge cases, and interaction patterns that may or may not match what the designer intended.
• Code to design. This is the direction almost nobody has. Once a component is built, does the design system know? If an engineer changes a prop, adds a variant, or fixes a bug that alters behavior, does that information flow back to the design file? In almost every organization I’ve worked with, the answer is no. The design file becomes a snapshot of intent, frozen in time, while the code evolves underneath it. Over time, the gap widens until the “source of truth” is neither a source nor true.

A real diagnostic layer handles both directions. It doesn’t just push design decisions into code. It validates that code matches design, flags deviations, and creates a continuous feedback loop that keeps both sides honest.

Where the source of truth really lives

This brings up a question I hear constantly: Where should the source of truth live? Designers say it’s their design tool. Developers say it’s code. Both camps defend their position passionately. Both are incomplete.

Here’s what I’ve come to believe after years of working inside this problem: We talk about “the source of truth” like it’s a fixed address. It’s not. It never was. Design starts as the seed, but systems grow, teams shift, and decisions get made wherever the work is happening. On most teams, developers outnumber designers significantly, so over time, code accumulates decisions that design never signed off on. 

The gap opens quietly and stays open because most tooling only moves information in one direction. The diagnostic layer changes that equation. It makes it possible to close the gap from either side. If code got ahead, pull those decisions back into design. If design evolved, push it forward into code. The point isn’t to declare a winner. It’s to keep both sides honest.

But if I’m being honest about where I think this is heading, the source of truth is migrating to a layer that sits between design and code. A layer owned by neither discipline exclusively. Readable by both humans and machines.

That layer has two parts.

• Design tokens define the aesthetic canon. Color palettes, typography scales, spacing systems. The visual identity of your brand encoded as structured, portable values. These don’t belong to any tool. They belong to the system.
• Component contracts define behavior and intent. Structured specifications, typically in JSON or a similar format, that describe what a component does, what properties it accepts, what states it supports, what accessibility requirements it must meet, and how it should respond to interaction. These aren’t code. They’re a description of what code should produce.

Marry tokens and contracts together, and you have a canonical representation of your design system that is tool-agnostic, framework-agnostic, and equally useful to a designer, a developer, or an AI agent generating a layout. That’s the real diagnostic layer. Not just a set of tools, but a shared language that both sides of the workflow can validate against.

Making it real

This isn’t theoretical. We’ve been building approaches that make this diagnostic layer tangible.

We run audits on design files that check for AI readiness and structural integrity: detached components, missing auto-layout, inconsistent token usage, absent metadata. These aren’t cosmetic issues. They’re the upstream problems that cascade into bad downstream output, whether that output is generated by a human developer or an AI agent.

We use structured protocols that give AI assistants full access to a design system’s token architecture, component specs, variables, and metadata. Not screenshots. Not flattened images. The actual structured data that defines what a component is and what it means.

We generate documentation that compares design components against their coded counterparts, surfaces mismatches, and produces structured contracts: reconciled representations of what a component should be, derived from both the design and the code.

None of these approaches replaces human judgment. They augment it. They make the invisible visible. They turn “I think something’s wrong” into “here’s exactly what’s wrong, here’s where it is, and here’s what it should be.”

The moment it clicks

I’ll share one example that captures the shift.

We worked with a team where designers and developers were operating in completely separate universes. The designer owned the brand: tokens, type, color, visual intent. The developers were building components without understanding that intent. Some of them didn’t believe design was necessary at all. They’d vibe-code their way through interfaces and ship whatever felt right.

The designer felt sidelined. Her work wasn’t being honored. It wasn’t being reflected in what shipped. And the harder she pushed, the more the developers dismissed the value of what she was contributing.

Once we introduced a systematic approach, tokens mapped to components, contracts describing behavior, diagnostics catching drift, something shifted. The developers realized that design wasn’t arbitrary. It was a system with rules and logic, just like code. And the designer, for the first time, felt respected. Her decisions were being enforced through structure, not ignored through shortcuts.

That’s the diagnostic layer working. Not as a policing mechanism, but as a translator. It converts intent into structure, structure into validation, and validation into trust.

Why the diagnostic layer matters beyond maintenance

The diagnostic layer isn’t just about catching bugs and preventing drift. It’s the prerequisite for everything discussed in part 1 of this series.

If you want AI to generate components that match your brand, it needs a clean, structured, validated design system to work from. If you want to support multiple platforms from a single source, that source needs to be portable. If you want non-developers to prototype with real components, those components need to be well-defined enough for an AI to assemble them correctly.

Every “future of design systems” conversation I have eventually arrives at the same point: Your system has to actually work first. Not “mostly work.” Not “work if you know which file to look at.” Actually work. Consistently. Across platforms. With clear ownership, clear structure, and clear communication between design and code.

The diagnostic layer is how you get there. It’s not the part that gets demoed on stage. But it’s the part that makes everything else possible.

Once your design system is truly complete, truly in sync, truly readable by both humans and machines, you unlock a fundamentally different kind of product. One where the interface is no longer static. No longer pre-designed. No longer the same for every user. The products we build next will be adaptive, ephemeral, and personalized. And they’ll be built on the back of design systems that were good enough to support them.

The only question is whether yours will be one of them.

TJ Pitre is speaking at zeroheight’s design systems conference, Converge, in Newcastle on October 22, 2026. Check out the rest of the line-up so far and get your tickets.

The results were analyzed and packaged up into our recently released The State of AI in Design Systems report. Here are some of the headline outcomes.

AI is now the default, but what about AI paying off?

82% of design system teams are using AI in some form. 32% say it is now part of their workflow, not just something they are trialing. In the four months since the release of the Design Systems Report 2026, AI usage has jumped from 50% to 82%. But adoption and value are not the same thing.

11% of teams have still not found a good use case for AI in their design systems work. And in most cases (particularly Enterprise companies) the tools teams are reaching for most — Claude, Figma Make, ChatGPT, GitHub Copilot are rarely chosen because they are the best fit. They are chosen because a license already exists and it makes them easily accessible. 

The floor is moving fast. That doesn’t mean everyone has worked out what to build on it.

The satisfaction gap tells a different story than the hype

We asked teams to name the AI use cases they are most and least satisfied with, and the results could not be clearer.

Documentation sits at the top. 63% of teams rate it as their most satisfying AI use case. Design generation sits at the bottom — 67% rate it as their least satisfying. The net satisfaction swing between those two is 97 points.

That matters because design generation is the use case that gets the keynote slot. It is the thing leadership asks for in demos. And it is the worst-performing use case in the entire dataset.

Meanwhile, documentation, auditing, code generation, linting — the unglamorous, perennially under-resourced work — is where AI is actually delivering. Teams that have leaned into these use cases are seeing real compounding returns. One respondent described documentation going from half a day per component to under an hour. And the savings keep adding up because everyone downstream benefits too.

AI is best at the work design systems teams have historically been worst at resourcing. That is both the opportunity and the trap.

The bottleneck was always documentation

Here is the catch. Documentation is where AI pays back most reliably. It is also the foundation for almost everything else AI can do for a design system; code generation, MCP, design-to-code, compliance checking. All of it sits on top of whatever your documentation looks like.

Only 17% of teams describe their documentation as very AI-ready. 35% call it inconsistent. 20% say it is not organized.

The people answering that question are mostly the people responsible for the documentation. This is not a stakeholder complaint. It is the design systems team itself saying: we know our docs are not ready for what we are trying to do.

As one respondent put it: “AI will compound good or compound bad.” 

Shadow AI is already a production problem

When a design system is not legible to AI, something fills the gap.

59% of teams report UI that bypasses the design system entirely. 50% say other parts of their organization are using AI in ways that are creating problems for them. And 44% say their organization just tolerates it.

AI tools that do not know your design system exists will default to Tailwind, Radix, or whatever is generic. The output looks like your system. It is not. And it is already shipping.

The teams most exposed are the ones whose documentation cannot be consumed by AI, because if the system is not legible, it gets routed around. That is not a future risk. It is already the reality for more than half of the teams in this data.

The blocker is time, not budget

25% of teams cite no time as their top barrier to AI adoption. Only 5% cite budget. At companies over 1,000 people, the time figure climbs to 33%.

This is not a story about skeptical leadership or missing resources. Half of teams already have a leadership mandate to use AI. 56% say the design systems team itself is the one driving adoption. The support is there.

What is not there is the hours. And without protected time to explore, none of the other moves are possible.

The pragmatist’s stance

63% of design system practitioners feel favorable about AI. 67% also think it is overhyped. Most teams hold both at once.

That is not a contradiction. It is the right posture for this moment in time, optimistic about what AI can do, clear-eyed about where it is actually delivering. The teams doing the most credible work are not the evangelists or the sceptics. They are the ones who have worked out which use cases compound and which ones just look good in a demo.

The through-line in this report is straightforward: the teams winning with AI are the ones who made their design systems legible to it. Documentation. MCP. Partnership. Policy. Time. In that order.

Your design system is either becoming AI’s source of truth or it is becoming the thing AI gets to go around. The data is fairly clear that there is no stable middle path.

This is just a sample of the findings, read the full report for a deeper look at the data, the failure modes of shadow AI, and eight practical moves the data says will pay back. Or watch our ‘The State of AI in Design Systems: What the data actually says‘ webinar on-demand to hear the findings walked through in full.

For a long time, building a design system was largely manual work. But AI tools have changed this status quo. AI tools, when integrated effectively into design system workflows, become co-pilots that act as smart documentation assistants, design moderators, and system enforcers.

In this article, I want to share five practical AI-powered workflows you can follow to streamline your organization’s design system process.

Workflow 1: Auto-generate specs for UI components 

A popular joke says that a documentation specification becomes outdated the moment it’s sent to the team. That happens because things move fast in the design world. Every time you update Figma components or styles, the docs can fall behind. And when the product team relies on stale design specs, it leads to inconsistent design. 

Fortunately, there is a solution to this problem. Use a Figma file with components and tokens as the source of truth that you feed to the AI to turn it into structured specs.

It’s fairly easy to establish the workflow of spec auto-generation. All you need to do is set up the Figma MCP server (by the way, all workflows listed in this article use MCP technology), share a link to the relevant component with an AI tool like Claude or Cursor, and ask it to generate the spec. The prompt format will be: “Generate a component specification using this information: [link to the Figma section with a component].”

Here is how to do it in Claude Code:

To make the process of spec generation more focused, you can tell the AI to account for constraints such as:

• Component states (default, hover, disabled)
• Component variants
• Interaction rules
• Do/Don’t usage

You don’t need to provide all these details directly in the prompt. Instead, it’s better to store them in a separate Markdown file and feed it to AI alongside the prompt. 

Don’t expect to get the perfect result on the first try. Use the AI-generated spec as a first draft and refine it to ensure it’s production-ready.

Workflow 2: Auto-generate usage guidelines for components (with specific dos and don’ts relevant to your org)

This is a more advanced variant of the previous workflow, and it solves a slightly different problem. Manually written usage guidelines are hard to scale; they might miss essential details about component behavior or, even worse, be overly subjective. 

When this happens, either a component is not used effectively or, worse, an incorrect component is used for a specific task. It’s possible to leverage AI to analyze component purpose, combine this analysis with common UX patterns, and generate practical usage rules.

The process of spec generation is similar to the previous workflow, but the prompt will be different: “Generate do/don’t usage guidelines for this component [link to component in Figma] based on design system rules and UX best practices.”

Once the AI tool generates the output, you need to validate it and align it with the product context.

Workflow 3: Accessibility validation as a continuous check

Accessibility validation is a mandatory step in the product design process. When this check is manual, there is always a risk that accessibility will be evaluated too late, leaving the team without enough time to fix defects. Worse, teams can overlook critical issues altogether. You can use AI to analyze ready-to-ship components for accessibility compliance (e.g., WCAG 2.2) and suggest fixes proactively.

You need to provide a link to the Figma selection and prompt AI: “Evaluate accessibility issues and suggest improvements for this component [link to component in Figma] using WCAG 2.2.”

Depending on the nature of your component, you can also mention essential constraints in the prompt for AI to validate, such as contrast issues, touch target sizing, semantic recommendations, etc.

Below you can see an accessibility compliance report generated by Claude for a web page:

Note that automated checks can’t catch all accessibility issues in a design system. Read Eric Bailey’s excellent article on the types of things they can’t detect when auditing and evaluating your design systems for accessibility.

Workflow 4: AI-powered documentation sync (design ↔ docs)

Manually written documentation is often disconnected from the actual implementation. Designers and developers who are responsible for implementing designs often have to adapt components and styles to real-world use cases. As a result, when the product team changes components, they need to update both the design in Figma and the documentation. Because it’s a manual step, it’s easy to forget or skip it.

Documentation sync is a perfect candidate for AI automation. It’s possible, for example, to use AI to detect changes in Figma, match those changes to the documentation, and regenerate the affected pages. AI can update specs, refresh guidelines, and provide a summary of changes for reference.

Workflow 5: Governance assistant (design system QA)

Documentation sync, which we discussed in the previous workflow, is just one example of design system governance. Another is quality assurance of design system components. Most organizations want to automate QA activities to streamline the product design process and minimize the risk of functional UI defects. This automation should also be applied to design system QA, because defects often stem from misusing components, breaking system rules, and introducing design inconsistencies.

AI can act as a design system reviewer. You can define foundational rules for the design system and provide them as input to AI. Even better, you can create a dedicated skill in tools like Claude Code to validate the system. After that, you can prompt AI: “Validate this UI against design system rules,” and it will return a list of violations, suggestions, and missing components in the current version of the design system. 

The payoff of bringing AI into design system workflows

The five workflows shared in this article are not about replacing designers with AI; they’re about augmenting teams with a layer of intelligence that keeps documentation in sync with reality, enforces consistency without slowing people down, surfaces issues like accessibility gaps before they reach production, and ultimately reduces governance overhead while improving quality. 

By introducing AI into your design system workflows, you move from static documentation to dynamic systems, from one-time reviews to continuous validation, and from subjective decisions to structured, repeatable processes.

The result is a design system that behaves like a well-maintained product: one that evolves reliably, scales across teams, and stays aligned with both design and code.

There’s a moment in every car owner’s life where they look at the check engine light and decide to keep driving. The car runs fine. Nothing feels wrong. Maybe the gas cap is loose. Whatever it is, it can wait.

I’ve spent years watching enterprise organizations do the exact same thing with their design systems.

They know something’s off. Designers are frustrated. Engineers are building things that don’t match what was designed. Handoffs take weeks instead of days. Components drift. Token values get hardcoded. Documentation goes stale. Everyone can feel the friction, but the product still ships, revenue still comes in, and nobody wants to be the person who says, “We need to stop everything and fix the foundation.”

So the light stays on. And the car keeps driving.

This is part 2 of a three-part series on design systems and what comes next. Part 1 covers the product your design system is actually building, and part 3 explores the diagnostic layer. 

The pattern

I run a design systems consultancy. We work with large organizations, many of them household names, helping them build, fix, and evolve their design systems. Over the past year, we’ve seen a dramatic uptick in inbound from enterprise teams, and the conversations almost always start the same way.

“We have a design system, but…”

But designers don’t trust it. But engineers don’t use it. But it only works for one platform. But nobody knows who owns it. But it’s actually just a collection of CMS-specific components that someone relabeled as a design system three years ago.

The symptoms vary. The root cause doesn’t.

It’s communication. Every single time.

Not “we need more Slack channels” communication. Structural communication. The kind that’s supposed to be encoded in the system itself: shared tokens, shared components, shared documentation, shared understanding of what a component means, how it behaves, and when it should be used.

When that communication breaks down, everything downstream breaks with it.

What it actually looks like

At one large enterprise we worked with, product designers and product engineers had essentially zero structural communication about the design system. Designers were building components in Figma, carefully structuring variants, naming tokens, documenting usage patterns. They were doing their jobs well.

But engineers were deploying something entirely different. Inline styles. Hardcoded values. Workarounds using whatever props were convenient, not what was intended. The components that users actually interacted with bore little resemblance to what had been designed.

The worst part? The designers had no visibility into what shipped. They’d open the product and see something they didn’t recognize. Months of careful design work, rendered invisible. Not because anyone was malicious, but because the system had no mechanism for keeping design and code in sync. No feedback loop. No diagnostic layer. Just two teams working in parallel, producing divergent results.

Layer a round of layoffs on top of that, and you can imagine the morale. Designers asking themselves: Does any of this even matter?

At another organization, a large enterprise with a globally distributed team, the design team of about 10 people had built a thorough component library in Figma with proper token architecture. The development team, over 50 engineers located overseas, was responsible for building what was designed. But instead of leveraging the Figma files or any design-to-code automation, the developers were exporting images of the components and color-picking values from the screenshots. 

The colors were close but not right. Every value was hardcoded. The hues were slightly off across the board. It was major drift, visible to anyone who looked, but nobody stopped it. Revenue-driven deadlines, time zone gaps, language barriers, and a general sense that “close enough” was good enough to ship. It wasn’t malicious. It was path-of-least-resistance engineering with no shared system connecting the work.

That’s the check engine light. Not a catastrophic failure. Not a system that’s completely broken. Just a steady, quiet divergence between what was designed and what was built, compounding with every sprint, demoralizing the people who care most about getting it right.

PJ Onori recently used the same analogy about the check engine light. Check out his article, The design system paradox: How abstraction can hollow out quality. 

Why nobody fixes it

The honest answer is that fixing a broken design system looks expensive and feels invisible. There’s no feature to ship. There’s no revenue impact you can point to on a quarterly call. It’s infrastructure work, and infrastructure work is always the first thing to get deprioritized when there are “real” features to build.

But the cost compounds. Every sprint where designers build something that engineers reinterpret is wasted effort. Every component that drifts from its spec creates debt. Every week spent routing a trivial change through governance is a week not spent building something that matters.

And here’s what’s changed: The cost of ignoring it just went up dramatically.

The real reason this matters now

A broken design system used to be a productivity problem. Slower sprints, frustrated teams, inconsistent UIs. Painful, but survivable.

Today, a broken design system is a strategic liability.

AI agents, code generators, and LLM-powered development tools are now consuming design systems as context. When a developer uses an AI assistant to generate a component, the quality of that output depends entirely on the quality of the design system it’s reading. If your tokens are inconsistent, the AI generates inconsistent UI. If your component metadata is missing, the AI guesses. If your documentation is stale, the AI builds against outdated specs.

A human developer can compensate for a messy design system. They ask a colleague. They read the code. They use judgment. An AI can’t. It takes what you give it and runs with it.

Design systems are crossing the same threshold that responsive design crossed a decade ago. Remember when “mobile-friendly” was a feature? Now it’s invisible. It’s table stakes. Nobody lists it on a product page because not having it isn’t an option.

Design systems are heading to the same place. In two years, asking “Do you have a design system?” will sound as quaint as asking “Is your site mobile-friendly?” It won’t be a differentiator. It’ll be the minimum cost of entry. Because without one, you can’t participate in what’s coming next: AI-generated interfaces, adaptive experiences, products that respond to individual users in real time.

The check engine light isn’t a suggestion. It’s a warning. And the road ahead requires a car that actually works.

Next time: The diagnostic layer.

TJ Pitre is speaking at zeroheight’s design systems conference, Converge, in Newcastle on October 22, 2026. Check out the rest of the line-up so far and get your tickets.

The package: the “what”

Install your design system package into the repo you’re working in. This sounds obvious, but a surprising number of teams skip it and then wonder why the AI keeps inventing things.

With the package in node_modules, the AI can read your real types, your actual props, and the tokens you’ve actually shipped. It can import { Button } from '@your-org/ds' and know it exists. It can pull --space-md and know that resolves to 8px on web or 16dp on native.

This is the only way you get platform-correct output. Working on iOS? It needs the iOS tokens. Working on web? It needs the CSS variables. The package is how the AI gets these right.

The MCP: the “why” and “when”

The package tells the AI what exists, but it doesn’t tell it when to use a Card vs a Panel, why your spacing scale jumps from 16 to 24, or what your composition rules are for stacking components together.

That’s what a documentation MCP is for. For example, connect zeroheight’s MCP and the AI can pull your usage guidance, your do/don’t examples, your UX patterns, and your accessibility notes, as well as whatever else is in there. With this layer, it has a better chance of actually using your design system as you intended, rather than creating more prototypes or proof-of-concepts that drift.

A useful way to think about it: the package is the vocabulary, the MCP is the grammar. Vocabulary is useful, but you need both to write coherent sentences.

Skills: the workflow layer

On top of both, skills (or rules, or instruction files, depending on your tool) encode workflows. “When building a form, check the form patterns in the MCP first.” “Never use raw hex codes; always pull from the tokens package.” “If a component you need doesn’t exist, flag it rather than invent it.” Skills are where you bake in the team’s way of working; the stuff that’s obvious to you and invisible to a generic AI.

Tool by tool: How you encode skills

Repo-native tools

Claude Code. Native MCP and skills (SKILL.md, project or global). Reads your installed package directly from node_modules, as long as it’s included in the project you’re working in. To avoid long skills files, you can also create smaller reference files (in /references) that work with edge cases.

Cursor. MCP via .cursor/mcp.json, rules via .cursor/rules/, and skills via .cursor/skills/ (rolled out in 2026). Strong codebase indexing picks up your installed package well, especially if you’re working directly in your design system project, or a project that has the design system added via a package.

GitHub Copilot (in VSCode). Agent mode supports MCP. Repo-level guidance via .github/copilot-instructions.md, path-specific via .github/instructions/, plus Agent Skills. Best fit if you’re already deep in GitHub workflows.

Sandbox tools

Figma Make. Used to be the weak link. Now Make Kits let you bring your production React design system in as a package (public npm or Figma’s private registry) with guidelines you write to teach Make how to use it. Also supports verified-partner and custom MCP connectors (including zeroheight). Requires React 18+ and a Vite-compatible build.

Lovable. Connect a project as a Design System (Enterprise) so other projects in the workspace inherit it. Supports public and private npm packages. Prebuilt personal connectors for tools like Atlassian and Linear on all plans; custom MCP on Business and Enterprise.

v0. Defaults to shadcn/ui — that’s the path of least resistance. For your own system, publish a shadcn-style registry (Vercel’s registry-starter is the canonical template). Each component gets an “Open in v0” deep link with the right context attached.

Repo-native tools (the first four) let you give the AI both the package and the MCP directly. Sandbox tools are catching up fast — Make Kits and Lovable Design Systems specifically address bringing your real package in — but each has its own conventions you need to follow.

The setup, in order

1. Install your design system package in the project you’re working in.
2. Connect your documentation MCP (zeroheight’s, or whatever yours is).
3. Add skills, rules, or instructions that tell the AI to actually use them.

That’s the whole thing. The AI now has the components, the guidance, and the rules of engagement. Most of the “AI doesn’t understand our design system” problem disappears the moment all three are in place.

As a bonus, if you’re using Claude Code with your zeroheight MCP, here are the two skills files I use to direct Claude in the right way. The first is a skills.md file that tells Claude where to look for what…

---
name: zeroheight-design-system-routing
description: Route design system queries when a zeroheight-style MCP is connected. Use for questions about components, tokens, props, variants, or usage; for building UI, prototypes, or new design system components; or for auditing code against design system standards. Routes "what exists" to the installed npm package and "how / when / why" to the zeroheight MCP. Triggers on phrases like "what components do we have", "which button should I use", "build me a [screen/component]", "add a [component] to the design system", "audit this for compliance".
---

# Zeroheight design system routing

Routes design system questions to the right source. Does not fetch or synthesise — it directs Claude where to look.

## Core principle

- **The installed npm package** is the source of truth for *what exists*: components, props, types, tokens, variants, exports. It matches the version installed in the project.
- **The zeroheight MCP** is the source of truth for *how, when, and why*: which component to use, when each variant applies, accessibility, composition, design principles.

Default to the package for lookups, the MCP for guidance. Don't cross over.

## Detection

1. **Find the design system package** in `package.json` (common shapes: `@<org>/design-system`, `@<org>/ui`, `<org>-ds`). If unclear, ask the user — don't guess.
2. **Identify the zeroheight MCP** by what it exposes (component guidance, design principles, token docs). Its name varies per styleguide, so don't match on a literal string.
3. **If a source is missing**, say so and use what's there. If neither is available, fall back to general best practices — never invent component or token names.

When the package and MCP disagree, the package wins on existence and API shape; the MCP wins on usage and intent. Surface the disagreement rather than picking silently.

## Scenarios

Identify the scenario first, then route.

### 1. Looking up an artefact

*"What button variants do we have?"*, *"What props does `<Modal>` take?"*, *"Is there a `spacing.lg` token?"*

→ Read the **package**. Faster, version-accurate. Use the MCP only for the follow-up *"which one should I use?"*.

### 2. Building a UI, prototype, or screen

*"Build a settings page"*, *"Create a checkout flow"*, *"Make a delete-confirmation modal"*.

→ **MCP first**, then package. MCP picks components and plans composition. Package implements — real imports, real prop names, real token names.

### 3. Building a new design system component

*"Add a `<Stepper>` component"*, *"Build a date picker following our patterns"*.

→ **Structure from the package** (read sibling components for layout, naming, prop patterns, tests, stories). **Principles from the MCP** (expected variants, a11y, spacing/typography rules). Works the same whether the user is inside the DS repo or contributing from outside.

### 4. Auditing or testing

*"Audit this page for compliance"*, *"Are we using the right tokens?"*, *"Is this accessible per our standards?"*

→ **MCP first** — auditing is applying guidance. Use the package only to confirm what's actually exported or what version is installed.

## Edge cases

For changelogs, deprecations, and MCP-duplicated API tables, see `references/exceptions.md`.

The second is the exceptions.md file that lives in references/

Edge cases for zeroheight routing
Cases where the default rule (package for what, MCP for how/when/why) inverts or needs both sources. Read this only when one of these situations comes up.
Changelogs and release notes
Usually live in the styleguide (MCP), not the package, even though they describe what changed. If the user asks "what's new in our design system recently" or "when did <X> change", start with the MCP.
Deprecations
Described narratively in the MCP — "don't use <OldButton>, use <Button variant="…">" — but often also annotated in the package's types as @deprecated. Check both:

The package tells you whether something is still exported and whether it's marked deprecated in code.
The MCP tells you the migration path and rationale.

Prop or token tables surfaced through the MCP
Some styleguides duplicate API tables in the MCP for convenience. Treat them as secondary — the installed package is canonical, because the styleguide may document a different version than the one pinned in the project. If the MCP says a prop exists and the package doesn't export it, the package wins.

Happy vibing!

We’re looking for speakers for this year’s Converge, which is happening in Newcastle, UK on October 22, 2026. For those who don’t know what Converge is (where have you been?), it’s a one-day community-focused design systems event, where some of the best design systems folks from around the world share their knowledge on everything design systems (you can see previous talks here).

What we’re looking for

Converge has always had a good mix of technical and theoretical talks, from token management to real-world case studies on driving adoption to what we can learn from the Luddite movement and how it applies to design systems today. Nothing is really off the table as long as it’s about design systems and interesting.

In saying that, there are a few topics we’re especially interested in at the moment: Obviously, AI and design systems. We’re in a new world, and things are changing fast, so we’d love to see some real-world examples of what folks are doing, as well as theoretical talks that can help drive our industry forward. Next up are the evergreen topics of driving adoption and what good documentation is. Do you have real-world examples of change you’ve made internally? We want to hear about them! Next up is community building and communication with design systems. We’re suckers for anything that focuses on the people aspect of design systems, so if you have anything specifically in this category, get in touch!

The technical details

We’ve got a small handful of slots available, including full talks (30 minutes) and lightning talks (15 minutes). Every approved speaker will be paid a small honorarium (£500) and have their travel and accommodation covered by zeroheight (unless your company doesn’t allow this). You’ll also be invited to the speaker’s dinner on the 21st of October and to the after-party on the evening of the conference. We don’t do Q&A sessions at the event, and encourage speakers to stick around and chat to attendees (they’re all nice people, we promise).

How do I apply?

Fill in the form below to submit! If you can submit your talk by June 30, we’ll then select the speakers in July. Some tips for applying:

• If you’ve got recent examples of talks you’ve given, please include them. It helps us understand what kind of speaker you are and how confident you are in presenting.
• If you’ve never spoken before, that’s also ok! We’ve had first-time speakers at almost every Converge, and are always keen to get new voices heard. If it is your first time, make sure you include a video pitch of your talk. Doing it on Loom or in an unlisted YouTube video is ok. It just gives us a feel for who you are.

What happens then?

We’ll be keeping an eye on submissions as they come in, and make sure we get back to all folks who submitted by the end of July.

What are you waiting for? Submit your talk!

[hubspot form-id=”20a69d99-6045-4348-9a83-ce0ffbcebae9″ heading=”Submit your talk” description=”Submit your talk to Converge 2026 on October 22 in Newcastle, UK”]

Let’s return to the phrase’s original negative perspective. If a designer pulls a poorly built component from a Figma library, two things can happen:

• They use the component as best they can, favoring consistency over quality. But it slows them down or impedes them from doing their best work. It may also confuse and frustrate them. 
• The lack of quality is offensive enough that the designer does not use the component, favoring quality over consistency. This can look like detaching, building their own component, or sourcing a component from another system.

Both of those situations teach consumers not to expect quality from the design system. This hurts trust — a hard thing to earn.

To help you start regaining trust with consumers, or get a new system going with a strong start, I’ve compiled a list of mistakes I’ve made myself or encountered in the wild.

1. Creating a “count” or “# of items” variant property

Why it’s bad: File memory. 

Each and every variant in a component is rendered in the background when an instance is placed on the canvas. Variants therefore should be considered the most expensive type of property (relative to string and boolean props, which let you manipulate individual layers). 

This is why when you’re using list-like UI elements — such as checkboxes or radios in a form field, options within a dropdown menu, rows in a table, list items in a list, or buttons inside of a button group — you’re likely to find them slower to work with. Or your file suddenly loses memory when a lot of them are present. 

Many component architects will use a variant property to give component consumers a closed range of items to populate the element with: 0 to 24 rows in a table, 2 to 7 radios in a form field, 1 to 55 options in a dropdown menu. Even if file memory wasn’t an issue, this approach requires an enormous amount of building effort and maintenance to keep working. This can introduce room for error when making updates, and consumers will likely always need “just a couple more” variants at the high end of any given range of items offered.

What to do instead: Use the latest slot feature. Even before slots were released, component architects could use instance swapping as a “pseudo slot”, alleviating all the issues that came with using variants.

Related reading: 

• Slots in design systems 
• Figma slots for repeating items 
• Figma’s documentation on slots

2. Adding interactive states to icons

Why it’s bad: Semantically confusing.

Remember what icons are: Their closest relative would be characters in a font. They’re not inherently interactive, but you could wrap them in an <a> or <button> tag to accomplish this. The same is true for icons. When you add states directly to an icon component, you risk confusing consumers and painting that icon into a corner. Icons’ use cases vary greatly, and they are not always interactive. Sometimes they’re informational, other times they’re decorative, and often they’re static.

What to do instead: Build UI elements, like icon buttons, and put instances of your icon components inside of those. Add interactive states to the UI element, rather than directly to the icon component. Also, toggle switches are not icons.

Related reading:

• Accessible icon buttons
• Icons

3. Over-using booleans in a component’s API

Why it’s bad: Loss of parity with engineering. 

Unless your consumers’ designs never need to leave Figma, you likely want to have alignment between Figma components and their coded counterparts. To achieve that, it’s beneficial to create symmetry in their APIs (their properties and the values of those props). 

A common offense I’ve seen is treating “dark mode” as a true/false statement (see this example). Even in a situation where there are only ever two options, it’s worthwhile to reduce cognitive load for component consumers. Theme=dark is easier to understand than Dark mode=true. And a sea of booleans does not make for a more usable properties panel.

What to do instead: Remember that a bloated property panel hurts usability for design system consumers. Toggle switches may save some time, only needing one click to interact with, but consumers will ultimately waste more time reverse-engineering the logic of the property schema. It will also make using features like Code Connect much harder. Your developers won’t be happy either.

Related reading:

• Crafting Component API, Together

4. Using variants for broad themes and contexts

Why it’s bad: Forces consumers to manually update each instance within a mockup to change a theme. 

This opens consumers up to huge risk for errors, and it’s a laborious, time-consuming process. No designer wants to spend time making sure every instance, even with the help of bulk-selection tools, across dozens of mockups, is all set to theme=dark-mode or breakpoint=mobile. 

It’s also hard on the library team. They will have many more variants to manage, and there are lots of opportunities to flub your naming conventions. Worse still, it’s expensive. Each theme a component offers is a multiplier on the cost of memory usage (don’t forget the hidden cost of variants from point #1).

What to do instead: Use variables and modes. Schema 2025 brought an increased number of modes to all plans, so there are fewer excuses not to use this feature. By simply applying a mode to a mockup, designers will both save time and reduce risk in their work.

Related reading: 

• Color in design systems
• Browsers and viewpoints and container queries, Oh My! Responsive design systems

5. Using Figma as a project management tool

Why it’s bad: Increases the risk of confusion and misinformation.

The risk for a ✅ or 🟢 to go “stale”, and no longer reflect whether the material on that page is stable, is just too high. It’s especially selfish for a design system team to use fragile, static emojis in their library file, because it means the consumers of that file will see nothing but green dots. And when everything is green… what’s the point?

What to do instead: Use the work-tracking tool you’re already using: Jira, Monday, Trello, Asana, etc. If you have access to the branching feature, you can name your branches to describe where work is happening: call out components, variables, or pages by name. Similarly, if you’re using dev mode, use the “mark ready for dev” feature — use it. It does a lot of what folks try to do manually with emojis for free! You can also find ways to reduce context switching between Figma and your work-tracking tool by integrating them with a plugin or widget (perhaps you can even make your own).

Related reading:

• I have beef with status emojis in component library Page names

6. Using shapes or groups instead of frames

Why it’s bad: Shapes are more limited than frames.

Shapes can’t use auto layout. They show up as SVGs in Code Connect or dev mode, which can confuse developers. 

In the example above, the leading and trailing lines within the Divider component are made with actual lines. If you’ve got an eye for alignment, you can see that the lines are sitting a little too high up. The optical alignment feels wrong. This is happening because a line has a height of 0px. 

If you created this same component but used frames that are 1px tall with a fill color, instead of 0px-tall lines with a 1px stroke, you’ll get better optical alignment.

As for groups, the same applies, except their dimensions are dynamic and will change based on the X & Y coordinates of their children. While these layers are important for organizing material on the canvas or for more traditional graphic design and illustration, they don’t have a huge role in design systems.

When you should use shapes: Icon artwork and illustrative graphics.

What to do instead: Use frames.

Related reading:

• Figma’s documentation on layer types

7. Adding “on click” prototyping interactions to all components

Why it’s bad: Inadvertently creates more work for consumers. 

Imagine a radio button with an on-click interaction that changes a “selected” property from false to selected=true. This may seem harmless, but it could create extra work for consumers. If they want to use that radio button in a set of radio buttons within a form field, they will need to remove all those on-click interactions so they can set up new ones. That’s because radio buttons are rarely used outside a group and must be aware of their neighbors’ selected states in order to function properly.

What to do instead: Include hover states, and leave out click interactions, except on toggleable elements like, well, toggles, and checkboxes.

Related reading: 

• Should library components come with prototyping interactions? Only sometimes…
• Tutorial: build WORKING radio buttons, tabs, pagination, and breadcrumb sets in your Figma library 

8. Not explicitly naming each layer

Why it’s bad: Not naming your layers increases your risk of override loss or unintended override transfers when swapping components or variants. 

Figma uses layer names to know what overrides should persist when swapping variants or components. By not taking the time to make sure layer names are well-named, you risk undesirable overrides.

Negative consequences for the properties panel. If you’re planning to expose a nested instance’s properties, you want to make sure the layer of that instance is named in a way that will be clear in the properties panel. Otherwise, you risk confusing consumers.

What to do instead: If you can’t be bothered to name your own layers, use Figma’s AI feature to rename layers for you.

Related reading:

• Figma’s documentation on renaming layers with AI

9. Using a “wrapping” variant property

Why it’s bad: You’re 2x-ing the memory consumption of that component. 

Recall the first point about how expensive variants are! Folks make a “wrapping” prop in an effort to offer components that can flex into tight places, or be resilient even when they contain a lot of content. On the web, this happens somewhat automatically: Elements will flow onto new lines. But in Figma, that behavior requires a more intentional setup.

What to do instead: Use auto layout wrapping.

Related reading:

• Figma’s documentation on auto layout wrapping

10. Overloading the “state” variant property

Why it’s bad: Conflating different kinds of states makes for a messier component API. 

This creates confusion for consumers and your engineering counterparts. It’s easy to fall into this trap because the name is widely applicable. “Error” is a state! So is “hover”. And so is “disabled”. 

But these are separate concerns, and cramming them all into a single property risks needing dozens upon dozens of values. For example, what happens when you hover over the element while it’s displaying an error? If all you allow yourself is a single “state” property, you’d need an “error default” and “error hover” values.

What to do instead: Consider splitting out the “Focus” state from interactive states like hover and pressed. Let “Focus” and, while you’re at it, “Selected”, “Disabled”, and “Populated” be the booleans they’re meant to be. Acknowledge that “Error” is about validation feedback, and not interactivity.

Related reading:

• The sorry state of states

Avoid pitfalls, save time, and build more confidently

I believe that knowing how to effectively wield your tools matters a great deal. Understanding a tool’s constraints, the “edges” of each feature, where it shines and where it’s lacking, all give you enormous confidence. To me, that confidence has been invaluable as I’ve worked across three enterprise-level design systems thus far. I can tell that my decision-making is sharper, weighing tradeoffs feels comfortable, and I know what I’m building will last. 

I hope I’ve saved you some time by showing you how to leverage Figma’s various features and what pitfalls to avoid. And I hope with that comes greater confidence as you build the best possible components for your team.

Design systems are a means to an end. They always have been.

We don’t build token architectures for the joy of naming colors. We don’t document component APIs because we love writing specs. We build design systems because they help us build products. The system serves the product. The product serves the user.

But the nature of that product is about to change fundamentally. And most design systems aren’t ready for what’s coming.

This is part 1 of a three-part series on design systems and what comes next. Part 2 covers the check engine light, and part 3 looks at the diagnostic layer. 

The end of static

For the last decade, the products that design systems enable have been relatively predictable. Dashboards. Ecommerce platforms. SaaS tools. Marketing sites. The interfaces differ in complexity, but they share a common trait: They’re pre-designed. 

Someone decided what the layout would be. Someone chose which components would appear. Someone wrote the content for each slot. A design system made that process faster and more consistent, but the output was always a fixed artifact. A page. A screen. A flow. The same for every user who encountered it.

That model is reaching its ceiling.

Users don’t want generic interfaces. They want experiences that respond to their specific needs, in their specific context, at that specific moment. And the technology to deliver that is no longer theoretical. Large language models can interpret user intent. Structured protocols can provide access to component libraries. AI agents can assemble layouts from component inventories using real data. The capability to produce personalized, context-aware interfaces on the fly already exists in an early form today.

What doesn’t exist, for most teams, is a design system capable of supporting it.

What ephemeral UI actually means

An ephemeral UI is an interface that’s generated in the moment, for a specific user, for a specific need, and may never exist in that exact form again.

Imagine a user expressing a need: “I need to book a reservation for four people this Saturday, with dietary restrictions.” Instead of navigating through three screens, two dropdowns, and a filter panel, the system generates a form. Not a generic form. A form with exactly the fields needed for that specific request, using your design system’s components, respecting your brand’s visual identity, and meeting your accessibility standards. The user fills it out. It does its job. It may never be rendered in that exact configuration again. It was built for that moment, for that user, for that intent.

Now extend that to dashboards that reorganize based on what you’re trying to understand. Data visualizations that assemble themselves around your specific question. Settings panels that surface only what’s relevant to your role. Admin interfaces that adapt to your permissions and workflow.

The interface becomes a response, not a destination. And it’s not a prototype. It’s hooked up to real endpoints, receiving real data, rendering real charts, tables, graphs, and maps.

What happens when you get the foundation right

I can say this with confidence because we’re already doing it.

At Southleft, my consultancy, we made a commitment in January 2025 to involve AI transparently in every project. Not as a gimmick. Not hidden in the background. As a genuine part of our methodology. Over the past year, we’ve invested heavily in two parallel tracks: making design systems AI-ready through structured tokens, component contracts, and diagnostic tooling, and building a custom agentic infrastructure of AI agents, skills, and automated workflows tuned specifically to our process.

Recently, we worked with an enterprise client on what we call a “mad scientist” engagement. We had already built them a design system that was AI-ready from the ground up: clean token architecture, structured component contracts, full metadata, everything validated and in sync. So we skipped the remediation phase entirely and went straight to generation.

What happened next surprised even us.

We generated multiple complete interface scenarios in weeks. Not mockups. Not prototypes. Working, data-connected experiences: charts, tables, graphs, maps, complex data visualizations — all assembled from the design system’s component library by our AI agents. The client’s reaction wasn’t, “That’s fast.” It was, “We didn’t know this was possible.” They started imagining experiences they’d never considered, and we executed on those, too. That loop kept going. Within months, they signed a year-long contract because the pace and quality of output exceeded anything their traditional development process could match.

Here’s the part that matters for this conversation: None of that was possible without the design system. Every interface we generated drew from the same token architecture, the same component contracts, the same accessibility standards, the same brand guidelines. The AI wasn’t freelancing. It was composing from a vocabulary that had been carefully authored by humans. The system was the constraint that made the creativity possible.

Why most teams can’t do this yet

Most design systems aren’t in a state where any of this is feasible. Not even close.

For AI to generate a correct, branded, accessible interface from components, it needs absolute clarity about what those components are, how they behave, and what constraints they must respect. It needs tokens that define the visual language without ambiguity. It needs component contracts that specify every prop, every state, every interaction pattern, every accessibility requirement. It needs a diagnostic layer that keeps design and code in sync so the system doesn’t drift.

It needs a design system that is complete. Not “mostly documented.” Not “good enough for the team that built it.” Complete. Because the margin for error in generated UI is functionally zero. A human developer who encounters a missing prop or an ambiguous token can ask a colleague. An AI agent generating an interface in real time cannot pause and send a Slack message. It uses what’s available. If what’s available is incomplete, the output is wrong. And wrong, at scale, is expensive.

We work with Fortune 100 companies that aren’t there yet. Their design systems have inconsistent tokens, missing metadata, components locked to a single platform, documentation that a human can interpret but a machine can’t parse. Some of them don’t have design systems at all. They have collections of platform-specific components that someone relabeled. Before they can generate adaptive interfaces, they have to fix the foundation. Before they can fix the foundation, they have to acknowledge it’s broken.

The prerequisite chain

The logic flows in one direction.

You can’t generate adaptive UI without a design system that AI can reliably consume. You can’t have a design system that AI can reliably consume without a diagnostic layer that keeps design and code in sync. You can’t build a diagnostic layer without first fixing the communication breakdown that causes drift in the first place.

Every step depends on the one before it. Skip a step, and the chain breaks. The teams that invest now in fixing their token architectures, structuring their component contracts, and establishing bidirectional communication between design and code aren’t just improving their current workflow. They’re building the infrastructure for a product paradigm that doesn’t fully exist yet, but is arriving faster than most people expect.

The human moves upstream

There’s a fear embedded in all of this that’s worth addressing directly. If AI can generate interfaces, what happens to designers? What happens to developers?

They become more important, not less.

Someone has to author the tokens. Someone has to define the contracts. Someone has to decide what “good” looks like, what the brand means, what accessibility standards to enforce, what interactions feel right. Someone has to build the system that the AI draws from, review what the AI produces, and evolve the system as products and user needs change.

The creative and technical judgment doesn’t disappear. It moves upstream. Instead of designing individual screens, designers define the rules, the vocabulary, the constraints that govern how screens get generated. Instead of building individual components from scratch, developers build the contracts and infrastructure that enable components to be assembled correctly at scale.

It’s not less work. It’s different work. And it requires more intentionality, not less.

Design systems were always about this

Design systems have always been about enabling products to be built faster, more consistently, and at greater scale. The means change. The mission doesn’t.

What’s changing is the scale of what’s possible. A design system that’s complete enough to support AI-generated interfaces doesn’t just serve one product team building one dashboard. It serves every possible configuration of your product. It serves users you haven’t met yet, in contexts you haven’t imagined. It becomes the engine of infinite personalization, constrained by the taste, judgment, and standards that your team encoded into it.

That starts with the boring stuff. Fix your tokens. Structure your contracts. Build the diagnostic layer. Get your system in a state where a machine can read it as clearly as a human can.

Because the product your design system is building isn’t the one you’re shipping today. It’s the one that doesn’t exist yet.

Next time: The check engine light is on. 

TJ Pitre is speaking at zeroheight’s design systems conference, Converge, in Newcastle on October 22, 2026. Check out the rest of the line-up so far and get your tickets.

Imagine opening a board game to find the rulebook is missing. Nobody would expect the game to work — yet that’s exactly how most teams ship a design system: technically complete, organizationally unplayable.

But the real problem is worse than a missing rulebook. Most design systems have multiple rulebooks — one per discipline, written in different languages, stored wherever that discipline lives. Your React engineers write their truth in Storybook. Your iOS team writes theirs in a Swift package. Your accessibility specialists write theirs in Confluence. Your designers write theirs in Figma.

None of these groups is wrong. They’re just incommensurable. The result isn’t conflict — it’s drift. And drift is slower and harder to diagnose than conflict, because nothing fails loudly. Things just quietly stop being the same system.

There isn’t one kind of truth

The reason design systems drift isn’t a tooling problem. It’s a taxonomy problem. We collapse three fundamentally different kinds of truth into one word — “documentation” — and then wonder why the documentation never does what we need it to do.

Operational truth is how things actually work. Component specs. Token values. Figma files. Teams obsess over this one because it’s tangible, and tools enforce it. It’s what you can point to when someone asks, “Where’s the design system?”

Normative truth is what we believe is correct. Design principles, like “we don’t use red for primary actions.” The standards, not just the specs. This is where organizational values live, and it’s the most fragile kind of truth because it exists almost entirely in human heads.

Historical truth is why decisions were made. The rejected alternatives. The constraint that shaped a direction. The tradeoff that seemed obvious at the time to the three people in the room. This is the rarest, most undervalued, and — in an AI-driven workflow — the most critical kind of truth your system has.

Operational truth gets documented because tools enforce it. The other two evaporate.

The game doesn’t stop when the rulebook is missing

Here’s what actually happens: The game continues. Players invent their own interpretations. The React team’s interpretation diverges from the iOS team’s, which diverges from the accessibility specialist’s. None of them know this, because there’s no shared binding. 

Game design scholars Katie Salen and Eric Zimmerman, in their foundational text Rules of Play, put it precisely: When players don’t share the same ruleset, “resolving this discrepancy is what the game is all about.” In most organizations, this is exactly what design reviews become — not creative work, but discrepancy resolution.

Medieval scholars had a word for the solution: sammelband — a single binding for independently produced texts that needed to be together. A design system’s documentation, when it works, is an organizational sammelband. Not a single author. Not a single format. A single place where legitimate truths from all disciplines are held together and made authoritative through their co-location.

That’s what a documentation platform like zeroheight actually is, when used properly. Not a component reference. Not a changelog. A binding.

What AI just changed about this

For 20 years, missing normative and historical truth was a human problem. A designer could look at a component and say, “That’s not right.” A tech lead who’d been through the original debate could recognize when implementation had drifted from intent. The normative standard lived in people’s heads, and people could mediate.

AI agents have no heads. Every session starts cold.

When you point a model at your design system through an MCP server, it receives your operational truth — specs, components, token values. It will infer normative truth from patterns in the corpus. And it has zero access to historical truth, because that was never written down.

The result isn’t hallucination. It’s something more subtle and more damaging: The model re-opens debates that were already closed. It proposes patterns your team considered and explicitly rejected six months ago, because the rejection was never recorded. It optimizes toward what’s measurable and ignores what’s intentional. 

The organizational theorist Herbert Simon — Nobel laureate and one of the founders of artificial intelligence research — observed in Administrative Behavior that organizational memory is stored mostly in human heads, and that “turnover of personnel is a great enemy of long-term organizational memory.” AI doesn’t replace personnel. It replaces the assumption that memory can live in heads at all.

The political philosopher Thomas Hobbes wrote about what happens when laws are written, but their intent goes undocumented: the interpreter, lacking the legislator’s reasoning, becomes the legislator. The model isn’t rewriting your design system. It’s making decisions in the space your undocumented history left unoccupied — and it has no way to know it’s doing so.

Writers on this very blog have been circling this problem from the practitioner side. Luke Murphy, zeroheight’s Lead Design Advocate, has argued that documentation generated from code “misses so much context” — that it takes a human who has been through the trials and tribulations to explain “not just the how but the why.” Amy Hupe, a design systems consultant whose work spans GOV.UK, the BBC, and BT, has put the same point from the design side: Usage guidance is “where we can communicate purpose and intent.” Both are describing the same missing layer. Neither quite had a name for it. Historical truth is the name.

What the rulebook actually contains

The fix isn’t more documentation. Most teams already have too much documentation that nobody reads. The fix is documenting a different kind of truth.

The architect and theorist Christopher Alexander spent his career arguing that what distinguishes generative systems from prescriptive ones isn’t the number of rules — it’s whether the rules encode understanding or merely outcomes. 

A prescriptive system says: Use this token, apply this component, follow this pattern. A generative one says: This hierarchy exists because users need to distinguish commitment from exploration; this constraint solves this class of problem; this decision was made after we considered and rejected these three alternatives.

Most design systems are thoroughly prescriptive. The rulebook is what pushes toward generative.

In practice, that means every significant decision in your system deserves three things alongside it: the context in which the problem appeared, the problem it was solving, and the solution chosen — including what was considered and why it was set aside. Not a legal brief. Usually two or three sentences. The reasoning that a new team member, or a new AI agent, would need to evaluate whether this decision still applies to their situation.

This is what the sociologist Paul Starr, in his Pulitzer Prize-winning study of professional authority, called being “consulted to resolve ambiguities” — the function that makes a document authoritative rather than merely informational. A dictionary isn’t just storage. It’s the thing you check when you need to know if you’re right. Your design system’s rulebook should work the same way: not consulted as a reference, but consulted as an arbiter.

The question your rulebook answers

There’s a useful test for whether any piece of documentation belongs in the rulebook. Imagine a new engineer joins the team. Imagine an AI agent is handed your system to work with. Now imagine a dispute arises about a design decision. Does your documentation resolve it — or does it send everyone back to find the person who was in the original meeting?

If the answer is the latter, you have operational truth. You don’t yet have a system of truth.The teams succeeding with AI are the ones who documented the reasoning, not just the decisions. The rulebook is what makes a design system legible to any agent — human or otherwise — that didn’t inherit the institutional memory of the people who built it. It’s what makes “this is wrong” a sentence that means something, because it gives “wrong” a prior standard to be wrong against.

Why this matters beyond the system

Herbert Simon observed that the purpose of organizational systems is to conserve what he called “the critical scarce resource — the attention of managers.” A design system exists for exactly this reason: not to enforce consistency, not to accelerate velocity, but to make solved problems disappear — so that human attention can be redirected toward the problems that genuinely require it.

Tokens and components do this at the level of decisions. The rulebook does it at the level of decisions about decisions. Without it, the solved-problem space isn’t actually solved. It’s only deferred — waiting to be re-litigated the moment a new team member joins, a new platform arrives, or an AI agent starts filling the gaps your history left open. Every hour spent re-adjudicating the past is an hour not spent on the problem nobody has solved yet.

That’s what the rulebook is actually protecting. Not the system’s integrity. Your team’s capacity to do the work that matters.

Your design system already has all the pieces. Give it the rulebook that tells everyone — and everything — how to play.

What most teams have instead is a process — often a well-documented one. But documentation isn’t the same as momentum, and a contribution model that nobody engages with is just overhead.

The gap between those two realities isn’t usually a process problem. It’s a ritual problem.

Processes tell people what to do, rituals give people a reason to show up. And in contribution programs, the reason matters more than the steps.

What contribution is actually for

A contribution model won’t make your design system produce more, or your team move faster. Getting someone’s contribution to a releasable standard almost always takes longer than doing the work yourself.

That’s not a reason to skip it. It’s a reason to be honest about what you’re optimizing for.

The real payoff is advocacy. When someone contributes to a system, they understand it differently. They’ve touched how it works, made decisions inside its constraints, and pushed against its edges. That experience turns passive consumers into people who explain the system to colleagues, defend its decisions in design reviews, and flag problems before they compound. That outcome — broader adoption driven by people who genuinely believe in the system — matters more than any component itself.

Rituals are how you create the conditions for that payoff consistently, rather than by accident. Don’t start too early, either. A system that’s still figuring out its core components doesn’t need open office hours and ambassador programs yet. Those rituals require capacity to absorb incoming work and enough consistency to evaluate contributions against. The right signal is when multiple teams independently describe the same missing pattern — that’s when there’s actual material to work with.

Office hours: the ritual that earns trust fastest

If you’re starting from scratch, office hours will do more work than almost anything else.

The format is simple. A regular block of time — an hour or two per week — where any designer or developer can drop in to ask questions, get a read on an idea, or start working through a contribution proposal. No agenda. No ticket required beforehand.

What makes office hours powerful isn’t the Q&A. It’s the consistency. Showing up at the same time every week signals that the design system team is reachable. One of the most common reasons teams don’t contribute is that the system feels like a black box — decisions go in, nothing comes back out. Office hours don’t fix that perception alone, but they make it harder to sustain.

Nord Health’s design system directs contributors to office hours or their Slack channel before anything procedural begins — the first step in their process is always a conversation, not a form. That’s deliberate. Keeping the entry point casual means teams with half-formed ideas still show up, and half-formed ideas are where most good contributions actually start.

The thing that breaks office hours is cancellation. I’ve seen contribution programs lose momentum entirely because sessions got dropped three weeks in a row during a busy sprint cycle. By the time office hours came back, the teams who’d been considering contributing had already worked around the system. 

Cancelling sessions when the design system team is busy teaches product teams that the availability is conditional, and conditional availability is almost the same as no availability. Keep office hours in slower weeks especially — those are the ones where you build the relationship before the contribution exists.

Making contributors visible

Crediting contributors is one of the simplest rituals in a contribution program, and one of the most consistently underused.

When contributor names appear in documentation, release notes, or Slack shoutouts, the relationship between the product team and the design system team shifts. It stops feeling like vendor and customer and starts feeling like co-authorship. People who see their name attached to something they helped build become invested in that thing — they explain it to others, flag issues when they spot them, and come back with more.

Eventbrite’s Marmalade design system takes this further across two distinct models. In their button component documentation, contributors are named directly: “Big thanks to Bryce Bennett, Cory Dransfeldt, Vincent Budrovich, and the Search and Discovery Team for partnering with us to build and test this component“. Elsewhere, they flip the direction entirely. If you’ve used a component in your work, you can reach out to get featured on their wall of fame. One model credits people for building. The other credits people for using. Both make the community visible inside the documentation itself.

When recognition becomes structural rather than occasional, it compounds. Sprout Social formalized this into an ambassador program — named liaisons embedded in each product team — as a result, the roster grew from two to six within four months, and contributions were shipping near-weekly. More telling than the numbers, the teams joining weren’t the ones already engaged. Recognition had created a channel, and new teams found it.

What complicates this — and Amy Hupe has written about it honestly — is that not everyone wants their name attached publicly. Some people worked on something without their manager’s knowledge. Some feel uncomfortable with the visibility. Some have genuine concerns about being associated with patterns that touch sensitive user experiences. A fair attribution practice means asking rather than assuming, and making it easy to opt out.

It also means being honest that once something is in the system, the design system team owns it — regardless of who built it. If a contribution attracts criticism, that’s yours to handle, not the contributor’s.

Crits, hackathons, and keeping up with AI

Design crits are an underused entry point for contribution proposals. Bringing a proposed component or pattern into a shared session — with the contributing team and the design system team both in the room — signals that the work is being taken seriously. It also means feedback happens in conversation rather than in an async comment thread, which changes how people receive it. The contributor can ask why, not just read what. That distinction matters for whether they come back.

Crits are also where you negotiate quality honestly. A contribution might need more abstraction to work at system scale. Token decisions might need revisiting. Edge cases the product team never encountered tend to surface here — things that would have taken three rounds of async comments to work through get resolved in 15 minutes when everyone’s in the room.

Hackathons serve a different purpose. They create a spike of momentum and, more importantly, a shared experience. As Ben Callahan has written, contribution can only work if it’s built into the incentive and capacity model — which means protected time, with leadership signaling this is real work. When product teams spend a day working alongside the design system team, near-miss patterns tend to surface — things that got built independently by two or three teams because the overlap wasn’t visible until everyone was in the same room.

Both crits and hackathons are also where you catch a newer problem before it compounds. Teams using AI coding tools — Cursor, Claude Code, Figma’s MCP server — generate components faster than ever, and some of that output lands in products without touching the contribution process at all. It’s not malicious. It’s just fast. The system-adjacent component gets built, it ships, and the design system team finds out later. Tools like zeroheight’s MCP help close that gap by making your documented standards available to the same AI workflows generating the code, but the human review rituals still need to be there.

That’s exactly why human review rituals matter more as AI output goes up, not less. AI tools have no awareness of your token architecture, your naming conventions, or the edge cases your system has already solved. The review process that applies to a human contributor applies to AI-generated output too — arguably more so.

Keeping rituals alive

The most common reason contribution rituals fail is inconsistency.

Office hours you cancel when things get busy, credits you post once and never mention again, hackathons you run once and never put back on the calendar.

Treat rituals like commitments. Schedule them before you need them. Keep office hours even in quiet weeks. Update contributor credits even for small releases, because the pattern matters more than any individual acknowledgment. And be honest about what your team can actually sustain — the cadence you can keep will always outperform the one that looks good in a proposal.

Design system contribution is a relationship problem. Rituals are how those relationships stay alive when the work gets busy and the calendar fills up.

The teams that have figured this out don’t talk much about their contribution models. They talk about their communities. That’s the difference.

It’s also the clearest example yet of the biggest lie in the design systems space.

Because everyone is talking about Claude Design as if it’s solved the AI-and-design-systems problem. It hasn’t. What’s solved is the easy half of design systems: the artifact-extraction problem. And for years, we’ve all been pretending the artifact layer is the whole thing. Claude Design, Cursor, v0, Lovable, Figma Make — they’re all pulling in the same stuff: tokens, components, maybe a type scale if you’re lucky. They’re ingesting the ending of a book and being asked to write the middle.

That’s why the output from these tools looks so uncannily similar, no matter whose brand you feed in. That’s why the interfaces that come out feel hollow in a way you can’t always name. Gabe Kelley wrote a piece a few days ago that nails the feeling: when you strip the human decision-making out of a design system and feed only the artifacts into a model, you get artifacts back. Competent and polished, but fundamentally authorless. And it’s not a new problem. In fact, Amy has been pointing out a version of this problem for half a decade: design systems are more than the artifacts we produce, and they should encode far more than what ends up in the token or component spec.

The AI moment has made it urgent. We had the luxury of papering over the ‘designers as interpreters’ problem, because this stuff just happened in our heads. Humans read the docs, absorb the rationale, and translate it all into product. But now that gets consumed directly. By a model. At speed. At volume.

So here’s the flag I want to reiterate: a design system is an organizational artifact, not a design artifact. The tokens and components are the surface. The decisions behind them are the system. AI can only reason about what you give it, and most teams are giving it the surface.

The hollowing

Component-centric documentation produces component-centric AI output that produces interchangeable product UI. I’ve spent the last year talking to people building with Cursor, Claude Code, v0, Lovable, Figma Make, and now Claude Design, and the pattern is the same everywhere: teams spend weeks getting an AI to “use their design system,” and what they get back is a button that’s the right color in an interface that could belong to anyone.

The problem isn’t that the AI is bad. The problem is that color-brand-primary doesn’t tell you anything about when to use it. It doesn’t tell you that primary actions appear at most once per screen because your team spent three months arguing about visual hierarchy. It doesn’t tell you that the token is being deprecated in favor of a new semantic one next quarter. It doesn’t tell you it fails AA contrast in one of your themes, and the accessibility team has strong feelings about it. None of that lives in a token file or component API.

If you feed AI only artifacts, you get generic, shitty interfaces. That’s what’s coming for most teams who think “connect it to our codebase or Figma library” is a design system strategy.

“We’ll just do it ourselves, but leaner and quicker”

There’s a conversation I keep having. It goes roughly: “zeroheight is becoming a moot point. We can write a few short specs, drop some design.md files into the repo, feed those into the AI, and we’re sorted.” I hear it from engineers, from design leads, sometimes from customers and potential customers.

Here’s what I’ve noticed after pulling that thread with the teams actually doing it: they are not doing less than they think. They are doing substantially more. What starts as “a few markdown files” becomes: a custom MCP server, a model fine-tuned on internal documentation, a prototyping environment, a migration plan to style third-party components like ShadCN instead of maintaining their own libraries, a restructuring of every piece of existing documentation so it’s machine-readable. Months of work and substantial cross-functional headcount. A quiet second product built in the shadow of the real one.

That’s not a rejection of structured documentation. It’s a rebuild, in-house, often without a realistic picture of what’s been taken on. The question has shifted from “do we need a corpus?” to “who builds and maintains it?” and many teams are answering that second question without really hearing it.

The companies doing this most confidently are validating the thesis. You need a substantial corpus of information to power your design system. It needs to be structured, machine-readable, and rich enough for a model to reason with. The debate is about custody, not category.

The pattern layer is the part everyone skips

Just like a UI library, a code repo, a set of tokens… component documentation does not a design system make.

The design system is the layer above it: patterns, intents, flows, compositions, anti-patterns, and decision records. A button is a commodity. ShadCN has buttons. So does Ant Design. So does every AI tool’s built-in component library. What makes your product yours is not the button; it’s the rule that says only one primary button per screen, the pattern for destructive confirmation, the way you handle empty states, the voice in your error messages, the decision to hide certain actions behind progressive disclosure, the things you tried once and rejected.

Teams shipping AI tools onto design-system-aware workflows are almost all focused on components. Component docs, component MCP servers, component code-generation. Not enough teams are building the pattern layer. And the pattern layer is what makes AI output feel like your product, not a stranger wearing your logo.

If you care about one thing in the next year of design system work, care about this.

Governance is no longer optional

AI generates confident output at volume, which is kind of its whole thing. Plug it into a well-structured design system, and it’s a superpower. Plug it into an ungoverned folder of markdown with no ownership, no review cadence, no deprecation signals, no currency checks, and it’s confidently wrong at scale, faster than any human can QA.

A markdown repo has no native concept of who authored what, when it was last reviewed, or whether it still reflects current practice. “Deprecated” is a comment someone forgot to remove. “Owned by” is whoever had the contract two years ago. None of that is a problem when the only consumer is a human person who already knows the history. It is a significant problem when the consumer is an AI tool generating production-ready prototypes off the back of it.

Who is accountable for what an AI tells your teams to build? If your answer is “whoever wrote the spec, I think Sarah, but she left”, you have a governance problem dressed as a documentation problem. This is going to become one of the defining questions of the next two years. Not “can we generate UI with AI” (we can, obviously, that’s settled) but “who is responsible when it’s wrong, and how do we know?”

If it only serves developers, it isn’t a design system

The quiet consequence of moving authoritative documentation into dev tooling is that every non-engineering contributor becomes a reader rather than an author. Designers. Content strategists. Accessibility specialists. Brand people. PMs. The moment the source of truth lives in a GitHub repo with a markdown editor, you’ve told all of them that their contributions need to be translated through an engineer to count.

That’s the artifact-without-author problem institutionalized at the tool level.

A design system has to be authored collaboratively, not just consumed collaboratively. The pattern layer I just banged on about cannot be written by engineers alone. It needs content folk writing error messages, accessibility specialists writing constraints, designers writing do-and-don’t guidance, and researchers writing user-intent context. If your tooling makes that hard (if the barrier to contribute is “learn git”), you have not built a design system. You have built a component library with a readme.

A design system is not a repository

A repository is a snapshot, but we all know products evolve. The difference matters because a living design system has to behave like a product: analytics on what’s being consulted, signals on what’s out of date, migration paths from old patterns to new ones, contribution flows that don’t require a PR, visible ownership, a release cadence…

Most DIY systems start as a repo and stay there, and the rot is silent until it isn’t. Six months in, half the pages describe components that have been replaced. The guidance about form validation references a pattern that got rewritten in Q2. Nobody’s noticed because nobody owns noticing. And now your AI is generating prototypes against documentation that is quietly and confidently wrong.

You wouldn’t run your customer-facing product like this. Don’t run the system that produces it like this either.

The honest note on build-versus-buy

Some teams genuinely should build their own. If you’ve got a capable in-house tooling team, a stable roadmap, and a system mature enough that the structure is well understood, then build away. There are orgs doing this well, and they deserve the credit.

For most teams, one or more of those things isn’t true, and the cost shows up later. Split focus within the design system team, because they’re now half a design system team and half a documentation-platform engineering team. Bus-factor risk, because the person who built the bespoke tooling is the only one who fully understands it, and they are statistically leaving within two years. Roadmap competition, because every hour spent on the internal docs platform is an hour not spent on the actual design system.

This is the maths worth doing, honestly, before you write the first markdown file.

What zeroheight is for

I work at zeroheight, so take the commercial angle with whatever grain of salt you’d like. But the argument I’ve just made isn’t about any particular tool. It’s about what a design system has to contain and do in an era where models are the primary consumers of design documentation. It has to carry the pattern layer, as well as the artifact layer. It has to be governed. It has to be authored collaboratively. It has to behave like something more than a snapshot. Whoever provides that, whether it’s zeroheight, a competitor, or a bespoke in-house build, is doing the work that matters.

A design system’s job is to capture the hard work that got you to the final outputs. The journey that prompts the decisions that lead to the artifact. Tokens without decisions are ink without a writer. Claude Design and every tool like it will get better at reading the ink. The advantage goes to the teams who’ve actually written something worth reading.

That’s what we should be aiming for.

“We weren’t choosing between ‘custom integrations’ and ‘nothing.’ We were choosing between fast yeses that scale your pain and a slower yes that scales your impact. Saying no to good ideas was how we chose the system over the request.”

It articulated something fundamental about the hidden cost of saying yes and got me thinking about how this tension plays out specifically in the context of design systems.

A tale of two teams

Most product teams operate in a world of one. They build for themselves, they ship for themselves, and they largely answer to themselves. When something breaks or needs to change, any negative effects are contained. The team feels the consequences of their own decisions and adjusts accordingly. There’s a tight feedback loop between action and outcome.

A design system team, on the other hand, has a very different experience. Because it provides reusable, shared infrastructure to other product teams across the organization, it’s responsible for those dependencies. That responsibility comes with a whole layer of additional activities: governance, training, maintenance, regression testing, support, documentation, and the ongoing obligation to keep everything working as the ecosystem around the design system evolves.

This is the reality of every design system team. And it’s a reality that most of its consumers never fully appreciate — not because the team members don’t care, but because the work is mostly invisible to them. They see the component, not the scaffolding.

The work around the work

When a product team makes a request — for a new component, a new variant, a new pattern, a new feature — they tend to think about the work required to build it. How long will it take? What does the implementation look like? When can we have it? These are perfectly reasonable questions, but they describe only the first and most visible layer of the iceberg.

What they rarely consider is everything that comes after.

There’s a first wave of work that happens before you can even release: the edge case handling, the accessibility audit, the cross-platform testing, and the documentation. This work is substantial on its own, but it’s just the beginning.

Then there’s the work that comes with the release itself. New components don’t ship into a vacuum — they need to be onboarded. Teams need to be trained. They ask questions that reveal the gaps between your documentation and your consumers’ mental models, questions that surface edge cases you hadn’t anticipated.

And then there’s the work that never really ends: governance, maintenance, and support. A bug gets reported. A dependency updates, and something breaks. A new design direction emerges, and the component needs to evolve. Another team has a use case that almost fits but not quite, and now you’re in a conversation about whether to extend the component or help them find another way. Every component you add to the system is a commitment you’re making to every team that depends on it, indefinitely.

This is the work around the work. It doesn’t show up in the estimate and rarely appears in the roadmap. But it accumulates quietly, and over time it becomes the biggest constraint on a design system team’s capacity.

Every yes is an investment

Every decision a design system team makes is an investment. And like any investment, you want to maximize the return. In this case, the return is the impact you have on the products consuming your system.

This reframes the question entirely. When evaluating a new request, the question isn’t just “how long will this take to build?” The real question is: “What is the total cost of supporting this, and is that cost worth the return?”

That calculation includes the time and effort to release, yes. But it also includes the documentation effort. The training and onboarding. The governance model you’ll need to put in place. The support burden. The maintenance overhead over the life of the component. The cost of fixing it when something goes wrong.

When you look at a request through this lens, what seemed like a quick win can reveal itself to be a significant long-term commitment. Not because the request is wrong, or the need isn’t real, but because the full cost was never visible in the first place.

Every no is an opportunity

Many design system teams struggle with saying no. They want to be helpful, and they want their consumers to feel supported. They want to be seen as enablers, not gatekeepers. Saying no can feel like the opposite of all of that.

But what if saying no, done well, could actually strengthen the relationship?

The key is transparency. When you say no, you have an opportunity to make the invisible labor visible. Show them what saying yes would actually mean in practice: the support tickets the design system team handles, the bug fixes, the ongoing maintenance. Share the transcripts from your office hours. Walk them through your support logs. Let them see the care and attention that goes into keeping the system reliable and coherent.

This kind of transparency does two things. First, it helps product teams build empathy for what the design system team is managing. When they understand the full picture, their requests become more considered, and their appreciation for what they’re getting out of the system deepens.

Second, it reframes the no as an act of stewardship rather than rejection. You’re not saying, “We don’t want to help you.” You’re saying, “We are committed to serving you well over the long term, and that commitment requires us to be honest about what we can sustain.” When you’re transparent about the full cost of a yes, saying no becomes less about the present request and more about the long-term health of this partnership. 

“Fast yeses that scale your pain”

There’s a particular kind of yes that feels good in the moment. A consumer has a legitimate need. The request is reasonable. Building it wouldn’t take long. Saying no feels unnecessary, even unkind.

So you say yes. 

And with each yes, you add to a system that is increasingly more complex to maintain. The component inventory grows, the edge cases multiply, the interdependencies deepen. Your team’s capacity gets consumed by maintaining what already exists, leaving less and less room for the work that will actually move the system forward. 

The more you say yes, the slower everything becomes. New requests take longer to evaluate because the system is more complex. Maintenance takes longer because there’s more to maintain. The team spends more time in support mode and less time in build mode. The system starts to feel less like a curated, intentional product and more like an accumulation of decisions made under pressure.

The yes you can afford

The alternative is harder in the short term and considerably better in the long term. It means looking at every request and asking not just whether you can build it, but whether you should, given everything that will come after.

It means being honest with your consumers about what a yes really entails — not to discourage them, but to build shared understanding of the constraints you’re both working within. It means sometimes asking them to wait for a solution that will serve them and everyone else better. It means treating your team’s time and attention as the finite, precious resource they are. And it means being willing to have the hard conversation now so you don’t have to have a much harder conversation later, when the fast yeses finally catch up with you.

It means choosing the system over the request.

This isn’t about saying no for the sake of it. It’s about understanding that a design system’s value comes from its coherence, its reliability, and its long-term sustainability. Every fast yes that compromises those things is a cost paid slowly, across many teams, over a long period of time.

The teams consuming your system deserve a system they can trust. They deserve to know that what they build on top of it today will still work six months from now. They deserve to depend on something that was built with care and maintained with intention. That kind of system doesn’t happen by accident. It happens when the team building it is honest about what it can sustain, shows discipline about what it takes on, and is transparent with its consumers about the reasons why.

The goal is to scale your impact, and that only happens when you’re willing to be candid about the full cost of what you’re building, and what you’re choosing not to build.

We need a better way. Often, the answer lies in what’s already around us. Open source design systems, paired with AI, offer a path to scalable, sustainable solutions by combining community, transparency, and speed. This sets the stage for rethinking how we build for the future.

Open design systems — by using machine-readable elements like tokens and schemas, along with clear documentation — enable streamlined workflows and conserve resources because they leverage existing open components. This consistency across repositories promotes better collaboration, in contrast to closed systems, which tend to create silos. Furthermore, involving the community can help uncover edge cases, thus driving innovation.

Practically, most of us have changed in our roles over the last few years. Transitioning from component creation to prompt crafting marked a significant shift for many: a move from a doer to a manager overseeing the process, with the AI tool now acting as the primary creator. Our systems also need to reflect that change. Recognizing this shift is not just useful, it’s necessary if we want the tools and processes we build to remain relevant.

The growing importance of open design systems

Open source design systems amplify the core benefits of efficiency, consistency, and scalability. Shared ownership spreads maintenance and pools resources, driving faster innovation, greater extensibility, and cost savings. Contributors build on each other’s work rather than duplicating effort, giving you access to a community and skills you may not have in-house, so you can focus on what you build on top.

Sustainability grows when teams share solutions and failures openly, which accelerates collective progress. This is often the bit people miss, sharing back to projects, but it’s critical. Each project made with the system moves it forward through collective knowledge that can be gained.

AI thrives in these open environments because it can learn from public code and documentation. Developers naturally remix and iterate on open code, fueling comfort and speed. AI understands open by default: code is available, people are already vibe coding using these sources.

True open design systems aren’t just collections of files; they are living ecosystems shaped by their communities and evolving through shared discussion and experimentation.

Embracing openness builds robust, adaptable systems and lays the foundation for lasting progress. Let’s look at how this plays out in practice today.

The state of open design systems today

To assess open design systems, I created designsystemdiff.com to analyse 29 systems, 1,285 components, and 27 maintainers so far. A few key challenges quickly surfaced.

• A major issue: 96.6% of systems ignore native HTML elements, favoring custom builds that undermine accessibility and performance. As standards improve, this approach becomes riskier and less effective. This shows the disconnect and delay between their adoption of not just trends but directions front-end development is moving in.

Some other facts from this system are worth calling out, which might not sit with the reality we think we know. 

• As of now, 30.4% have a storybook. This means documentation isn’t as widespread as we hope today. 
• And only 69.6% can be themed, but if a system can’t be themed, it’s limiting.

From a technology perspective, most systems follow current trends:

• 19 use React and 17 have a MIT license. This tracks with how people build today.

Sameness is spreading, too. Everyone is using the same kits and “vibe codes”. This fast remixing speeds delivery but stifles diversity. Even with many options available, most teams still reinvent systems rather than extend or contribute to them.

This leads to many underused systems, wasted effort, and little real progress. To change that, we need to rethink both how and why we build design systems, and how new tools like AI can help.

AI as a practical tool for design systems

AI has moved from buzzword to practical tool, making design systems more efficient, consistent, and sustainable. Human roles have shifted from manual builders to overseers who prompt, review, and refine AI-generated work. This lets us focus on quality and strategy.

AI brings speed, consistency, rapid generation, issue prediction, and automated maintenance to design systems. It multiplies impact when paired with open systems, helping teams evolve and maintain systems efficiently rather than starting from scratch. Still, as AI’s role grows, we need to be mindful of the new risks it entails.

AI can hallucinate files, sameness may creep in, and it’s crucial to choose stable, well-funded projects. Ethical checks for bias and inclusivity remain more important than ever. These challenges call for a change in our approach.

AI won’t solve every problem. However, it can alleviate difficulties. We should view it, like a design system, as a valuable tool. The goal should be to integrate the latest technology with the established practice of design systems.

Rethinking our approach

We need to stop creating new systems for every project. Sustainability must be the goal, with systems adapted and shared across teams. Start by building within existing ecosystems. If you need something new, build on top of existing systems, or make your work open for others. Avoid starting fresh unless absolutely necessary.

Adopt or extend systems gradually, component by component. Transparency and openness should be architectural principles from the start. This mindset produces design systems that are stable, accessible, sustainable, and that can save time on prototyping and reduce maintenance efforts. 

Challenges arise when differences aren’t documented, leading to confusion. Most systems pull components from a source but do not synchronize updates, which results in many products maintaining their own systems while using unstyled component libraries.

This approach leads to systems that last and scale for real teams. As our strategies shift, so do our day-to-day roles and our collaboration style.

Evolving roles in the design system era

The human role is changing from performing repetitive tasks to reviewing, refining, and governing processes. This shift allows for more use of tools and focuses on quality and creative decision-making.

It’s not about replacing skilled workers; it’s about reallocating their time from mechanical tasks to thoughtful refinement. This flexibility opens up new opportunities and improves work-life balance. 

Reviews can now be done on mobile devices, enabling initial assessments while engaging in other activities, which helps avoid extra hours due to tight deadlines. Handovers are giving way to collaborative, iterative reviews and collective stewardship.

AI is fundamentally a tool, much like any other instrument that enhances human capabilities and supports our tasks without replacing us. While we have often been captivated by its more remarkable features, we should prioritize how it can improve our daily lives and measure its effectiveness in specific applications. By keeping this perspective, we can better navigate potential implementation challenges. This understanding will be relevant for a long time.

Looking forward

The future is uncertain; nobody can definitively predict where things are headed, especially given the rapid pace of change over the past years, months, and even days.

However, one fundamental truth remains: Tackling change collectively allows for a much faster response. This collaboration is crucial for addressing modern challenges, whether it’s solving native issues or responding to emerging concerns.

An open approach accelerates the handling of bug reports and technology updates. Furthermore, community innovation yields compounding benefits over time that no single, isolated team can match. While closed systems are increasingly adopting many open characteristics, the inherent openness provides a powerful, sustained incentive for maintaining the system’s viability.

Design systems are more crucial than ever: They are dynamic, evolving projects that require continuous experimentation and iteration to remain effective. We need to prioritize sustainable, open systems as a foundation. Don’t reinvent the wheel. Focus collective energy on enduring, scalable options. Build upon existing open systems rather than starting from scratch. By concentrating our shared efforts on scalable and enduring solutions, we avoid unnecessary work.

Open design systems bridge human creativity and AI capability. They enable rapid innovation and experimentation. In the years ahead, I truly believe the system will be all that matters, not the page. It will be the first thing people ask AI to build. 

If we treat design systems as shared ecosystems, we unlock greater efficiency, creativity, and sustainability. The future belongs to those who build together in the open and are willing to adapt as the landscape evolves. These very systems need to adapt as well, but they do that by being used, receiving contributions, and being actively maintained. 

The teams that embrace this, that resist the pull to start over and instead invest in what already exists, are the ones best placed to lead. What we build together, openly and incrementally, will outlast anything built alone.

These numbers may be dazzling, but there is actually a silver lining here: If you work in tech, you have lots of opportunities to help improve the situation at work. 

In this article, we’ll look at the Web Sustainability Guidelines and how they apply to the components in your design system.

Meet the Web Sustainability Guidelines

Over the past few years, a group at the W3C has been developing the Web Sustainability Guidelines (WSG). The document, currently in draft state, explains how to make more sustainable digital products. It centers on three main principles: Planet, People, and Prosperity. 

Together, those principles ensure that we don’t just consider the environmental aspects of the planet’s sustainability. They also explicitly balance it with what matters to people – including harm reduction and equal access – and focus on the economic factors that shape global development.

The guidelines are organized into four areas, similar to how many companies are structured:

• user experience design,
• web development,
• hosting, infrastructure, and systems,
• business strategy and product management

There is plenty you can do within your design system team to improve the sustainability of your organization’s digital products. Not only does this make a positive impact on the world, it also helps with compliance. As sustainability is increasingly part of required corporate reporting (see Laws & Policies), making it a priority in your design system often also supports organizational goals.

However, when using the Web Sustainability Guidelines, make sure to avoid greenwashing: Only make claims that you have evidence for, and be aware that there will always be gaps in the coverage.

At CSS Day 2025, I talked about how we can all make an impact on sustainability at work using the Web Sustainability Guidelines. 

How your design system can help

Many sustainability improvements in digital products involve things outside the scope of the design system: for example, choosing greener hosting (see the Green Web Foundation’s green hosting check), using batch processing when computing stuff on the server, and applying server-side file compression.

And then there’s a whole range of things that matter on a component level. Design systems can make a real impact here. They are ideal for making sustainability documentation easily available and can show the way via published components that can be reused across products. 

Lastly, a design system is a great tool for minimizing duplication: It standardizes specific approaches, and the decision process for what to add to your design system also makes the overlaps obvious.

Measuring sustainability

It isn’t trivial to measure sustainability because the data needed to calculate impact is often missing. Some necessary data is simply not disclosed by vendors. In other cases, our data is incomplete because so many different factors are at play: the products we build (websites and apps), the devices they are used on (your users’ phones, tablets, and laptops), and the infrastructure that delivers them (data centers and the electrical grid).

At the same time, current research and data (like that from the International Energy Agency) point to plenty of areas for optimization. And where measurement is hard, we can estimate instead. There are also useful proxies: Lowering your data center’s electricity bill will lower your impact as well.

I can recommend these two tools for a first check of how you’re doing: 

• Website Carbon Calculator: rates web pages from A to F, tells you how you compare to others, checks whether your hosting is sustainable, and how much CO2 is produced every time someone visits your page.
• Ecograder: provides a donut chart of your assets, which is great if you want to see where you can improve, as well as a concrete list of tips that you can get started with.

Both are estimate-based, but very useful for your first steps. You can compare your site to competitors and show the results to less technical team members and/or folks motivated to make improvements.

For more exact measurements, there are also tools like the carbon emissions data displayed in Firefox Profiler. 

Green components: 6 practical ideas to start with

So what can you do in components to make them greener?

Click to use

Identify all components that may require a lot of data to be transferred, such as video players, high-resolution photo galleries, or comprehensive maps. 

If the user wants to watch this video or explore a map, great — it may be worth the network hit. But chances are they don’t. Are there ways you could delay the downloading of most data until you are sure the user wants this? A “click to use” button could help here.

Lazy-loaded media

In media-related components, make lazy-loading the default for assets such as images and videos (see the Lazy-loading Success Criterion). For images, browsers support loading=”lazy”. 

Optimized fonts

If using custom fonts, consider reducing their file size by subsetting to just the required variants, axes, and character sets. 

If your design system powers a wide range of products globally, you will likely end up needing larger file sizes. System fonts are ideal in this case, as users have them on their system already. For more on fonts, see Guideline 2.13. 

Necessary dependencies

Maybe your dependencies are all tiny, but most codebases still contain large and unnecessary dependencies. Removing them entirely or replacing them with browser-native functionality can lead to significant reductions in file size across all products that consume your design system.

Carbon-aware design 

Greener energy exists, for instance when it comes from solar panels or windmills instead of coal. But the thing with most green energy sources is that availability varies. There is just one power grid, in which the distribution between green and not-green constantly changes. 

On a sunny and windy day, you can expect a much larger share of green energy, for example. We can design digital products that adapt to this “carbon intensity”. Google already does this for media processing, and Apple has this feature for phone charging. What if the consumers of your components could pass in a carbon number as a property that it adapts to? 

Imagine a video component that is capable of switching to lower resolutions or a team member component that renders a video when intensity is low, a picture when it’s medium, and just the person’s name when it’s high? We can even make components work with our natural rhythms.

To make the implementation of this sort of work easier, you can use the Green Web Foundation’s Grid-Aware Websites toolkit and open-source library. 

Saving your users’ CPU and GPU

Did you know that only 15% of emissions for devices like iPhones come from their daily use? In contrast, 81% come from their production (see Apple’s Product Environmental Report for iPhone 14). From a design system team’s perspective, this is why extending your users’ device lifetime is one of the most effective optimizations. 

One way to do that is to reduce their CPU and GPU strain. Make sure your components throttle or debounce when they respond to scroll or resize, use requestAnimationFrame, rely on CSS transforms rather than layout properties for animations, and virtualize large lists.

Bringing sustainability into your design system

In this post, we looked at how you can use some of the Web Sustainability Guidelines to build components that can make your digital products greener. By adding thoughtful changes to your components – from font optimizations to carbon-aware design – you too can encourage carbon reductions from within your design system. 

A design system is a great starting point for teams to create better products in many aspects. It’s about time we add sustainability considerations to that mix. 

A quick note on the numbers: Emissions from aviation are about 2.5% (according to Our world in data). Estimates for IT range from 0.35% (European Commission) to 3.7% (French think tank The Shift Project). The figures vary wildly for various reasons, for example it depends on how each source defines “IT” and which emissions they include.

When this happens, the first instinct is to blame the tools, the documentation, the quality of the components, or some other artifact of the system. Maybe the library isn’t flexible enough. Maybe it’s too flexible. Maybe the tokens are outdated. Maybe the guidelines aren’t clear.

In reality, these issues are rarely the root cause. More often, design systems struggle because of how they are led.

Design systems are organizational systems, not just digital artifacts. They are influenced by how work is funded, how success is measured, how decisions are made, and how conflicts are resolved. Over time, leadership choices determine whether a system becomes critical infrastructure or optional overhead.

When a system is treated as infrastructure, teams assume it’s the default starting point. It shapes roadmaps, influences architectural decisions, and appears in strategic planning. When it’s treated as overhead, it becomes something teams consult after decisions are already made, if at all.

The misconception: If we build it well, teams will use it

Many organizations approach design systems like traditional product design efforts. If the components are well designed, the documentation is thorough, and the tooling is solid, adoption should flow naturally.

In practice, this rarely happens.

Product teams operate under constant delivery pressure. Roadmaps are tight. Deadlines are visible. System health is not. When teams have to choose between shipping on time and aligning perfectly with a system, speed usually wins.

Leadership often underestimates design systems because their impact is distributed and long-term. A feature launch is visible. A system decision is not. The benefits of consistency compound quietly over time, while the cost of inconsistency is absorbed across teams.

Without leadership actively reinforcing the value of the system, it becomes something teams use when it’s convenient, not when it’s difficult. There is rarely a single moment where leadership is forced to intervene. Fragmentation happens gradually, spread across teams and roadmaps. By the time the cost becomes obvious, it’s already embedded in workflows and culture.

Failure mode #1: Unclear ownership and accountability

One of the most common leadership failures is unclear ownership. In many organizations, design systems are “owned by everyone,” which usually means they are owned by no one.

Valuable updates are slowed due to resource bottlenecks. Decisions are derailed by organization-wide bikeshedding. The system gradually biases itself toward the teams that contribute most frequently, rather than toward what the organization actually needs.

I have seen this play out in environments where a system went unstaffed for long periods. Design updates were handled by designers embedded in product teams, each optimizing for their own immediate needs. Component designs of varying fidelity and quality were handed off to platform engineers juggling unpredictable system updates alongside a litany of other priorities.

Without a dedicated owner, the system stopped functioning as shared infrastructure and instead became a collection of disconnected solutions, often weighted toward short-term product strategy. By the time the organization reinvested and formed a dedicated team, people had already learned to work around the system. Trust had eroded. Re-adoption felt optional rather than necessary.

Rebuilding a neglected system is not just a technical exercise. It’s a trust exercise. Teams burned by instability or inconsistency are slow to return. They have built their own safeguards. They have learned that depending on the system carries risk. At that point, rebuilding the system requires more than technical improvements. It requires leaders to clearly signal that the system matters, and to back that signal with consistent decisions and reliability.

You can read a much more in-depth take on the pitfalls of federated design systems in this excellent post from Nathan Curtis, but the point is that ownership is not just about who builds components. It’s about who has the authority to make decisions, resolve conflicts, and set priorities. Without that clarity, systems drift.

Failure mode #2: Misaligned incentives

Even when ownership is clear, misaligned incentives can undermine adoption.

Product teams are rewarded for shipping features, hitting milestones, and driving business outcomes. Design systems are rewarded for stability, reuse, and long-term consistency. When these incentives conflict, the system loses.

In many organizations, design systems implicitly compete with product delivery. When timelines slip, system alignment is often the first compromise. This is not because teams don’t value consistency, but because leadership hasn’t made system health part of what “success” means. When speed is rewarded, and reuse is invisible, teams will always optimize for speed.

In large platform organizations, central systems often serve multiple “child” products. Teams adopt selectively. They pull from the system when it helps them move faster, and bypass it when it slows them down.

From their perspective, this behavior is rational. They are responding to how success is measured: shipping and velocity. Maybe they will contribute their new work back to the system when they have time. Maybe they will not. Once that code is deployed, it becomes another dependency for others to navigate. Over time, these local exceptions accumulate into what is effectively “system debt”. This is work that future teams must navigate, reverse, or rebuild.

Without leadership aligning incentives for system adoption and adherence, consistency becomes a personal choice rather than an organizational priority.

Failure mode #3: Weak or inconsistent sponsorship

Many organizations assume that funding a design system is the same as supporting it. It is not.

I have seen systems re-funded after periods of serious neglect, with dedicated teams and modern tooling, but little visible leadership backing. Teams were encouraged to use the system, but not required to do so. Exceptions were tolerated. Tradeoffs were avoided.

Design system designers were frequently pulled into short-term concept work for executive presentations or reassigned to support other teams. This sent a clear message: The system was support work, not strategic work.

As a result, the system remained one option among many, rather than becoming the delivery accelerator and experience unifier it was promised to be.

Leaders don’t communicate priorities only through speeches or slide decks. They communicate them through resource allocation. When system teams are consistently deprioritized, teams notice. When exceptions go unchallenged, teams adapt. When tradeoffs are avoided, fragmentation accelerates.

True sponsorship means more than approving headcount and budgets for design system tooling. It means advocating for the system when priorities conflict, reinforcing expectations for adoption, creating space for contribution, and protecting system work when pressure increases.

Without that support, even well-resourced systems struggle to become defaults.

What effective design system leadership looks like

Successful, sustainable design systems are rarely the result of perfect execution. More often, they are the result of consistent leadership.

Effective leaders create clear ownership, align incentives, and actively sponsor system work. More importantly, they treat the system as infrastructure, not a side project. They don’t just maintain libraries. They shape behavior. They clarify decision rights. They define contribution models. They invest in enablement. They set expectations for adoption and reinforce them consistently. They make it easy for teams to do the right thing. And they intervene early when misalignment appears. 

They also accept that systems require tradeoffs. Not every product request should become a system addition. Not every exception should be absorbed. Discipline is part of sustainability.

That doesn’t mean enforcing rigid control. It means creating stable conditions where teams can trust the system and build on it. Healthy systems prioritize clarity over consensus, long-term value over short-term wins, and consistency over novelty. They evolve, but they do so deliberately.

Build the conditions, not just the components

When design systems struggle, it’s tempting to look for technical fixes. Something new: new components, new tools, new libraries, new documentation. These can help, but they rarely solve the core problem.

Design systems succeed when leaders build the conditions that allow them to thrive: Ownership is clear, incentives are aligned, and sponsorship is consistent. Under these conditions, systems tend to stabilize and scale.

Without those foundations, even the best-designed systems will stall. With them, systems become true multipliers — accelerating teams, strengthening brands, and enabling organizations scale with confidence.

• “Can we add this new component urgently?”
• “We need to fix adoption. Nobody is using the system.”
• “This executive wants the UI to feel more premium.”
• “Engineering says this migration will take months.”

Everyone is right. Everyone has a point. And somehow, it’s your job to decide what actually gets done.

This is where prioritization becomes less about managing tasks and more about managing trade-offs.

One of the most useful frameworks I’ve found for navigating this is balancing three lenses: feasibility, desirability, and viability. It sounds simple, but when used intentionally, it brings clarity to what can otherwise feel like a very loud room full of competing priorities.

Let’s break it down.

Desirability: Does this solve a real problem?

Desirability is about people. Does this work actually improve the experience for customers or the teams building the product?

This is often the most important lens, and also the easiest to lose sight of.

Design systems exist to create better, more consistent, more accessible experiences. But it’s easy to get pulled into work that feels productive without actually delivering meaningful value. Polishing something nobody uses. Building components nobody asked for. Or optimizing edge cases while core flows remain inconsistent.

A good question to ask is simply: Who benefits from this, and how much?

Sometimes the answer is obvious. Fixing a broken component used across critical workflows is high desirability. Improving accessibility compliance is high desirability. Removing friction that slows teams down is high desirability.

Sometimes it’s less obvious. A stakeholder may request something that feels important, but when you look closer, the impact is narrow.

This doesn’t mean you ignore those requests. It means you understand them in context.

Desirability keeps you anchored in customer value. It prevents your design system from becoming a museum of beautifully crafted components nobody needs.

Feasibility: Can we realistically deliver this?

Feasibility is about effort, complexity, and technical reality.

Some ideas sound great until engineering gets involved. What looks like a small tweak can turn into a deep refactor touching dozens of areas. What feels like a quick win may require migrations, versioning, and careful rollout planning.

This is where close collaboration with engineering is essential. Design systems are infrastructure. Changes ripple outward.

Understanding feasibility early helps you avoid accidental landmines.

It also helps you sequence work intelligently. Sometimes the right decision is not “yes” or “no,” but “not yet.”

You might need to lay the groundwork first. Improve token architecture. Clean up legacy patterns. Strengthen documentation. These investments may feel less exciting, but they unlock future progress.

Feasibility is what keeps your roadmap grounded in reality.

Viability: Does this make sense for the business?

Viability connects design system work to business outcomes.

This is often the hardest lens to articulate, but it’s essential.

Viability asks questions like:

• Does this reduce engineering effort?
• Does this accelerate product delivery?
• Does this support upcoming company initiatives?
• Does this reduce risk or operational overhead?

Design systems are sometimes perceived as a design concern. In reality, they are a business accelerator.

When you frame work in terms of viability, conversations change. Instead of asking, “Do we have time for this?” stakeholders start asking, “Can we afford not to do this?”

Viability helps design systems earn their seat at the strategic table.

Trade-offs are the job

Here’s the truth: you will never have enough time or resources to do everything.

Prioritization is not about finding the perfect answer. It’s about making informed trade-offs.

Sometimes you prioritize feasibility. A quick win builds momentum and trust.

Sometimes you prioritize desirability. A high-impact improvement delivers meaningful value.

Sometimes you prioritize viability. A foundational investment unlocks future growth.

The key is being intentional about those decisions.

When teams don’t explicitly balance these lenses, prioritization becomes reactive. Work gets driven by urgency, volume, or hierarchy rather than value.

That’s how design systems slowly drift off course.

Fires will always exist

There will always be fires.

A broken component. A production issue. A critical accessibility gap.

These deserve immediate attention. Reliability is the foundation of trust.

But if you only ever fight fires, you never move forward.

Design system teams need space to work on longer-term, strategic investments alongside urgent fixes.

This might mean improving token structure. Simplifying component APIs. Investing in documentation. Increasing adoption across teams.

These projects often don’t feel urgent. But they are essential. They reduce future fires. They improve system health. They enable scale.

Think of it like maintaining a city. You fix potholes, but you also invest in better roads.

Transparency builds trust

One of the most important things you can do as a design system PM is explain why you prioritized work the way you did.

Not just what you are doing, but why.

When teams understand the reasoning behind decisions, they are far more likely to support them.

This is especially important when you can’t say yes to every request.

If a team understands that you’re prioritizing foundational improvements that will benefit everyone, they’ll be far more patient.

If stakeholders see how desirability, feasibility, and viability shape decisions, prioritization stops feeling arbitrary.

It starts feeling intentional.

Transparency turns prioritization from a black box into a shared process.

Customer value is the north star

Stakeholders will always have requests. Some will be urgent. Some will be important. Some will be loud.

Your job is not to ignore stakeholders. Your job is to translate their needs into decisions that serve the broader system.

This is where the desirability, feasibility, and viability framework becomes powerful. It gives you a shared language to navigate complexity.

You can say:

• “This is highly desirable, but currently low feasibility. We need groundwork first.”

Or:

• “This is feasible and desirable, but viability is limited right now. Let’s revisit when it aligns with upcoming initiatives.”

Or:

• “This is viable and feasible, but desirability is low. The impact on users is minimal.”

These conversations become clearer, calmer, and more productive.

And most importantly, they keep customer value at the center.

Progress, not perfection

Design systems evolve continuously. Prioritization is not a one-time decision. It’s an ongoing practice.

Some decisions will be right. Some will need adjustment.

That’s normal.

What matters is having a clear framework, communicating openly, and consistently aligning work with meaningful outcomes.

When you balance feasibility, desirability, and viability intentionally, prioritization stops feeling like guesswork.

It becomes a strategy.

And that’s when your design system shifts from being a collection of components to becoming a true platform for scale.

• screen readers
• keyboards, switch controls, and trackpads
• screen magnification and font resizing
• dark mode
• voice command software

Other users benefit from inclusive design choices that help them perceive and operate the experience: strong color contrast for text, links, icons, and buttons; plain-language labels and instructions; auto-complete form fields; and a clean, simple layout.  

It’s essential to annotate the code and layout specifications for tech compatibility, and the content and color specs for perceivability and operability. That’s accessibility: You’re enabling full access to technologies that people use every day. You remove barriers and build usable components and patterns that work for the widest possible audience. 

Geri Reid wrote an excellent article on how to annotate design system components for accessibility, with examples that teams can cut and paste directly into their documentation.

This piece now takes things a step further. I outline five built-in zeroheight features you can use to create effective ways to annotate for accessibility and inclusive design within your design system.

The annotation format matters

Recently, I served as the accessibility subject-matter expert on the design system team at the Bank of Montreal (BMO), where I used zeroheight to guide the efforts of UX designers, content designers, and developers across 15+ teams within the organization. 

When adding accessibility annotations to our design system, I asked myself:

• How can the design system raise the current accessibility maturity level? (Hint: It varied greatly, from non-existent to active advocacy.)
• How do people learn and adopt new knowledge to apply to their work every day? 
• Which formats were being used for general design annotations and specs?
• How can I ensure accessibility annotations get the same attention and adoption as general design requirements?

I decided to match the formats teams already used. Accessibility and inclusion aren’t separate considerations or afterthoughts — they are digital design. Wherever the design specs lived, that’s where my annotations belonged, too.

The approach

I wanted accessibility guidance to be more than just a bullet list at the bottom of a component page, or completely separate “accessibility information” buried in our Foundations section that designers visited once during the onboarding process and rarely returned to. I wanted accessibility guidance to be fresh, fun, informative, and practical. 

So I wove WCAG legal requirements, best practices, how-to examples, and assistive technology demos into the Core design system structure.  

After all, it’s the source of truth. 

The principles

I applied these principles to make the accessibility annotations effective.

• Inclusive design: Accessibility is part of user experience design. It’s someone’s real experience out there, one you may still be learning about, so explain how to design for real people and real needs.  
• Association: Make annotations visible and put them in the same format as general requirements, so teams give them the same value and priority. 
• Demos: Include a demo of the product or component that shows people with disabilities using it, especially with assistive tech. Let users’ words and feedback drive the guidance. 
• Trust: Make the design system a trusted, go-to resource for accessibility and inclusive design across all departments, including minimum legal requirements. 
• Community: Back the annotations in the design system with weekly “office hours”, so designers can share knowledge and safely ask, “Is my design accessible?” or “How does this design work for a blind person?” 
• Full picture: Present accessibility annotations in design specs for a component, but also log test results against legal standards like WCAG 2.2. 

The formats

In this section, I share the zeroheight features I used to format my annotations. Also, the content formats I chose, and the placement of accessibility information in important areas of the design system.   

Rules – dos and don’ts

Each component page in our design system has a set of tabs for design, development, and content specifications. 

Each tab contains the anatomy of the component (embedded from Figma) with layout specs, color and font palettes, and zeroheight’s Rules block feature with clear dos and don’ts: short, concise text and a visual example (e.g., Figma embed or screenshot). 

For all three tabs — Design, Develop, and Content — I added an “Accessibility Dos and Don’ts” section immediately below the general specifications. 

For the Design and Content tabs, I created “good” instructions, with the same concise text and visual example, embedded from Figma. This “do” gave a clear action for designers.

Here’s an example of the Design rules:

Do: Ensure color contrast ratio between button and page background is at least 3:1.

Do: Ensure color contrast between button background and text is at least 4.5:1 and 3:1 for larger text. 

The “don’t” contained the “why” and how it impacts the user:

Don’t: Don’t design background contrast too low for users to operate.

Don’t: Don’t design color contrast too low for users to read.

And here’s a Content rules example:

Do: Use clear, action-oriented language that describes exactly what will happen when it’s selected. 

Don’t: Don’t use vague language. Screen reader users rely on the label for the button’s purpose or action.

Do: Keep labels short and scannable to quickly understand meaning. 

Don’t: Don’t write vague, inconcise labels that confuse all users including those with cognitive needs.  

I created corresponding “bad” visual examples, either in Figma or a graphics editor (Photoshop, Microsoft Paint). Many times, the color contrast was terrible and the layout completely askew, unusable for people using a screen reader and keyboard.  

It worked. The feedback from my design system team and designers was that visual examples of poor accessibility are effective. They stand out clearly as “what not to do”. 

On the Development tab, the “dos” contain a screenshot of the correct code, and in the same way, the “don’ts” reiterate the “why” and the importance of compatibility with relevant assistive tech. 

Accessibility tab for components

I used zeroheight’s tabs feature to create a separate Accessibility tab to the set, alongside Design, Develop, Content, and the change log. 

If visitors failed to land on the other tabs and went to the Accessibility tab first, this was a way to capture their attention and give them a practical overview.  

Assistive technology demos

In the Accessibility tab, I created a User Demos section and used zeroheight’s video embed feature to add one- or two-minute video clips of a user with disabilities demonstrating how the component is operated with assistive technology (screen reader, keyboard navigation, screen magnification, dark mode, etc.).  

BMO partnered with Fable, a community of people with disabilities who test digital products for companies. I curated a video clip library in SharePoint from their user research sessions over the last three years. Then, I embedded videos directly in the Accessibility tab.   

This placed real feedback and applicable guidance from users with disabilities in front of UX and content designers, as well as developers. Otherwise, this high-impact, high-value content would not have reached them. I was no longer the sole proxy for their voices. Why not learn directly from users?

Each clip included a short summary of design takeaways, translating what teams observed into concrete actions they could take.

Here is an example using a JAWS screen reader demo from Knowbility:

I summarized the key takeaways in the video:

• Use a clear, descriptive label that communicates the button’s action.
• Ensure the button is coded using native <button> elements or appropriate ARIA roles.
• Make the button fully operable using the keyboard (Tab to focus, Enter/Space to activate).
• Provide a visible focus indicator so keyboard users can see when the button is active.
• Avoid using icons alone; include accessible text or an accessible name for screen readers.

WCAG 2.2 test log

Part of my role was to test design system components and patterns for compliance with WCAG 2.2 on desktop, tablet, and mobile. I used zeroheight’s table feature to list all relevant WCAG success criteria as a series of statements, their numbers (e.g., 1.1.1), and the pass or fail results for each check (i.e., meets Y/N). 

Resource links

I used zeroheight’s Links feature to point design system visitors to:

• People’s needs: W3C Web Perspectives videos and Diverse Abilities and Barriers 
• Requirements: WCAG 2.2 Understanding Docs
• Specs: Links to the dos and don’ts in the Design, Develop, and Content tabs

In the example below, these are W3C Web Accessibility Perspectives videos on people’s needs regarding buttons and how to meet WCAG compliance.

Accessibility in the Foundations section 

Color palette

In the Foundation section of the design system, the designers on our team took responsibility for ensuring that all colors in the brand color palette are contrast-sufficient and WCAG-compliant.   

They used a color contrast checker in Figma, tested various combinations, wrote accessibility guidance, and essentially, delivered a trustworthy, accessible color palette resource.   

The team listed the contrast ratio and WCAG level for quick reference:

Based on those color choices, I created an Accessibility Dos and Don’ts ruleset for digital and printed graphs, charts, and data visualizations.

Design system accessibility support

In the Introduction section, I placed our “manifest”, which outlines the support role of accessibility subject matter experts and the system itself in educating and improving accessibility adoption, knowledge, and ownership. 

Support included:

• Being available any time to answer questions
• Holding weekly “Design” office hour meetings to get guidance and validation from experts that they’re on the right track 
• A consultation strategy for small, medium, and large projects
• Encouraging designers to run co-design sessions with people with disabilities (Fable or in-house). 

How accessibility annotations change outcomes

At BMO, I identified ways to embed accessibility documentation into the design system, so it clearly shows how people with disabilities interact with components and patterns. I followed the principles of association, demonstration, trust, and community-building to ensure inclusive design practices were an irreversible part of the source of truth.  

I recommend using existing zeroheight features and effective formats — such as video clips, color palettes, and visual samples — to make annotations easy to find and use.

So do annotations and baking in accessibility early actually make a difference to the way teams work and the products they build? Yes! The evidence is clear:

• The cost to fix an error found after product release is four to five times that of one uncovered during design and up to 100 times that of one identified in the maintenance phase (according to the highly regarded report from the Systems Sciences Institute at IBM on defect prevention cited by iSixSigma).
• Introducing accessibility earlier in the process helped save the BBC design system team from a potentially time-consuming, stressful, and messy refactor much closer to a deadline (see Sophie Beaumont’s blog post). 
• GitHub realized that nearly half of their accessibility audit issues could have been prevented if design intent had been better documented upfront by integrating WCAG considerations directly into annotations. So they built and open-sourced an annotation toolkit to level up design-to-code collaboration, improving communication between designers and developers and reducing guesswork about implementation.

And accessibility guidance is in high demand: A 2023 survey of software professionals from Cornell University found that about 70% of designers and developers want accessibility training materials, workshops, and bootcamps, indicating a strong appetite for accessibility skill growth.

I’m still excited by how enthusiastically designers at BMO adopted and applied accessible practices — and zeroheight’s annotation features made that possible. 

Resources

Creating and managing accessible design systems — Karen Hawkins

Are design systems the key to sustained disability? — David Cox

Accessible design systems with Karen Hawkins — UXPodcast

Accessibility Annotation Kit for Figma — Indeed Design

BBC Global Experience Language (GEL) — BBC

Connect with Jennifer on LinkedIn and check out her company, Journey Accessibility, which provides a strategic planning program, role-based workshops, and co-design sessions with people with disabilities.

Let’s get to know him a little better:

What do you do at zeroheight?

I’m a Product Engineer 🧑‍💻 currently working on the editing experience, making sure it’s easy for users to build and maintain their design system docs with as little friction as possible.

What’s your favourite thing about working at zeroheight?

I love working with people who want to leave things better than they found them. No-one sidesteps something because “it’s not my job”, instead people just get it done.

How would you describe zeroheight in three words?

Supportive, trusting & fun 😊

What’s your favourite company tradition or perk?

Off-sites! As a fully remote company, it’s great to meet everyone in person every few months and get to know each other in a fun, relaxed setting (without having to do corporate trust falls).

What made you want to join the company?

zeroheight’s values were a big sell for me. Seeing a company that genuinely understands that a person does their best work when they’re happy, instead of values focused on a ‘high performance culture’ or pure profit metrics, stood out. And paradoxically, that company mindset ends up producing exactly the kind of performance and results that matter.

Dream holiday destination?

Japan. I just want to use the vending machines.

One thing you can’t work without?

A good instrumental Spotify playlist – it’s basically a focus switch for my brain

Favourite film or TV comfort watch?

Perfect Days (2023). I almost never re-watch films, but I watched this three times last year.

Quick fire round 🔥​

Tea or coffee? Tea (and preferably Yorkshire Tea)

Early starter or late finisher? Late finisher – as much as I wish I could start early!

Podcast or Music? Music – everything’s easier with the right playlist

Early bird or night owl? Early bird by force, night owl by nature

Remote work or office buzz? Remote work – I love the flexibility of working from anywhere

Cats or dogs? Dogs – I’ve never had a cat, but I’m warming to them

Winter or summer? Summer forever! Winter is sad and boring

Sweet or salty? Sweet – as much as I’m a health nut, I can’t resist a sweet treat

Email or slack? Slack – though I think I’m addicted to checking my emails too

Off the back of the data gathered from the Design Systems Report, we wanted to do a deeper dive into the use of AI in design systems and really get to the bottom of where we’re at. As a result, we’ve pulled together a survey for folks in the design system space, and we’d love it if folks could take 15 minutes to fill it in.

It will be open until the 14th April, 2026, and after we’ve recieved the responses we’re going to crunch the data, and put it all into a ‘state of AI in design systems’ report, along with a whole bunch of chapters on how folks are currently using AI in their design systems, the lessons and the unlocks that they’ve found. This will be coming out in late April or early May.

But first, fill in the survey!

Thanks folks,

Luke and the zeroheight advocacy team.

And in the 2026 edition, one thing is clear:

Design systems are no longer emerging. They’re expected.

But expectation changes the game. It raises the bar and exposes the gaps.

This year’s findings don’t point to a discipline that’s struggling to get started. They point to one that’s grown up… and is now wrestling with how to sustain itself. From resourcing constraints to stalled adoption, from AI experimentation to automation gaps, this is the reality design systems teams are operating in today.

Let’s unpack it.

Design systems have matured. Stability hasn’t.

The data makes it clear: design systems are no longer new.

Over half of the systems in this year’s report are more than three years old, with the largest group sitting in the 3–5 year range. Only a small minority are less than a year old. The days of “we’re building our first system” are, for the most part, behind us.

What’s replaced them is something more complicated.

Teams are now maintaining and evolving systems that were often built under very different conditions—different org structures, different tooling, different expectations. And that shift is showing.

Because while systems are aging, they’re not necessarily stabilising.

Only 8% of teams describe their systems as very stable. At the same time, nearly half report instability to some degree. That’s a striking gap. It suggests that maturity alone isn’t enough. Time doesn’t automatically make a system better—it just makes its problems harder to ignore.

Most teams are now operating in the “messy middle” caught between early momentum and long-term sustainability, trying to scale something that was never designed to operate at this level.

The biggest constraint isn’t technology. It’s people.

If there’s one theme that runs through this year’s report, it’s this: design systems are under-resourced.

Teams are small, often surprisingly so. The vast majority have fewer than 10 people, and more than half have fewer than five. The median team size is just four.

On its own, that might not sound unusual. But context changes everything.

Those four people aren’t working in isolation. They’re supporting entire product organisations. On average, there is just one design system team member for every 126 designers and engineers. That’s not a small gap, it’s a structural imbalance.

And teams feel it.

A clear majority say they don’t have enough people to meet their goals. Only a small fraction strongly believe they do. This lack of resourcing isn’t a background issue, it’s the number one challenge teams report, by a significant margin.

What’s more, it’s not just about headcount. It’s about coverage.

Many teams are missing key roles entirely. Product management is absent in more than half of teams. Responsibilities like accessibility, content, governance, and community building are often distributed across whoever has the capacity, which usually means they’re underdeveloped or inconsistent.

The result is a system that relies on a small group of people to do an increasingly large and complex job. And over time, that’s not sustainable.

Adoption is stuck. But not for the reasons you might expect.

Adoption has been a persistent challenge for years, and in 2026, that hasn’t changed, but the story behind it has.

On the surface, adoption levels are middling. Many teams report moderate uptake, while a significant portion still see minimal or no adoption.

But trust tells a different story.

An overwhelming majority of respondents report moderate to high trust in their design system. Very few say trust is low. Which creates a tension that’s hard to ignore: people believe in the system, but they’re not consistently using it.

That’s a critical distinction. Because it suggests the problem isn’t quality. It’s not that systems are broken or unusable. It’s that something else is getting in the way.

When we look at what drives adoption, the pattern becomes clearer. Systems gain traction when they are genuinely useful—when components are complete and solve real problems. But usefulness alone isn’t enough. Communication, community, and company mandate all play a major role.

And when adoption is low, the biggest reason isn’t poor design or bad documentation. It’s the absence of organisational support. A lack of mandate. Weak governance.

In other words, adoption isn’t just a product problem. It’s an organisational one.

Communication and community are still treated as optional

Despite being one of the strongest drivers of adoption, communication remains one of the most underinvested areas in design systems.

Nearly half of teams report having no dedicated focus on community building at all. For many others, it’s a shared responsibility—spread thinly across team members who already have full workloads. Very few teams have it formally owned, and almost none have a dedicated resource.

That lack of ownership shows up in the experience.

Only a minority of respondents are satisfied with how changes to the design system are communicated. Most are either neutral or dissatisfied suggesting that communication is happening, but not effectively.

And this matters more than it might seem.

Design systems don’t succeed on structure alone. They rely on shared understanding, ongoing engagement, and a sense of participation. Without that, even a well-built system can struggle to gain traction.

Buy-in is getting harder and harder to prove

Another notable shift this year is the growing difficulty teams are having in securing stakeholder buy-in.

Dissatisfaction has increased significantly year over year, pointing to a broader issue: teams are finding it harder to justify the value of their work.

Part of that comes down to measurement.

While some teams are tracking adoption or usage, a notable portion aren’t tracking anything at all. Even fewer are measuring ROI. Which creates a fundamental problem—if you can’t clearly demonstrate value, it becomes much harder to secure investment.

And without investment, the resourcing challenges persist.

It’s a cycle that’s difficult to break: limited measurement leads to limited buy-in, which leads to limited resources, which in turn limits impact.

Collaboration is improving. The outputs aren’t keeping up

There is, however, a clear bright spot.

A strong majority of teams report that design systems have improved collaboration between design and development. That’s a meaningful signal. It shows that, at a human level, systems are doing what they were intended to do: bringing teams closer together and aligning how they work.

But that alignment doesn’t always translate into the work itself.

Consistency across design, code, and documentation remains a challenge. Only a small percentage of teams report full alignment, while many still deal with mismatches.

So while collaboration has improved, the system’s outputs are still catching up. The way teams work together has evolved faster than the systems they rely on.

AI is here but the reality is more measured than the hype

AI has quickly become part of the design systems conversation, and adoption is already widespread.

More than half of respondents are using it in some form, often having started within the last year. Very few teams are actively avoiding it.

But sentiment is still cautious.

Some see clear value, particularly in reducing repetitive work and speeding up processes like documentation, prototyping, and code scaffolding. Others are less convinced, pointing to concerns around quality, control, and reliability.

For most, the answer is still unclear.

AI isn’t being rejected but it’s not fully trusted either. It’s being explored, tested, and in many cases, kept at arm’s length. Especially in areas like design generation, where precision and consistency are critical.

For now, AI feels less like a transformation and more like an experiment. One with potential, but not yet proven impact.

The bigger opportunity isn’t AI. It’s automation.

Alongside AI, the report highlights something more immediate and arguably more practical: the automation gap. Despite the tools and infrastructure available today, relatively few teams have implemented meaningful automation. Many have no plans to.

This is particularly surprising when you look at areas like design tokens. Adoption is high, but automation of token pipelines is not. Which suggests that teams are still relying on manual processes for work that could be streamlined.

And when teams are asked what they want to automate, the answers aren’t ambitious, they’re practical.

Documentation. Testing. Token syncing.

These aren’t headline innovations. They’re the everyday friction points that slow teams down. Closing this gap doesn’t require new technology. It requires time, knowledge, and investment, things that many teams are currently lacking.

Looking ahead

If the last few years were about building design systems, the next phase is about making them sustainable. The focus is shifting.

Success will depend less on creating new components or expanding tooling, and more on strengthening the foundations: resourcing, communication, governance, and measurement.

Design systems are now a standard part of how products are built. The challenge for 2026 and beyond is making sure they’re supported like it.

Based on insights from the Design Systems Report 2026 survey data. Read the full report here.

Now those explorations are turning into real processes and deliverables. In this article, I pull together three big moves I’m seeing in real time right now:

1. MCPs, skills, and design guidelines
2. Designing with code
3. Shipping patterns via structured relationships

MCPs, skills, and design guidelines

Discovery and education have always been a core pain point for design system teams. Why don’t people just look at the docs? Why do they have to come into the DS Slack channel and ask the most basic questions? Can’t they look at what’s available in Figma? 

While we recognize service as a key part of being on a design system team, there’s always been a nagging sensation that we could do more to help our product designers and engineers understand how to use the system better: up-to-date docs, just-in-time answers to exactly respond to their questions, safeguards, and easy-to-copy patterns.

This is one of the most exciting elements of LLM-supported design systems. It’s also one of the most loosely explored right now.

The messy reality of AI-generated code

If you’ve been using AI to generate code over the last few years, your experience might have gone something like this: An engineer using an LLM-supported editor can prompt the UI they want, maybe even with a Figma file and the Figma MCP turned on. But the generated code has nothing to do with your design system code components. It’s full of sloppy patterns, hex colors, and recreations of components you already have.

When your LLMs have access to your entire codebase, they’ll use anything they find there as a pattern to copy. More importantly, the models aren’t trained on your codebase. They’re trained on publicly available code, which is why Tailwind and ShadCN are so over-represented.

How to guide LLMs toward your design system

MCPs, AGENTS.md files, and agent skills are the way we put guardrails around how LLMs write code for us. (This article is a great breakdown of the difference between skills and MCPs.)

So here’s what your toolkit should consist of:

• MCPs to connect multiple systems, like Figma, zeroheight, Storybook, etc. “Model context protocols” are a universal power adapter that lets various systems talk to each other: Figma nodes to TypeScript props to color tokens to code editors. If you’re a zeroheight customer, their built-in MCP enables this with no extra effort from you. The same applies to many other design system tools and pre-built component libraries (MUI MCP, ShadCN MCP, Storybook MCP, etc). The latest buzz around Figma’s Claude-to-Figma MCP is the beginning of a potential round-trip between design and code.
• Repository-wide code guidelines, e.g. AGENTS.md, including where to find design system code. These live in your codebase and enforce coding norms that should always apply.
• Skills that define specific capabilities. These are written Markdown files that get used by the LLM, if relevant to the task they’ve been prompted to do. Write skills around how your system should be used, company-specific knowledge, or, most excitingly, design guidelines.

Despite the fact that these skill files live primarily in the codebase, the guidelines and skills don’t have to be about code. You might write a skill explaining where to find color tokens and how to use them, but you might also write a skill describing when and how you apply semantic vs brand color in your UI. 

Since the LLMs are trained on generic code and design practices, you’ll find the designs and UIs they generate don’t always make sense for your product. At my company, we help people get screened for cancer early, and we understand their risk; we never use chips with semantic color to show risk status. The LLMs love to drop an error-red “high risk” chip, unless we explicitly tell it otherwise.

Most design system component docs focus on the how: how to use, the difference between a checkbox and a radio, listing the props and variants available. Generating UIs with components means the LLMs need guidance (just like humans) on when and why to make certain design choices. 

I’m not talking about the kinds of choices that replace designers, but the kinds of choices already represented in your system — just not encoded in any way. You can’t encode into a checkbox component’s code that a switch should be used if there’s only one selection. Or the cases where you’d use a “Select all/none” checkbox in addition to the other options. Those choices already exist in your system and your current designs. You can write a skill to define them.

Design guidelines — not just the how but the why of the choices behind your system’s design — are critically important to getting good outcomes from LLMs. These are the new deliverables that a design system needs to ship, alongside the components and docs we’ve been providing. These are what will unlock real change in the way your team uses your design system.

Also see Luke Murphy’s article, How LLMs use MCPs to read your design system and how to write prompts that work with that, and watch this guide on how to connect your design system to ChatGPT and Claude Code using zeroheight’s remote MCP server.

Designing with code is in

Design seems to be divided, at least if you read my LinkedIn feed: Half of us are spending our AI exploration energy on trying to generate code from Figma; the other half are eagerly exploring design-with-code tools.

In my opinion, it will always be more accurate to design a webpage or web app in its original medium — the browser — than trying to generate it from an image. 

Designing on a vector canvas isn’t going anywhere: Imagery, illustrations, hero elements, and branding all still require the freedom of putting pixels anywhere. For a significant portion of design work on web apps, however, the focus is more on user experience and flow than visuals. The ability to use existing components — especially those with complex interactions — and create a new page or feature with them, does not need to be done in a vector program. (And no, designing with hi-fi components may not be the best way to explore early ideas — I’m predicting a return to sketching and boxy wireframes and a focus on outcomes over visuals.)

Design with natural language

One exciting unlock that LLMs offer is that we no longer have to have the “should designers code” argument. You can design, iterate, and adjust using natural language — not code. Prompting definitely isn’t the most efficient way to change from one spacing token to another, but it won’t be long before the design-with-code tools have UIs that directly show us component variations and Figma-style precision editors. And when they do, there’s no reason to build a “fancy screenshot” of your UI when you can just build the real thing.

This isn’t limited to designers, either. Your design system’s internal ROI is about to either skyrocket or plummet, depending on your team’s answer to this question: When your PM or account manager or finance lead creates their own internal tool – or product feature! — can they use your design system? Or do they bypass it? Design-with-code tools right now are mostly on the “bypassing” side of that question. They’re limited to Tailwind or require you to recreate all your components in yet-another-format. 

We’ll see these tools improve by leaps and bounds this year. If your design system can translate between all kinds of tools — engineering IDEs to design-with-code tools to Figma or Penpot — its value to your organization jumps from “useful” to “critical.” 

Shipping patterns via structured relationships

Design guidelines written as skills for LLMs unfortunately take up a lot of context and tokens, which makes them expensive. Code already has an answer: structured data and schemas. Just like in Figma, in code languages like TypeScript, when you define a property of a component, you have to specify if it can be a number, a Boolean, a string of text, or a node (instance swap). When writing code using that definition, you cannot insert a node for a string, or a string for a Boolean.

We can encode a lot more rules and rigidity (even without AI!) into our components than we usually consider possible. We avoid this because it makes components rigid, over-engineered, and difficult to maintain. Rigidity means teams find a workaround if the component doesn’t do exactly what they need. The maintenance burden (and bugs) fall on the system team when we have a component that tries to do too much. 

Schemas or components as data

Patterns have long been a design system bogeyman. They’re built for a specific product purpose, made of multiple smaller components, and often have complex variations that multiply exponentially when you consider the variations of their sub-parts. Consider this Stripe PaymentElement – if this is one “component,” it’s made of six expandable sub-forms, one of which (“More”) might have different behavior; multiple form elements including number and text inputs and dropdowns; and all the associated interactions, tokens, and layouts.

Schemas or “components as data” offer an intriguing solution. What if this PaymentElement is not a single component, per se, but a set of structured relationships that define how to use all the individual atomic components? 

Imagine a PaymentElement file that doesn’t include code but instead includes a structured schema that explicitly describes its relationships and usage?

Describe components by relationships

Murphy Trueman captures this idea in her excellent article, “Your next design system user is an agent,” where she shows the above example for a button. This particular button must be in a “modalContext”, and can only have an optional sibling CancelButton. This creates a clear contract — just like a RESTful API or TypeScript props.

Let’s say you need to build a product onboarding flow. The component library has generic atomic components: Card, Button, InfoPane, Modal. But your LLM assistant has no clue what any of these actually do. The names might hint at visual styling, but they don’t encode purpose or behavior.

Semantic naming and structured relationships provide a whole new level of contextual information and enable agents to compose interfaces that make sense. I don’t think it’s just agents that benefit, either. As Murphy writes, this creates a design system where human and non-human consumers “can make sense of your design system without relying on undocumented conventions or visual inference.”

Taking this one step further, we’re already seeing components and design systems being used to build flexible, multi-turn, interactive UIs. Think Expedia in ChatGPT or A2UI. “It’s building a visual system that can dynamically recompose itself based on infinite conversations.” 

Atomic components are table stakes for systems. These days, product teams get more value out of specific patterns that meet their products’ needs. Schemas that ship alongside components can offer a more flexible way to deliver patterns to our teams. Instead of a massive, rigid, over-engineered code component, we can offer a skill, a prompt, a set of structured relationships, or a template.

Where to start today

AI is finally starting to change what a design system ships. In 2026, design systems need to deliver more than components and static docs. They need MCPs and skills to guide LLMs, runtime-friendly design-with-code flows, and structured schemas that let humans and agents compose meaningful UIs. 

If you’re working on a design system, start by asking: Where do we want the system to enforce behavior, and where do we want to stay flexible? Ship the guidelines that explain the why, add the skills that teach the how, and experiment with schemas that encode relationships.

Want to hear more from Elyse? Check out her On Theme podcast, which explores how successful design systems get built, maintained, and deliver impact for their product teams. And watch Elyse’s Converge 2025 talk, From Promises to Practice: The Future of Design Systems.

We often talk about “hygiene” in codebases, but we rarely apply the same rigor to our design files. However, the benefits of linting extend beyond development into the construction of design systems.

If you work on or maintain a design system, it’s more than likely that you are already linting, albeit manually. Every time you notice a button using a hard-coded hex value instead of a semantic token, you are linting. Every time you modify a padding value by a pixel because you notice it doesn’t adhere to the grid, you are linting. You are identifying small problems and fixing them by hand.

To do this necessary work at scale is tedious, prone to human error, and it represents a poor use of time and effort.

Why you should be linting

Even the most well-laid plans fall apart. In design systems, the most common catalyst is scaling.

Regardless of how well-structured and deliberated a design system may be at the start, it doesn’t always scale smoothly. It can deviate and deteriorate over time. Deadlines, crunch, new team members, additional features, and other variables often outside your control hit hard. Next thing you know, you have people fed up with the design system jumping ship and abandoning it, and the boat begins to sink.

All systems slide toward this entropy, and while we are likely accustomed to employing countermeasures to address it, linting is one of the most valuable.

A well-configured linter can alert you to a range of undesirable factors in a design system. It can help you avoid errors such as invalid values, duplicates, and misspellings. It can also help in the enforcing of conventions, such as specific units, naming patterns, upper and lower limits, and chosen notations.

The benefits don’t stop with hygiene; linting can also improve the accessibility of your design system. Accessibility shouldn’t be an afterthought, so integrating it into the very fundamentals of your design system has a positive knock-on effect. 

There is also a benefit in linting removing ego and pressure from reviews, as automated checks feel less personal than human critique and are accepted more readily.

Crucially, we often treat our documentation platform, like zeroheight, as the single source of truth. But zeroheight can only be as truthful as the data we feed it. If we feed it unlinted, messy design files, we are documenting chaos. And if we ignore the data that comes out or use the wrong data, then we are wasting time and effort. Linting ensures that what we sync to our documentation is accurate, pristine, and ready for consumption.

If we neglect our source of truth, then our design system is as good as useless. As people lose trust in the truth, they start guessing or adopting their own.

Introducing linting into your workflows

Adopting new tools is rarely done lightly or at the flick of a switch. Linting requires effort to adopt. Treat linting as an equivalent to a first step of tests; it ensures that the code and the system itself meets standards before they move down the pipeline.

Regrettably, there’s no “one-size-fits-all” solution. There are many variables at play, from team sizes, structures, experience, ability, and culture to the different tools and technologies used to build products, so the best option depends on your specific situation. You’ll want to look to adopt linting of your design tokens themselves, the items on a visual canvas such as Figma, and the final application of the design system for full coverage.

There are many ways to approach this. You can use Figma’s built-in check designs feature, or a similar plugin like FigmaLint if you don’t have access. You can use ESLint, which is likely already being used by your developers, or Stylelint if you are working with CSS. There are also many accessibility-oriented linters, such as Stark, which can be used in tandem. zeroheight even has token linting built into their MCP offering (coming soon!), if you want to go down an AI route.

Rolling out linting in a mature design system

If you are adopting linting in a mature design system, it can be a daunting task. An initial lint might return an overwhelming number of errors that are unrealistic to address at once and demoralizing to work on. In that case, consider a gradual adoption, and there are a few main approaches you can take to doing so.

You could start on a per-component basis, linting each one as they’re updated. This isolates complexity and presents small wins. Once components are clean, you can expand your scope, first to patterns or modules, then to templates and layouts, and finally to full pages or screens.

You could consider linting only the sections needed for the next handoff, for now, to avoid becoming bogged down by technical debt in currently unused areas. Alternatively, you might start on specific attributes. For example, ensuring all your colors are correct, then units, and finally expanding to address larger issues like layer naming structures.

If you’re in a stage of growth, you might consider adopting linting only on fresh extensions for now. Otherwise, if you’re just starting a design system, you should make an effort to adopt linting as early as possible to bake in best practices from the start and to avoid more effort later. By linting early and often, we’re stopping problems where they start and before they have a chance to snowball throughout the rest of our design system.

None of this is to say that adopting linting should be relegated to an afterthought, merely that it can take time to implement and settle, and that care may need to be taken to avoid killing momentum. It’s an upfront cost that pays for itself in time.

In adopting linting, it’s vital that everyone, from the people constructing the design systems to the people using them, be on board. Configure linting for everyone working in design files, and require linting steps before design files can progress. Encourage linting regularly while working, not just during review. Let linting serve as a first layer of testing in your robust and structured system.

Linting in action

Let’s look at a simple example of linting in action with a card component that has been detached to customize but hasn’t been properly re-linked. It may look fine visually, but the code has raw values. A linter would immediately highlight this mistake, allowing it to be identified and fixed before it causes any issues.

The first place linting could catch an issue is at the design token data level, where the below #ffffff is flagged as a hard-coded value, and our linting instead recommends using {color.base.white}.

{
	"card": {
		"container": {
			"background": {
				"$value": "#ffffff",
				"$type": "color"
			}
		}
	}
}

Otherwise, we might catch it at the design level, like here with the Design Lint Figma plugin:

It could also be caught at the code level, as seen here by running Stylelint on some offending CSS:

.card-detached {
	background-color: #fff;
	padding: 13px;
}

card.css

  2:3  ✖  Raw value. You must use a Design Token.   scale-unlimited/declaration-strict-value

  3:3  ✖  Raw value. You must use a Design Token.   scale-unlimited/declaration-strict-value

✖ 2 problems (2 errors, 0 warnings)

Having linting steps at every stage stops Swiss cheese model-style failures. For an example of a very mature and comprehensive linting setup, you might refer to the ESLint plugin rules for the Atlassian Design System.

Linting: long-term wins for your design system

Designers and developers alike strive for order in the face of mounting complexity and are already familiar with guidelines and structure. Linting is just an extra hand to maintain that order.

Setting up linting is to your long-term benefit and often comes without immediate short-term gain, but that delayed gratification shouldn’t disincentivize adoption. You may spend several hours configuring linter rules and fixing errors now and not directly notice any change, but in the background, linting will keep your efforts on track.

Consider linting as part of your design system hygiene. We keep our teeth clean with toothpaste, we keep our bodies clean with soap, and we can keep our design systems clean with linters. Good hygiene is a kindness to both you now and whoever may have to use your systems in the future — whether that’s a designer being onboarded in a few months or a developer scrambling to meet a deadline.

Let’s talk about something that’s been bugging me for years: disabled states. They’re everywhere. Every design system that I’ve worked on has had them. They’re in all the usual places: buttons, inputs, and menus. They’re there to remind you that the thing you want to do is absolutely not available and you have no idea why. They’re like weeds in a garden. Annoying, persistent, and hard to get rid of.

Let’s unpack my frustration with disabled states.

So, what’s a “disabled state,” anyway?

It’s the state that designers and engineers can use in any interactive element when they don’t want the user to touch it. The easy way, if you don’t want to really think about good UX. The UI control goes gray, the text fades, and everyone in the product feels good about “preventing errors.”

Except for, ahem, a small detail… It’s no longer accessible to everyone.

Components that are disabled use the disabled HTML attribute, which makes them non-interactive. That means they won’t receive any browser events like mouse clicks, taps, or focus-related ones.

But here are my problems with disabled states:

• They are often skipped by screen readers.
• They are not focusable.
• They are often so low contrast that many users can’t even tell they’re there. 
• Users have no idea why they can’t click on that button, which causes a lot of frustration because they don’t know what they are doing wrong. In fact, as a UX designer, sometimes I may understand why a button is disabled, but that’s only because of my experience, and that is not always the case. In reality, most users won’t know. 

“What do you mean, Chela? I can see the gray button, and I know why it’s disabled and how to enable it.” Well, then you, my friend, have perfect vision, you’re not using assistive tech, and you probably designed the damn flow yourself.

Nobody is asking the obvious question:

Why are we still using something that’s literally not accessible?

Like… what’s the point of building “inclusive design systems” if half our components are invisible to some users and cause frustration when they’re disabled? Come on.

Let me explain with a hypothetical scenario so we’re on the same page!

In the example above, the Employee ID is set to a disabled state. While the intention is to prevent unauthorized edits, this choice creates a UX dead end in three very real ways:

• Zero interaction: Once the field is disabled, the user can’t click it, select it, or copy it. Need that ID for an email or another form? Cool, hope you enjoy manually retyping a long string of numbers and praying you don’t mess it up.
  
• Zero context: The UI offers absolutely no explanation for why this field is locked. Is it a permissions issue? Is it permanent? Should the user contact HR? Who knows.
  
• Zero accessibility: If you’re using a screen reader, you may not even know the Employee ID exists at all. And if you have low vision? The washed-out gray text makes the field effectively invisible. It’s there… allegedly.

So yes, we technically “prevented an error.”

But in the process, the disabled state also prevented the user from interacting with their own data.

WCAG stance on disabled elements

WCAG 2.2 doesn’t require disabled elements to meet color contrast. Which is basically saying, “yeah, you can make it unreadable, it’s fine.” So 99% of teams go, “Sweet! Less work, let’s gray them out almost like they are not there!” And I’m sitting here like… how is that accessible to anyone? Why does no one seem to care about this?

If you’re skipping content for some users but not others, that’s called digital segregation with extra steps.

Why are we still doing this?

Because it’s easy. Because every UI kit or design system comes with a “disabled” variant by default. Because someone in 2014 decided gray equals “unavailable”, and we all just nodded along like zombies.

Designers continue to use disabled states not only because they are available on design systems, but also because they are lazy. I know that sounds harsh, but it’s true. Disabling things is often a shortcut, a way to avoid designing a better interaction.

Instead of asking, “How do we teach users what’s happening?” designers just lower the opacity and call it a day. 

“But ‘disabled’ prevents mistakes!” Cool. You know what else prevents mistakes? Context.

If people keep clicking the wrong thing, maybe your design isn’t clear. Maybe you don’t need a disabled button; maybe you need to explain what’s happening.

Okay, less rant, more solutions

Let’s fix this mess. Here are 7 patterns that you can use instead of the disabled HTML attribute, which actually help people.

1. Read-only 

This one never gets enough attention; the disabled state totally stole its spotlight. Many design systems don’t even support read-only because “disabled” became the default lazy pattern, and honestly… many designers don’t even know what a read-only state is.

In one audit I did for a company, 43% of their disabled-state use cases were actually supposed to be read-only. Designers were using disabled states to “gate” actions or “prevent” errors, but in reality, those situations needed read-only. 

Forty-three percent! That’s not a small slip. That’s a system-wide misunderstanding.

Read-only states are amazing. They’re the HTML attribute you put on an input when you want the user not to edit it, but it still stays focusable, hoverable, and copyable. You’re not blocking access; you’re just preventing editing. That’s it. Simple. Beautiful. Perfect. 

In this revised example, the Employee ID uses the read-only attribute instead of being disabled. Tiny semantical change. Massive UX upgrade. And suddenly, everything works the way users expect it to.

Here’s what that unlocks:

• Preserved utility: Text can be highlighted. Unlike a disabled field, a read-only field still lets users click in and copy the value. Alex can now grab their Employee ID without playing the high-stakes game of manual retyping.
  
• Clearer context: Because the field is still interactive, the UI can actually explain itself. A “read-only” label, hover state, a helper text, or a tooltip can tell the user why the value can’t be changed. Permissions, system rules, HR policies, whatever. No more guessing, no more “but… why?”
  
• Full accessibility: Read-only fields stay in the tab order, which means screen readers always announce the field. Users relying on assistive tech get the same information as everyone else, instead of being quietly excluded.

2. Aria-readonly

Why don’t we use read-only for everything? HA! Because the read-only attribute only works on inputs. So remember that 43% I mentioned above? Yep… almost all of those use cases were input fields.

read-only doesn’t work on other elements you might want to lock, like checkboxes.

“But Chela,” you ask, “when would I ever need a read-only checkbox?” Allow me to introduce Alex (again).

Alex is working on the product when they suddenly realize they can’t push their latest code to the live server. They can see their code and review others’ work, but they can’t deploy the code. So naturally, Alex goes to their Employee Profile to check their system access.

These permissions were set by an admin in the system. Alex didn’t choose them, and they can’t change them, but they directly determine what Alex can and can’t do in the product.

This is why visibility matters: If Alex were using a screen reader that skipped over these details, they might never understand what’s happening.

Checkboxes don’t support native read-only, but if you still need to communicate “locked but visible,” you can use aria-readonly. It behaves the same way, just not natively. So the checkboxes are visible. They’re selected. They’re just not editable.

3. Aria-disabled

This one mostly applies to buttons and other UI elements that aren’t form controls. If I could, I honestly wouldn’t support the native disabled HTML attribute at all. I’d just use aria-disabled.

Why? Because with aria-disabled, screen readers still detect the element, it stays focusable and hoverable. Plus, you can add tooltips to inform the user why the field is not clickable.

I am a BIG fan of showing a tooltip or inline message explaining why the user can’t interact with the button and how to enable it. I love it. I love it.

In this case, Alex didn’t fill out the phone number, and they wanted to submit the form. So, instead of letting them guess why they can’t click the button, we are providing them with explicit guidance to set them up for success. 

4. Error validation instead of gating

This one’s an easy win for everyone. Text inputs already come with built-in error states, so use them! Stop disabling the “Submit” button until all fields are filled. Let Alex hit submit, and then tell them what’s missing. Instant feedback beats guessing every time.

Users love that stuff. Giving feedback after an action makes the process faster, clearer, and less frustrating.

5. Display-only mode

Let’s talk about this one. I didn’t invent the concept, but I did make it official. I’ve added this pattern to multiple design systems I’ve worked on because nobody was naming it, and apparently, we needed to.

Teams keep using read-only fields just to show plain text. And like… why? If it’s not a field, it shouldn’t look like a field. If nobody can interact with it, stop putting it in a box with borders, as if you’re trying to fool people.

That’s what display-only is for. It’s just text. Plain text.

In this example, Alex won’t even try to click or edit the Employee ID because it clearly isn’t an input. They can still copy and paste it, but there are no fake inputs, no tab stops, no visual cues misleading them into thinking “Wait… is this a field? Should I be doing something with this?”

Display-only is simply another way to avoid disabled states.

6. Conditional visibility

Here’s a radical idea: Just hide controls that aren’t relevant.

For example, it drives me nuts when I see a “Previous page” button on the first page. You’re not preventing errors; you’re creating frustration and adding noise.

If a control isn’t usable, hide it until it is. Don’t taunt users with grayed-out buttons they can’t press. Same logic for “Next”: If the user is on the last page, hide it. Don’t make them wonder why a next button exists when there’s nowhere to go.

7. Give users info, not dead buttons

How about using other components in the component toolbox to display data that’s already defined by someone else? In this example, the “Job Verification” checkbox wasn’t meant to be edited by Alex, HR already set it. So why give them a dead, disabled checkbox to stare at?

Instead, we turn it into a status badge. Same data, same official meaning, but now it’s actually readable and actionable in the sense that Alex can immediately understand their verified status. The data already exists. Our job is to show it clearly, not gatekeep it behind a disabled control.

I could list a dozen more ways to avoid disabled states, but you get the point: Stop disabling elements, and start communicating. Think about how to show users what’s happening instead of just blocking them.

This isn’t just about accessibility

Yeah, this started as an accessibility rant (hi, it’s me), but it’s bigger than that.

It’s about inclusion, giving everyone the same information, regardless of how they navigate. When we hide controls from certain users, we’re making decisions about who gets to participate. That’s not just bad UX; that’s unethical design.

We’re not designing for edge cases; we’re designing for people.

As a design system designer, I get to influence how every single team designs these states. That’s a huge responsibility. Because when the system gets it right, everyone downstream benefits.

My job isn’t just to clean up Figma files; it’s to build a system that makes good decisions the default. One that says:

“If it’s not accessible, it’s not shipped.”

• We can replace “disabled” with smarter patterns, read-only, display-only, conditional states, and contextual messaging.
• We can update our token structure so disabled colors actually pass contrast, even though we are not required by WCAG, so what? Make it accessible.
• We can document when not to use it.

And maybe, just maybe, we stop supporting disabled states when we create a new design system, so that no designer or engineer slaps the disabled state on a component and calls it a day; they actually need to think about other ways to communicate to the user why something may not be available.

So, are we ready to let “disabled” go?

Because honestly, it’s time. We’ve outgrown it. It’s outdated, misunderstood, and low-key discriminatory.

There are better ways to communicate. Better ways to teach users. Better ways to design.

Let’s stop treating “disabled” like a UX security blanket and start building interfaces that actually talk to people.

The goal isn’t to prevent mistakes, it’s to design clarity. 

The goal isn’t to limit interaction, it’s to empower understanding.

We can do better. We have to do better. Because the next time someone says, “Oh, just disable it,” I’m disabling them.

References

• HTML attribute: disabled – MDN Web Docs
• HTML attribute: readonly – MDN Web Docs
• ARIA: aria-disabled attribute – MDN Web Docs
• ARIA: aria-readonly attribute – MDN Web Docs
• Making Disabled Buttons More Inclusive
• The disabled state in UI design
• Read only VS Disabled
• HTML Disabled vs Readonly: Make Your Forms Better
• Difference between disabled and readonly attribute in HTML
• Web Form Conundrum: disabled or readonly?
• Where are all the read-only radio buttons?
• Accessible design of user interface elements: Radio buttons

This concern isn’t hypothetical. In a recent survey I ran with Ben Callahan on The Question, one respondent put it bluntly:

“My concern is that when leadership sees AI generating UIs, they’ll be so wowed that they’ll simply think there’s no need for a design system or a team to maintain it. They won’t see how the two can complement each other perfectly. They’ll fall into the trap: just seeing dollar signs.“

Yet the same survey revealed something encouraging: The majority of practitioners see AI in design systems as amplifying their work, not replacing it. Documentation, code generation, auditing, and prototyping were the most common uses. Humans are still very much in the loop. The question isn’t whether to use AI to generate a design system – it’s how to use it well.

Design systems are needed more than ever

So why do some managers and executives feel that AI can build applications without a design system in place? 

If I were to give the lazy definition of a design system, I’d reduce it to a dysfunctional situationship of a Figma file and an associated git repo. From that angle, it’s easy to conclude that a machine can create it by rapidly remixing things it has seen before.

This reductionist view, however, does a huge disservice to what a design system actually is. And it’s easy to conflate output with outcome. The serotonin-fueled high that floods the minds of executives when they see a demo of an LLM creating an application sometimes leads to a sinister, secondary thought: Do I even need these troublesome, expensive, fleshy beings in my money-producing machine?

It won’t surprise you that my answer to this question is, of course, YES. Naturally, I’m biased in the respect that a lot of those expensive fleshy beings are also my prized friends and colleagues. But I have a more objective reason for this, too, and it’s often overlooked when we focus on output alone.

What’s more important about a design system isn’t the visuals or the code that accompanies it: It’s the series of decisions people have painstakingly made through discussion, argument, and sometimes tears.

That’s one of the primary reasons why I believe that we shouldn’t just generate documentation from code. It misses so much context. It’s much better for a human being who has been through the trials and tribulations to explain not just the how but the why inside those sacred documents.

These decisions, however, have always come at a great cost in terms of implementation. Creating code is an expensive pastime, and once a team decides to do something in a particular way, changing course later usually requires meetings, cost estimates, and pain.

LLMs are a step forward in innovation because they really speed up how fast we can crank out stuff. That quick output means we can get fast results to use or ditch.

What is our target output?

Let’s set the frame about what we’re actually talking about when we say “AI-generated design systems”.

This isn’t a definitive list, but here are the components I think materially make up a design system’s output:

Documentation

• Storybook
• zeroheight
• Codebase documentation
• Architectural decision records

Code

• Front of the front-end code
• Tokens

Design

• Component-level designs
• Recipes

Also see What does a design system include?. 

Which of these do we want our unfeeling robot overlords to accelerate? The first thing I tried to automate, unsurprisingly, was code generation. 

Generating web components with AI

Way back in late 2023, I was working with a major U.S. financial market operator, and I promised that – even when LLMs were still somewhat in their infancy – I could generate our component code. 

The thing I struggled with was that back then, people were writing huge prompts to try to shepherd these unwieldy models into giving us an output that was acceptable and coherent. I never found that to work particularly well with the way that my mind thinks as an engineer. I like direct, succinct instructions, and I like my robots to be the same.

The challenge here was to deliver the context of what the component is, how it works, and how it interfaces with other components in the system. 

My solution for this was to create a YML-based specification describing how a component works. It was so simple that non-technical people, including designers, joined in and helped write these specifications. It was also a way for us to help document our code. 

Here’s what they looked like:

name: calendar
description: A calendar widget that can be used to show or select dates. It shows only a month at a time.
properties:
  - name: selectedDate
    description: The selected date in the calendar.
    type: string
  - name: minDate
    description: The minimum date that can be selected in the calendar.
    type: string
  - name: maxDate
    description: The maximum date that can be selected in the calendar.
    type: string
  - name: disabledDates
    description: The dates that are disabled in the calendar.
    type: array
    items:
      type: string
considerations:
  - The calendar should show the current month by default.
  - The calendar should show the days of the week at the top.
  - The calendar should show the dates of the month in a grid.
  - The individual dates should be selectable.
  - The individual dates should have stying states for hover, if its today, if its selected, if its disabled.
  - The user should be able to select a range of dates

Accompanying this, I created a Rust-based application that read in these specification files in a rather dashing 1980s-style interface. And, as if by magic, it’d output a rather convincing-looking component. This was coupled with the crucial infrastructure, such as the project scaffolding, code guidelines, and, of course, design tokens.

With that critical infrastructure in place, I was surprised by how close the output got to the design – without even touching Figma. Context is vital, and giving it to the AI without hitting token limits or sending it down a winding path to hallucinated nonsense is where design system practitioners come in. We can act as the shepherds and guardians of these tools to make sure that, whilst they’re pumping out this slop, the slop is at least tasty and useful.

In reality, the tool’s output was limited at the time, but it did accelerate us significantly. We still needed humans to do the final polishing here and there to make sure it deserved a place in our repository. We also had some issues with developer adoption – devs were always itching to edit the code manually, which ran counter to my idealistic expectation that we’d just prompt our way out of any problem.

Things have changed a tad since then. Claude Opus 4.5 and GPT-5.2 blow my humble generator out of the water. Agentic tools such as Claude Code and OpenAI’s Codex intelligently scour through your existing codebase and formulate the current context into something the model can use to produce much more accurate and sophisticated code. 

Delivery methods for providing context to the AI have changed, too.

Context is important

Model Context Protocol (MCP) is basically the USB port for AIs. If you don’t know what MCP is, think of the clunky ways in which we’ve had to inject context into an LLM before: either by writing those super-long system prompts or by creating that YML structure, which I always had to have ready in advance. 

It was like a student having to check out every library book, DVD, and microfiche before they could study. MCP means models now have access to context and tooling to do things at their fingertips, in a predictable format that can be read.

One exciting upcoming MCP is the Storybook MCP, which not only arms the agentic coding system with relevant information about the component library in question but can also empower the agentic tool to self-heal errors and bugs. At the time of writing, this isn’t generally available yet. 

But one thing that is available is the zeroheight MCP! This will give your agentic coding system, or even a chat app like Claude Desktop, the ability to get page content from your carefully crafted documentation. Additionally, it can also fetch styleguide information to inform your agentic amigo further. (Also see Vibe coding your design system with the zeroheight MCP).

Another MCP worth mentioning is, of course, the Figma MCP – one of the more powerful Figma AI tools available. This was one of the missing pieces in my old component generator: It enables you to pull all of the metadata from individual nodes within your Figma document, and it gives it more knowledge to be able to understand and style. This works really well when you integrate it with Cursor or Claude Code and a well-structured design system codebase.

What about documentation?

I’ve always thought that design system documentation isn’t just a clinical assessment of the facts, but a record of lived experience and the decisions, with rationales, behind them. 

AI does have a place here, though. There are exciting developments around generating Storybook stories. TJ Pitre at Southleft has created a rather innovative tool that, once integrated into your Storybook, lets you prompt it to generate stories – even from a screenshot. It’s well worth a look to accelerate your work and reduce some of the tedium that can come with creating stories.

The future is bright for design systems

I have fond memories of having my headphones on, going into deep concentration, alone, and working on boilerplate and complex component code alike. Sadly, those days are either over or nearing completion – especially for boilerplate code.

Design systems aren’t going anywhere, though. They’re critical infrastructure that is vital in the AI age because they provide the context that can differentiate slop from usable products.

I don’t believe that in the near future interfaces will remain static. Projects such as A2UI present an exciting paradigm whereby the application signals intent to the AI, which then generates an interface from your design system and presents it to the user. 

As these agentic tools improve, our code and our design files will become build artifacts. These artifacts will be created at the speed of thought.

The word thought here is, of course, a loaded term. I’ve chosen it particularly because, despite appearances, LLMs are incapable of the sort of thought that we expensive fleshy beings are able to manifest.

One of the major impediments to agility, a big criticism of design systems, may well disappear when we can design and code at the speed of thought.

For design systems, usefulness comes down to one thing: context.

AI can generate a screen in seconds, but without your system it doesn’t know your components, your tokens, your accessibility rules, or the way your product actually behaves. You get something fast, but you still have to fix it.

The zeroheight MCP changes that dynamic. It gives AI tools structured access to the guidance stored in your zeroheight styleguide — including component documentation, usage rules, and tokens. Which means the output starts aligned instead of generic. Your system stops being a destination people have to visit and becomes something that shows up inside the flow of work.

That shift sounds subtle, but it fundamentally changes how teams use a design system.

From doc site to in-flow guidance

Most documentation still lives outside the tools people use to do their jobs. Even if your content is excellent, using it means breaking focus, opening a browser tab, searching, reading, then returning to what you were doing and trying to hold it all in your head. Or slower still, Slacking questions to colleagues on the design system team.

That context switching has always been the hidden tax of design systems.

With MCP, AI tools can reference your zeroheight styleguide as structured context and respond with guidance that reflects your actual standards. You ask a question when you need the answer. The AI checks your zeroheight styleguide and responds with guidance and resources that reflect your actual standards.

It’s the difference between knowing your system exists and having it actively participate in the work.

That becomes especially valuable as systems grow. No one, no matter how embedded they are, can keep hundreds of components, patterns, and rules in their head. Being able to ask “what should I use here?” and getting a system-aware answer removes friction without removing governance. For quick questions, teams can also access the same guidance through the zeroheight Assistant, which lets viewers query styleguide content directly inside zeroheight, integrations in Slack, Teams, or where you’re working in Figma. Powered by MCP, it’s a lighter-weight way to surface the system when someone simply needs an answer.

What the MCP actually gives the AI

There’s no magic layer behind the scenes. The MCP exposes your zeroheight documentation in a structured, machine-readable format that AI tools can query directly.

That includes the written guidance on your pages, your documented design tokens, and references to design and code sources — everything you’ve built into your styleguide. The AI doesn’t infer or fill gaps; it works with what’s actually documented. Which means strong documentation isn’t just good practice — it’s the raw material the AI reasons from.

The MCP works best as one part of a broader setup, sitting alongside your Figma library and code packages. Each fills a different role:

• Your documentation explains the intent — how components should be used, what the rules are, how patterns are constructed.
• Your design library shows the visual structure.
• Your code defines the implementation.

The MCP connects the AI to the first of those layers. Together with the other two, you give it something close to the mental model a human team member would build up over time.

Auditing becomes a starting point, not a project

One of the most interesting side effects of this setup is what it does to auditing and planning work.

LLMs are well-suited to reading large volumes of information and identifying patterns. When an AI has access to your documentation — and, where connected, your design assets and code — it can start answering questions that would otherwise require a workshop, a spreadsheet, and a lot of collective memory:

• Where is documentation incomplete or inconsistent?
• Which components have guidance that conflicts across pages?
• What patterns are documented but lack clear usage rules?

Example of using Claude to help audit your design system

The more of the picture the AI can see, the more of these questions it can address. With documentation alone, it can surface gaps and contradictions. With design and code alongside it, you can start asking broader questions about what’s in sync and what isn’t.

Either way, instead of spending the first half of a roadmap conversation establishing the current state, you start with a generated, system-aware view of it. The team still decides what matters — but the slowest part of the process is largely done. Then zeroheight’s in-editor tools like Build with AI and Improve with AI help teams fill those gaps, fast. 

The same principle applies at a smaller scale. Before sharing a prototype, you can ask for an audit against your own documented guidelines and get a structured list of issues back. It turns your documentation from something people are supposed to remember into something that actively checks work.

Tokens move from reference to enforcement

The token-aware code workflows push this even further.

When your tokens are documented in zeroheight, the MCP exposes them in a way that enables token linting directly — meaning AI can look at a piece of code, recognise where someone has hard-coded a value that should be a token, find the closest match, and suggest the fix. CSS, SCSS, and common JavaScript frameworks are all supported.

In practice, that means you can take something that technically works but doesn’t follow the system and bring it back into alignment in a single pass.

It’s a small, practical example of a bigger shift. The design system stops being a set of guidelines that people try to follow and becomes a mechanism that actively pulls work back toward consistency.

Vibe coding that actually respects the system

All of this comes together in the workflows people are most curious about: generating UI.

Vibe coding without context is fast, but it produces generic output that needs heavy editing. Vibe coding with design system context starts from the right place, from the very first prompt.

When you ask for a multi-step checkout or a settings flow, the AI can read your component guidance, pull the right building blocks via the Figma MCP, apply the correct structure, and follow your usage rules. In Figma Make, that happens through the official zeroheight connector, which lets the AI reference documented components and guidance directly from your styleguide. In code tools like Cursor, it happens through the zeroheight MCP directly.

The zeroheight connector for Figma Make

The result isn’t perfect, and it shouldn’t be treated as production-ready without review. The more accurate mental model is a very fast junior contributor who already understands your system. You still do the final pass, but you skip the blank page and most of the mechanical work, getting you to iteration and refinement much faster.

For designers who don’t live in code tools, this also lowers the barrier to prototyping. You can work in a familiar environment and still generate something that reflects the real product.

Documentation that works for humans works for AI

The changes you make to support these workflows are less dramatic than they might seem.

Clear, well-structured documentation has always been easier to use. It also happens to be easier for AI to interpret.

Guidance that is concise, direct, and written in plain language gets used more reliably. A strong hierarchy helps the model find the most important rules first. Consistent naming reduces ambiguity. Removing contradictions between pattern guidance and component specs improves both human and AI understanding.

In other words, the practices that make a design system healthier also make it more effective as context for AI.

The good news is that AI can help you get there. zeroheight’s in-editor AI Assistant can review your existing pages and recommend improvements, flag gaps, and help you build or refine content directly. Tone of voice settings keep writing consistent across contributors, so the guidance your team reads — and the guidance the AI reasons from — stays coherent throughout.

It’s a useful loop: AI tools help you build and improve documentation, and better documentation makes your AI-workflow more effective.

Adoption is mostly about removing friction

For this to become part of everyday work, people have to find it, set it up quickly, and see value almost immediately.

That’s why native connectors, simple setup, and shareable access matter. The zeroheight connector for Figma Make is built directly into Figma Make rather than bolted on, while the MCP gives code tool users a consistent way to connect their own environment. 

When a design system team can enable these and give consumers a simple way to get started, the barrier drops from “new infrastructure” to experimenting and confidence building to “new habit”. 

For product teams, that means usage questions answered in context, prototypes that start from the right place, and code that arrives closer to compliant — without the design system team becoming a bottleneck for any of it.

Not every workflow needs a server

There are also cases where teams can’t or don’t want to connect an MCP server. For those, zeroheight is introducing ways to hand AI a clean, markdown version of a page and use that as the source of context for a conversation.

It’s a lighter-weight approach, but it still moves the system into the AI workflow instead of leaving it in a separate tab.

Where is this heading

The direction of travel is consistent: reducing the distance between guidance and execution.

• Deeper token access enables more accurate enforcement.
• Better authentication and control makes security teams more comfortable.
• Native integrations remove setup steps, lowering barriers to entry for more people.
• A Figma plugin that lets designers select any frame and query it against their design system — chatting with their guidelines, checking alignment, catching issues — without ever leaving the canvas.

The role of the design system changes

When your system can guide, generate, and audit work in real time, documentation ceases to be a passive artifact.

You’re no longer publishing a resource and hoping people follow it. You’re providing the context that shapes what gets produced.

That doesn’t make the design system less important. It makes the quality of your guidance more important because it directly affects the output of the tools your organisation uses every day.

And it means the system’s success is no longer measured by page views or adoption decks, but by how naturally it fits into and enhances the workflows that ship the product.

Get started with the zeroheight MCP or try on-system prototyping with the zeroheight connector for Figma Make.

That’s how most design system documentation ends up. Not some spectacular failure, just a slow fade into uselessness. Teams pour effort into creating comprehensive design documentation at launch, then six months later it’s fiction.

Most teams do document. They’re not skipping it. But documenting design systems often gets treated like a box to tick rather than something that needs to stay alive. When you’re figuring out how to document a design system, the question that matters isn’t “what should we write?” – it’s “how do we keep this current?“.

The maintenance cliff

Every design system starts out well-intentioned. Launch week, you’ve got gorgeous component documentation. Usage guidelines, accessibility notes, dos and don’ts with screenshots. Everyone’s proud of it.

Fast forward three months. Someone updates a component but not the docs. A new prop gets added, and nobody mentions it in the styleguide. A designer hits an edge case that directly contradicts what’s written. Nobody fixes any of it because nobody owns it. Updating docs wasn’t in the ticket.

Brad Frost put it well in Atomic Design: “Once a pattern library ceases to reflect the current state of the products it serves, it becomes obsolete”. Once that happens, the docs that were supposed to speed teams up actually slow them down. Why trust documentation when asking someone directly feels safer?

The cost sneaks up on you. Teams lose faith in the docs. They fall back to Slack and meetings. New people learn through word of mouth instead of self-service. Every repeated question that should’ve been answered in documentation lands on the design system team’s plate.

Why updates fall through the cracks

The core problem is that documentation lives somewhere different than where work happens. Components are built in Figma and code, while documentation sits in a wiki, a static site, or some other platform. Switching contexts to update docs takes effort, and that effort gets cut when deadlines hit.

There’s also nothing telling you when docs go stale. Change a component’s props in code, and no alert fires saying the documentation’s wrong now. Update something in Figma, and the design guidelines just sit there, unchanged. The gap between reality and what’s written widens, and nobody notices until someone’s already frustrated.

Most design system workflows don’t treat documentation as required. Components ship without doc updates because shipping is the milestone. Maintaining design systems already feels like extra work to most teams. When it competes with feature deadlines, documentation loses every time.

Treating documentation as part of the system

One approach that helps: Stop thinking of documentation as separate from components. It’s part of the contract. Ship a component change, and the doc update ships too. Not optional, but required. If the docs are wrong, the component isn’t done.

This sounds straightforward, but it needs structural backup to actually happen. Documentation belongs in the acceptance criteria. Reviews should check docs alongside code. And updating has to be easier than skipping.

This is where design system tools that hook into Figma and code repositories make a real difference. Sync your Figma components and code examples straight to your documentation platform, and the copy-paste disappears. Prop tables can generate from TypeScript definitions. Token values can pull from your token files. The stuff that goes stale fastest should be the stuff that updates itself.

That’s what makes the design system process matter more than individual effort here. You can’t count on people remembering. You need updating to be the path of least resistance.

The structure that scales

There’s another problem beyond maintenance. Most design system documentation is organized by component name, alphabetically or grouped by type. That only works if people already know what they’re looking for.

But people don’t usually think that way. They’re not searching for “button”. They’re thinking “I need to submit this form” or “I need to let users do something destructive”. Task-based organization matches how people actually search. It gives them paths based on what they’re trying to do, not just an alphabetical list.

This plays out the same way at company after company. One team kept hearing that people couldn’t find components. The docs had everything, thoroughly documented. But it was organized around what the design system team had built, not how product teams thought about their problems. Adding a task-based layer, stuff like “showing loading states” and “communicating errors”, pushed component usage noticeably up the next quarter.

Depth matters too. Most design guidelines dump everything on you at once, presenting walls of text that overwhelm rather than help. It’s better to lead with what someone needs right now, then link out for those who want more. A quick start that works, common patterns for the 80% case, edge cases that are accessible but don’t get in the way, and technical reference that’s linked rather than inline.

And live design system examples beat screenshots. Screenshots go stale the second you capture them. Interactive examples pull from actual components, so they stay current. People can try things and answer “will this work?” without guessing.

The metadata opportunity

Component descriptions in Figma used to be nice-to-have. Now they’re parseable, and that changes things. Nathan Curtis’s recent work on “code only props” shows how Figma components can carry implementation details designers never see but tools can read: accessibility labels, semantic HTML requirements, slot configurations.

What this means for documentation: Some information can live in the component itself instead of prose you have to maintain separately. Prop types, defaults, structural requirements. Machine-readable metadata that documentation platforms can query directly. Platforms built for this kind of integration, like zeroheight documentation with its MCP server, cut out the manual copying between systems.

The split gets cleaner. Metadata handles props, types, and relationships. Written documentation handles judgment calls: when to use something, when not to, and guidance that can’t be reduced to data. Both need upkeep, but metadata can be automated and verified, so it’s less likely to go wrong without someone catching it.

This also sets up your design system for AI tools. If your design system depends on conventions nobody wrote down and context only humans pick up on, automated tools won’t get far. Structured metadata gives them something to actually work with.

Building maintenance into the workflow

Sustainable documentation means distributed ownership, but with accountability. The core team owns structure and standards, while component authors document what they build. Contributors should be able to update docs, with clear guidance on what “good” looks like.

It helps to bake this into the process. PR checklists should include doc updates. Reviews should look at documentation, not just code. Quarterly audits can flag components where docs lag behind reality. Tracking the age of the documentation alongside other health metrics makes staleness visible.

Figure out what to measure. Which docs get viewed? What searches come up empty? Which components generate tons of support questions despite having documentation? Tracking the gap between component updates and doc updates is useful. If that’s measured in months, there’s a process problem.

DesignOps thinking helps. Treat documentation like a product with its own feedback loops. Put feedback mechanisms in the docs themselves, whether that’s a simple form or something wired to your support channels. Surface gaps before they pile up.

Starting with what hurts most

You’re not going to fix everything at once. Start by figuring out where the pain is. Which components generate the most questions? Which docs get the most traffic, and which get ignored? Where do teams get stuck adopting things? What keeps coming up in Slack even though documentation exists?

Fix findability first. If people can’t find the docs, it doesn’t matter how accurate they are. Improve your search, add task-based navigation, and make common questions answerable in 30 seconds. Check whether search actually works before and after you change things.

Then go after staleness. Pick five components that are most used or most confusing, and rewrite their docs so they’re actually current. Make those the model for everything else, because visible wins build momentum.

Where you can, add automated checks that catch when docs and code don’t match. Build doc updates into how components are developed, and set a threshold for how stale is too stale. Small steps, repeated until they become a habit.

Documentation as infrastructure

Teams that take design system best practices seriously treat documentation as infrastructure, not a launch deliverable you forget about. The docs that actually get used are the ones that stay current because updating them is built into the process.

Automate technical details where you can, but be intentional about what needs a human: the judgment calls and the guidance on when to use what. Start with your worst pain points, build momentum, and measure whether the docs are actually reducing support load or just sitting there.

Good documentation lets teams help themselves. Bad documentation becomes a bottleneck. The difference has nothing to do with how much effort you put in at launch. It’s whether maintenance is part of how you work, or an afterthought that never happens.

To mark the occasion, the women across our team have shared personal reflections, insights on empowerment and equality, and their hopes for the future. We’re proud to bring their voices together here.

How have you experienced the power of giving or being given support, and how has that shaped your growth?

Early in my career as an intern, I was encouraged to ask questions about how and why things worked, especially within our CRM. Instead of being told “that’s just how we do it,” I was trusted to investigate, challenge steps that did not make sense, and even improve workflows.

That trust gave me room to think creatively and take ownership, even at a junior level. It led me to work on a new projects and sparked the operational mindset I still carry today.

Being given that support so early shaped my confidence and ultimately my career path. It showed me that when you give someone space, trust, and real responsibility, you do not just improve a process, you unlock their potential.

What’s something you’ve learned about yourself as a woman through your career so far?

One of the biggest things I’ve learned through my career is that it’s okay to take up space. As women, it often feels like there is no “right” way to show up. If you speak up too little, you can be seen as quiet or unsure. If you speak up too much, you risk being labelled as bossy or intense.

I’ve learned to embrace the fact that I’m naturally energetic, quick to share ideas, and expressive. That is not something I need to shrink. At the same time, I’ve also learned the importance of creating space for others who process differently, giving people time to reflect before jumping straight into action.

Overall, my biggest takeaway has been that I can show up as myself without apology, and I can help build environments where everyone else feels able to do the same.

What’s a piece of advice, perspective, or encouragement you’d like to give to other women?

Make sure you’re feeding your soul from more than one place. Work can be fulfilling, but one part of your life should not be responsible for carrying the weight of all the others.

Find the things that restore you outside of work too, whether that’s time with people you love, a hobby, being outdoors, or simply slowing down. Your needs will change day to day, and that’s normal.

Be patient with yourself, be kind to yourself, and remember that balance is something you build over time. You only get one life, so give yourself permission to protect your peace.

What’s something you’re proud of that might seem small to others?

One thing I’m proud of is learning to protect my time and energy.

To me, being able to say “I’ll need more time to do this well” or setting more realistic expectations has helped me avoid burnout and feel more balanced in my work and life.

Earlier in my career, I felt pressure to say yes to everything and prove myself. But now, I understand that being thoughtful about my limits and capacity isn’t selfish. 

What’s a piece of advice, perspective, or encouragement you’d like to give to other women?

One thing I’ve learned is how much the people around you matter.

In my case, having supportive people both inside and outside of work has made a huge difference. Even if you can’t always choose who you work with, finding a few people who genuinely support and believe in you can change how you see yourself and what feels possible. It doesn’t solve everything, but it gives you strength as you move through your career.

In day-to-day work, what practical steps can colleagues (of all genders) take to support women’s advancement?

I think in terms of Customer Success, it is important to be intentional about framing CS work in commercial terms. When highlighting wins, connect them to retention, expansion, or product influence. That positioning helps ensure women in CS are seen as strategic operators, not just relationship managers.

What skill, strength, or trait do you wish more women recognised in themselves?

Some key facets of Customer Success are relationship-building, communication, and intuition, which are important drivers of account retention and growth.

To that effect I wish more women in Customer Success recognised how powerful their emotional intelligence is and how it ties to company profit. The ability to read a room on a call, understand what a customer isn’t saying, balance empathy with commercial awareness, and navigate complex stakeholder dynamics, is not just being nice. It can also be incredibly strategic.

What is one hope you have for the future of women in your industry?

I hope we move from just “making space” for women for DEI numbers to truly valuing different leadership styles and perspectives. Not just increasing representation, but redefining what success and management look like. When diverse voices shape strategy, not just culture, the whole industry becomes stronger and undoubtedly more successful.

How do you balance giving to others while still protecting your own energy and wellbeing?

It’s not something I’m the best at doing 😊 but I try to remind myself that if you’re not looking after yourself too, you won’t be able to properly look after others.

I’m slowly learning that sometimes you’re the one giving the support, and other times you’re the one that needs it more. That the balance will move all the time, and if you do need help, it’s okay to ask for it.

I’m also learning how to say no to things when I don’t have the space or capacity to take it on, and that protecting your time and energy when you need to isn’t selfish.

What skill, strength, or trait do you wish more women recognised in themselves?

Their empathy and emotional intelligence. How often they are able to understand people, read situations, and support the people around them so naturally.

What’s a piece of advice, perspective, or encouragement you’d like to give to other women?

I saw a quote recently from Maya Angelou: “I am grateful to be a woman. I must have done something great in another lifetime.”

Being a woman feels like such a special experience, and I am constantly in awe of the women I meet – from the ones I surround myself with daily to the ones I may cross paths with only once. We are stronger, smarter, braver and kinder than we might believe or realise. And once we remember that, there’s very little we can’t do.

How do you balance giving to others while still protecting your own energy and wellbeing?

As a working mum with chronic health issues, I can very easily burn myself out if I’m not careful. Low energy is a fact of daily life for me. The only way I’ve managed to stay sane (and upright) is to learn to properly distribute my somewhat meagre reserves across my life.

While my little one will always need my energy, and won’t accept “Bugger off, mums tired” when he asks me to explain why the dog can wee in the garden, but he can’t. I’ve learned that there are things I don’t have to parcel out extra energy to, and it’s okay to say “No, I can’t”.

What is a barrier (big or small) you’ve had to overcome, and how did you approach it?

I often struggle to put into coherent words what my barriers have been, and how I’ve even managed to overcome them. I’ve had a lifetime of mixed messages.

I’ve been told I need to be soft and feminine, so that I’m approachable, but not too “girly”, otherwise people won’t take me seriously. I’ve also been told (sometimes in the same sentence) that I need to be loud, strong and assertive, but I must be careful or people will think I’m just rude.

Much of my struggle comes from not feeling confident in what’s acceptable, and what’s not. I’ve been told in equal measure that I should call out micro-aggressions, and that I should “let some things slide” for the sake of not causing a fuss over the “little things”.

This push and pull between what, in society’s eyes, I can and cannot be upset about, has left me in a place of exhausted apathy, where I’m too tired to even look deeper into what may be unfairly holding me back.

What change would you most like to see in society that would help accelerate gender equality?

We are now (mostly) past the stage where asking “Are you on your period or something?” in response to any form of assertiveness, or suggesting that we’d be happier back in the kitchen, is considered acceptable.

From this societal change, we’ve built up a basic level of respect that has turned into a general established framework of policies for most workplaces.

While these frameworks are a good thing, they often fail to recognize women as individuals with unique, personal needs. Not every woman faces the same challenges or requires the same support. Putting up ladders is all well and good, but if you forget to check if everyone can climb those ladders, you’re still leaving people behind.

In day-to-day work, what practical steps can colleagues (of all genders) take to support women’s advancement?

One way to help give better support, is to work on understanding why that support may be needed in the first place.

While you may be in same role as someone, you don’t know what their journey to get there looked like. It may have been a short walk for you, and a difficult uphill climb for another. You may feel ready to carry on ahead, and another may need to wait a while to catch their breath before forging on.

How do you balance giving to others while still protecting your own energy and wellbeing?

Reflecting. Every now and then, I do a check-in with myself and think – How am I doing? Could I give more? Do I need to reassess my boundaries?
– I remind myself that I never think negatively if someone says no to something I ask of them, so why would I worry that they will think negatively of me if I say no.
– I make sure that I do something for ‘me’ at least once a week. At the moment, that is going for a walk and listening to a podcast.

How do you balance giving to others while still protecting your own energy and wellbeing?

When I’m giving to others, the outcome is split in some ways: sometimes I’m drained, and other times my own energy and wellbeing is actually improved. So I’d say the balance comes from being aware of if I’m giving to others in service of hustling or proving worth (which is usually where my burn out happens) vs. seeing an opportunity to meaningfully support based on my own clarity and beliefs – which lights my brain up and helps me too. 

In day-to-day work, what practical steps can colleagues (of all genders) take to support women’s advancement?

In my view, any and every group of people would advance if we were less resistant to acknowledge gaps in our own perspectives. When people stop getting curious or deny that we’ve all got blind spots, we stop learning and the inclusivity of our collective experienced is massively limited. Pause to challenge your assumptions. Ask yourself how your day to day might vary from others. Notice how other people are moving through the systems around you differently. From there, equity has a chance! 

How have you experienced the power of giving or being given support, and how has that shaped your growth?

I’ve experienced how transformative it is when someone gives you their time, belief, or encouragement, especially at moments when you’re still figuring things out yourself. Having managers and peers who trusted me with responsibility before I felt 100% ready helped me grow faster and with more confidence. It’s also shaped how I try to show up for others: sharing knowledge openly, and creating space for different voices. The more I’ve given support, the more I’ve realised growth isn’t a solo journey but rather it’s something we build together.

In day-to-day work, what practical steps can colleagues (of all genders) take to support women’s advancement?

Small actions matter. Amplify ideas in meetings. Credit people clearly for their contributions. Invite women into stretch opportunities. Be mindful of who gets interrupted and who gets heard. And most importantly, advocate for people when they’re not in the room. Consistent allyship builds long-term change.

What’s something you’re proud of that might seem small to others?

I’ve lived in several countries around the world and have been able to build a community in each place. That’s something I’m incredibly proud of. Starting over isn’t always easy, but being able to create connection wherever I go has taught me resilience, openness, and the value of investing in people.

What is one hope you have for the future of women in your industry?

I hope more women get into tech and take active leadership roles. Representation at decision-making levels shapes products, culture, and opportunity. The more diverse leadership becomes, the stronger and more innovative the industry will be.

What’s a piece of advice, perspective, or encouragement you’d like to give to other women?

Even if you don’t meet all of the requirements for a new role or new sector, if you’re interested in it, go for it. Apply anyway. Growth rarely happens inside your comfort zone, and you never know where one application, one conversation, or one brave step might lead.

How do you balance giving to others while still protecting your own energy and wellbeing?

I think taking the time to give unsolicited praise and support to people when you have the capacity to do so can go a long way. Giving to others doesn’t have to take a lot of time or effort. It can be as simple as saying ‘you did a great job in that presentation’ or calling attention to someones idea in a meeting if they are being overlooked. Little things compound and add up.

What is a barrier (big or small) you’ve had to overcome, and how did you approach it?

I think one of the difficulties for me was overcoming some internalised expectations around being opinionated or confident. I have a habit of downplaying the work I’ve done but having others on my team support me and even push me to be more opinionated has helped me become more confident. 

What skill, strength, or trait do you wish more women recognised in themselves?

Borrowing from the barrier I’ve overcome I wish more women could recognise how capable they are in whatever they choose to do. Be opinionated, be confident, don’t be afraid to disagree and make your point of view known. Take up space.

What’s a piece of advice, perspective, or encouragement you’d like to give to other women?

The tech industry can move fast but your personal growth isn’t a race. Do what feels right for you and trust your own judgement.

What is one hope you have for the future of women in your industry?

That no opportunity or ambition looks unachievable. If we get to a stage where women feel like every path is genuinely open to them, not just in theory, but in what they see around them every day – then we’ve done something right. I’d love for confidence to come from lived reality rather than resilience, and for success stories to be so normal that they’re no longer described as exceptions or “firsts.”

What’s a piece of advice, perspective, or encouragement you’d like to give to other women?

Don’t shy away from the difficult situations, as that’s where true growth will come from. The moments that challenge you are often the ones that build your confidence, sharpen your voice, and show you what you’re truly capable of.

How do you balance giving to others while still protecting your own energy and wellbeing?

In design, we’re constantly problem solving for others – our users, our teams, our business. I’ve learned that protecting my energy is part of protecting the quality of my leadership. I balance it by prioritising what truly needs my attention, empowering my team instead of trying to carry everything myself, and being intentional about switching off. Balance for me is about designing my time as intentionally as I design experiences.

What skill, strength, or trait do you wish more women recognised in themselves?

The ability to navigate complexity, adapt, and keep going – often while carrying more than people realise – it’s extraordinary, even if it feels ‘normal’. Pair that with trusting your own voice, and it changes everything. So many brilliant women already have the skills, sometimes the missing piece is simply believing it.

What is one hope you have for the future of women in your industry?

My hope is that the next generation of women in tech don’t feel like exceptions – they just feel expected. I hope the industry continues shifting from ‘making space’ for women to fully valuing different leadership styles, perspectives, and ways of thinking. Technology is at its best when it’s built by diverse teams – not just because it’s fair, but because it leads to better outcomes.

What’s something you’ve learned about yourself as a woman through your career so far? 

That women are as capable and intelligent as men but we don’t have the confidence that men do. This is why women are still a minority in the C-Suite and in tech in general I believe. 

What is one hope you have for the future of women in your industry?

Women still make up only about 25% of the workforce in the tech sector. I’d like to see women becoming half of the workforce in tech, and I hope we reach that soon. However, sadly I feel like we still have a very long way to go.

One of my hobbies is DJing and music production. Women make up only 12.5% of electronic music producers signed to labels, so that industry is even more male dominated than tech! I’m not sure why I end up in industries that are super challenging in that way. I guess it’s maybe because isn’t life a bit boring if we don’t have any challenges?!

How have you experienced the power of giving or being given support, and how has that shaped your growth?

Giving – this is actually one of my favourite parts of the job. You can’t coach or train empathy and a human approach to management. I’ve been lucky to learn from some incredible managers, and honestly I’m glad of those managers whose approach didn’t align with mine at all (there’ve been plenty!) as I’ve been able to pick and choose what I’d want to either emulate or ignore! But now having the ‘power’ to support my team in a way that means their days/weeks can work in a way that works for them, their families/children, mental health, mood, hobbies etc, feels like a great way to give support. Ultimately, sales people will do their best work and sell better when they’re happy and supported in a way that feels good. Caveat is, to manage in this way.. you have to find great hires – I’ve been lucky enough to do that. 

How do you balance giving to others while still protecting your own energy and wellbeing?

This is very much a work in progress…! I haven’t cracked it but know I will at some point and will continue focusing on making progress – stay tuned. 

What change would you most like to see in society that would help accelerate gender equality?

I could write an essay on this but if I think about work, I’d like to see more men in the industry, being active allies. It’s not enough to have a value about DEI, or open up hiring for 2 weeks to female applicants first. It’s everyday – the language used, the ability to self reflect and see their own unconscious bias, not being afraid to admit when they’re unsure, ask questions, be proactive in their learning. Outside of work, I think it’s time the world was run by female leaders.. 

In day-to-day work, what practical steps can colleagues (of all genders) take to support women’s advancement?

Maternity leave/returning to work post maternity are career stallers and is hard work for women – practically and emotionally. Women are often expected to go back to work as if nothing has changed, whilst society – alongside a lot of political figures) – tells us that women should be the main house runners / primary care giver to children. Employers allowing flexibility where needed, financial support/benefits and also recognising the skills a Mum can bring to the table, even after time out, should be the minimum. I’m not a Mum but the best multi taskers, context switchers, problem solvers I’ve known – are all mothers!

Who is a woman (public figure or personal mentor) you admire and why?

My colleague Madelin Snyder, our Head of Product here at zeroheight. I think she is the wisest woman I know, genuinely. It’s like she has ‘been here before’ and she is the person I first go to for advice of any kind. 

What’s something you’re proud of that might seem small to others?

I live in Glasgow and this is the 4th city I’ve lived in, outside of home. I’m proud that a) I was never afraid to up and leave home in the first place and b) Build a life for myself in each city and I trust I’d be able to do so time and time again

What skill, strength, or trait do you wish more women recognised in themselves?

We often hear ‘women are emotional’. There’s a lot of research to show that women have stronger emotional intelligence and that is not a trait that should be overlooked.

What’s something you’ve learned about yourself as a woman through your career so far?

This doesn’t feel specific to being a woman albeit I think it shows up differently for women. Everyone is basically winging it! No one knows what they’re doing 100% of the time… and that’s okay. You say yes and then you figure it out. What I often remind friends of, is that women are less likely to feel comfortable with that fact though… 

What’s a piece of advice, perspective, or encouragement you’d like to give to other women?

From my time in recruitment I saw that men were most likely to apply for a job when they ticked around 60% of the boxes, women were more likely to aim to tick closer to 100%. Apply for the job, say yes, figure it out later.. 

Let’s carry the spirit of Give to Gain beyond today — supporting, advocating and creating space for one another to thrive.

And hey, I wasn’t exactly wrong. Design system work is creative, challenging, and fulfilling. It just doesn’t necessarily always feel as freeing as creating art can be.

Design systems, by nature, are structured and well-organized. They have to be, in order to be functional. They seek to solve problems for their consumers. Art, however, favors expression over systems. Seldom does art consider itself to be functional and usable. Art doesn’t start with a problem that needs to be solved; more often, it starts with an idea or a story that needs to be told. Even the most methodical works of art aren’t perfect, but that is what makes them so delightful. 

What happens when we take art in all its messy, unorganized glory and try to fit it nicely and neatly into a smoothly running, well-structured design system? Well, problems, mostly. In this post, I provide 8 tips that can help you mitigate these problems before you build your next illustration system.

1. Get access to the source files

Your brand team comes to you with a set of wonderful, thoughtfully crafted illustrations, hand-drawn on a tablet in Adobe by a talented freelance illustrator. The work is beautiful, but it does not fit into your product – literally: the SVGs are too big at 300-500 KB, and your engineers are freaking out. 

To set yourself up for success, I highly recommend getting access to a copy of the source file. In an age when most UI designers never need to reach outside of Figma, I think every design system team should have at least one member with an Adobe Illustrator license and the know-how to use it. Digital artists, graphic and brand designers will continue creating in Illustrator, and it’s important that we are able to access those files in order to mitigate the problems that arise when implementing their vision into product.

2. Move multiple files to a single source

To make your illustration system more scalable, you should create a single-source Illustrator file that houses all your assets of that type. This file will become your source of truth, from which you can bulk-export files to create a Figma library or hand assets over to engineers.

Put each illustration on its own individual artboard and name your artboards. Here is where you establish a suitable naming convention that designers and engineers can both agree on. If you want to go that one step further, you can also organize artwork into different layers. This is particularly helpful if you need to toggle aspects of your artwork, like a background, on or off. Illustrator allows you to add prefixes during bulk export, which makes it really easy to keep different collections in one place.

3. Talk to your engineers

Getting your engineers involved early is paramount. They can help test out files as you optimize them, provide helpful guidance, and be involved in deciding naming conventions or a dedicated process. 

When creating our illustration system at Just Eat, our engineers recommended resizing illustrations to 200px – a huge difference compared with the original 1800px. This is because our illustrations were vector-based and could be scaled up without a loss of quality. A large physical size was therefore unnecessary and excessive. For us, this led to a decision to resize 60+ illustrations from their source files. 

4. Scale down artwork

Digital artists like to work big. At large sizes, they can capture finer details, and it’s much easier to scale down a large file than to scale up a small one without quality loss. Digital artists often get briefed to create illustrations for multiple business purposes, and product isn’t always considered the first priority. Physically scaling down the artwork and rehoming it within your single-source file gives you more control over the asset.

When scaling artwork, it’s really important that you don’t make any fundamental changes to the work itself. This can happen easily if the editable attributes (like strokes or effects) haven’t been converted into vector shapes. Before you scale any artwork, make sure to select all of it and click Object > Expand.

5. Be cautious of textures, masks, and effects

You want your file sizes to be as small as possible, ideally under 30 KB. If your assets are still in the hundreds, then you may need to look at the finer details.

Digital artists love to create well-considered, beautiful pieces of art – shocking, I know. They will use highly detailed brush strokes, layer large custom-made textures into their artwork, and create complex shadows from different gradients. All of that information creates data that is retained in the code of the SVG, making the file size considerably bigger and messier. 

Texture and brush strokes are particularly problematic because when expanded, each difference creates a new editable ‘node’. This problem isn’t limited to using Illustrator. The new functionality in Figma that allows designers to draw with brush strokes may feel intuitive for interfaces, but once exported as an SVG, that smooth line will expand to reveal hundreds, if not thousands, of messy nodes.