A few months ago, I realized I’ve been trying to approach agentic design systems the wrong way. I found a way to reframe it that’s been helpful for me. I’m writing because I hope it’ll be helpful for you too. When things feel choppy, it’s nice to have an anchor.

From Style Guides to Systems#

In the early days of design systems, before we even called them design systems, there were style guides and sticker sheets. For those who don’t remember: A designer would carefully craft every detail into these documents, poring over every pixel, counting on others to reliably reproduce their work to create cohesive interfaces and high-quality experiences. And sometimes we did. But most of the time it was a mess.

There were too many gaps in the translation layer and too many opportunities for error. Our tools simply were not up to the task.

But the tools improved, and we did too. We overhauled our development process. We built systems to connect specs and code. We unified our documentation and created a shared language. We bridged the chasm between design and engineering. What once felt audacious became attainable – and not only for giant organizations. We saw the rise of relatively small, scrappy design system teams build innovative tools and work in new ways. All of those achievements would have been impossible in the era of static style guides.

And now we’re in a new era where development looks drastically different than the one we built our ecosystem around. And again we’re finding our tools are simply not up to the task.

And while so much has changed, I would posit the problem is actually quite similar. The chasm between design intent and development implementation has widened again. We find ourselves patching the gaps in our systems, betting that probabilistic agents and engineers will reliably implement our intent. It’s not so different from what we’ve faced before – adding redlines to Photoshop docs and trusting people to follow them faithfully.

Reframing the Problem#

But we need to look at this problem differently and redesign our tools accordingly. In short, we need to transform our design data systems into design knowledge systems.

Our former systems were built to transfer design data from one medium to another. We had sizes, colors, and typography locked in artifacts that were difficult to translate to code. So we built systems around tokens, components, and icons to extract that data so the exact design values made it into our products. We relied on people to understand the broader design context to build cohesive experiences.

But agentic systems are quite good at transferring data. They can copy values almost perfectly from one artifact to another regardless of the format. They can even find surrounding context and turn it into helpful information. And they can build massive amounts of code at a rapid rate. But where they struggle is reliably translating the design knowledge behind all that data. And what we’ve seen is that even if we get agents to use all the right values, it doesn’t ensure a good experience. And that’s the problem our new tools need to solve:

How might we build intelligent systems to help agents translate design knowledge reliably to our products?

Data, Information, & Knowledge#

Before we get too far into the ideation phase, I’d like to make sure we’re using the same terminology. Borrowing from a classic systems-theory distinction: data are raw values, information connects those values with context, and knowledge makes that information actionable. Thinking about these terms has been very helpful for me to reframe the problem at hand.

flowchart LR
  A["<b>Data</b><br/>Raw Values"] --> B["<b>Information</b><br/>Data + Context"] --> C["<b>Knowledge</b><br/>Info + Action"]

To translate that to design systems:

  • Data: The value of red-600 is oklch(0.5342 0.2172 29.53/1).
  • Information: red-600 is used for error states.
  • Knowledge: You should apply red-600 to input borders for error states. However, you must not use color alone to communicate errors. Supplemental error text is required and should also use red-600.

Design knowledge isn’t always the intuition we’ve accumulated over the years. Often it’s these basic rules that already exist and are somewhat obvious. The problem is that so much of our tooling is built to support the data and information that support our design systems. Very little tooling exists to ensure our design knowledge is provided to agents, and even less exists to ensure they consistently and reliably apply it.

What This Means for Systems#

What does this actually mean for design systems? We could go wide ideating on possible solutions, but I’ll limit myself to three areas that feel particularly relevant at the moment.

  1. Restructuring Our Knowledge Systems
  2. Tracing Design System Provenance
  3. Evaluating Better Outputs

Restructuring Our Knowledge Systems#

So much of our design knowledge is locked up in unstructured documents. It’s also spread across Markdown files, decision docs, and Figma comments.

In the early days, it felt like a huge win to throw all our docs at an agent and assume it would know all about our design system and follow our rules. It did not, and trying to patch holes in our docs required a ton of effort with very little performance improvement. Why? Because unstructured docs are great for transferring data and information, but they are poor at transferring knowledge and intent. It gets swallowed in a massive context window, lost in opaque reasoning, and is impossible to evaluate.

We need to transform our unstructured data into structured knowledge.

We are experimenting with a design system knowledge graph to see how it performs against our current unstructured knowledge base. The benefits of this system are:

  • Making implicit connections explicit
  • Focusing on design intent
  • Making information actionable
  • Providing just enough context

Here’s an example from an early prototype:

a screenshot of a Claude UI displaying accessibility rules for our Primary Button

We extracted rules and other metadata directly from our PrimaryButton docs. Instead of relying on an agent to parse through unstructured documentation to find relevant information about our components, it can fetch the exact information it needs from the graph. On this attempt, we were able to extract 524 explicit rules (must not, should not, may, should, must), all of which are tied directly to source quotes from our docs. We also pulled prop values, usage guidelines, content guidelines, examples, and more.

Tracing Design System Provenance#

We need better tools for tracing design system provenance. Anyone can vibe code a design system skill or feed a model your documentation and claim their agentic system is “using the design system.” And further, any agent can alter existing rules or entirely fabricate new ones and state them as fact.

Every statement an agent makes about your design system should be traceable. We need to be able to check the provenance on any given rule and compare the actual source text to the statement being made. Without this, we have no way to assess the veracity of the claim.

This is another reason I like the idea of storing design knowledge in a graph structure. Every component has rules directly attached to it, and every rule has a source location and excerpt where we can audit what the agent referenced.

Evaluating Better Outputs#

Not only should we be able to audit the rules agents are using, but we also need to be able to objectively evaluate how they apply those rules.

Design will always have subjective aspects that require someone to provide their personal opinion. But when we rely solely on subjective evaluation for probabilistic output, it’s very easy to become untethered and lose any meaningful critique. I frequently hear, “This output seems better” or “I think this tool helps.” But no one has established what “good” or “better” mean or how we are measuring it.

Agent evaluations are starting to pick up significant traction across product, design, and engineering communities. I’m optimistic that while the tooling and processes are not where they need to be, we’ll get there. I also see a significant opportunity to work alongside design researchers in this space. Setting up tests, reading through traces, and analyzing patterns objectively are all in their wheelhouse, and that’s most of the evaluation process.

A Bit of Hope#

I hope this was helpful. I’m personally bullish on the design system community figuring this out. We’re systems thinkers, we’re highly adaptive, and we love wrangling chaos. And we’ve got plenty of chaos to keep us occupied for a while.

If I can leave you with a bit of hope, it’s that we solved this problem once, and I know we can solve it again. We don’t have all the tools we need right now, but that’s been true before. We don’t need to rethink everything. We’ve got good instincts. Let’s reframe the problem, focus on building better systems, and share what we’re learning. That has always been our secret to success.