I spent a few years collecting public design systems into my Airtable. I tracked what each system actually ships: tokens, GitHub repos. I have now used AI and gathered valuable insights.

The finding that surprised me most: almost no design system ships all the “layers”. They all make trade-offs. And the trade-offs follow a pattern.

The seven layers of a design system

A design system can serve its users in seven ways. I checked which of these layers each system makes publicly available:

What this tells you

This measures how many layers a system makes available, not how good any layer is. It also only measures what’s public. Some systems have excellent internal Figma libraries, Storybooks, and docs that score low here because the outside world can’t see them. I’m not scoring quality. I’m mapping coverage.

A note on the dataset

The 158 systems were collected from public sources: documentation sites, GitHub repositories, Figma community files, npm registries, and design system directories. Each entry was manually verified against its live URL. Some systems required deeper digging than others.

What the data shows

89% have code examples. That’s the first layer teams build. But after that, each subsequent layer drops off sharply. Only 37% add usage guidelines. Only 21% document accessibility. Only 13% include content guidelines.

Three systems scored a perfect 7: Polaris (Shopify), Paste (Twilio), and eBay Playbook.

The leaderboard

Look at the top. Shopify. Twilio. Workday. Microsoft. Salesforce. These are companies with dedicated design infrastructure teams and years of investment. The gap between them and the average is not small.

Accessibility is still a lower priority

Only 34 systems explicitly mention accessibility. That’s 21%.

4 systems have accessibility issues flagged. Meaning someone noted problems.

Some of these systems probably have accessible components under the hood. They just don’t document it or surface it as a priority. But if you don’t talk about it, your adopters won’t prioritize it either.

The tech landscape

React dominates. But the picture is more interesting than “React won.”

React is the default. More than half of all systems use it. No surprise.

Web Components are the quiet second wave. These are not startups experimenting. These are large organizations making a deliberate bet on framework-agnostic components.

Tailwind is the new entrant. 8 systems: shadcn/ui, daisyUI, Flowbite, Tremor, HeroUI, Nessie, Nuxt UI, Park UI. All relatively new. All growing fast. The utility-first, copy-paste model is rewriting the distribution rules.

15 systems support 3+ technologies. Carbon (IBM) leads with 6: React, Vanilla JS, Angular, Vue, Svelte, Web Components. That’s not a design system. That’s a platform.

The Tailwind gap

This one surprised me.

There are 8 Tailwind-based design systems in the dataset: shadcn/ui, daisyUI, Flowbite, Tremor, HeroUI, Nessie, Nuxt UI, Park UI. They are some of the fastest-growing projects in the ecosystem. shadcn/ui alone has 112K GitHub stars.

But across all 8 systems, not a single one documents accessibility. Not one includes content guidelines.

This isn’t a criticism of Tailwind. It’s a pattern about what happens when the distribution model is “copy this code.” The copy-paste philosophy solves the adoption problem brilliantly. But it skips the layers that make a design system more than a component starter kit. When you own the code, nobody is responsible for documenting when to use it, how to make it accessible, or how to write the words inside it.

The question is whether these systems will fill in those layers as they mature. Or whether the “you own it, you document it” model means those layers never get built centrally.

Tone of voice

Only 21 systems out of 158 include content guidelines. 13%.

But look at which 20. Sainsbury’s. Polaris (Shopify). Atlassian. Lightning (Salesforce). NHS Digital. Pharos (JSTOR). Bolt. Workday Canvas. Paste (Twilio).

These are retail, fintech, healthcare, government, and enterprise SaaS. Industries where getting the words wrong has consequences. An error message that says the wrong thing in a banking app isn’t just bad UX. It’s a compliance risk. A healthcare system that uses inconsistent terminology isn’t just confusing. It’s dangerous.

The systems that ship tone of voice aren’t doing it because they’re more thorough than everyone else. They’re doing it because their industry demands it. Content guidelines aren’t a “nice to have” when regulators read your interfaces.

But compliance isn’t the only reason. When 10 teams use your Button component and each writes different label text, different error messages, different confirmation dialogs, your product speaks in 10 different voices. Content guidelines aren’t a legal checkbox. They’re how you keep the experience consistent at scale. Without them, your design system controls how things look but not what they say. That’s half a system.

The documentation gap

89% of systems have code examples.

But only 37% tell you when to use a component. Only 21% tell you how to make it accessible. Only 13% tell you how to write the content inside it.

33 systems have code examples but no usage guidelines and no accessibility documentation. They show you how to implement a button. They don’t tell you which button to use, when, or why.

A design system without usage guidelines is a component library. A component library without accessibility documentation is a liability.

How many components do the top systems actually ship?

This one gets misunderstood constantly. People equate “big design system” with “lots of components.” The data says otherwise.

The range is massive.

More components is not better. More components is more to maintain, more to document, more to keep accessible. The systems that score highest aren’t the ones with the most components. They’re the ones that document the components they have.

How many design tokens power these systems?

I counted CSS custom properties and documented tokens across the top systems. Some counts are verified from the source code. Others are estimates from documentation.

The popularity contest nobody asked for

npm downloads measure one thing: who gets npm installed. Open community libraries naturally dominate here. Enterprise and internal systems are consumed behind firewalls, not through public registries.

Stars don’t mean what you think

I almost didn’t include this chart. But the myth of “more stars = better system” needs data thrown at it.

The architecture fingerprint

I divided each system’s token count by its component count. The ratio tells you something fundamental about design philosophy.

I’ve thrown a lot of numbers at you. Here’s what they change about how I’d build a design system today.

1. Write usage guidelines before building more components.

2. Add accessibility documentation now.

3. Add Storybook before another component.

4. Ship decision logic, not just components.

5. Content guidelines are required if you’re regulated.

6. Fund it like an infrastructure.

Why this matters more than it used to

I’ve spent the past year building agentic design systems. AI agents that audit tokens, compose patterns, generate documentation, and open pull requests. I wrote about the architecture in Parts 1, 2 and 3 of that series.

But here’s the thing I keep running into: agents can only work with what’s documented. An AI agent can’t use a component that has no usage guidelines. It can’t check accessibility if accessibility isn’t described. It can’t compose a pattern from a system that only ships code and a landing page.

Everyone is talking about AI agents for design systems. This data shows that many systems aren’t ready for a human to use properly, let alone a machine.

Fix the layers first. The agents will follow. 🙌

— If you enjoyed this post, please tap the Like button below 💛 This helps me see what you want to read. Thank you.

💎 Community Gems

MemPalace / Free, local AI memory system that stores your entire chat history and makes it searchable across sessions. 96.6% recall, no cloud, works with Claude/Cursor/ChatGPT

🔗 Link

In Part 1 and 2, I made the case that design systems are the semantic layer that makes AI-assisted design possible. The understanding, not the code, is the asset.

Now let’s talk about the machinery AND the judgment calls. The architecture, the self-healing loop, what AI genuinely cannot do, and three phases you can start this week.

The architecture

This is the architecture I’ve built over the past year.

At the center: Claude Code as the orchestration layer. Connected via MCP to Figma (through my Tidy plugin), to GitHub, to Storybook, to PostHog (analytics) , to Granola (meeting notes), to Sentry for error monitoring, to the documentation layer, and to the Observatory dashboard.

👋 A note on tooling:

Claude Code is not the only option here. Because everything connects through MCP, the orchestration layer is swappable. I’ve tested Cursor, Codex, and other AI coding tools in this setup. I also run the same exercises across new models whenever they come out (Gemini, GPT 5.2 through 5.4, Llama, Mistral) to benchmark how they handle token naming, component composition, and system-level reasoning. Claude Code consistently delivered the best results for design system work, particularly in reasoning about component relationships and token semantics. But the architecture doesn’t lock you in. If a better tool shows up tomorrow, you swap the center, and everything else stays the same. That’s the point of building on a protocol, not a product.

The loop is:

1. Watch. Detect drift in tokens, components, and docs.

2. Analyze. Score severity, prioritize fixes.

3. Execute. Generate PRs, update docs, sync tokens.

4. Observe. Verify results and loop back.

But here’s the thing. This architecture only works because the foundation is solid. Without clean token naming, without component descriptions, without intent documentation, the agent has nothing meaningful to work with.

Six agents, each specialized

I built six agents on top of those MCP connections:

Each has clear boundaries. The Composer doesn't do health scoring. The Guardian doesn't write docs. Specialization matters because it keeps the agents focused and predictable.

The knowledge graph: how the agent knows what to assemble

Remember the destructive confirmation dialog from Part 2? The agent assembled Dialog + Alert + Button destructive. But how did it know THOSE three? How did it know that’s the right combination, and not Modal + Toast + Link?

Because of the knowledge graph.

Every tool knows something. But none knows everything. Here is the example:

The knowledge graph connects the dots. It knows Button destructive has been paired with Dialog in 6 existing patterns across production. It knows Alert warning appeared in 4 of those. It’s not guessing. It’s reading your system’s history.

Think of this as “smart defaults.” We provide the agent with preloaded context for each component combination. The agent doesn’t start from zero. It starts from your team’s accumulated decisions.

That’s the difference between an AI that generates components and an AI that understands your system.

And here’s the thing most people miss: the knowledge graph is not a database. Example below:

Tidy: the quality gate

Every AI tool I tried could generate components, but none could tell me whether the result was actually correct. Was the naming right? Were the tokens semantic or primitive? Did the component follow our conventions? I needed something that could answer those questions automatically, not after a manual review, but in the moment.

So I built Tidy: a Figma plugin and an MCP server. The plugin validates inside Figma. The MCP server lets AI agents do the same thing from the terminal. What started as a simple naming validator grew into over 100 tools that cover everything from token auditing to pattern composition to documentation generation.

Tidy has two faces:

The Figma Plugin audits naming, tokens, and components. Scores health across 6 categories. Validates new variables. Navigates to issues on the canvas.

The Agent Integration exposes 100+ tools via MCP. Create, alias, and batch-update tokens. Compose patterns from natural language. Run accessibility audits. Generate component specs. Check design-code parity. Run any Figma Plugin API from the CLI.

One command. Is color.bg.danger applied correctly? Is the naming consistent? Are the component descriptions present? Is auto-layout used? Full scan, instant feedback.

This is the quality gate before anything ships.

The evolution was important here. I started with static context files. Rules files, token definitions, and component templates that you feed to Cursor or Claude. It works. But every token change means a manual update. Every new component means editing the template. That friction is exactly what led me to build Tidy. A live connection to Figma instead of a static snapshot.

The Token Intent Validator: guardrails, not just components

Back to our dialog component. The agent composed it with color.bg.danger for the destructive button. But what if someone manually swaps that to color.bg.primary because it “looks nicer”?

The Token Intent Validator catches it. Red flag: primary token used in a destructive context. Intent mismatch.

It detects:

• Raw hex colors used instead of tokens

• Primitive tokens like blue.500 used directly in components

• Status color misuse (danger in the wrong context)

• Intent-property mismatches

And it’s context-aware. It knows the difference between a button in an alert versus a button in a card.

Design teams need to invest in guardrails. Not just components. Not just tokens. The rules that prevent your system from degrading over time.

Pattern composition: where everything converges

Pattern composition is where everything comes together. The agent acts as a Composer.

You say “create a login form” and it assembles the right components with the right variants and the right tokens. Input default, input password, button primary. It knows the composition because of the reasoning layer.

Now the payoff. Remember the destructive confirmation dialog? This is what the agent built:

• Dialog container

• Alert with warning slot

• Button destructive for the action

• Button secondary for cancel

• color.bg.danger on the action

• Semantic color mapping

• Auto-layout with proper spacing

The agent didn’t design this. It assembled it. From the index, the metadata, the reasoning, and the knowledge graph. Every layer we talked about converges here.

Four patterns. Four different intents. Same system. Same agent. Different outputs because the CONTEXT is different.

And one more thing: one command. I type generate-code Dialog in the terminal, and five files appear. The React component, the CSS module with design tokens, tests, Storybook stories, and a barrel export.

The self-healing loop

Self-healing systems are not a new idea. IBM published the MAPE-K control loop in 2003. Monitor, Analyze, Plan, Execute, with a shared Knowledge base in the center. It’s been running server farms and cloud platforms for over twenty years.

I just applied it to design systems.

Here’s what it looks like in practice. The destructive dialog shipped. A week later, a developer on another team needs the same pattern. But instead of using the composed version, they fork it. They hardcode #DC2626 instead of using color.bg.danger. They skip the cancel button.

The self-healing loop kicks in:

Detect. Tidy scans and finds a raw hex value in a dialog context. And a destructive action without a cancel pair.

Score. Observatory drops the health score from 96 to 84. Two violations, one structural.

Fix. Claude + Tidy MCP opens a PR. Replaces the hex with color.bg.danger. Adds the missing cancel button based on the component metadata that says “always paired with a cancel option.”

Verify. Re-run the audit. Health back to 96. Tests pass.

Learn. And here’s the important part. That fork taught the system something. It captured a new anti-pattern: “hardcoded red in dialog context.” Next time anyone tries the same shortcut, the agent flags it BEFORE review.

Every mistake makes the system smarter. That’s the flywheel.

Automated documentation

Documentation is the first thing that drifts. So I automated it.

Four triggers:

1. A variant gets added in Figma

2. A token alias changes

3. Health drops below threshold

4. A pattern gets promoted as canonical

Four outputs:

1. A changelog

2. A component spec with props and variants

3. Do/Don’t usage guidance

4. A migration plan when tokens are deprecated

No one has to remember to update the docs. The system does it.

I use Mintlify. I already wrote about this setup.

The Observatory: my dashboard

The Observatory is a dashboard that shows the health of your design system in real time. Token compliance, naming scores, component coverage, and drift over time.

This is what turns gut feeling into data. Instead of someone saying, “I think our system is getting messy,” you have a score.

Everything connects

Here’s the deeper truth behind everything I’ve shown you:

• The Token Intent Validator encodes what tokens mean

• Tidy’s 100+ tools encode what correct looks like. That becomes governance.

• The Observatory encodes health over time. Component adoption, team usage, drift detection.

• The knowledge graph connects data from tools. All queryable.

• The learning flywheel captures every human correction and makes the next suggestion better.

Every tool is a seed. The tree is the context-aware design system.

It does not matter if you can hook up a CLI to Figma if you’re not implementing strategic work. Define your naming conventions. Write your component intent. Map your token relationships. Build the guardrails. Then point the agents at it.

And babysit every PR at the start. Review every suggestion. Correct every mistake. That’s how the agent learns your standards. Only some tasks will ever earn the right to merge automatically. The goal was never full autonomy. The goal is safe autonomy. The agent earns trust the same way a new team member does: by being right, consistently, over time.

Here’s what governed autonomy looks like in practice:

There’s an approval queue, an escalation queue, and a full audit log.

This is not about letting AI run wild. It’s about making governance programmable.

The trust level system

Every time you hand over decision-making to an agentic system, you’re giving up control. You want to make sure the agent has earned that trust.

The trust system works like a team member’s career progression:

But the level alone doesn’t decide what happens. Every action goes through a decision matrix:

• Low risk, high confidence, trust level allows it? Auto-merge. Ship it.

• Low risk, but confidence is low? Draft a PR and request review. Don’t guess.

• High risk, any confidence? Always human review. No exceptions.

• Unknown? The agent doesn’t pretend. It logs, learns, and suggests. That’s it.

That last row is the important one. The system knows what it doesn’t know. And when it doesn’t know, it watches. It doesn’t act.

What AI can’t do at the moment

Not everything is perfect. I think it’s important to be honest about what doesn’t work, because the hype around AI agents can set the wrong expectations.

AI can fix:

• Naming violations

• Token inconsistencies

• Structural issues (missing auto-layout, wrong nesting)

• Documentation generation

• Repetitive auditing

AI cannot fix taste.

Here’s what doesn’t work yet:

• Novel problems are still yours.

• Multi-file awareness across repos isn’t there yet.

• Cross-team conflict resolution needs a human.

• Full autonomy is graduated. Most tasks stay at Level 2 or 3.

But there is something important to know.

When a human expert fails, they come back with a reason. They own the mistake. They explain what went wrong. They adjust. With agents, 25 failures land on your desk, and none of them come with insight. No ownership, no explanation, no learning. And if nobody is reviewing those failures, nobody takes responsibility. That’s still your job.

No matter what, you have to try. Start small, observe what works, throw away what doesn’t. Every correction teaches. Every rejection refines. That’s the flywheel. But invest in guardrails, not just components. Without clear vision, the flywheel just spins faster in the wrong direction.

Stay tuned for more. 🙌

Happy Easter. 😍

— If you enjoyed this post, please tap the Like button below 💛 This helps me see what you want to read. Thank you.

💎 Community Gems

Product in the Age of AI: Designers on How Their Role Is Changing from
(I described my workflow and opinions)

🔗 Link

This year I gave a talk at the Into Design Systems conference called Agentic Design Systems. The response genuinely caught me off guard. Thank you to everyone who showed up, stayed engaged, and sent those messages. It means more than you know.

A year ago, I already presented at IDS and talked about context-aware design systems. A vision. Something we could see coming but couldn’t quite build yet.

This year, I came back with tools, numbers, and failures. Real ones.

This series covers everything from that talk. Not as a transcript, but as something you can actually use. If you’re building a design system today, or thinking about what AI means for your system, this is for you.

Let’s start with the shift that changes everything.

Your design system is infrastructure

Before anything else, I need to set one thing straight.

A design system is not a side project. It is not a nice-to-have. It is infrastructure. The same way your CI/CD pipeline is infrastructure. The same way your database is infrastructure.

And right now, in 2026, design systems are more important than they have ever been. Every product team is shipping faster than ever. AI is generating code at scale. And the only thing standing between your product and total inconsistency is the system that governs it.

Design systems reduce rework. They enforce brand. They catch accessibility issues before your users do. If you still need to justify your design system to leadership, frame it as infrastructure. Because that’s what it is.

The design system is the API that allows AI to build your product safely.

That’s not a metaphor. That’s literally what’s happening.

The numbers that should wake you up

Let me set the scene with what happened in the 12 months between IDS 2025 and IDS 2026:

• 28+ frontier models released by 6 major labs in under 10 months

• $226 billion invested in AI. Nearly 2x the year before.

• 84% of developers now use AI tools daily

• 41% of all new code written in 2025 was AI-generated

Claude Code hit a billion dollars in revenue in under 12 months. The MCP ecosystem went from 100K to 8 million downloads. Gartner says 40% of enterprise apps will embed AI agents by end of this year.

This is the environment your design system lives in. Code is being generated faster than anyone can review it.

And that changes everything about how we think about governance.

The economics have flipped

When code is cheap and understanding it is expensive, architecture must optimize for the impermanence of code.

We all know by now that developers using AI agents ship faster. Studies show a 39% productivity increase. But the interesting part is where the gain comes from. It's not that people write more code. The work shifts from syntactic to semantic. From "how do I write this" to "what should this do and why."

That’s exactly the shift design systems need to make.

A developer can generate a button component in 30 seconds with AI. But that button won’t know it should use your danger token inside an alert. It won’t know it should be secondary inside a card. It won’t respect your spacing scale.

The code is free. The understanding is the expensive part.

And that understanding? That’s what your design system encodes. Your tokens, your naming conventions, your component intent, your usage guidelines. That’s the real asset.

So when people ask me “will AI replace design systems?” I tell them: AI makes design systems more critical than ever. Because AI generates code. Design systems generate understanding.

How an agent actually works

Let me make this concrete. One story runs through the entire talk: a team needs a destructive confirmation dialog.

A developer says: “I need a confirmation dialog for deleting a workspace.”

Watch what happens when an agent handles this:

1. Reading context. It pulls in your component index, your token structure, your usage guidelines.

2. Thinking. It knows Dialog exists. It knows Button has a destructive variant. It knows Alert has a warning slot.

3. Planning. Dialog + Alert + two Buttons. Destructive primary, secondary cancel. color.bg.danger for the action, not color.bg.primary.

4. Acting. It assembles the pattern, applies the right tokens, and generates the code.

What makes it agentic is three things: autonomy, tool use, and feedback loops. It doesn’t just answer a question. It takes action, observes the result, and adjusts.

But here’s the key: none of this works unless the agent has something to read. The components need to be described. The tokens need intent. The patterns need reasoning.

That’s what the rest of this series is about.

Intent changes everything

The flow looks like this:

Intent (natural language) -> Context (extracted dimensions) -> System output (specific guidance)

“I need a confirmation dialog for deleting a workspace” is the intent.

The system extracts five dimensions from that: component type, action severity, user flow, token scope, platform. These are the lenses the agent looks through.

The output isn’t a vague suggestion. It’s specific: Dialog + Alert + 2 Buttons. color.bg.danger token mapping. “Always pair with cancel” rule. A link to the Dialog component in Figma. A suggested composition template.

The agent doesn’t guess. It reads your system’s rules through these context layers.

This only works if those rules exist.

MCP: USB for AI

For any of this to work, the agent needs to connect to your tools. That’s where MCP comes in.

Model Context Protocol is a standard way for AI agents to connect to external tools. Think of it as USB for AI. Instead of building custom integrations for every tool, you expose your tools as MCP servers and any AI agent can use them.

My most used MCPs: Figma, GitHub, Storybook, Chromatic, Granola, Notion, Jira, Stylelint, Linear, Mintlify. Each one gives the agent a different slice of context.

CLI vs MCP: you need both

A practical question I get a lot: do I need MCP for everything?

No. CLI and MCP serve different purposes.

CLI is for speed. Direct command execution. Simple setup. No servers, no schemas. Fast experimentation. Designers can start immediately with local tools. Less context overhead, fewer reasoning loops. Great for single-tool workflows, like tasks happening entirely inside Figma.

Here’s what CLI looks like in practice.

I built a token command that resolves Figma token values straight from the terminal:

$ token color.bg.danger
→ #DC2626 (alias: primitives/red-600)

Or composing a full UI pattern with one shell script:

$ ./patterns/run-pattern.sh destructive-confirmation
→ Creating frame in Figma...
→ Dialog + Alert + Button(destructive) + Button(secondary)
→ Tokens bound: color.bg.danger, color.text.on-danger
→ Done. Check your Figma canvas.

No MCP server running. No schema negotiation. Just a direct HTTP call to a Figma plugin that exposes a local API, and the pattern appears on your canvas (will share more in part 3). You can read token values, compose patterns, and run audits without any agent infrastructure. That’s the power of CLI: you go from zero to useful in minutes.

MCP is for scale. When the agent needs to orchestrate multiple tools. Connect Figma, GitHub, Storybook, docs, CI in one flow. The agent understands structured design data: components, tokens, variants. Changes propagate end-to-end from design to code to docs. It enables autonomous agents that detect, analyze, plan, and fix. Standardized protocol that runs in CI pipelines. Scales across teams.

Where MCP shines is when the agent needs to connect the dots across tools. “A token changed in Figma. Which components use it? Which pages are affected? What’s the traffic on those pages? Should I open a PR?” That’s four different data sources (Figma, GitHub, PostHog, the knowledge graph) orchestrated in one flow. CLI can’t do that. MCP can.

CLI for speed. MCP for scale. The best systems use both. We used both in our setup: Tidy’s HTTP API for CLI-speed pattern composition, with MCP’s structured component and token data for the orchestration layer.

The three layers that make components machine-readable

This is where most design systems fall short. I see teams with a component library and tokens, but the agent can’t do anything useful with them because they’re missing layers.

There are three layers an agent needs:

Layer 1: The Index

What exists, what uses what, what depends on what.

The agent knows Dialog exists. It knows Button has 4 variants. It knows Alert connects to both. This is the relationship map.

Without the index, the agent is blind.

Layer 2: Metadata

This is the how and why.

The component description for Button says: “use the destructive variant for irreversible actions, always paired with a cancel option.”

That single sentence is what told the agent to add a secondary cancel button. Without metadata, the agent knows components exist but not when to use them.

Layer 3: Reasoning

The selection logic.

For a confirmation dialog, compose Dialog + Alert + two Buttons. For a login form, compose Input + Input + Button.

This is the playbook. Without reasoning, the agent assembles random parts.

Most design systems today have some of layer one, very little of layer two, and almost none of layer three. That’s the gap we need to close.

And closing it is not a year-long project. Writing 554 component descriptions took me one session with AI.

Context makes the same component behave differently

Here’s what context-aware means in practice.

Same component: Button. Three different contexts:

• In an alert: use bg-danger. Intent: destructive action. Always pair with a cancel button.

• In a card: use bg-neutral. Intent: secondary action. Don’t compete with page-level CTAs.

• In the nav: use bg-brand. Intent: conversion action. One per nav bar maximum.

Same Accordion component. FAQ gets question-phrased headers (”How do I reset my password?”). Settings gets noun-phrased headers (”Notification settings”).

The agent writes different docs for each because it knows WHERE the component lives, not just what it is.

But here’s what nobody tells you: if the agent knows where a component lives, it can infer most of this automatically.

Take Accordion. The agent sees it in FAQ, in Settings, and in Checkout. Same component. Three different contexts. Now it can write three different sets of documentation without anyone asking.

It figured that out by looking at 34 instances across 6 products. It can generate do/don’t examples. It can prioritize: a component on homepage and checkout is more critical than one only in admin.

The agent doesn’t just know the component spec. It knows the business context. And you get this for free if you map which pages represent which products.

Plant seeds, not trees

I showed two videos in the talk.

First one: seeds. You plant them. You water them. You wait. Growth is slow but it’s real.

Second one: trees. You buy them fully grown and drop them into your garden. Looks impressive on day one.

Every team I talk to wants the tree. They want the fully autonomous agent that fixes everything. But that’s not how this works.

You have to plant seeds. You have to build the foundation first: the naming conventions, the token structure, the component descriptions, knowledge graph. Then the automation grows on top of it.

Without structure, AI amplifies noise at scale. With structure, it amplifies understanding.

What this means for you

If you take one thing from this part of the series, let it be this:

The asset is not just the code. The asset is the understanding.

Your design system’s value isn’t in the React components or the Figma library. It’s in the naming conventions, the token intent, the component metadata, the usage reasoning, your knowledge graph. That’s what AI reads. That’s what makes the difference between a generic button and a button that belongs in your product.

Start there.

The rest of the series shows you how.

Next up: Part 3: The Self-Healing Design System where I’ll show the architecture, the MCP connections, the knowledge graph, and the self-healing loop that catches problems before they ship.

Stay tuned,
Romina

— If you enjoyed this post, please tap the Like button below 💛 This helps me see what you want to read. Thank you.

💎 Community Gems

Granola

If you want to make an extra step when setting up an agentic design system, connect meeting notes to Claude via MCP and start using Granola. 🔥
I use Granola and as additional data layer.

Granola is an AI notepad that transcribes your calls in the background.

NO MEETING BOTS.
No weird "AI assistant has joined the call."

You take notes as you normally would, and Granola automatically turns them into structured summaries, action items, and next steps. It works on both Mac and Windows.

But here's where it gets powerful.

Granola supports MCP (Model Context Protocol).
That means your meeting notes flow straight into Claude or ChatGPT as searchable, queryable context. 🤯

Instead of digging through old notes, I ask:

* "What did we decide about the component API last Tuesday?"
* "Pull all action items from client calls this month."
* "Summarize feedback from our last three design reviews."

5 seconds, boom, done. ✅

My workflow:

↪️ Meeting happens. I add quick notes. Granola transcribes in the background.
↪️ Meeting ends. Summary, action items, and next steps are ready instantly.
↪️ Recipes (pre-made prompts) help me write follow-ups or prep for the next call.
↪️ Zapier pushes action items to Linear, Jira, wherever work lives.
↪️ MCP connects it all to Claude. Every past conversation becomes a context I can query.

Try it and thank me later ☺️ I've got a link to a free month

Recommended read → UX + AI written by ✨

This is a space for curious minds who care about how we design, build, and think about digital products in a world shaped by AI. Really recommend you follow Ileana and learn something new every week.

UX + AI

Product in the Age of AI: When Product Manager and Designer Skills Start to Overlap

Over the last two years, the rise of AI has reshaped the design world…

Read more

2 months ago · 66 likes · 28 comments · Ileana, Karo (Product with Attitude), Elena | AI Product Leader, and Just J

🔗 Link

I am not affiliated with any of the suggested tools

I know what you’re thinking.

“Vector databases? That’s for AI engineers and data scientists. What does that have to do with my design system?”

Here’s the thing: Vector databases solve a problem that design systems desperately need to solve, too.

They organize information by meaning, not just by structure.

And that changes everything.

The Problem With How We Organize Design Systems Today

Right now, your design system is probably organized like a SQL database.

You have rigid hierarchies:

• Components → Buttons → Primary → Hover State

• Tokens → Color → Background → Primary

It’s clean. It’s logical. It works.

But here’s what it doesn’t do: It doesn’t help you find things based on what they mean or why you’d use them.

When a designer asks, “What should I use for a destructive action?” they have to translate that intent into your taxonomy. Is that a “danger button”? A “negative action”? A “warning state”?

You didn’t have to memorize the exact folder structure in your brain. You just had to know the right keywords.

But what if your design system could understand intent?

How Vector Databases Actually Work

Let me show you what I mean.

Vector databases don’t store data in rows and columns. They store meaning as high-dimensional numerical coordinates.

Here’s a simple example:

When you search for “king” in a vector database, it doesn’t just find exact matches. It finds concepts that are semantically similar:

• “queen” (same domain, different gender)

• “monarch” (same meaning, different word)

• “ruler” (related concept)

The database understands that these concepts cluster together in meaning-space.

Now imagine applying that to your design system.

What Changes for Humans

You Can Search by Intent, Not Just by Name

Instead of browsing through component categories, you could ask:

“Show me all patterns that convey urgency”

And your design system would return:

• Error messages

• Warning banners

• Destructive action buttons

• Toast notifications with alert icons

• Red status indicators

These components live in completely different parts of your taxonomy. But they share semantic meaning.

That’s the power of meaning-based organization.

You Can Finally Solve the “New Component vs. Variant” Debate

I’ve sat through countless design system meetings where teams debate:

“Do we need a new component, or is this just a variant of what we have?”

I’ve seen this firsthand. When you’re looking at a system with 50, 80, even close to 100 components, the overlaps become invisible. Manual audits catch some of them. But naming differences, context differences, and organic growth across teams create duplicates that no spreadsheet review will surface.

Vector logic could actually quantify similarity between components.

Compare two components based on:

• Visual embeddings (how they look in Figma)

• Code structure (how they’re built)

• Token usage (what design decisions they share)

• Usage context (where they appear in products)

If two components score high similarity across these dimensions, you probably don’t need both.

You might be wondering, “How accurate is this really?”

That’s fair. But here’s what I’ve learned: You don’t need perfect similarity scores. You need better visibility into what you already have.

Even a rough similarity map helps you spot duplicates that manual audits miss.

What Changes for Agents

AI Tools Actually Know What to Use

Here’s where it gets interesting for agentic design.

Right now, when an AI tool generates a UI, it relies on your component names and descriptions. It’s essentially doing keyword matching.

But with vector-based context retrieval, the AI could understand:

“I’m building a form validation error. What components, patterns, tokens, and accessibility guidelines are semantically related to this task?”

The system retrieves:

• Similar error patterns from your existing designs

• The correct tokens (not just “red” but “color.feedback.error”)

• Accessibility requirements for error announcements

• Validation timing patterns

• Microcopy guidelines for error messages

All pulled together by meaning, not by manual tagging.

Design Tokens Could Become Behavioral

Traditional tokens store values: color.blue.500 = #3B82F6

Vector-inspired tokens could store behavioral meaning:

• How assertive (0.8 on a scale)

• How calm (0.2)

• How noticeable (0.9)

Now imagine an adaptive interface that reads the user’s context and adjusts its tone.

Picture a checkout flow. The payment fails. Instead of the UI just swapping in a red banner, the entire interface shifts. Visual assertiveness dials down. Calmness increases. The system isn’t just showing an error state. It’s modulating the experience to match the emotional weight of the moment.

A celebration moment? It cranks up energy and noticeability.

The same components, but contextually tuned based on meaning vectors, not just static values.

Components Gain Semantic Elasticity

In agentic systems, context determines behavior.

Take a toast notification. It can:

• Confirm a successful action

• Warn about a risky operation

• Inform about system status

• Celebrate an achievement

Right now, you’d handle these with separate variants or different components entirely.

But with vectorized meaning, a single component could adapt based on detected intent.

The system reads the context (”this is a celebration”) and adjusts:

• Color intensity

• Animation style

• Icon selection

• Duration on screen

All semantically informed, not hardcoded.

Compare that to manually coding every possible variant upfront. The difference is massive.

The Reality Check

Let me be honest: Most design systems aren’t ready for this yet.

This isn’t because the technology doesn’t exist. Vector databases are mature. Embedding models are accessible.

The challenge is conceptual.

We’ve built design systems around structure: hierarchies, taxonomies, strict naming conventions.

Shifting to meaning-based organization requires rethinking:

• How we document components

• How we describe patterns

• How we train our teams

• How AI tools interact with our systems

It’s a fundamental shift from “what is this thing called?” to “what does this thing mean?”

What This Actually Looks Like

You don’t have to rebuild your entire design system around vectors tomorrow.

But you can start thinking differently today.

Here’s what that might look like:

Start with documentation:

• Add semantic descriptions to components: “This pattern expresses urgency and requires immediate attention.”

• Tag components with intent, not just categories: “confirmation,” “prevention,” “celebration.”

• Describe usage contexts: “Use when the user needs reassurance that their action succeeded.”

Experiment with embeddings:

• Generate vector embeddings for your component descriptions

• Build a simple similarity search

• See what clusters emerge naturally

Augment, don’t replace:

• Keep your existing taxonomy

• Layer semantic search on top

• Let both approaches coexist

The next generation of design systems will likely blend:

• Token databases (structured facts)

• Vector databases (semantic meaning)

• Context engines (runtime reasoning)

➡️ That’s how you get agentic design systems. Systems that understand why a component exists, not just what it’s called.

Try This

If you’re ready to experiment, here’s where to start:

1. Pick 10-20 components from your system

2. Add a semantic description for each: What’s its purpose? When would you use it? What feeling does it convey?

3. Use an embedding model (OpenAI’s text-embedding-3-small works well) to generate vectors

4. Run similarity comparisons between them

5. Look at what clusters together

You might discover patterns you didn’t know existed.

You might find duplicates hiding under different names.

You might see how your system could be organized by meaning instead of taxonomy.

And that’s when design systems start to get really interesting. 🙃

Next week, I will share more about Agentic Design Systems, my setup, and MCP. ✨

Stay tuned,
Romina

— If you enjoyed this post, please tap the Like button below 💛 This helps me see what you want to read. Thank you.

💎 Community Gems

Building Effective AI Coding Agents for the Terminal: Scaffolding, Harness, Context Engineering, and Lessons Learned

AI agents suffer from the same problem as large design systems:

Context collapse. A new 55-page paper on terminal coding agents explains why.👇

AI agents in long sessions forget their instructions, bloat their context, and start making bad decisions.

🔗 Link

I am not affiliated with any of the suggested tools

Everyone wants to add AI agents to everything right now. Your design system is no exception.

Someone on your team has already suggested it. “What if we built an agent that validates token usage?”

Let me give you a framework to figure out when an agent actually makes sense, when a simple workflow does the job, and when you should just write a shell script and move on with your life.

First, what is an agent?

An agent is an LLM that can use tools and take actions. Not just answer questions. Act.

That’s the key difference from a regular AI chat. When you ask ChatGPT or Claude a question, it generates a response and stops. It lives entirely inside the conversation. It can’t open your files, check your codebase, run a command, or push a commit. It can only talk.

An agent can do all of those things. It has access to tools such as your file system, terminal, APIs, design token files, and Figma. When you give it a task, it doesn’t just tell you what to do. It reads your code, finds the problem, writes a fix, runs the tests, and tells you what happened. Then it decides what to do next based on the result. If the tests fail, it reads the error, adjusts, and tries again.

Here’s what that looks like in practice. You tell an agent: “Check if our Button component matches the Figma design.” The agent:

1. Connects to Figma’s API and pulls the design specs for the Button component.

2. Reads your component source code to understand the current implementation.

3. Launches a browser using Playwright, navigates to your Storybook, and takes a screenshot of the rendered Button.

4. Compares the screenshot against the Figma design and flags differences: wrong padding, missing hover state, border-radius off by 2px.

5. Writes a summary with specific suggestions and the exact lines of code to change.

No single tool does all of that. The agent stitched five tools together on its own and decided the order. That’s the difference. A chat would have told you how to do the comparison. The agent did it.

So, you tell it what you need, and it figures out the steps. Sometimes it asks for clarification. Sometimes it goes down the wrong path and corrects itself. Sometimes it nails it on the first try.

The other key difference is from a workflow: an agent chooses its own path. A workflow follows steps you defined in advance. When the task is predictable, a workflow wins. When the task requires adapting to what it finds along the way, that’s where agents earn their keep.

How do you actually make an agent?

You don’t need to write code to use an agent. Tools like Claude Code, Cursor, and GitHub Copilot are agents you can use right now. Open a terminal, point Claude Code at your codebase, and ask it to do something. That’s it. You’re using an agent.

But if you want to build your own, the format is simpler than you’d expect. At its core, an agent is just three things:

1. Instructions. A markdown file or system prompt that tells the agent who it is, what it knows, and how it should behave. Think of it as the job description for your intern.

2. Tools. What the agent can actually do. Read files, search code, call APIs, run commands, edit files. You decide what to give it access to.

3. A loop. The agent reads its instructions, picks a tool, uses it, looks at the result, and decides what to do next. It keeps going until the task is done or it gets stuck.

That’s the whole architecture. Instructions, tools, loop.

For design systems specifically, the most common entry points are:

• Claude Code with a CLAUDE.md file. You write a markdown file describing your design system’s conventions, token structure, component patterns, and coding standards. The agent reads it before every task. This is the lowest-effort way to get a design-system-aware agent.

• Custom MCP servers. The Model Context Protocol lets you expose your design tokens, component docs, or Figma data as tools an agent can query. Your agent can now look up your actual token values, not guess at them.

• SDKs for full control. Anthropic’s Agent SDK, OpenAI’s Assistants API, and frameworks like LangChain let you build agents programmatically. More power, more complexity. Only go here if the simpler options aren’t enough.

You don’t need to start with SDKs. Start simple with Claude Code and a well-written CLAUDE.md file. Start there.

Agents have opinions

And agents have opinions. A recent study of 2,430 Claude Code interactions found that in 12 out of 20 task categories, the agent chose to build a custom solution rather than recommend an existing tool. Asked to add feature flags? It builds a config system from scratch instead of reaching for LaunchDarkly. Asked about authentication? It implements JWT + bcrypt rather than suggesting Auth0.

This matters for design systems. Point an agent at your token validation problem and it will happily build you a custom solution. That might be exactly what you need. Or you might have been better off with an ESLint plugin that already exists. The agent won’t make that call for you. You have to.

The hype is real, but so is the waste

Peter Steinberger, creator of OpenClaw (the fastest-growing GitHub project ever), just joined OpenAI. His mission: “build an agent that even my mum can use.” Gartner published a report on February 13 about “context graphs” as essential infrastructure for agentic systems. Enterprise is all-in.

But Anthropic, the company behind Claude, says something much more grounded in their “Building Effective Agents” guide: find the simplest solution possible, and only increase complexity when needed.

That’s worth repeating. The company selling you AI agents is telling you not to build agents unless you have to.

Why? Because agents trade latency and cost for better task performance. They consume roughly 4x more tokens than simple chat interactions. Multi-agent systems? Try 15x. And when something goes wrong, you don’t get a nice red error message. You get a token bill that looks like someone put an API call inside an infinite loop.

For most design system work, a workflow or a well-written script will outperform an agent. Less cost, faster execution, more predictable results.

By the way, these are typical token drivers:

• System + tool schemas → High upfront cost

• Planning / reasoning loops → Medium–high

• Tool outputs re-ingested → High

• Memory retrieval → Medium

• Self-reflection / retries → High

✨ A simple chat = 1 request → 1 response
✨ An agent = plan → act → observe → reflect → retry

Agent Skills are modular capabilities that extend AI coding assistants. Each skill consists of a SKILL.md file with instructions, plus optional scripts and templates. In December 2025, Anthropic released the Agent Skills specification as an open standard, and OpenAI adopted the same format for Codex CLI and ChatGPT. Skills are model-invoked—the AI automatically decides when to use them based on context.

🔗 https://skillsmp.com/

A five-question checklist

1. Is the task complex enough?

If the task follows the same steps every time, you want a workflow. If it requires judgment, adaptation, and handling unexpected situations, you might want an agent.

Token linting is a workflow. You know the rules. Check if raw hex values are used instead of tokens. Flag primitive tokens used directly in components. Run it on every PR. Done. No agent needed.

But reviewing a new component design against your entire design system’s guidelines, considering context, brand, accessibility, and platform constraints? That requires judgment. That’s agent territory.

2. Is the task valuable enough?

If each task run saves less than $0.10 of human time, use a workflow. If it saves more than $1.00 per run, an agent starts making economic sense.

Checking a file for unused imports? Pennies. Not worth an agent.

Migrating 200 components from one token schema to another, where each component needs contextual decisions about which new token maps to the old one? That’s hours of human work per component. An agent pays for itself on the first run.

3. Are all parts of the task doable?

This one trips people up. If your agent needs to access Figma’s internal rendering engine, read a designer’s mind about intent, or make pixel-perfect visual comparisons without any ground truth, you don’t have an agent problem. You have a scope problem. Reduce it until every step is technically feasible.

4. What is the cost of error?

High cost of error means read-only access and human-in-the-loop. Low cost of error means you can let agents run autonomously.

An agent that suggests documentation updates? Low risk. A human reviews before publishing. Let it run.

An agent that automatically pushes token changes to production across 12 codebases? Extremely high risk. One wrong semantic mapping, and your entire product suite has the wrong error colors. Keep this read-only, with human approval gates at every step.

5. Can you trust the output?

There’s a design systems angle to agents that almost nobody is discussing yet. Design systems are trust infrastructure.

Teams adopt your tokens, components, and patterns because they produce consistent, predictable results every time. Agents introduce variability. Run the same prompt twice, and you might get two different outputs. That’s fine for a blog draft. It’s a problem when the agent is deciding which semantic token maps color.background.danger across your component library.

So before you deploy an agent into any design system workflow, ask yourself: is the output deterministic enough that teams can rely on it? Can you audit what the agent did and why? Can someone else reproduce the result? And when the agent makes a choice, can it explain its reasoning in terms your team actually understands? If the answer to any of those is no, you don’t have an agent problem. You have a governance gap. Close it before you ship.

Three core principles for agents from Anthropic:

1. Simplicity in design

2. Transparency → explicitly show planning steps

3. Careful ACI (agent-computer interface) → invest heavily in tool documentation and testing

Applying this to real design system work

Let me walk through five common scenarios.

Token validation → Workflow

The rules are static. You know exactly what correct looks like. Check if raw hex values are used instead of tokens, flag primitives used directly in components. AST parsing and token matching are solved problems. Each individual check is cheap, and false positives are just noise.

Write a linter. Run it in CI. Done.

Component documentation generation → Agent with human review

This one gets interesting. Reading code, extracting props, understanding usage patterns, writing clear descriptions. There’s real judgment involved. And documentation is the #1 complaint about every design system, so the payoff is high.

But bad docs are annoying, not destructive. So scope it to generating drafts. The agent handles the tedious extraction and first pass. You handle the voice and accuracy check. A human approves before merging.

Design review against guidelines → Scoped agent

Context matters enormously here. A red button is fine in a destructive action confirmation, wrong in a success state. Manual design reviews are a bottleneck for every team, so the value is obvious.

The problem is feasibility. Visual comparison is hard. Semantic analysis of intent is harder. And bad feedback wastes designer time and erodes trust.

So reduce scope to what’s actually doable. Token usage, spacing consistency, accessibility requirements. Leave subjective judgment (layout quality, visual harmony) to humans. Be honest about what the agent can and cannot evaluate.

Cross-codebase migration → Agent with strict guardrails

This is where agents genuinely shine. Every component has unique context, dependencies, and edge cases. Migrations eat months of team time. It’s the single most valuable automation you could build.

But it’s also the most dangerous. One wrong semantic mapping and your entire product suite has the wrong error colors.

Run agents with read-only access first. Generate migration PRs for human review. Never auto-merge. Test each migration against visual regression snapshots before approving.

Generating new components from Figma → Agent

Translating design intent to production code involves many judgment calls. Hours saved per component. Tools like Claude Code already do this well when given proper context (your existing components, tokens, and conventions).

The agent generates a first pass. A developer refines it. Bad code gets caught in review. This cuts component creation time from days to hours.

The “90% workflow” test

Anthropic’s framework includes a brutally practical insight. Track your agent runs for a month. If the agent does the same tasks in the same order for 90% or more of cases, you’ve discovered a workflow hiding inside an agent.

Convert it. You’ll get faster execution, lower costs, and more predictable results.

Most design system automation falls into this category. Token syncing, changelog generation, accessibility checks, component scaffolding. These are all repetitive, well-defined tasks. Build them as workflows. Save agents for the genuinely complex work.

Start here

If you’re considering agents for your design system, start with this:

1. Audit your manual tasks. List everything your team does repeatedly and time needed for each one.

2. Score each task against the four questions. Be honest about complexity and error cost.

3. Build workflows first. Linters, CI checks, and scripts handle 80% of design system automation needs.

4. Pilot one agent use case. Pick the highest-value, lowest-risk task from your audit. Documentation generation is usually the safest starting point.

5. Measure ruthlessly. Track time saved, error rates, and token costs. If the agent isn’t clearly outperforming a workflow, simplify.

The goal isn’t to have the most sophisticated AI setup. The goal is to free your team from repetitive work so they can focus on what actually matters: making decisions about your system’s direction, quality, and adoption.

Don’t build an agent because you can. Build one because nothing simpler will do the job.

The real way to learn this

Pick a small problem you actually have. A report you have to manually compile. A workflow that’s tedious. A prototype you wish existed.

Spend 30 minutes writing context before you prompt. Not the prompt itself. The context. What the problem is, who it’s for, what good looks like, what constraints exist.

Point an agent at it and watch what happens. Don’t expect perfection. Expect a starting point. React to it. Guide it. Iterate.

Do this ten times. With different problems. Different levels of complexity. You’ll develop intuition for what works, what context matters, how to evaluate output.

The hard part is still the same thing→ understanding the problem, user empathy, judgment, taste.

Those don’t get automated. They get more valuable. 🙌

Start building,
Romina

— If you enjoyed this post, please tap the Like button below 💛 This helps me see what you want to read. Thank you.

💎 Community Gems

Component Odyssey (Course)

Learn to build and publish your own component library that works in any web framework.

Save yourself and your company weeks of development time. Build components your users will love. Become a future-proof web developer.

🔗 Link

Paper (just launched)

The connected canvas for teams shipping with agents.

🔗 Link

I am not affiliated with any of the suggested tools

You have more demand than capacity.

You are expected to ship components, keep tokens in sync, help product teams move faster, reduce inconsistency, and now also “use AI.”

Here are 20 ways design system teams can use AI this year. Real tools, workflows, and setups that reduce toil and make your system feel more like a product.

I have written about most of them in depth. I will link to those articles so you can go deeper into whatever interests you.

I grouped the 20 ideas into five areas:

• Components and implementation

• Documentation and enablement

• Strategy and prioritization

• Tokens and consistency

• Adoption, metrics, and ROI

Let’s go 👇

Components and implementation

1. Generate components from your Figma designs with AI

Most AI-generated components look fine in isolation but fall apart the moment you put them next to your real system. They use the wrong tokens, invent their own spacing, and ignore your composition patterns. Meanwhile, designers hand off Figma frames, and engineers still rebuild from scratch. The AI output is a curiosity, not a shortcut.

The fix is to connect AI directly to your system. Figma Make generates code from your design frames, but instead of producing generic markup, it references your existing component library. Pair it with MCP connectors (Notion, GitHub) so Figma Make can read your component docs and token files. Then add an .ai/ directory in your repo that contains your component generation rules: which tokens to use, which base components to compose,and accessibility requirements.

The setup:

1. Figma Make generates a first pass from your design frames. Not generic code, but code that references your existing components

2. MCP connectors (Notion, GitHub) give Figma Make access to your component docs and token files

3. An .ai/ directory in your repo contains your component generation rules: which tokens to use, which base components to compose, accessibility requirements

This same approach works outside Figma Make. Both Cursor and Claude Code can connect to the Figma MCP server, read your design frames directly, and generate components using your tokens and component library. The .ai/ directory works the same way regardless of which tool you use. Pick the one your team already runs.

The gap between “design done” and “component shipped” shrinks from days to hours. AI does the first draft; you do the review.

I covered the full workflow here:

2. Automate design system audits with Playwright

Accessibility audits, visual regression tests, and token usage checks are the work nobody has time for, but everybody notices when they are skipped. Most teams run these manually once before a major release, identify a backlog of issues, and then do not address them again for months.

Playwright’s MCP integration changes this. It gives you three AI agents that work together to keep your audits running continuously:

• Planner: explores your Storybook or documentation site and creates test scenarios

• Generator: writes the actual test code by interacting with your components

• Healer: fixes broken tests automatically when components change

Five audits you can automate today:

1. Token consistency audit (scan rendered components for hardcoded values)

2. Component behavior testing (keyboard nav, focus management)

3. Accessibility checks (ARIA roles, contrast, screen reader labels)

4. Documentation accuracy (do the docs match what the component actually does?)

5. Visual regression (screenshot comparison across themes and viewports)

Your team stops catching checkbox-level issues in reviews and focuses on the hard stuff (interaction patterns, naming, architecture) while Playwright handles the checklist.

3. Build a custom Figma plugin for your design system

Every design system has rules that Figma does not enforce. Designers use the wrong tokens, skip semantic layers, or apply status colors to the wrong contexts. You catch these in review. The same review comments, week after week.

A custom Figma plugin can automatically validate token usage. And with plugma, building one is no longer a side project that takes a sprint. Plugma gives you a modern dev toolchain for Figma plugins (hot reload, TypeScript, bundling) so you can use AI to write most of the plugin logic while plugma handles the build.

Example: a token intent validator

Your plugin can scan selected frames and flag:

• Raw hex colors used instead of tokens

• Primitive tokens (blue.500) used directly in components

• Status colors (danger/success) used in the wrong context

• Interactive tokens applied to static elements

Designers get inline warnings with suggested fixes. You stop repeating the same review comments.

The setup:

npx create-plugma@latest my-token-validator
cd my-token-validator
npm run dev  # hot reload in Figma

Use AI to generate your validation rules from your token naming convention (see “Generate a token naming convention” below).

4. Write a migration guide for breaking changes

You ship a breaking change. Three teams break. Nobody reads the changelog. Changelogs list what changed, not what to do about it. A migration guide is the artifact that actually gets used: who is affected, what to change, and where to watch out.

Feed AI the diff between the old and new API, plus a short explanation of why the change was made. It generates a structured guide in minutes that would otherwise take you an hour to write and another hour to format.

Prompt:

Write a migration guide for this breaking change.
Inputs:
- old API: [paste]
- new API: [paste]
- why we changed it: [paste]

Output:
1) who is affected
2) before/after examples
3) a step-by-step migration checklist
4) common mistakes

Save as migration-guides/[component]-[version].md. When teams ask “how do I update?”, send a link instead of typing a response.

Documentation and enablement

5. Automate your documentation pipeline

Documentation that lags weeks behind code is worse than no documentation. It actively misleads people. Screenshots go stale. Props tables list options that were removed two releases ago. Teams stop trusting the docs and start reading source code instead, which defeats the entire purpose of having a design system.

The fix is not “write docs faster.” The fix is a pipeline that keeps docs in sync with your components continuously. Connect Figma MCP + Claude Code + Mintlify (or your docs framework of choice). Figma MCP reads your component designs and extracts props, variants, and states. Claude Code generates documentation markdown from your component source code combined with the Figma data. Mintlify publishes automatically on merge.

The pipeline:

1. Figma MCP reads your component designs and extracts props, variants, and states

2. Claude Code generates documentation markdown from your component source code + Figma data

3. Mintlify (or Storybook, or your docs site) publishes automatically on merge

4. Cron job (optional) runs weekly to re-sync screenshots and catch drift

Add Claude Code Skills to your design system workflow

Everyone on your team prompts AI differently. One person writes a paragraph of context. Another pastes raw code and says, “Fix this.” The results are wildly inconsistent, and people end up writing the same instructions repeatedly, or worse, stop using AI because the output never matches the system.

Claude Code Skills solves this. Skills are reusable instruction sets that auto-load based on context. They are prompts that know when to activate and what files to read. You do not have to remember to use them. They just show up when relevant.

The best Skills for design system work:

✨ token-migration-assistant
Detects your token format and migrates between Style Dictionary, W3C DTCG, Figma Variables, CSS, and Tailwind.

✨ component-audit
Runs comprehensive audits: accessibility, theming, responsiveness, code quality.

✨ documentation-standards
Generates consistent component docs matching your format.

✨ brand-guidelines
Applies your brand’s colors, typography, spacing, and motion rules.

✨ figma-variables-generator
Generates Figma Variables JSON directly from your design tokens.

A prompt library is a document people forget exists. A Skill auto-loads when Claude Code detects it is relevant. That difference is everything.

I covered Skills in depth here 👇

7. Make your own custom Skill

The prebuilt Skills cover common workflows, but your design system has its own rules, naming conventions, and patterns that no generic skill can cover. The good news: a custom Skill is a Markdown file with YAML front matter. That is it.

Example: a token naming validator Skill

---
name: token-naming-validator
description: Validates design token names against our naming convention
autoload: when working with design tokens or token files
---

# Token Naming Validator

When reviewing or generating design tokens, enforce these rules:

## Naming structure
- Format: `{category}.{property}.{variant}.{state}`
- Categories: color, spacing, typography, elevation, motion
- Use dot notation, not camelCase or kebab-case

## Rules
- Semantic tokens MUST reference primitives, never raw values
- No color names in semantic tokens (use "primary" not "blue")
- State variants: default, hover, active, disabled, focus
- Every token must have a description field

## On violation
- Flag the token name
- Suggest the correct name
- Explain the rule that was broken

Save personal Skills to ~/.claude/skills/ or project Skills to .claude/skills/ (version controlled, shared with the team). Now your entire team gets consistent AI behavior (same naming rules, same validation, same output format) without anyone memorizing the rules.

8. Create a design system onboarding FAQ from real questions

Every new hire asks the same 20 questions. Where do I find the tokens? Which Button variant do I use for destructive actions? How do I submit a new component request? You answer these individually, every time, in Slack DMs that nobody else can see.

Take the last 50 questions that new team members actually asked. Answer them, feed them to AI and generate a structured FAQ. The next person who joins does not need you to onboard them. They have the FAQ.

Prompt:

Turn these questions into an onboarding FAQ for our design system.
Requirements:
- group by theme
- answer in plain language
- link to the right doc sections (use placeholders if unknown)
- include "common mistakes"

Save as onboarding-faq.md and link it from your main docs. Update it quarterly as new questions come in.

Strategy and prioritization

9. Turn requests into a single backlog

Design system requests come from everywhere: Slack threads, Jira tickets, meeting sidebars, and post-it notes from a workshop three weeks ago. You spend hours manually deduplicating, and you still miss things because half the requests were verbal.

Dump your last 30 days of requests into a single document. Feed it into the AI and ask it to deduplicate, group by theme, count frequencies, and identify the underlying job-to-be-done. You get a clean backlog in minutes, not a half-day of spreadsheet work.

Prompt:

You are helping a design system lead consolidate requests.

Input: a list of requests (Slack snippets, Jira tickets, meeting notes).
Output:
1) A cleaned list of requests grouped by theme (duplicates merged)
2) For each theme: frequency, impacted teams, and the underlying job-to-be-done
3) A short "what we are NOT doing" list (scope control)

Format: markdown

Save as design-system-backlog.md. Update it weekly. 2–3 hours saved per sprint, and you now have a source of truth that is not your memory.

10. Write a one-page strategy map

Leadership asks, “What’s the plan?” and you have 47 Notion docs, but no clear answer. The detail is there. The clarity is not. What you need is a single-page summary: everything you know about the current state, the vision, and the path forward, reduced to one page that anyone can read in two minutes.

Prompt:

Create a one-page design system strategy map with:
- Context: what is broken today (3-5 bullets)
- Vision: where we want to be in 12 months
- Strategy: our 3 biggest bets
- Metrics: what we will measure monthly
- Stakeholders: who needs updates and how often

Make it plain English. No corporate jargon.

If it does not fit on one page, you do not understand it well enough yet.

11. Run a component ROI sanity check before you build

Most component decisions follow the same pattern: someone with influence requests it, you build it, and six months later it is used in two places. Meanwhile, the component the three teams need is in the backlog because no one lobbied for it loudly enough.

Before you build, run a quick sanity check. Map the request to screens, teams, and reuse potential. It takes five minutes and saves you from building the wrong thing first.

Prompt:

Help me decide whether to build a new component.

Component request: [paste]
Context:
- Teams requesting it: [list]
- Known screens / flows: [list]
- Alternatives in system today: [list]

Output:
1) Reuse likelihood (high/medium/low) with reasoning
2) Risks (maintenance, variants, accessibility complexity)
3) MVP scope (minimum viable version)
4) What to validate before building

Save the output in your decisions folder. When someone asks, “Why didn’t we build X?” you have a written record of the reasoning.

12. Use Claude Code for design system research

Researching how other systems handle a problem (token structures, component APIs, theming approaches) usually eats an entire afternoon. You open ten tabs, compare three Storybook instances, skim four blog posts, and still end up with scattered notes.

Claude Code has built-in web search and file analysis. Point it at a competitor’s public repo, a Storybook instance, or a set of documentation pages, and it pulls everything together into one document.

Example:

# From your terminal, ask Claude Code to research
claude "Research how Shopify Polaris, Atlassian, and GitHub Primer
handle their color token structure. Compare naming conventions,
semantic layers, and how they handle dark mode. Output a comparison
table I can share with my team."

You get a research summary your team can act on in the same week you asked the question, not a collection of bookmarks you will never revisit.

Tokens and consistency

13. Generate a token naming convention from your real usage

Token naming inconsistencies are a burden on every engineer who touches your system. color-primary in one file, primaryColor in another, brand.primary in a third. Engineers guess. Designers copy what looks right. The inconsistency compounds silently until a rebrand or a multi-brand initiative forces you to deal with all of it at once.

Instead of designing a naming convention from scratch, give AI your current token set and ask it to propose a scheme that matches what you already do, then tighten the edges.

Prompt:

Analyze our token set and propose a consistent naming convention.
Goals:
- predictable
- scalable to multiple brands
- clear semantic vs primitive separation

Output:
1) naming rules
2) 10 "before -> after" renames
3) a short migration strategy

The goal is predictability. A developer should be able to guess the token name without checking the documentation.

14. Connect Figma variables to your codebase with MCP

Every time you paste token values into an AI prompt, they are already stale. Your Figma variables update. Your tokens JSON gets a new release. But the AI is working with whatever you copy-pasted last Tuesday.

A Model Context Protocol (MCP) server connects your design tokens directly to Claude. The Figma MCP server lets AI read your variables, modes, and collections in real-time.

The setup:

1. Install the Figma MCP server (or build your own with the MCP Design Tokens Server template)

2. Point it at your Figma file or your tokens JSON

3. Now every AI prompt you run has live access to your actual token values

15. Use Context7, so AI always has current documentation

AI models have a training cutoff. When you ask Claude or Cursor about Style Dictionary v4, Radix Themes, or Tailwind v4, you might get answers based on last year’s API, and not realize it until you have already built something around a deprecated method.

Your token pipeline probably depends on Style Dictionary. Your components might use Radix or shadcn. Your utility layer might be Tailwind. If AI gives you advice based on outdated docs, you waste time fixing problems that do not actually exist.

Context7 feeds AI the latest documentation for the libraries your design system depends on. Add it as a reference source in your AI workflow. When generating components or debugging token transforms, ask AI to check Context7 for the current API first.

16. Run a token drift audit with a Skill

Teams bypass tokens. You find out weeks later when the UI looks wrong. Manually checking every PR for hardcoded colors and spacing values does not scale. And asking people to “just use tokens” in Slack is not enforcement, it is hope.

A token audit Skill tells Claude Code exactly what to look for in your codebase (hardcoded hex values, raw pixel spacing, missing theme variants) and how to report it. Save it once, and anyone on your team can run it on demand or as part of their review process.

Example: a token audit Skill

---
name: token-drift-audit
description: Scan codebase for hardcoded values that should use design tokens
autoload: when reviewing PRs or checking token usage
---

# Token Drift Audit

Scan the codebase for values that bypass the design token system.

## What to flag
- Hardcoded hex, rgb, or hsl colors in component files
- Raw pixel spacing values (4px, 8px, 16px, etc.)
- Inline font sizes instead of typography tokens
- Colors that exist as tokens but are written as raw values
- Primitive tokens (e.g. blue.500) used directly in components

## What to check
- All themes (Light, Dark, High Contrast) have matching token sets
- No broken token references
- Color contrast ratios meet WCAG AA (4.5:1 text, 3:1 large text)
- Naming follows the convention: {category}.{property}.{variant}

## Output format
- Group findings by severity: critical, warning, info
- Show file path and line number for each finding
- Suggest the correct token for each hardcoded value
- End with a summary count

Save this as .claude/skills/token-drift-audit/SKILL.md in your repo. Now anyone on your team can run it:

claude "Run a token drift audit on the components/ folder"

You catch drift in PRs, not production. And because it is a Skill, the audit is consistent. Every team member gets the same checks, the same output format, the same severity levels.

Adoption, metrics, and ROI

17. Build an adoption dashboard

Leadership wants metrics. But runtime tracking (watching which developers use which components in real time) feels invasive, and the data is noisy anyway. Importing a component does not guarantee it is used correctly.

Start with build-time signals instead. Component imports, token drift counts, bypass signals (raw <button> elements, inline styles), and PR drift delta. These are facts extracted from code, not surveillance of people.

Prompt:

Design a design system adoption dashboard plan.
Start with build-time metrics only:
- component imports / usage counts
- token drift counts
- bypass signals (raw <button>, inline styles)
- PR drift delta

Output:
1) metrics definitions
2) data sources
3) weekly reporting format

Build-time metrics tell you what is happening in the codebase without anyone feeling watched. That is the foundation. Add complexity only when you have proven the basics are useful.

18. Find the bypass patterns that hurt consistency

When teams bypass your design system, the instinct is to blame them. “They should have used the component.” But if people are bypassing consistently, the system is failing them. The component does not exist. The token is missing. The docs are unclear. The API is too rigid.

Bypass patterns are user research. Feed AI your drift report and ask it to identify what is recurring, why teams do it, and what the smallest fix is that you can ship this sprint.

Prompt:

Given this drift report, identify the top bypass patterns.
For each bypass:
- why teams do it
- what the design system should change (component, token, docs)
- the smallest fix we can ship this sprint

Every bypass you fix makes the system easier to use, which makes the next bypass less likely. That is how adoption compounds.

19. Generate release notes that teams will actually read

Your changelog says “updated Button component.” Nobody knows what changed, who is affected, or whether they need to do anything. So nobody reads it, and then they complain they were not told about breaking changes.

Release notes for design systems need to be written for non-design-system people. What changed, why it matters for product work, and what teams need to do (if anything). AI can generate this from your changelog and merged PRs in minutes.

Prompt:

Write design system release notes for non-design-system people.
Inputs: changelog + list of merged PRs.

Output:
- what changed (3-7 bullets)
- why it matters (tie to product outcomes)
- what teams need to do (if anything)
- links to migration guides

If the release note does not say “what this means for you,” it will not get read.

20. Run your own AI design system assistant 24/7

OpenClaw (previously clawdbot) is an open-source AI assistant that runs 24/7 on your own hardware. A ~5/month Hetzner VPS is enough. Connect it to Telegram, Slack, Discord, or WhatsApp and your team has an always-on design system expert that can actually read your repo.

What it gives you:

• Always-on access via Telegram, Slack, Discord, or WhatsApp

• Full system access: it can run scripts, query your token files, check your repo

• Scheduled jobs: automate weekly reports, competitor checks, content generation

• Persistent memory: it remembers previous conversations and context

• Your choice of model: Claude, GPT, Gemini, DeepSeek, whatever fits your budget

Example setup for a design system team:

• Morning cron job runs a token drift scan and posts results to Slack

• Team members message the bot on Telegram: “What’s the current spacing scale?” It reads the actual tokens and responds

• Weekly automated competitor check: “What did Polaris, Carbon, and Primer ship this week?”

A word on security: Keep this on a separate server from your production infrastructure. Give it read-only access to a clone of your token files and documentation, not your live codebase. This is a tool for answering questions, running reports, and automating research. It is not a deployment pipeline. Treat it like a team assistant with a read-only badge, not an engineer with push access.

The toolkit

Here is every tool mentioned in this article and where to start:

Claude Code
AI coding assistant with file access, web search, and Skills

MCP (Model Context Protocol)
Connects AI to live data sources (Figma, tokens, docs).

• Figma MCP for reading variables, design frames, and component metadata

• GitHub MCP for reading repos, PRs, issues, and component source code

• Slack MCP for monitoring design system requests and support channels

• Notion MCP for reading and writing design system documentation and decision logs

• PostHog MCP for querying adoption metrics, feature flags, and usage data

• Zapier MCP for connecting your design system workflows to Jira, Linear, and hundreds of other tools

Figma Make
Generates code from Figma designs using your component library.

Playwright
Automated browser testing with AI agents (Planner, Generator, Healer).

Context7
Feeds current library documentation to AI tools.

plugma
Modern Figma plugin development toolchain. npx create-plugma@latest

OpenClaw
Self-hosted AI assistant on your own server.

PostHog
Product analytics platform with feature flags, session replays, and A/B testing. For design systems, it tracks component usage in production, measures adoption across teams, and gives you real data for ROI conversations with leadership. The PostHog MCP server lets AI query your analytics directly.

Enjoy exploring 🙌

— If you enjoyed this post, please tap the Like button below 💛 This helps me see what you want to read. Thank you.

💎 Community Gems

Swap Wizard Figma plugin

1st place at the IDS hackaton

✨ Auto-matches components even when names don't align perfectly
✨ Lets you validate and adjust mappings with live previews
✨ Handles variant properties so you pick the exact component you need
✨ Re-attaches detached components

🔗 Link

Edgy Figma plugin

2nd place at the IDS Hackaton → The team explored whether a plugin could analyse flows, call out missed edge cases, and generate any missing screens directly on the canvas using an existing design system. And they did it.

🔗 Link

Design Token Naming Guide + Builder

🔗 Link

I am not affiliated with any of the suggested tools

You spend 2 hours setting up beautiful variants in Figma. Primary, secondary, ghost. Small, medium, large. Default, hover, disabled.

Then a developer asks: “What are the props for this component?”

You explain everything again. In a meeting, in a Notion doc, or in Slack messages. The developer writes the component with slightly different naming. Now “Primary” in Figma becomes type: 'main' in code.

The translation layer between design and code breaks down within weeks.

Here’s the thing: your Figma variants already ARE your props. They just need to speak the same language as your code. When you set this up correctly, your Figma button with variants “Primary, Secondary, Ghost” automatically becomes a React component with variant: 'primary' | 'secondary' | 'ghost', which automatically becomes interactive controls that anyone can toggle.

No manual documentation. No translation meetings. No drift.

What you will learn:

• Figma variant properties = Component props: When you name variants correctly, AI generates matching TypeScript types automatically

• The naming alignment is everything: “Primary” in Figma should become 'primary' in code, not 'main' or 'type1'

• Storybook controls generate from types: Clean union types mean clean dropdown controls, no configuration needed

• Prompts: Copy-paste prompts for every step of this workflow

What is Storybook (and why should you care)?

Storybook is a free, open-source tool that lets you browse and test your components in isolation, outside of your app. Think of it as an interactive catalog of every component in your design system.

Why is it so useful:

• You can click through every variant without spinning up the full product

• Controls panel lets you toggle props (size, variant, disabled) in real time

• Auto-generated documentation pulls from the code, so it never goes stale

• Shareable URL means you can send a link to anyone for review

When your Figma naming matches the code, Storybook generates all of this automatically from your TypeScript types.

The mental model: how props flow

Before you touch any tools, understand this flow:

FIGMA                      CODE                        STORYBOOK
───────────────────────────────────────────────────────────────────
Variant property     →     Component prop       →     Control panel
"Variant: Primary"         variant: 'primary'         [Dropdown: Primary ▼]
"Size: Medium"             size: 'md'                 [Dropdown: Medium ▼]
"Disabled: True"           isDisabled: boolean        [Checkbox: ☑]

You set up Figma → AI generates the code → Storybook creates the controls.

When this chain works, everything stays in sync. When it breaks (usually because Figma naming doesn’t match code conventions), you get drift.

Let’s go step by step.

Setting up Storybook

In your React/Next.js project, run:

npx storybook@latest init

This creates a .storybook folder with configuration. Start it with:

npm run storybook

You’ll see a local server at http://localhost:6006 with example stories.

Optional: Publish with Chromatic

Chromatic publishes your Storybook online, so your entire team can browse components in a browser. Free for open source, generous free tier for everyone else.

I use this option, so I can also share the work with others.

→ Sign up at chromatic.com (GitHub login works)

→ Create a new project and get your project token

→ Install and publish Chromatic:

npm install chromatic --save-dev
npx chromatic --project-token=YOUR_TOKEN

You’ll get a public URL to share. Chromatic also catches visual regressions when you push changes.

Setting up Figma so AI can read it

This is the most important step. AI tools read your Figma file directly: your variant properties, layer names, and design tokens. If these are messy, the generated code will be messy.

Your Figma variant property names become your prop names.

Name your Figma variants with code-friendly values (lowercase, no spaces, consistent format), and AI generates cleaner code.

Checklist before you generate

Open your component in Figma and verify:

• Consistent naming: All variants use the same format (sm/md/lg, not sm/Medium/LG)

• Code-friendly values: No spaces, lowercase preferred (primary, not “Primary Button Style”)

• Boolean properties for on/off states: isDisabled, isLoading, hasIcon (not “State: Disabled”)

• Meaningful layer names: “Leading Icon”, “Label”, “Trailing Icon” (not “Frame 47”, “Vector”, “Text”)

Add a component description

Select your component set in Figma and add a description. AI reads this and uses it for context:

Button component for user actions.

Props:
- variant: primary | secondary | ghost | danger (default: primary)
- size: sm | md | lg (default: md)
- isDisabled: boolean (default: false)
- isLoading: boolean (default: false)

Usage: Use primary for main actions, secondary for alternative actions,
ghost for tertiary actions, danger for destructive actions.

Pick your AI tool

You need an AI tool that can read your Figma and generate code. Here are your recommended options:

Claude Code reads Figma files directly through the Figma MCP server. One-time setup. Claude Code can be used as an extension in any IDE or in your terminal.

Or, you can use Cursor.

Cursor is an AI-powered code editor (IDE) with built-in chat. It also supports MCP servers, so you connect Figma the same way. You can switch between AI models (Claude Opus 4.6, GPT-5.2, Gemini, etc.) to compare outputs.

The two prompts that do everything

This is the core of the workflow. The first builds your component, the second pushes it to Storybook.

Prompt 1: Generate the component

Select your component in Figma, then paste this:

Get the design context for the selected Figma component.

Generate a React component with TypeScript that:
1. Has props matching the Figma variant properties exactly
   (use the same names and values, lowercased)
2. Uses TypeScript union types for all variants
   (e.g., 'primary' | 'secondary', never just string)
3. Uses boolean props for on/off states
   (e.g., isDisabled?: boolean)
4. Adds JSDoc comments for every prop explaining:
   - What it does
   - Available options
   - Default value
5. Follows the patterns in our existing components at src/components/

Show me the generated TypeScript interface first so I can verify
the prop names and values match my Figma setup before you write
the full component.

More detailed guide and tricks about generating components with AI here →

What you should get back:

export interface ButtonProps {
  /** The visual style of the button */
  variant?: 'primary' | 'secondary' | 'ghost' | 'danger';
  /** The size of the button */
  size?: 'sm' | 'md' | 'lg';
  /** Whether the button is disabled */
  isDisabled?: boolean;
  /** Whether to show loading state */
  isLoading?: boolean;
  /** Button content */
  children: React.ReactNode;
}

Check that the prop names and values match your Figma exactly. If AI-generated type instead of variant, or small instead of sm, tell it:

The prop names don't match my Figma. Change "type" to "variant"
and "small/medium/large" to "sm/md/lg".

Prompt 2: Generate stories and run Storybook

Once your component looks good, paste this:

Look at the component you just created.

Generate Storybook stories that:
1. Use CSF 3.0 format with Meta and StoryObj types
2. Include the 'autodocs' tag for automatic documentation
3. Create one story for each variant
4. Create one story showing all sizes side by side
5. Create stories for every boolean state (disabled, loading, etc.)
6. Add an "AllVariants" story that renders every variant
   in a grid so I can compare them at a glance
7. Add edge case stories:
   - Long text label (50+ characters)
   - With leading and trailing icons
   - Inside a form context
8. Add a play function to the default story that:
   - Clicks the component
   - Verifies the click handler fires
   - Tests keyboard navigation (tab + enter)

Put the stories next to the component file.
Then run Storybook so I can see the result.

What happens next

Open http://localhost:6006 (or whatever local address you have) You’ll see:

• Live component preview you can interact with

• Controls panel with dropdowns for variant and size, checkboxes for isDisabled and isLoading

• Auto-generated docs with your JSDoc comments as prop descriptions

• AllVariants story showing every combination in a grid

You didn't configure any controls. Storybook figured it out from your types. That's the whole point of getting the naming right in Figma.

Check the example story here →

When things go wrong

Two issues come up most often:

Controls don’t match your Figma variants

This happens when AI uses different names than your Figma. Tell it exactly what to fix:

Update the component types to match my Figma naming exactly:
- variant: primary | secondary | ghost | danger
- size: sm | md | lg

Types are too loose

If AI typed a prop as string instead of specific values, tighten it:

The size prop is typed as `string` but it should only accept
specific values. Change it to a union type: 'sm' | 'md' | 'lg'

Why this matters

The props connection between Figma and Storybook creates a single source of truth.

When your Figma variants, code props, and Storybook controls all use the same language:

• Designers review components without asking “what did the developer call this?”

• Developers implement without asking “what does the designer mean by Type 2?”

• Documentation stays accurate because it generates from the code

• AI updates everything when you change the Figma source

The biggest design system problems aren’t technical. They’re communication problems. Naming alignment solves a surprising number of them.

Inspiration: Storybooks worth exploring

See how top companies document their components:

🔗 Shopify Polaris: Accessibility auditing, viewport testing, theme switching

🔗 GitHub Primer: Clean organization, great props documentation

🔗 IBM Carbon: Comprehensive component library with detailed usage guidelines

🔗 BBC iPlayer: Rebuilt their entire UI library in Storybook after a component audit

🔗 Monday.com Vibe: Beautiful welcome page, clear navigation

🔗 Audi UI React: Brand imagery meets component documentation

🔗 Grommet (HPE): Extensive theming examples

🔗 WordPress Gutenberg: Block editor components, accessibility focus

🔗 JetBrains Ring UI: Developer tools components, dark mode support

Browse more at the Storybook Showcase.

Enjoy exploring 🙌

— If you enjoyed this post, please tap the Like button below 💛 This helps me see what you want to read. Thank you.

Introducing: Design Token Naming GUIDE + BUILDER 2.0 🎉

Try it here

I built a free, interactive tool to help designers and developers improve their naming of design tokens. And maybe, build their own token systems along the way. 🙃

Whether you're just getting started with tokens or trying to get your team on the same page, this might help.

Here's what you'll find:

• 6 interactive lessons that walk you through what design tokens actually are, how they work, and how to name them well (about 15 mins total)

• Token BUILDER to configure your own naming structure with components, categories, states, and roles

• Primitive vs Semantic modes, so you can switch between simple scale-based tokens or full semantic naming

• Live preview that shows your token names as you build them

• Export-ready, so you can copy or download your tokens and start using it

• Figma Variables ready format

• Advanced filtering and sorting

• Add values manually or put placeholders in a second
  

The whole point is to let you quickly switch naming conventions and test what works for your project.

Feedback for improvements is always welcome. 🫶

💎 Community Gems

Winden Tokens
A Figma plugin for managing design tokens (variables) with a spreadsheet-style interface. Quickly create, edit, and organize your design system variables.

🔗 Link (GitHub) 🔗 Figma plugin

Design systems don’t sleep. Teams push code at midnight. Someone uses a raw hex value “just this once.” A deprecated token sneaks into production.

It’s hard to watch everything. But for €5/month, something can.

A personal AI assistant running 24/7 in the cloud. It monitors your repos, flags violations, and messages you on Telegram when something needs attention. It runs while you sleep. It’s yours to customize.

In short

• €5/month beats €600 hardware: A Hetzner cloud server gives you 24/7 uptime without buying a Mac Mini

• Telegram is your control center: Message your AI from anywhere, get responses even when your laptop is closed

• No DevOps needed: Copy-paste commands get you from zero to running in under 2 hours

• Bonus: Complete command cheat sheet: Every command you need on a single page

Why everyone’s talking about OpenClaw

If you’ve been on tech X lately, you’ve probably seen the Mac Mini buying frenzy.

People are setting up dedicated machines just to run an AI assistant 24/7. One user described it as “sort of amazing knowing that we are all having the same weekend... Mac Minis and OpenClaw.”

So what is OpenClaw, and why are people treating it like hiring their first employee?

OpenClaw (formerly Clawdbot, then Moltbot) is an open-source personal AI assistant created by Peter Steinberger (@steipete). The lobster has molted twice already. Unlike ChatGPT or Claude.ai, which live in browser tabs, OpenClaw:

• Runs on your hardware (Mac, Linux, Windows, Raspberry Pi, or cloud VPS)

• Connects through chat apps you already use (Telegram, WhatsApp, Discord, iMessage, Slack)

• Has full system access (can execute terminal commands, write scripts, install software)

• Works with any LLM (Claude, GPT, Gemini, DeepSeek, Perplexity)

• Remembers everything (persistent memory across sessions)

• Can improve itself (add new capabilities just by talking to it)

The project has exploded: 108k GitHub stars, 15k forks, and a Discord community building skills for everything from calendar management to home automation.

What makes it viral? It feels like “the future” because it actually does things, not just chats. One user set up OpenClaw to manage multiple AI coding agents, autonomously debate code reviews, and deploy features while walking the dog. Another had it decode emergency radio frequencies using RTL-SDR hardware, which they just plugged in.

Here’s the thing, though: you don’t need a $600 Mac Mini. The creator himself keeps telling people to stop buying hardware. A €5/month cloud server works just as well, and that’s what this guide covers.

Before you start: Security is not optional

This is not a toy. OpenClaw has full system access. It can execute terminal commands, write scripts, install software, and spin up sub-agents. If you’re not paranoid about security, you should be.

Treat it like hiring a stranger with the keys to your house.

Here’s what that means in practice:

Isolate the environment

• Run it on a dedicated server or user account, not your main machine

• If using a Mac, create a separate user just for OpenClaw

• A cloud VPS (like this guide covers) is actually safer than your personal laptop

Lock down messaging

• Use a messaging app you don’t use for anything else (Telegram works well)

• If your phone is stolen or a token is compromised, someone could impersonate you

• During testing, OpenClaw sent emails as one user rather than for them. Careful prompting required.

Use the “new employee” rule

• Don’t give it your primary email, passwords, or personal accounts

• Create separate accounts with limited access (e.g., read-only calendar access)

• Use a dedicated password vault with only the credentials OpenClaw needs

• When OAuth asks for permissions, manually restrict to only what’s necessary

Think about what you’re exposing

• Your calendar has your kids’ school schedules, doctor appointments, and home address

• Your repos have API keys, deployment configs, and business logic

• Ask yourself: would you hand this to a contractor you just met?

Have an exit plan

• Know how to revoke all tokens and API keys

• Know how to delete the Telegram bot

• Know how to wipe the server

If you haven’t done a security tabletop exercise for this, do one before you start. The power is real. So are the risks.

OpenClaw vs Claude Code: When to use which?

If you already use Claude Code, you might wonder why you’d bother with OpenClaw. Fair question.

When OpenClaw makes sense:

• You want something running while you sleep (”Research competitor APIs and summarize by morning”)

• You need an assistant available from your phone, anywhere

• You want to monitor repos, get alerts, or run scheduled tasks

• You’re building workflows that span hours or days

When Claude Code is better:

• Active coding where you need fast feedback loops

• Working on local files in your IDE

• You want tight integration with your development environment

• Latency matters (OpenClaw’s Telegram round-trip adds delay)

The honest answer: They complement each other. Claude Code for real-time coding. OpenClaw for “set it and forget it” tasks that run while you’re not at your desk.

The architecture

Here’s what you’re building:

┌─────────────────────────────────────┐
│         HETZNER SERVER              │
│         (runs 24/7 in the cloud)    │
│                                     │
│    • OpenClaw installed here        │
│    • Always online                  │
│    • €4-5/month                     │
└─────────────────────────────────────┘
              ↕
        ┌─────────────┐
        │  Telegram   │  ← You control it from here
        │  (phone or  │     (anywhere in the world)
        │   desktop)  │
        └─────────────┘

Your laptop is only needed for the initial setup. Once configured, OpenClaw runs independently.

Part 1: Create your Telegram bot

Before touching any servers, let’s set up the Telegram bot you’ll use to control everything. You can, of course, use any other messaging service, but again, be careful with which account (better to create a new one than share your real one).

Step 1: Talk to BotFather

Open Telegram and search for @BotFather. This is Telegram’s official bot for creating bots. Start a chat and send:

/start

BotFather will ask you two questions:

1. Name: This is the display name. Call it whatever you want (e.g., “Mochi”)

2. Username: Must end in bot. Something like puffy_assistant_bot

BotFather then gives you a token that looks like this:

123456789:ABCdefGHIjklMNOpqrsTUVwxyz

Save this token somewhere safe. You’ll need it later.

Step 2: Get your Chat ID

Now you need your personal Chat ID so the bot knows who to talk to.

1. Find your new bot in Telegram (search for the username you just created)

2. Send it /start

3. Open this URL in your browser, replacing YOUR_TOKEN with the token from BotFather:

https://api.telegram.org/botYOUR_TOKEN/getUpdates

Look for "id" in the response. It’s a number like 123456789. That’s your Chat ID.

Common issue: If you see {"ok":true,"result":[]}, the message expired. Go back to Telegram, send /start again, then refresh the URL within a few seconds.

What you should have now

ItemExampleWhere you got itBot Token123456789:ABCdef...From BotFatherChat ID123456789From the getUpdates URL

Keep these somewhere safe. You’ll paste them during server setup.

Part 2: Set up your Hetzner server

Step 1: Create a Hetzner account

Go to hetzner.com/cloud and sign up. You’ll need to add a payment method (credit card works).

Step 2: Generate an SSH key

SSH keys let you log into your server without a password. On your Mac or PC, open Terminal and run:

ssh-keygen -t ed25519 -C "your@email.com"

When it asks questions:

• File location: Press Enter to accept the default

• Passphrase: Press Enter twice (no passphrase makes things easier)

Now copy your public key:

cat ~/.ssh/id_ed25519.pub

You’ll see something like:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your@email.com

Copy that entire line. You’ll paste it into Hetzner.

Step 3: Create the server

1. Go to console.hetzner.cloud

2. Create a project (name it whatever you want)

3. Click + Create Server

Use these settings:

• Location: Falkenstein or Helsinki

• Image: Ubuntu 24.04

• Type: Shared Resources → Cost-Optimized → CX22

• SSH Keys: Click “Add SSH Key” and paste your public key

• Name: openclaw-agent

Click Create & Buy now. In about 30 seconds, you’ll have a server with an IP address like 112.111.2.221.

Step 4: Connect to your server

In Terminal, run:

ssh root@YOUR_SERVER_IP

Replace YOUR_SERVER_IP with the actual IP from Hetzner. When it asks “Are you sure you want to continue connecting?” type yes.

You should see:

Welcome to Ubuntu 24.04.3 LTS
root@ubuntu-4gb-hel1-1:~#

You’re now inside your cloud server. Everything you type runs there, not on your laptop. First win! 🥳

Part 3: Install OpenClaw

Now the fun part. You’re on your server via SSH. Let’s install the AI.

Step 1: Update the system

Run this first (takes 1-2 minutes):

apt update && apt upgrade -y

Step 2: Install Node.js and OpenClaw

OpenClaw requires Node.js 22 or newer. Install it first:

curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
apt install -y nodejs

Now install OpenClaw:

npm install -g openclaw@latest

Then run the onboarding wizard:

openclaw onboard --install-daemon

The wizard walks you through:

• Accepting the security warning

• Choosing your AI provider (Anthropic, OpenAI, etc.)

• Pasting your API key

• Configuring messaging channels

Step 3: Give your bot a personality

OpenClaw asks what it should be. Type something like:

Your name is Mochi. You're my AI assistant for design systems and coding projects. You help me monitor GitHub repos, analyze code, and automate tasks. Be helpful, proactive, and friendly.

Press Enter.

Step 4: Connect GitHub (optional but useful)

If OpenClaw asks for GitHub access:

1. Go to github.com/settings/tokens

2. Click Generate new token (classic)

3. Name it openclaw

4. Check the repo scope

5. Generate and copy the token (starts with ghp_...)

6. Paste it into OpenClaw

Part 4: Connect Telegram

Almost there. Let’s hook up your bot to Telegram.

During onboarding, OpenClaw asks which messaging channels you want to use. Select Telegram and enter:

• Bot Token: The token from BotFather

• Chat ID: Your personal Chat ID

If you skipped this during onboarding, you can re-run:

openclaw onboard

And select Telegram when prompted for channels.

Test it

1. Open Telegram on your phone

2. Go to your bot’s chat

3. Send: hello

You should get a response from your bot. If you do, it’s working.

Part 5: Keep it running forever

When you connect to your server, you’re opening a “session.” Any programs you start live inside that session. When you close your laptop, disconnect from WiFi, or just close the Terminal window, that session ends. And when the session ends, everything running inside it gets killed.

It’s like having a conversation on the phone. The moment you hang up, the conversation stops. What we need is a way to start OpenClaw and have it keep running even after we “hang up” our SSH connection.

That’s what process managers do. They run your program in the background, completely independent of your SSH session. Even better, they can restart your program automatically if it crashes or if the server reboots.

Option 1: PM2 (recommended)

PM2 is the most popular process manager for Node.js applications. Think of it as a babysitter for your programs - it watches them, restarts them if they crash, and keeps logs of what happened.

npm install -g pm2

This installs PM2 globally on your server. You only need to do this once.

pm2 start openclaw --name "openclaw"

This tells PM2 to start OpenClaw and give it the nickname “openclaw” (so you can refer to it later). PM2 immediately moves it to the background.

pm2 save

This saves your current setup. PM2 now remembers that it should be running OpenClaw.

pm2 startup

This is the magic command. It creates a system service that starts PM2 automatically when your server boots up. PM2 then starts all saved processes (including OpenClaw).

The result: You can now close your Terminal, shut down your laptop, go on vacation. OpenClaw keeps running. If the server restarts for any reason (updates, maintenance), OpenClaw comes back automatically.

Verify it’s running

After setting up PM2 (or daemon mode), disconnect from your server:

exit

Wait a few seconds, then send a message to your bot on Telegram. If it responds, congratulations - your AI assistant is now running independently of your computer.

Check status anytime

You can always SSH back in and check on things:

pm2 list
# or
systemctl status openclaw

Command Cheat Sheet

Copy this and keep it somewhere handy:

┌─────────────────────────────────────────────────────────────┐
│                   OPENCLAW CHEAT SHEET                      │
├─────────────────────────────────────────────────────────────┤
│ SERVER CONNECTION                                           │
│   ssh root@YOUR_IP          Connect to server               │
│   exit                      Disconnect from server          │
├─────────────────────────────────────────────────────────────┤
│ OPENCLAW COMMANDS                                           │
│   openclaw onboard          Run setup wizard                │
│   openclaw onboard --install-daemon  Setup + auto-start     │
│   openclaw gateway          Start the control plane         │
│   openclaw agent --message  Send a task to your agent       │
│   openclaw doctor           Diagnose issues                 │
│   openclaw update           Update to latest version        │
├─────────────────────────────────────────────────────────────┤
│ PM2 COMMANDS (PROCESS MANAGER)                              │
│   pm2 list                  Show running processes          │
│   pm2 logs openclaw          View live logs                  │
│   pm2 restart openclaw       Restart the bot                 │
│   pm2 stop openclaw          Stop the bot                    │
│   pm2 save                  Save current config             │
│   pm2 startup               Enable auto-start on boot       │
├─────────────────────────────────────────────────────────────┤
│ SKILLS (via ClawdHub)                                       │
│   clawdhub install <slug>   Install a skill                 │
│   clawdhub update --all     Update all skills               │
│   Skills dir: ~/clawd/skills/                               │
├─────────────────────────────────────────────────────────────┤
│ IN-CHAT COMMANDS                                            │
│   /status                   Show model and token usage      │
│   /new or /reset            Clear session history           │
│   /think <level>            Set reasoning depth             │
│   /verbose on|off           Toggle detailed output          │
└─────────────────────────────────────────────────────────────┘

Troubleshooting

“Connection refused” when SSHing
Double-check the IP address in Hetzner’s dashboard.

OpenClaw command not found
Run the install script again, then source ~/.bashrc.

Bot not responding on Telegram
Check the service status with systemctl status openclaw or pm2 list. Verify your Bot Token and Chat ID are correct by re-running openclaw onboard.

Got disconnected from SSH
Just reconnect with ssh root@YOUR_IP. OpenClaw keeps running if you set up PM2.

Cost breakdown

Infrastructure:

• Hetzner CX22: ~€4.35/month

AI Models (per 1M tokens in / out):

• Claude 3.5 Sonnet: $3 / $15 (~$0.01-0.03 per message)

• Claude 3.5 Haiku: $0.80 / $4 (~$0.005 per message)

• GPT-4o: $2.50 / $10 (~$0.01-0.02 per message)

• GPT-4o mini: $0.15 / $0.60 (~$0.001 per message)

• DeepSeek V3: $0.27 / $1.10 (~$0.002 per message)

Realistic monthly API costs:

• Light use (10 messages/day): $3-10/month

• Moderate use (50 messages/day): $15-50/month

• Heavy use (automated tasks running overnight): $50 →

Mac Mini vs. Server Cost Comparison

The Complete System

The guide above gets you a working AI assistant. But if you want OpenClaw to actually help with design system work, you need the right skills and configuration.

1. Design System Skills Pack

Skills teach OpenClaw how to use tools. Each skill is a SKILL.md file with instructions. Browse available skills at ClawdHub.

Install skills via ClawdHub CLI:

clawdhub install steipete/bird      # Twitter/X access
clawdhub install steipete/goplaces  # Google Places API
clawdhub update --all               # Update all installed skills

Some useful skills for design system work:

• bird: Monitor design system discussions on X, post updates

• Web browsing (bundled): Research design patterns, check documentation

• File system (bundled): Monitor token files, read component code

• Git (bundled): Track repo changes, review commits

Create your own skill:

Skills live in ~/clawd/skills/. Create a folder with a SKILL.md:

---
name: token-validator
description: Validates design token usage in code files
---

## Instructions

When asked to validate tokens:
1. Scan files for raw hex colors (#XXXXXX)
2. Check for primitive tokens used in components
3. Report violations with file paths and line numbers

OpenClaw learns from your SKILL.md and applies those instructions when relevant.

2. SOUL.md Template

This is the personality file that shapes how OpenClaw thinks and responds. Copy this into ~/clawd/SOUL.md:

# Identity

You are a Design System Assistant specialized in helping design and engineering teams maintain consistency, quality, and adoption of their design system.

## Core responsibilities

1. **Token management**: Monitor token files for changes, validate naming conventions, flag breaking changes
2. **Component health**: Track component usage, identify inconsistencies, suggest consolidation opportunities
3. **Documentation**: Keep docs current, generate changelogs, answer team questions
4. **Adoption support**: Help teams migrate to new components, explain design decisions, provide code examples

## How you communicate

- Be direct and specific. "Button uses wrong token" not "there might be an issue"
- Include file paths and line numbers when referencing code
- Provide copy-paste solutions when possible
- Flag severity: 🔴 breaking, 🟡 warning, 🟢 info

## What you monitor

- Changes to `/tokens/` directory
- PRs that modify component files
- Issues tagged with `design-system`
- Figma file updates (when connected)

## Scheduled tasks

- **Daily 9am**: Summarize overnight PRs affecting design system
- **Weekly Monday**: Generate component usage report
- **On PR merge**: Check for token violations in changed files

## Token naming conventions

Follow this hierarchy:
- Primitive: `color.blue.500`, `spacing.4`
- Semantic: `color.background.primary`, `color.text.danger`
- Component: `button.background.default`, `input.border.focus`

Flag violations when:
- Raw hex values used instead of tokens
- Primitive tokens used directly in components
- Semantic intent doesn't match usage (e.g., `danger` on non-destructive action)

## Response format for alerts

When alerting about issues, use this format:

**[SEVERITY] Issue Title**
- File: `path/to/file.ts:42`
- Problem: What's wrong
- Fix: How to resolve it
- Context: Why this matters

Customize the scheduled tasks and monitoring paths to match your repo structure.

3. GitHub Webhook Setup

Make OpenClaw respond to repository events in real time. This requires the Gateway service to be running.

Step 1: Generate a webhook secret

Ask it to create a webhook based on your configuration and it will help you.

Step 4: Add webhook to GitHub

1. Go to your repo → Settings → Webhooks → Add webhook

2. Payload URL: https://webhook.yourdomain.com/github

3. Content type: application/json

4. Secret: The hex string from Step 1

5. Events: Select “Let me select individual events”

   • Pull requests

   • Push

   • Issues

   • Issue comments

Step 5: Test it

Create a test PR. Within seconds, OpenClaw should message you on Telegram with a summary.

4. Automation Recipes

Five ready-to-use workflows. Tell OpenClaw to set these up, or configure manually.

✨ Recipe 1: Token Sync Alerts

Trigger: Any push to tokens/ directory

When files in /tokens/ change:
1. Parse the diff
2. Identify added/removed/modified tokens
3. Check for breaking changes (removed or renamed tokens)
4. Send Telegram alert with summary
5. If breaking: tag as 🔴, list affected components

✨ Recipe 2: PR Review Summaries

Trigger: New PR opened

When a new PR is opened:
1. Read the PR description and changed files
2. Identify design system impact:
   - New components?
   - Token changes?
   - Breaking changes?
3. Generate summary for Telegram:
   - PR title and author
   - Files changed (grouped by type)
   - Design system impact assessment
   - Suggested reviewers

✨ Recipe 3: Component Usage Reports

Trigger: Weekly (Monday 9am)

Every Monday at 9am:
1. Scan codebase for component imports
2. Count usage per component
3. Identify:
   - Most used components
   - Unused components (candidates for deprecation)
   - Components with declining usage
4. Generate markdown report
5. Post to Slack/Telegram and save to /reports/

✨ Recipe 4: Documentation Updates

Trigger: Component file changes merged to main

When component files change on main:
1. Parse the component's props/API
2. Compare with existing documentation
3. If mismatched:
   - Generate updated docs
   - Create PR with changes
   - Alert on Telegram

✨ Recipe 5: Weekly Health Check

Trigger: Sunday 8pm

Every Sunday at 8pm:
1. Run token validation across all files
2. Check for console warnings in component tests
3. Verify all components have documentation
4. Count open design system issues
5. Generate health score (0-100)
6. Send weekly digest:
   - Health score trend
   - Top 3 issues to address
   - Wins from this week

How to set up a recipe:

Tell OpenClaw in plain English:

Set up a scheduled task: Every Monday at 9am, scan the codebase
for component imports, count how often each is used, and send
me a summary on Telegram. Save the full report to /reports/weekly/

OpenClaw will create the automation and confirm the schedule.

Are you stuck?

1. Check the OpenClaw Discord for community help

2. Search GitHub Issues

3. Run openclaw doctor for automated diagnostics

What’s next

Once you have OpenClaw running:

1. Browse and install skills from ClawdHub:

clawdhub install steipete/bird
clawdhub install steipete/goplaces

1. Set up GitHub webhooks so your AI monitors your repos

2. Add more integrations like Discord or Slack

3. Customize the personality by editing SOUL.md in your workspace

You now have a personal AI assistant running 24/7 in the cloud. You control it from Telegram on your phone. And unlike ChatGPT or Claude.ai, it’s yours to customize however you want.

More to come …

Enjoy exploring and stay careful. 🙌

Explore more

🔗 Hetzner Cloud → Affordable European cloud hosting

🔗 OpenClaw Documentation → Official documentation

🔗 OpenClaw GitHub → Source code and issues

🔗 OpenClaw Website → Project homepage

🔗 Telegram BotFather → Create Telegram bots

🔗 Anthropic Console → Get your Claude API key

🔗 PM2 → Node.js process manager

— If you enjoyed this post, please tap the Like button below 💛 This helps me see what you want to read. Thank you.

💎 Community Gems

Figma Console MCP Repo by TJ Pitre

Your design system as an API. Connect AI to Figma for extraction, creation, and debugging.

🔗 Link

If you’re anything like me, you’re tired of the same recycled advice about design system teams.

“Hire a design systems engineer.” “You need a dedicated team of 5.” “Document everything.” The playbooks written in 2022 still get passed around as gospel, even though the world shifted A LOT.

The “right” team size changed dramatically in the past two years. What required 3 people in 2023 can now often be done by 1 person with the right AI toolkit. And what required a much larger enterprise org can now often be done by a smaller, senior team. Well, if the whole delivery system evolves (review, testing, release), not just “writing code.”

But here’s the uncomfortable part: the landscape now changes almost weekly.

New AI capabilities drop constantly. Claude gets better. Cursor ships new features. MCP servers unlock new integrations. What was impossible 6 months ago becomes trivial this month.

This creates a paralyzing question I hear from every design system team: when does it make sense to invest in upskilling?

Most teams are stuck in this loop:

• “We should probably learn these AI tools properly.”

• “We should create our own LLM.”

• “But what if everything changes again next month?”

• “The time investment feels bigger than the payoff.”

• “Let’s wait until things stabilize.” 🫠

The problem? Things won’t stabilize.

The teams waiting for the “right time” are falling further behind those that have accepted that continuous learning is now part of the job.

The ROI calculation has flipped. The question isn’t “is it worth the investment?” It’s “can you afford NOT to, when your competitors are shipping 2-3x faster?”

This isn’t about replacing humans. It’s about understanding which roles become MORE important with AI, and which tasks you can delegate to AI tools.

I want to share 5 ideas on design system team structure that challenge the conventional wisdom and actually reflect reality in 2026.

Let’s begin.

The cheat sheet: company size → team structure

You aren’t struggling with headcount. You’re struggling with leverage.

Most design system leads I talk to have the same complaint: “We need more people.”

But when I dig into how they spend their time, I find the same pattern. Senior engineers writing documentation. Designers are manually auditing token usage. Leads are drowning in Slack support requests while their roadmap collects dust.

They don’t have a headcount problem. They have a leverage problem.

The reality is that design system work falls into two categories: work that requires human judgment and work that doesn’t.

Human judgment work:

• Deciding which components to build next

• Designing APIs that will scale

• Building relationships with product teams

• Navigating organizational politics

• Solving novel accessibility challenges

Non-judgment work:

• Writing the first draft of documentation

• Scaffolding component boilerplate

• Auditing tokens for consistency

• Generating changelogs from commits

• Triaging support tickets

In 2023, we had to do both categories ourselves. In 2026, AI handles the second category with minimal oversight.

If you want to scale your design system, you must have the systems that create scale before you add headcount.

Most teams add people first. Then wonder why the output doesn’t double. The new person gets absorbed into the same inefficient workflows. You pay for two people to do what one person with better leverage could accomplish.

I’ve seen 3-person teams outperform 10-person teams. Not because they worked harder. Because they understood which work to automate, which to delegate, and which to own.

The team of 10? They had more hands, but every hand was doing low-leverage work.

The traditional team models are obsolete. Here’s what replaced them.

The 1-person design system team (2026 edition)

You’re alone. You have to:

• Design components in Figma

• Build them in code

• Write documentation

• Evangelize adoption

• Handle support requests

• Maintain governance

• Plan the roadmap

In 2023, this was nearly impossible to do well. Something always suffered (usually documentation and adoption).

But even with AI, there’s a ceiling. One person cannot:

• Build deep relationships across 10+ product teams

• Ship major components AND do adoption evangelism simultaneously

• Handle a design system used by 100+ developers

AI extends your reach. It doesn’t give you infinite capacity.

Warning: The 1-person + AI model only works if...

This model is compelling, but it’s easy to dangerously over-generalize. It only works under specific conditions:

• Senior-level experience
  You’ve shipped design systems before. You know what good looks like. AI can’t replace the judgment you’ve built over years.

• Organizational trust
  Leadership gives you autonomy to make decisions without endless approval cycles. If every component needs a committee, AI won’t save you.

• Product maturity
  Your company’s product patterns are relatively stable. If requirements change weekly, you’ll spend all your time on context-switching, not leveraging AI.

• Technical foundation
  You can set up your own tooling. If you need someone else to configure CI/CD, MCP servers, or AI integrations, this model breaks down.

• Scope discipline
  You can say “no” to requests. One person + AI can maintain 20-40 components well. Trying to maintain 100 components solo is a path to burnout.

Red flags this model won’t work:

• Your org expects a “design system team” to also run the component library, documentation site, design ops, AND Figma governance

• You’re expected to support 5+ product teams with conflicting priorities, design changes, endless meetings, etc.

• There’s no executive sponsor who shields you from scope creep

• You’re junior/mid-level and still building core design system skills

If you don’t have these prerequisites, push for a 3-person team before accepting the solo + AI role.

The 3-person model

The 3-person model (2023):

• Design Systems Lead (Figma, design decisions, documentation)

• Design System Engineer (code, CI/CD, tooling)

• Product/Ops (roadmap, adoption, support)

This made sense when each domain required full-time effort. Documentation alone could consume 30% of someone’s week.

The 3-person model (2026):

• Design Systems Lead (strategy, governance, adoption – 60% strategic, 40% hands-on)

• Design Systems Engineer (components, CI/CD, AI tooling, MCP servers)

• Design Engineer (Figma library, design-to-code, prototyping, documentation)

Every team member needs these AI-era skills:

• Prompt engineering basics: Writing effective prompts for consistent output

• AI orchestration: Knowing which tool to use for which task

• Quality control mindset: AI output requires review; knowing what to check

• MCP/API literacy: Understanding how to connect AI to your systems

Traditional → now handled by:

Documentation writing → AI-assisted, owned by whoever builds the component

Support ticket responses → AI triage + templates, minimal human time

Changelog maintenance → Automated from commits

Usage analytics reports → Dashboards + MCP servers querying data

Contribution process → Templated workflows, AI-assisted code review

The real question isn’t “how many people?” anymore. It’s “how many people doing WHAT?”

What a 3-person team can realistically achieve with AI augmentation in 2026:

• 50-100 components maintained

• Support for a few product teams

• Bi-weekly release cadence

• Comprehensive documentation (AI-assisted)

• Basic design token automation

• Visual regression testing

• Accessibility compliance monitoring

The 10-person design system team (2026 edition)

At 10 people, you’re running what’s essentially an internal product. The challenge shifts from “can we build it?” to “can we coordinate it?”

Most 10-person design system teams fail not because they lack talent. They fail because they lack clarity.

• Nobody knows who decides what

• Design and engineering work in parallel silos

• Governance becomes bureaucratic gatekeeping

• AI tools are used inconsistently (or not at all)

• No change log (or decisions log)

Here’s what the optimal 10-person team looks like in 2026:

Strategic Layer (3 people):

• Director: Exec alignment, strategy, vision

• Product Manager: Roadmap, metrics, prioritization

• Adoption Lead: Evangelism, training, support relationships

Design Layer (2-3 people):

• Lead Designer: Architecture, governance

• Design Engineer: Figma + Code, prototyping

• Visual Designer (optional): Multi-brand systems

Engineering Layer (3-4 people):

• Engineering Manager: Architecture, code quality

• Platform Engineer: AI infra, CI/CD, MCP servers

• Frontend Engineers (x2): Components, features

Specialized (1-2 people):

• Accessibility Specialist: Compliance, auditing, training

• Developer Experience (optional): Docs, AI tooling, prompt libraries

The hiring signals that actually matter

Don’t hire based on company size. Hire based on these signals:

• You’re spending more than 50% of time on support and maintenance

• Adoption has stalled because you can’t do outreach

• You have a backlog of 6+ months of component requests

• Teams are building workarounds because they can’t wait for you

• You’re burning out

The skills that became MORE valuable

Own these:

• Strategic decisions: Which components to build next

• Design quality: Ensuring components solve real problems

• Relationship building: Getting teams to actually adopt the system

• Governance frameworks: Setting the rules (even if AI helps enforce them)

• Complex problem-solving: Edge cases, accessibility nuances, cross-platform considerations

Delegate to AI:

• First drafts of documentation

• Code scaffolding and boilerplate

• Token validation and linting

• Changelog and release notes

• Support ticket triage and initial responses

Delegate to product teams (with good tooling):

• Basic component usage

• Bug reports with clear templates

• Contribution of simple patterns

Roles that are becoming MORE important in 2026:

1. Adoption Lead

AI can generate components. It can write documentation. It can even respond to support tickets.

What AI cannot do is convince a skeptical product team to use your system instead of their custom solution. It cannot navigate the politics of a reorg. It cannot sit in a room and understand why adoption stalled.

The companies winning at design systems in 2026 have someone dedicated to this. Not as a side responsibility. As the main job.

2. Platform Engineer

Someone needs to set up and maintain the AI infrastructure. MCP servers. Automation pipelines. The tooling that lets AI access your design system data.

Most teams underinvest here. They use AI tools but don’t customize them for their context. They get generic outputs because they provide generic inputs.

3. Accessibility Specialist

AI catches basic accessibility issues. It can run automated scans and flag obvious violations.

But accessibility at scale requires human expertise for edge cases, cultural considerations, and training teams to think accessibly from the start. This role became more important, not less.

4. Developer Experience Engineer

With AI-assisted development, the quality of your AI tooling setup directly impacts productivity. The prompts. The context. The MCP configurations.

This role didn’t exist in 2023. In 2026, it’s a competitive advantage.

Roles that shrunk or merged:

1. Technical Writer (as a standalone role)

Documentation is now AI-assisted and owned by builders, not a separate function. The writer role evolved into “documentation architect” – someone who designs the structure and reviews AI output.

2. Junior Developers

AI handles much of what junior devs used to do. Copy-paste patterns. Boilerplate scaffolding. Basic component implementation.

Fewer junior roles, but those who remain need AI collaboration skills. The junior dev of 2026 is more like the mid-level dev of 2020.

3. Pure Visual Designers

Design engineers who can implement are more valuable than designers who only produce Figma files.

The 2026 Formula

Fewer people + Higher seniority + AI augmentation = Same or better output

A 1-person team with AI beats a 1-person team without.
A 3-person team with clear roles beats a 5-person team with unclear ownership.
A 10-person team with defined accountability beats a 15-person team playing politics.

Your design system team structure isn’t about hitting a magic number. It’s about:

1. Understanding what AI changed

2. Investing in the right roles

3. Matching structure to stage

4. Watching the signals

Start by auditing your current team against these models. What’s your biggest gap?

That’s where you either hire or leverage AI.

I’ve gathered more articles below, if you want to dig in to numbers or experiences from other companies.

Stay tuned and enjoy the process,

Romina

💎 Community Gems

Hackathon

February 6-8 2026 - Online

I am part of the jury and will also help you to hack faster ;) See you there. 😊

🔗 Link

• 84% of developers were using or planning to use AI tools in 2025

• GitHub Copilot now generates 46% of all code written by active users

• Design in 2025: Navigating the AI Revolution and Redefining Our Role

• 90% of Fortune 100 companies utilize GitHub Copilot

• Developers complete tasks 55% faster with GitHub Copilot

• Average time to open a pull request dropped from 9.6 days to 2.4 days

• The death of design expertise? How AI is reshaping creative industries forever

• Design Systems Report 2025 - An overview

• Top 5 Trends for 2025: How AI, Change, and Employee Experience Are Shaping Organizational Design

• Cursor study showed 39% increase in merged pull requests

• Gartner estimates 80% of engineers will need to reskill by 2027

• “Hiring someone who can see the big picture and work well with AI reduces the need for large, specialized teams”

— If you enjoyed this post, please tap the Like button below 💛 This helps me see what you want to read. Thank you.

Today I’m releasing Taste 1.0, a new model specifically designed for design system work.

Key capabilities:

• Generates components that match your system’s conventions

• Knows when to use ghost vs secondary vs tertiary

• Understands your spacing scale, your naming patterns, your anti-patterns

• Ships accessibility by default

• Never invents a new variant when an existing one works

Availability: today.

The model is a folder of markdown files. 🙃

I knoooow. You were hoping for something with 400 billion parameters and a clever name. But here is the thing:

You ask AI to generate a component. It ships something that looks fine. Then you paste it into your product, and it sticks out. Wrong spacing. Wrong naming. Wrong defaults. Wrong “feel”.

And you think: “I need a better model.”

You probably do not.

You need a “taste layer,” or in other words, an opinionated, structured set of guidelines. The best model in the world does not know what “good or good looking” means at your company. It does not know that you rejected outline buttons in 2025. It does not know that your spacing scale is 4px-based, not 8px. It does not know that color.text.muted it is for helper text, not placeholders.

No model knows this. No model will ever know this.

Unless you tell it.

That is what your set of markdown files can be. Your judgment, decisions, and taste, saved as context.

Two signals that this is where we are heading

First, Gartner predicts that by 2027, organizations will use small, task-specific AI models 3x more than general-purpose LLMs (Gartner press release).

However, we already moved from “pick a smart model” to “build a smart system”. And please don’t get me wrong, which model you choose still affects what you get in the end.

Model system vs model taste

Here is the simplest way I can explain it:

• Model system: the base model’s general capability. It can write, code, reason, and remix patterns. (Claude, GPT, Gemini, Llama, etc.)

• Model taste: your organization’s judgment layer. It defines what “good” means here. (Your markdown files: ds-core.md, ds-components.md, etc.)

Your taste lives in the files you maintain:

• ds-core.md says “use semantic tokens, never raw hex”

• ds-components.md says “max 4 variants per component.”

• ds-tokens.md says “we rejected 8px spacing in favor of 4px for density”

These files shape what gets produced and what gets rejected. They act like a conditioning layer on top of the base model.

I know what you are thinking

“Okay, but is this just documentation with a new name?”

Not really. These are opinionated, specific, structured guidelines for building user interfaces.

But here is what changes when you treat it like a system component:

• You version it.

• You review it.

• You prune it.

• You enforce it.

You write constraints so people and agents can ship consistently.

Routing is the shift

You do not ask every model to solve everything.

You first figure out what kind of problem this is. Then you route it to the right specialist.

Agent workflows need three things:

1. Routing: decide which specialist should answer.

2. Memory: keep decisions and context over time.

3. Specialization: use narrow experts instead of one generalist.

It is all about system design. Ask yourself, “How do we design an intelligent system made of many parts?”

The research backs this up. A 2025 study on instruction-following capacity (IFScale benchmark) found that even the best frontier models only achieve 68% accuracy when given 500 instructions. Most models show one of three degradation patterns:

• Threshold decay: near-perfect until ~150 instructions, then sharp decline

• Linear decay: steady, predictable drop across the spectrum

• Exponential decay: rapid early degradation, then floors at 7-15% accuracy

The takeaway: do not stuff everything into one prompt. Route to specialists with focused context.

Knowledge graph as the glue

When you split work across multiple specialists, you need something that keeps them aligned. That is the knowledge graph.

A knowledge graph is a structured representation of concepts and their relationships.

Think of it like this: instead of a flat list of definitions, you have a map. The map shows what things are, how they connect, and what rules govern their relationships.

In technical terms: nodes (things) plus edges (relationships) plus properties (attributes).

In practical terms: a shared vocabulary that everyone and everything can reference.

What does this mean for design systems?

For design systems, the knowledge graph answers questions like:

• What is a “Button”? What variants exist? What tokens does it use?

• What is color.text.muted? When do you use it? What is it not for?

• What is a “Card”? How does it relate to “Surface”? Can they nest?

• What counts as a “pattern” vs a “component” vs a “primitive”?

Without this, you get drift. One agent generates a GhostButton. Another generates a Button with variant="ghost". A third generates a TextButton. All three think they did the right thing.

With a shared knowledge graph, every specialist checks the same source before generating. They use the same names, the same relationships, the same constraints.

How is this different from regular documentation?

Regular documentation describes things. A knowledge graph connects things.

For example:

“Use muted text for secondary content” → color.text.muted → applies to → helper text, timestamps, captions

The key difference: a knowledge graph makes relationships explicit. An agent can traverse it. “What tokens does Button use?” “What components can go inside Card?” “What is the difference between muted and secondary?”

What should you put in your design system knowledge graph?

Design systems are evolving into intelligent context-aware systems.

Start with the foundation layers, then build toward the future.

Foundation layers (what you need today)

1. Primitives

The lowest-level building blocks.

• Colors (and their semantic mappings)

• Spacing scale (and when to use each step)

• Typography scale (and what each level is for)

• Radius, shadow, motion tokens

Example:

- Always use Tailwind CSS defaults
- Never use primitive design tokens on components

2. Components

The UI building blocks.

• Name, variants, states

• Which tokens each component uses

• Composition rules (what can go inside, what cannot)

• Accessibility requirements

- Check existing components before creating new ones
- Never hardcode colors
- Always check Storybook (link/token)
- Always check Figma UI kit (link) via Figma MCP
- Always check Gitlab (link)
- and so on ... 

3. Patterns

Combinations of components that solve recurring problems.

• Form layouts

• Navigation patterns

• Data display patterns

• Empty states, loading states, error states

- Always include one call to action
- Follow these rules for combining components (XY)

4. Decisions

The “why” behind everything.

• Why we chose X over Y

• What we tried and rejected

• When to break the rules

5. Taxonomy

The classification system that makes routing work.

• design vs engineering

• tokens vs components vs patterns

• new work vs existing pattern

Future layers

These are the layers that turn a design system into an experience system.

6. Context engine

How the system adapts to who is using it and what they need.

• Intent detection rules: what signals indicate the user wants X vs Y?

• Personalization mappings: user type → defaults, density, complexity

• Platform adaptation: web vs mobile vs embedded vs voice

• Locale rules: what changes per region, language, or market?

• Brand adaptation: how does the same component express different brands?

Example entry:

Intent: user wants to delete something

- Signals: clicked delete icon, selected items + pressed backspace, said "remove"
- Response pattern: show confirmation dialog (AlertDialog, not Dialog)
- Modality options: visual confirmation, haptic feedback on mobile, voice confirmation
- Escalation: if bulk delete > 10 items, require explicit confirmation

7. Interaction blueprints

Agentic flows and adaptive behaviors.

• Flows that shift based on user behavior (not just screen size)

• Proactive assistance patterns: when does the system offer help?

• Fallback rules: what happens when intent is unclear?

• Handoff patterns: when does the system escalate to a human?

Example entry:

Flow: onboarding

- Adaptive rule: if user skips 2+ steps, offer "skip to dashboard" option
- Proactive assist: if user pauses > 10 seconds on a field, show tooltip
- Modality switch: if voice detected, offer voice-guided onboarding

8. Multimodality mappings

One intent, expressed in the best way for the context.

• Touch, visual, audio, voice, gesture

• Haptic, text, ambient, motion

• Which modality is primary vs fallback for each intent?

• How do modalities combine?

Example entry:

### Action: confirm destructive action

- Visual: red button + confirmation dialog
- Voice: "Are you sure you want to delete [item]?"
- Haptic: warning vibration pattern before confirm
- Fallback order: visual → voice → haptic

9. Governance rules

How the system stays aligned at scale.

• Which decisions require human approval?

• Which outputs get auto-validated vs flagged for review?

• What are the hard constraints that never bend?

• How do you handle conflicts between agents?

You do not need fancy tooling to start

Start with markdown that acts like one:

Design Specs:

Colors:
- Background: #3B82F6 (primary), #FFFFFF (secondary)
- Text: #FFFFFF (primary buttons), #1F2937 (secondary buttons)
- Border: #E5E7EB (1px)
- Focus ring: #3B82F6 with 2px offset

Typography:
- Font family: Inter
- Font size: 14px (small), 16px (medium), 18px (large)
- Font weight: 500 (medium), 600 (semibold for primary)
- Line height: 1.5

Spacing:
- Padding: 8px 16px (small), 12px 24px (medium), 16px 32px (large)
- Gap between icon and text: 8px
- Minimum height: 32px (small), 40px (medium), 48px (large)

Visual effects:
- Border radius: 6px
- Box shadow: 0 1px 2px rgba(0,0,0,0.05)
- Hover: darken by 10%, lift shadow to 0 2px 4px rgba(0,0,0,0.1)
- Transition: all 150ms ease

This is not as powerful as a real graph database. But it gives you 80% of the benefit: shared definitions, explicit relationships, and a single source that agents can reference.

Why this matters for multi-agent systems

When you have a single model doing everything, you can embed context into a single prompt.

When you have many specialists, that breaks down. Each specialist sees a slice. If they do not share definitions, their outputs conflict.

The knowledge graph is the glue:

• All specialists reference the same definitions

• Outputs stay semantically aligned

• The system scales without drift

Without it, small models drift. Outputs contradict each other. Your system falls apart.

With it, models stay modular and coherent.

Binary tree routing: a mental model that makes this click

Think of routing like a decision tree. Each step narrows the problem.

Every decision reduces complexity until you hit the right specialist.

This is why small models work. They do not need to understand everything. They only need to understand their slice.

So, what I mean by “markdown is an additional model”

I mean, it behaves like a conditioning layer:

• It constrains behavior. It tells the system what “good” looks like.

• It compresses decisions. It prevents re-litigating the same debates.

• It generalizes across tasks. UI, copy, naming, motion, tokens, component APIs.

• It stays cheap to update. You edit a file. You do not retrain a model.

The taste kit: a folder of markdown files

Here is the key insight: if you are heading toward multiple specialists doing small things, your context files should mirror that.

Do not put everything in one giant CLAUDE.md.

Create multiple markdown files, each specialized for a specific design system task. When you route a task to a specialist, you give it only the context it needs.

The folder structure

.cursor/
├── ds-core.md           # Shared foundations (tokens, principles, stack)
├── ds-components.md     # Component creation and modification
├── ds-tokens.md         # Token decisions and naming
├── ds-prototyping.md    # Rapid prototyping rules
├── ds-ux-review.md      # UX review checklist and criteria
├── ds-documentation.md  # Writing component docs
├── ds-migration.md      # Migrating legacy patterns
└── ds-accessibility.md  # A11y requirements and testing

Each file is specific. Each file gets loaded only when relevant.

File 1: ds-core.md (shared foundations)

This is the only file every specialist sees. Keep it short.

# Design system core

## Stack
- React + TypeScript
- Tailwind CSS with design tokens
- Radix primitives for accessible components

## Principles (in priority order)

## Token rules

## Naming

File 2: ds-components.md (creating and modifying components)

Load this when the task is “create a component” or “add a variant”.

# Component creation rules

## Before creating a new component

## Component structure

## Variant rules

## Composition

## Anti-patterns

File 3: ds-tokens.md (token decisions)

Load this when the task involves tokens, theming, or color decisions.

# Token rules

## Naming convention

Examples:

## When to create a new token

## When NOT to create a token

## Token relationships

## Decisions log

File 4: ds-prototyping.md (rapid prototyping)

Load this when speed matters more than polish.

# Prototyping rules

## Goal

## What to skip

## What to keep

## Prototype checklist

## Output format

File 5: ds-ux-review.md

You can specify how to create automated screenshots, review work, review colors, etc.

# UX review criteria

## Consistency check
- [ ] Uses existing components (not custom implementations)
- [ ] Uses semantic tokens (not hardcoded values)
- [ ] Follows established patterns (not inventing new ones)
- [ ] Matches existing density and spacing rhythm

## Interaction check
- [ ] Interactive elements have visible focus states
- [ ] Destructive actions use confirmation dialogs
- [ ] Loading states use skeleton patterns
- [ ] Error messages appear near the action

## Accessibility check
- [ ] Color contrast meets WCAG AA (4.5:1 for text)
- [ ] Interactive elements are keyboard accessible
- [ ] Icon-only buttons have aria-label
- [ ] Form inputs have visible labels

## Content check


## Red flags (block the PR)

File 6: ds-documentation.md (writing component docs)

Load this when documenting components.

# Documentation rules

## Every component needs

## Writing style

## Props table format

## Do not include

The workflow: propose, route, generate, validate

If you want this to work in real teams, you need a repeatable workflow.

Step 1: Propose the intent

Write a short intent plus constraints in the PR description. One paragraph max.

Step 2: Route it

Decide which specialist should answer.

Start with a simple taxonomy:

• design / engineering

• tokens / components / content

• new pattern / existing pattern

Step 3: Generate with constraints

Give the specialist the minimum context it needs:

• ds-core.md (always)

• the task-specific file (ds-components.md, ds-ux-review.md, etc.)

• one canonical example if relevant

Step 4: Validate

Check the output against your rules:

• Does it use the right tokens for the right reason?

• Did it introduce a new variant?

• Does it follow your naming and composition patterns?

• Does it ship accessibility by default?

Step 5: Capture the decision

If you accept a new pattern, write down why.

If you reject it, write down the rejection rule.

This is how taste compounds instead of resetting every quarter.

Where to start

Start with two files and one task.

• Understand what a consistent, accessible, coherent UI looks like

• Know when to say NO to a new variant

• Capture decisions so taste compounds

• Evaluating output against real standards, not just “does it work?”

Here is a 60-minute plan:

1. Create ds-core.md with your stack, principles, and token rules. Keep it under 30 lines.

2. Pick your most common task. Component creation? UX review? Prototyping?

3. Create the matching task file. Start with ds-components.md or ds-ux-review.md.

4. Run one generation using only those two files as context.

5. Review the output. What did it get right? What rule was missing?

Then iterate. Add one file per week as new tasks come up.

Pro tip: If you use Claude Code, start with Plan Mode. It reads your codebase and markdown files before generating anything. This is exactly the “route first, then execute” pattern. Let it analyze your context files, propose an approach, then generate. You will catch misunderstandings before they become wasted code.

In short

You do not win in 2026 by picking the smartest model. You win by designing the system around it: routing, memory, specialization, and a shared source of truth.

Markdown is one of the fastest ways to build a taste layer that scales.

You got this.

Enjoy, Romina 🙌

Related read

🔗 Gartner predicts by 2027, organizations will use small task-specific AI models three times more than general-purpose large language models - Gartner press release on the shift toward smaller, task-specific models.

🔗 How to Write Good AI Agent Specs by Addy Osmani - Practical guide on structuring specs for AI agents, with emphasis on modular context and clear boundaries.

🔗 How Many Instructions Can LLMs Follow at Once? - Research showing instruction-following degrades significantly as instruction count increases.

— If you enjoyed this post, please tap the Like button below 💛 This helps me see what you want to read. Thank you.

💎 Community Gems

Hackathon

February 6-8 2026 - Online

I am part of the jury and will also help you to hack faster ;) See you there. 😊

🔗 Link

You’re watching another “build a design system in 4 hours” video and asking yourself: “Hoooooow?!” and thinking you’ll finally solve your component chaos.

I get it.

But here’s what the video doesn’t show:

• Three different button implementations across your codebase (plus more in Angular, Vue, and legacy jQuery)

• Developers asking “which token do I use?” (spacing, color, shadow... pick your confusion)

• The design system team of one, drowning in maintenance requests

• Leadership eventually seeing “why does our app look exactly like every other startup?”

This isn’t a design system. This is expensive copy-paste with extra steps.

I know what you’re thinking: “AI changes everything. We don’t need design system teams anymore.”

Let me show you why that’s only half true.

What changed in the last year(s)

Shadcn made component libraries free. Then came Radix, Ark UI, Park UI, and dozens more. AI made customization instant. Every startup can “build a design system in 4 hours.”

The narrative became: “You don’t need a design system team anymore.”

And they’re right until the codebase grows and customization takes up all your time.

Here’s what happens next:

Initial setup: Fast ✅
Customization: Much longer than expected
Answering “which variant?” questions: Ongoing forever
Fixing things when Shadcn breaks: Ongoing forever

Still cheaper than traditional design systems. But not free.

The trap you can fall into

This is where you can make expensive mistakes.

Startup reality:

• 10 developers

• One codebase

• Modern stack

• Can break things and move fast

Enterprise reality:

• 500 developers

• 12 codebases (React, Angular, new Next.js projects)

• Compliance requirements

• Cannot break things

Shadcn solves React. What about the other 60%?

Migration costs often exceed custom build costs by 3-5x when you have legacy systems. You’re not just migrating code. You’re retraining teams, updating tooling, managing parallel systems during transition, and dealing with breaking changes across multiple products.

From tools to taste

When you can buy a UI kit for $300 (or less) or copy Shadcn for free, leadership asks: “Why do we need a design system team?”

The answer most teams give is wrong. They say: “To build components faster.” But AI builds components faster than any team.

When software becomes cheap to create, the value shifts to problems that require deep context, taste, and ongoing stewardship. You just can’t buy judgment about what deserves to exist. That’s irreplaceable.

Old model:

• Design system team = Component factory

• Value = Shipping new components

• Success = Coverage+adoption (Do we have all the patterns?)

• Investment = Large team building everything from scratch

New model:

• Design system team = Curators + Strategists

• Value = Context

• Success = Coherence (Is everything consistent?)

• Investment = Smaller team + AI tooling

The role didn’t disappear. It evolved. And that’s actually good news if you’re willing to adapt.

AI amplifies what you already know. If you understand what makes a good pattern, AI helps you implement it 10x faster. If you don’t have that foundation, AI just helps you create garbage faster.

The data advantage

When everyone can generate a button in 30 seconds, the button has “no value”. The context for WHY you need this specific button is priceless.

Most design systems track adoption. That’s table stakes. The real advantage comes from capturing the context that’s invisible by default and compounds over time.

1. Usage data tells you what’s actually happening.

• Which components get used? Which gets ignored?

• How are they connected together? (The patterns that work best often emerge from real usage, not planning.)

• Where do people struggle? What gets copy/pasted instead of imported?

2. Decision history tells you why things exist.

• Why did we choose this pattern over alternatives?

• What did we try that failed?

• When should we sunset this?

Without this, every new team member asks the same questions. Every redesign starts from scratch. You lose years of learning.

3. Taste and curation tells you what deserves to stay.

• What’s been validated enough to standardize?

• What’s redundant and needs to be removed?

• What’s good enough to keep vs. what’s just legacy?

These three layers build on each other. Usage data informs decisions. Decisions shape curation. Curation improves usage. It’s a flywheel, but only if you’re capturing it.

Companies with this infrastructure will make better decisions 10x faster. The teams treating design systems like static libraries will drown in technical debt they can’t even see.

Making your system AI-readable

You’ve probably blamed the model when AI generates garbage. But the model isn’t the problem. Your context is.

Context is everything the AI sees when you ask it something. Your prompt, yes. But also the system instructions, previous messages, files it can access, and metadata. All of it.

And here’s the catch: AI tools have limited memory. Claude Code technically supports 200k tokens, but by the time you account for system prompts and tool definitions, you’re working with maybe 120k. Fill that up with noise, and the output quality tanks.

So the question becomes: what deserves to be in that limited space?

For design and design systems, I’ve found four things matter:

1. A project context file. Call it CLAUDE.md or whatever. Put it at the root. Tell the AI how your system works: naming conventions, component patterns, token structure, key decisions. This is the single highest-impact thing you can do.

2. Decisions in plain text. Not buried in Confluence. Not hidden in Figma comments. In markdown that AI can actually read. “We chose X over Y because Z.” Simple.

3. Lean documentation. Not 50 pages of Storybook stories. A clear reference that fits in context and answers the questions developers actually ask.

4. Tokens with intent. Not just color-primary: #0066FF. Explain why that color exists and when to use it. The AI needs the “why” to make good choices.

The goal? Anthropic calls it “the smallest possible set of high-signal tokens.”

Soooo, if your components keep coming out wrong, don’t switch models. Fix your context first.

The governance problem

AI makes creating components trivial. AI also makes creating BAD components trivial at scale.

Technical governance (solvable by AI):

• Linting rules ✅

• Type checking ✅

• Automated tests ✅

Human governance (still unsolved):

• Who decides when to add a new variant?

• How do we prevent “button-primary-new-final-v3”?

• What’s the process for breaking changes?

• Who has taste?

When creation is free, curation becomes priceless. The bottleneck isn’t “can we build this?” anymore. It’s “should this exist?” That question requires taste, context, and the courage to kill things. AI doesn’t have opinions. You do.

Cost of bad governance:

• Small company: Technical debt, slower velocity

• Enterprise: Massive duplicate work across teams

You can generate components quickly. You need years to build the taste, context, and governance.

Things are moving so fast that there are no books about new UX patterns. AI interactions, voice interfaces, spatial computing. We’re inventing the rules as we go. There’s no “Design Patterns” book for conversational U or best practices for AI-assisted workflows.

This means creating new ways of interacting requires more iterations than ever to build something genuinely useful. You can’t copy what worked before because “before” doesn’t exist for these patterns. You have to experiment, fail, learn, and iterate. Repeatedly. Until you discover what actually works.

The learning curve illusion

“Shadcn has a lower learning curve than traditional design systems.”

This is technically true, but strategically? Not so much.

❌ Before: Clear learning curve, high initial cost
✅ After: Fast start, expensive long-term maintenance

Lower initial learning curve ≠ Lower total learning cost.

You’re just deferring the learning to a more expensive phase.

What design system teams should actually do in 2026

Old job:

• Build React components

• Write Storybook documentation

• Fix component bugs

• Ship 2-3 components per quarter

New job (2026): Design System Lead

One person (or small team) with three responsibilities:

Curation:

Kill more patterns than you create. Use AI to generate, humans to judge. Ask “should this exist?” constantly.

Context:

Capture tribal knowledge before people leave. Translate the system into AI-readable formats. Maintain the “why” behind every decision.

Quality:

Track analytics on every component. Define “good enough” with data. Sunset bad patterns aggressively.

This isn’t a solo effort. Design systems require constant collaboration:

• Product teams need to understand business goals

• Designers and developers need to be in sync

• Stakeholders need to trust the system

• Leadership needs to see the value

You’re not just building software. You’re building organizational muscle memory about what good looks like.

My actual recommendations

Startup (<100 people)

Setup: Days, not months

✅ Use Shadcn/Radix + Tailwind
✅ Use AI for customization
✅ Assign someone to own consistency (part-time is fine)
✅ Track usage data from day one
✅ Document decisions in markdown (AI-readable)
✅ Accept you’ll rebuild every few years

❌ Build from scratch
❌ Hire a dedicated design system team
❌ Create perfect UI kit in Figma before product-market fit

The goal: Stay lightweight. Don’t over-engineer. Test what works.

Mid-size (100-500 people)

Setup: A few months

✅ Start with Shadcn for new projects
✅ Connect old and new with Web Components (see below)
✅ Dedicate someone to stewardship (not creation)
✅ Invest in analytics
✅ Use AI for generation, humans for curation

❌ Try to migrate everything at once
❌ Rewrite legacy code from scratch
❌ Build a massive team
❌ Copy enterprise approaches

Mapping old + new components

You have two paths for legacy components:

Option A:

Wrap it. Use Web Components to wrap legacy code. They work across React, Angular, Vue, and jQuery. Teams keep their existing APIs. The system modernizes underneath. Lower risk, slower progress.

Option B:

Regenerate it. Use AI to analyze legacy components and generate new components that match your target system. Feed AI the component code plus usage examples from your codebase. Validate the output. Replace the imports. Faster progress requires thorough testing.

Most mid-size companies do both: wrap the complex/risky stuff, regenerate the simple/well-tested stuff.

The goal: Bridge old and new without burning everything down.

Enterprise (500+ people)

Setup: Depends on your legacy!

✅ Custom design system is still worth it
✅ Small team focused on curation (not building)
✅ Invest more in governance than components
✅ Use AI for generation, not strategy
✅ Build data infrastructure around your system
✅ Measure outcomes, not adoption
✅ Use Web Components as the universal layer across all frameworks

❌ Try to move everyone to Shadcn
❌ Build components without usage data
❌ Measure adoption as success

Why Web Components make even more sense at scale:

Enterprise has the hardest legacy problem: React 2019, Angular 2017, Vue, jQuery, and whatever new framework the next acquisition brings. Web Components work everywhere. Build once, deploy across all frameworks. No more maintaining 4 versions of the same button.

The bridge strategy from mid-size applies here too, just on a larger scale. Wrap the legacy systems that are too risky to touch. Regenerate the simpler components with AI. Gradually consolidate.

ROI: Track how much time developers spend duplicating UI work. Even a conservative estimate shows the cost of inconsistency far exceeds the investment in a design system team.

Start with the right question

✨ “What problem are you actually solving?” ✨

“We need a starting point for components.”
→ Pick any library (Shadcn, Radix, whatever). But assign someone to own consistency from day one.

“We have 500 developers building duplicate UIs.”
→ Build a system. Hire a Design System Lead.

“We don’t know which patterns actually work.”
→ Invest in analytics.

“AI generates garbage code that doesn’t match our system.”
→ Make your system AI-readable. Then use AI.

“We can’t ship fast enough.”
→ Your problem isn’t just the design system. 🫢

What to do this week

You don’t need to build a design system right now. Start by building the infrastructure to know if you need one. Here’s a practical path:

Step 1: Set up analytics (Day 1-2)

• Track component usage

• Measure user outcomes

• Identify duplicate patterns

Step 2: Document decisions (Day 3-4)

• Create CLAUDE.md with context

• Make decisions AI-readable

• Capture the “why” behind every choice

Step 3: Test with AI (Day 5)

• Generate one component with AI

• See if it matches your standards.

• Identify gaps in your system’s clarity

Step 4: Make one decision (End of week)

Should you:

• Build a system?

• Use Shadcn?

• Invest in curation?

• Invest in agentic XY?

Base it on your data, not industry trends. Trust what you’re learning from your own context.

In short

Design systems in 2026 aren’t about components. They’re about CONTEXT.

Software is cheap to build.
Context is expensive to maintain.

Components are free.
Taste is priceless.

AI can generate anything.
Only humans know what deserves to exist (so start building taste).

The teams that understand this will build better products faster. The teams that don’t will spend hundreds on infrastructure that nobody uses.

And if you’re reading this, asking these questions, thinking critically about the path forward? You’re exactly the kind of person who will figure it out. 🙌

Enjoy the process 😊, Romina

— If you enjoyed this post, please tap the Like button below 💛 This helps me see what you want to read. Thank you.

💎 Community Gems

The Rise of the Model Designer

Interview with Barron Webster (Figma)

🔗 Link

This year, I stopped getting ready to get ready.

I went deep on AI and treated it like a mirror for my work: every workflow I had… I questioned. Some stayed. Many didn’t. Only Google spits out instant results → everything worth building takes reps.

If you read, replied, challenged me, shared your story, or trusted me with your work this year, THANK YOU. You made this year. 💛

If you want to go on a deep dive during the quiet days, here’s a curated list of what I built and published (or prepared) this year.

Start here

• YouTube (Design System Guide)

• The Design System Guide

• AI Design Guide

Guides

Creators 💛

(if you don’t follow them, start now 😊)

Alexander Fandén

Design Systems @Stripe

🔗 Linkedin

Check his 🔗 portfolio (inspiring for any design system designer) and listen to his 🔗 interview.

Vitaly Friedman

Vitaly is THE real UX king, sharing invaluable resources about all things design and UX.

🔗 Smashing Magazine

🔗 Linkedin

🔗 Smashing Events

🔗 UX Metrics Course

Sil Bormüller

Founder of

🔗 Website

🔗 Linkedin

🔗 Design System Jobs Portal

🔗 YouTube

/ Samantha Gordashko

🔗 Substack

🔗 Linkedin

🔗 Design Tokens aren’t enough. Architecture Decisions need a place in your Design System.

Ileania Notarangelo

Partner & Creative Director @ ILLO

My god, these animations are out of this world. Just check their work at illo.tv

🔗 Linkedin

Andressa Lombardo

Design System Lead @ Miro | Teacher @ Memorisely | Host @ IDS

🔗 Linkedin

Justine Montgomery

Design systems @Stripe

🔗 Linkedin

Listen to her talk about building a design system portfolio. Loooots of useful tips!

Growth Advisor, ex-Miro | Founder at Growthmates | Speaker · Creator

🔗 Linkedin

🔗 High-quality principles to support your Product-Led-Growth

Robin di Capua

🔗 Linkedin

David Aerne

David is the true color’s wizard and one of the best interaction developers I know :)

🔗 Linkedin

🔗 FettePalette

🔗 Farbvelo

🔗 Generative Copic Color Wheel

Useful tools and resources

aidesign.guide

Everything you need to integrate AI into your design workflow. Practical guides, prompting techniques, and curated resources for designers.

🔗 Prompts library

bunny.net

🔗 Website

bunny.net is a high-performance CDN with a globally distributed edge network, optimized routing, and aggressive caching (built to deliver content fast and reliably at scale).

I used bunny.net to integrate with storage (via the API) and build my illustration database (both with Figma Make and Cursor). It’s really easy to use and there is no "enterprise” complexity.

🔗Anthropic YouTube Channel where you can learn a lot about how to use Claude + Claude Code

🔗 Lenny’s podcast and newsletter 👌

🔗 a16z podcast

What I’m carrying into 2026

Less “instant” thingies.

More focus.

More systems that make the next thing easier to build.

Wishing you an unforgettable start to the new year. 🥰
Romina

— If you enjoyed this post, please tap the Like button below 💛 This helps me see what you want to read. Thank you.

Product teams do not struggle to design screens. They struggle to validate ideas fast without creating a mess.

Most AI prototyping tools force you to leave Figma, and then you spend time translating the output back into your file.

Figma Make solves a specific problem: it helps you generate functional prototypes while staying inside the Figma file where your team already works.

If you have a design system, Figma Make can reuse it. If you do not, it still helps you move faster on flow, states, and interactions.

What you will get from this article

• A clear decision framework for when to use Figma Make.

• A step-by-step workflow you can run today, including the setup most people miss.

• Prompt templates that force design system consistency.

• Four concrete examples:

  • Prototype with 4 versions

  • Simple example: a mobile learning flashcard prototype

  • Design system example: a Figma Make prototype with existing components

  • Advanced example: an illustration gallery powered by Supabase + CDN (API)

The real problem is context loss

Most “AI prototyping” workflows look like this:

1. You design in Figma.

2. You leave Figma to generate code in another tool.

3. The tool invents new components and styling.

4. You spend time swapping everything back to your system.

5. You hand it off, and the team debates what is real.

The tools are not the enemy. Context loss is.

With Make, you have direct access to:

• Your components (and their variants).

• Your variables (colors, spacing, typography).

• Your naming conventions (which encode decisions).

Figma Make keeps that context close. That is the whole point.

The design system advantage

If you do not connect your libraries, you get generic output. Period.

When you enable the right libraries, Figma Make can treat them as “building blocks” and generate prototypes using:

• Your button (with the variants you already defined).

• Your spacing tokens (instead of hardcoded values).

• Your card, table, bodal, stepper (instead of invented UI).

That is the difference between “AI-generated UI” and “AI-generated UI that your team can actually review.”

One more lever matters: connectors. If your requirements and content live outside Figma (Notion, GitHub, Linear, Jira, and more), you can pull them in so the prototype reflects the actual spec and copy, not your best guess.

Here is the mental model: your Figma libraries are the building blocks, and connectors plus APIs are the context sources.

The complete workflow (setup to output)

This is the workflow I recommend for designers who want speed without sacrificing consistency.

Phase 1: Setup (5 minutes)

Step 1: Turn on the correct libraries

• Open the file where you will prototype.

• Go to Assets → Team library.

• Enable the libraries you want Figma Make to use.

Checkpoint: you can insert your system components manually from the Assets panel.

Step 2: Learn the component names you will reference

Figma Make responds best when you use names exactly as they appear in your library. If your component name reads Button/Primary, use that.

Checkpoint: write down 8 to 12 component names you expect in most screens (Button, Input, Select, Card, Table, Modal, Toast, SideNav).

Now try to create a prototype with and without your library. You can see the difference below with my example.

Step 3: Decide what “done” means for the prototype

You will iterate faster when you define the boundary.

• Are you validating flow, layout, copy, or interaction?

• What states must exist (loading, empty, error, success)?

Phase 2: Prompting with design system context

Don’t add generic prompts. Think about what you need, structure the prompt and the idea, and then copy/paste it. For complex prototypes, I start with the longer prompt, where I specify all the things. Once I see the prototype, I use shorter prompts.

Examples:

Prompt template: system-first screen

“Create a [screen name] using my [layout component] and my [form/data components]. Use spacing tokens for all margins and gaps. Include loading, empty, and error states. Use component names exactly as defined in my library.”

Example: settings screen

“Create a settings page using my SideNav on the left. Build a form with Input, Select, and Checkbox components. Use page spacing tokens and include Button/Primary for Save and Button/Secondary for Cancel. Include validation states and an error banner.”

Complex example:

Responsive Illustration Gallery (check the video below)

Create a clean, minimal illustration gallery that fetches artwork from a bunny.net CDN.

Design System & Styling:

• Strict Adherence: The UI must strictly adhere to the design system defined in /styles/globals.css.

• Typography: Use ONLY the Geist font family as defined in the global CSS. Do not import or use any other fonts.

• Variables: Use the specific CSS variables defined in globals.css for all colors (e.g., --background, --foreground, --primary, --card), spacing, borders, and radius (--radius, --radius-card).

Data Source:

• Fetch the list of illustrations from bunny.net using the available environment secrets: BUNNY_STORAGE_ZONE, BUNNY_ACCESS_KEY, and BUNNY_CDN_URL.

(💡 this is why you need Supabase)

Core Features:

1. Dynamic Categorization:

   • Parse the filenames of the fetched images.

   • Extract the first word of the filename to serve as the “Category” (e.g., “Billing-icon.png” → “Billing”).

   • This logic should drive both the display tags and the filter options.

2. Search & Filter Interface:

   • Search: A text input to filter images by filename.

   • Filter Dropdown: A Select menu positioned immediately next to the search bar.

   • Dynamic Options: The dropdown options must be automatically generated from the unique categories found in the file list.

3. Gallery Grid:

   • Render a responsive grid of IllustrationCard components.

   • IllustrationCard: Must display the image thumbnail, the filename, and the extracted category tag.

4. Interactions:

   • Lightbox: Clicking a card should open a modal/lightbox for a full-size preview.

   • Download: Include a button to download the original file directly.

Implementation:

• Use React and Tailwind CSS.

• Use lucide-react for icons.

• Ensure the layout is fully responsive for mobile and desktop.

Phase 3: Iteration (the loop that saves you time)

Don’t expect “pixel-perfect” prototypes from the first prompt. You will need to iterate a bit to get it how you want it to look.

Iteration loop

1. Generate the screen.

2. Fix the layout and hierarchy in Figma (auto layout, spacing, alignment).

3. Swap variants (Primary to Secondary, compact to regular).

4. Prompt for one change at a time (do not stack requests).

Rule: if the output drifts from your system, stop prompting and fix the system reference in the next prompt.

Phase 4: Connecting external tools (Connectors)

Figma Make can connect to external tools via MCP so you can pull specs in as context instead of copy-pasting.

Common connectors:

• Supabase

• Notion

• GitHub

• Linear

• Asana

• Atlassian (Confluence, Jira, Compass)

• monday.com

• API

Example: Build from a Notion PRD

Setup

1. Click Add context in the chat box.

2. Select Add connector and choose Notion.

3. Authenticate.

4. Enable read tools.

Prompt

“Use the specs in [Notion page link] to create a first-draft prototype. Follow the user flow described in the PRD and use my Button and Input components. Include the error states listed in the acceptance criteria.”

Example: Mobile learning flashcard app (simple)

This is a great “start here” project. It is mostly UI and local state, which means you can validate the flow quickly.

Example prototype: 🔗 Mobile Learning Flashcard App (Figma Make)

What this is great for:

• Validating the core flow (browse decks, study, progress).

• Iterating on hierarchy, copy, and interaction.

• Stress-test empty, completed, and error states before wiring real data.

How to move faster with Notion :

• Put your decks and cards in Notion, then connect Notion in Figma Make and pull the content in as context.

• This lets you prototype with real copy and structure while editors keep the source of truth in Notion up to date.

Example: Create or update a prototype from a GitHub issue

Prompt

“Fetch the requirements from [GitHub issue link]. Build a prototype that satisfies the user story. Include the edge cases and error states mentioned in the acceptance criteria.”

Connector permissions (what I recommend)

Figma disables write tools by default for good reason.

• Keep write tools on Ask to run until you trust the workflow.

• Enable only the connectors relevant to the current project.

Using API integrations

Live data prototypes expose content length, edge cases, and failure states.

Use live data when you need to validate:

• Real content density and truncation.

• Empty and loading states.

• Error handling.

• How your UI behaves with real user data.

Example: Illustration gallery (Supabase + external API)

This is the “real app” pattern: you store metadata in a database and serve images from a CDN. And wohoo, it works in Figma, too. ✨

Example prototype

Architecture:

• bunny.net hosts the image files (CDN delivery) → Imagine it like a “Dropbox folder”. You can use any other CDN provider as well.

• Supabase stores the metadata (title, tags, dimensions, URLs, created_at).

• The prototype fetches records from Supabase and renders thumbnails from Bunny URLs.

Other possible examples for using the API

Theme previewer: fetch brand themes (colors, typography scales) from an internal theming API and preview the same screen across themes.

Support ticket patterns: pull top support topics from Zendesk and map them to components (“most complaints mention DatePicker”) to guide fixes.

How to set up API integrations (a checklist)

1. Start with public endpoints or a simple API key.

2. Define the data shape you expect (fields and types).

3. Ask for loading, empty, and error states.

4. Iterate and add more prompts

Phase 5: Output options

Option 1: Stay in Figma

Use this when you:

• Need stakeholder buy-in.

• Need to test flows.

• Still expect the design to change.

Option 2: Export code as a reference

Use this when you:

• Want devs to understand the interaction and structure.

• Want a concrete artifact for implementation discussions.

Treat the export as a reference, not production code.

Option 3: Publish as a standalone demo

Use this when you:

• Need a link for remote stakeholders.

• Want a demo that behaves like a real app.

• Want to share it under your own domain.

My tips for Figma Make

Create reusable templates you can copy and paste. Save context blocks, data shapes, and state requirements, so you stop rewriting the same instructions.

Establish foundational rules and save them as markdown. Reuse the same constraints at the start of every new Make session.

Define structure, not just tasks. Tell the tool what the app is made of (screens, states, data model), not just what it should do.

Refine the design before you prompt. Start with a decent layout and reusable components. The more solid your structure is, the less you fight the AI.

Reference your exact component names. Use the names exactly as they appear in Assets so Figma Make uses the right building blocks instead of inventing new UI.

Connect your team library first. Do this before you prompt; otherwise, you will spend the session undoing generic components.

Set up connectors before prompting. Get access set up first so context is ready, then focus prompts on screens and states instead of setup.

Create a global CSS file you can reuse. Use it for published demos so typography, spacing, and layout defaults stay consistent across screens.

Start with short prompts, then iterate. Change one thing at a time so you can see what caused the shift.

Use revert as a workflow tool. Try an idea. If it drifts, revert. Prompt again with tighter constraints.

So, when to use Figma Make?

Figma Make fills a gap most teams feel: fast prototyping that stays consistent with your design system.

Use Figma Make when:

• You already have a component library and variables in Figma, and you want the prototype to reuse them.

• You need to validate a flow with realistic states (loading, empty, error, success), not just a static mock.

• Your content or requirements live in tools like Notion or GitHub, and you want to pull them in rather than copy-paste.

• You want to iterate directly in Figma (auto layout, variants, copy edits) after the first draft.

• You want a shareable demo link for stakeholders, including on your own domain.

If you want to try it today, do this:

1. Create an account (if you are late to the party 🙃)

2. Open a file connected to your team library.

3. Prompt using your real component names.

4. Demand loading, empty, and error states.

5. Iterate in small steps until the prototype looks and behaves like your product.

More Figma links to explore

🔗 Connect external tools using Figma Make connectors
Official documentation on MCP connectors

🔗 6 Winning Figma Makes and what you can learn from them

🔗 What’s new from Config 2025
Official Figma announcement covering Make features

🔗 Figma AI agent workflow builder
Figma’s documentation on AI workflows

🔗 Empowering designers: AI, design systems, and quality
Schema by Figma 2025

Enjoy exploring and let me know how it goes. 🙌
Romina

— If you enjoyed this post, please tap the Like button below 💛 This helps me see what you want to read. Thank you.

💎 Community Gems

Conference 2026 / AI + Design Systems

2026 will be a turning point for our field! If you want to understand how top teams build worldwide AI-ready Design Systems, this conference is the place to learn.
I will also talk there. 🙃

🔗 Link

Intercom’s 3-point framework for AI-driven design

Shipping code, vibe coding the roadmap, and owning the entire frontend

🔗 Link

Designing AI for Collaboration: The Future of Work is Multiplayer

from Salesforce

🔗 Link

Most design system teams are drowning in manual work. Syncing tokens between Figma and code takes hours. Documentation is outdated. Tracking component adoption means digging through multiple dashboards. And every time someone asks, “What did we decide about X?” you’re scrolling through months of Slack messages.

I’ve tested maaaany of the AI tools this year. Most sit unused after the initial hype. But a handful have cut my repetitive work by 50-60% and become part of my daily workflow.

Here’s what I use every day, and it actually works.👇

For coding and automation

Claude Code

Anthropic’s command-line AI assistant that works directly in your terminal and codebase. It reads your files, runs scripts, and executes multi-step workflows autonomously.

🔗 Claude Code

Why it’s useful:

• Understands your entire codebase context, not just single files

• Runs Python/JavaScript scripts for accurate calculations (no LLM guessing)

• Claude Skills let you define patterns once and reuse them automatically

• Handles multi-file changes like updating all components when tokens change

• Works with MCP servers to connect Figma, GitHub, and other tools

Example: “Sync our design tokens from Figma variables to our JSON files and check for any mismatches.” Claude Code reads your token files, compares them against Figma (via MCP), and reports discrepancies. What used to take 30 minutes of manual spreadsheet comparison now happens in under 60 seconds.

Time saved: 2-3 hours per week on token management alone.

Cursor

AI-powered code editor built on VS Code. It sees your entire codebase and suggests completions based on your existing patterns.

🔗 Cursor

Why it’s useful:

• Autocomplete learns your component patterns and suggests matching code

• Composer mode shows every file affected by a change before you make it

• Supports multiple AI models (you can also connect your own)

• MCP integrations connect directly to Figma, GitHub, and docs

• Familiar VS Code interface means no learning curve

Example: When updating a component’s API, Cursor’s Composer mode shows every file that imports that component. You see the full impact of your change before you make it.

For voice and writing

Whispr Flow

Voice-to-text that works anywhere on your Mac. Press a hotkey, speak, and text appears wherever your cursor is.

🔗 Whisprflow

Why it’s useful:

• Works in any app (Slack, Figma, VS Code, browser)

• Fast transcription with high accuracy

• No need to switch windows or break your flow

• Great for first drafts when you think faster than you type

• Useful during design reviews when your hands are busy

Example: Use it in any tools (just use the shortcut) and start speaking.

Time saved: Surprisingly A LOT. 😅

For connecting tools

Figma MCP Server

Official Figma integration that connects your designs to Claude and Cursor via Model Context Protocol. Your AI tools can read components, tokens, and specs directly from Figma.

🔗 Figma MCP

Why it’s useful:

• AI reads actual component specs, not your descriptions of them

• Compares Figma variables with code tokens automatically

• Generates specs without manual copy-paste

• Works with both Claude Code and Cursor (and other AI tools)

• Understands variants, spacing, and token references

Example: “Generate specs for the modal component in our Figma library.” The AI reads the actual component directly from Figma: variants, spacing values, token references, everything. OR you copy link to your design and instruct Cursor to build your components or screens.

Time saved: Spec documentation that used to take 20-30 minutes now takes 2 minutes.

GitHub MCP Server

GitHub integration for AI tools via Model Context Protocol. Search code, analyze PRs, and track adoption across repositories.

🔗 GitHub MCP

Why it’s useful:

• Search across all repositories in seconds

• Analyze imports to track component adoption

• Review PRs and check for token usage

• Generate changelogs from commit history

• Find which teams haven’t updated to the latest versions

Example: “Which teams are still using our deprecated v1 button component?” Claude searches across all repositories, analyzes imports, and returns a list of file paths.

PostHog MCP

Analytics integration that brings usage data into your AI workflow. Query component metrics without digging through dashboards.

🔗 Posthog

Why it’s useful:

• Get component adoption data through natural language queries

• Compare usage between component versions

• Identify which components need better documentation

• Track design system health metrics over time

• Make data-driven decisions about what to build next

Example: “Show me which components have the lowest adoption rates this quarter.” Instead of clicking through dashboards and building custom queries, you get a direct answer with the data. This changed how I prioritize roadmap decisions. Low adoption often means the component needs better docs or has usability issues.

Time saved: Analytics deep-dives that took an hour now take 5 minutes.

For research and processing

NotebookLM

Google’s AI research assistant that turns your documents into interactive conversations and even generates podcast-style audio discussions.

🔗 NotebookLM

Why it’s useful:

• Upload multiple documents and ask questions across all of them

• Generates podcast-style conversations about your content

• Great for processing large documents passively (listen while commuting)

• Finds connections between different documents

• Free to use

Example: Add any video, get a transcription, and ask any question about the content. You can also create quizzes, mind maps, and audio summaries.

For prototyping and deployment

Replit

AI-powered development environment where you can build, iterate, and deploy apps publicly - all in your browser.

🔗 Replit

My “guilty pleasure” is iterating on my ideas on the go via Replit’s mobile app (way better than scrolling on social networks). 😅

Why it’s useful:

• Replit’s Design Mode (it is fast)

• Build and deploy in the same environment

• Share live URLs instantly

• AI assistant helps you code and debug

• Great for quick tools and prototypes that need to be public

• Others can fork and remix your work (public projects)

• Mobile app where you can code on the go :)

Example: Build any tool you want. My design tokens name generator was built with Replit. Plus, I just published Token Health Checker.

For design exploration

Figma Make

Figma’s built-in AI for generating designs from text prompts. Creates layouts, components, and variations directly in your Figma file.

🔗 Figma Make

Why it’s useful:

• Generates multiple layout variations quickly

• Good for early exploration before committing to a pattern

• Works directly in Figma (no export/import)

• Helpful for prototyping new component ideas

• Saves time on initial layout work

Example: “Create 3 variations of a pricing card layout.” I use this for rapid exploration when starting a new pattern. Generate 5 variations in 2 minutes, pick the best direction, then build properly with your tokens.

Midjourney

AI image generation known for high-quality, artistic outputs. Best for conceptual and brand-level visuals.

🔗 Midjourney

Why it’s useful:

• Exceptional quality for mood boards and brand exploration

• Great for marketing and promotional visuals

• Helps explore visual directions before committing

• Generates consistent styles with style references

• Strong community with shared prompts and techniques

Example: Creating mood boards for new brand directions or marketing visuals. When you need to show stakeholders “this is the feeling we’re going for” before diving into component work. I use it at the start of major rebrand projects to align on visual direction. Generating 20 mood board images takes 10 minutes instead of hours searching stock sites.

Gemini (Nano Banana Pro)

Google’s multimodal AI with powerful image generation and editing. The Nano Banana Pro model (built on Gemini 3 Pro) is particularly strong at understanding context and making precise edits to existing images.

🔗 Gemini

Why it’s useful:

• Generate and edit images in the same interface

• Edit specific parts of images with natural language (”change the button color to blue”)

• Up to 2K resolution output

• Strong at infographics, diagrams, and data visualization

• Consistent character appearance across multiple images

• Free tier available, Pro for advanced controls

Example: Quick image edits without opening Photoshop. “Remove the background from this icon” or “Update the screenshot to show the new header.” Or merging two photos.

For audio and video

ElevenLabs

AI voice generation that creates natural-sounding voiceovers from text. Useful for video documentation and onboarding content.

🔗 ElevenLabs

Why it’s useful:

• Natural-sounding voices in multiple languages

• Fast turnaround for voiceover content

• Consistent voice across all your documentation videos

• No need to schedule recording sessions

• Good enough quality for internal documentation

Example: Creating voiceovers for component demo videos or onboarding content. Record a script, generate the voiceover, and add it to your screen recording. What used to require scheduling time with a narrator now happens in 10 minutes.

For communication

Slack MCP

Connects Slack history to your AI tools. Search conversations, find decisions, and track discussions without scrolling through months of messages.

🔗 Slack MCP Official

🔗 Slack MCP Unofficial

Why it’s useful:

• Search design decisions from past conversations

• Find who approved what and when

• Track component feedback across channels

• No more “what did we decide about X?” confusion

• Valuable for teams where decisions happen in Slack

Example: “What did we decide about the modal animation timing in last month’s design review?” Instead of scrolling through months of messages, you get the answer with context and links to the original conversation.

For documentation

Mintlify

Documentation platform with built-in AI features. Write in markdown, deploy instantly, and get AI-powered search and suggestions out of the box.

mintlify.com

Why it’s useful:

• Deploy docs from markdown with zero config

• AI-powered search understands natural language questions

• Auto-generates API documentation from OpenAPI specs

• Built-in analytics show which docs people actually read

• Integrates with GitHub for automatic deployments on merge

Example: I use Mintlify for our design system documentation site. Claude Code generates the markdown, I push to GitHub, and the docs deploy automatically.

Time saved: Documentation that used to take a full day to publish now deploys in minutes. AI search reduced support questions by roughly 40%.

For model access

OpenRouter

A unified API that gives you access to dozens of AI models through one interface.

🔗 openrouter.ai

Why it’s useful:

• One API key 100+ other models

• Compare outputs from different models on the same prompt

• Fall back to alternative models when one is down or rate-limited

• Often cheaper than going direct to each provider

• Pay only for what you use, no monthly commitments per provider

Example: When building internal AI tools for your design system, OpenRouter lets you experiment with different models without having to rewrite integrations.

For general AI assistance

ChatGPT

OpenAI’s conversational AI with web browsing, image generation (DALL-E), and Canvas for collaborative editing. The most versatile general-purpose AI assistant.

🔗 ChatGPT

Why it’s useful:

• Web browsing for real-time research and fact-checking

• Canvas mode for collaborative document and code editing

• DALL-E integration for quick image generation

• Voice mode for hands-free conversations

• Memory feature remembers context across sessions

• Strong at explaining complex concepts in simple terms

Example: Quick research, transforming file formats, explanations, practical “every-day” questions, training suggestions. So many examples 🙃

Where to start

If you’re new to AI tools for design work:

1. Start with Cursor - It’s familiar (VS Code), and the autocomplete is immediately useful

2. Add Figma MCP when you’re comfortable

3. Try Claude Code for repetitive workflows

4. Add more MCPs

The landscape changes fast. What matters is finding tools that save more time than they cost to learn. Skip the hype tools until they prove themselves. Most AI plugins are still thin wrappers that don’t understand your context.

Enjoy exploring 🙌
Romina

— If you enjoyed this post, please tap the Like button below 💛 This helps me see what you want to read. Thank you.

💎 Community Gems

Watch the Converge conference videos

The talks from Converge 2025 are now available to watch.

🔗 Link

Most design tokens are structured for humans using Figma or JSON files. When you connect them to Claude via MCP (Model Context Protocol), the AI sees a wall of nested objects with no context about why these values exist or when to use them.

The result: AI generates code with blue-5 when it should use color-feedback-error. It picks space-3 for the button padding when your system specifies button-padding. You spend more time typing prompts to fix and explain than you do actually saving with AI.

Here’s how to restructure your tokens so AI actually understands your design system.

What you’ll learn

• Why tokens fail AI

• The three elements of AI-readable tokens

• Add descriptions to your top 10 tokens in 15 minutes

• How to add context without restructuring legacy tokens

• Catch token misuse in Figma

• How AI-readable tokens enable context-aware design systems

The problem: tokens that lie

👋 Just a quick note → I’m mostly using Claude Code or Cursor, so I will write about this tool, but you can use other tools as well. However, keep in mind that the model you pick also affects what you get in the end.

I connected my design tokens to Claude via Figma MCP. First test: “Build me a button component using my design system.”

Claude’s output used:

• red.6 for the error state (should be color-feedback-error)

• space-2 for padding (should be space-4)

• neutral-7 for text (should be a semantic token)

The tokens were technically correct. They existed in my system. But Claude had no way to know that red-6 is a primitive meant for building semantic tokens, not for direct use in components.

Here’s what Claude saw:

{
  “red”: {
    “6”: {
      “value”: “#DE3E25”,
      “type”: “color”
    }
  }
}

What was missing: the semantic layer.

If you use Tokens Studio or Figma Variables, you already create primitive tokens like red-6 and then connect them to semantic tokens like color-feedback-error. But many teams either skip the semantic layer entirely or don’t expose it to AI tools.

Here’s what Claude needs to see:

Same underlying hex value. But now AI tool sees the primitive, the semantic token that references it, and the description that explains intent.

Why are tokens the foundation

Design tokens sit at the bottom of the stack. Every component, pattern, and product page ultimately resolves to tokens. This makes them both the smallest unit of your design system and the highest-leverage place to add AI readability.

If tokens lack intent, everything above them inherits that blindness.

When Claude generates a Button component, it needs to pick colors, spacing, and typography. If your tokens are just primitives (red-6, space-4), Claude makes arbitrary choices. Those choices cascade upward—into patterns, into pages, into your product.

But if your tokens carry intent (color-feedback-error, spacing-component-button-padding), Claude’s choices are informed at every layer. The Button uses the right error color. The Form pattern that contains the Button inherits that correctness. The Settings page that contains the Form stays consistent.

Tokens are the API contract between design and code.

Think of tokens as the interface definition for your visual language. Just like a well-documented API tells developers what each endpoint does and when to use it, well-documented tokens tell AI what each value means and where it belongs.

// A bad API
GET /data/123  → What is this? When do I call it?

// A good API  
GET /users/{id}/profile  → Clear intent, obvious usage

The parallel is exact. Tokens without intent are like undocumented endpoints: technically functional but impossible to use correctly without tribal knowledge.

🚨 Tokens are the only layer AI always touches

When Claude generates code, it might skip your component library entirely and build from scratch. It might ignore your patterns. But it cannot skip tokens (every visual property resolves to a value).

This makes tokens your guaranteed point of influence. Even if Claude improvises everything else, AI-readable tokens ensure the fundamentals are correct: the right colors for the right states, the right spacing for the right contexts, the right typography for the right hierarchy.

Start with tokens because they’re the smallest, fastest fix with the largest impact.

You can’t restructure your entire component library overnight. You can’t document every pattern in a week. But you can add descriptions to your top 20 tokens in an hour.

That hour of work propagates upward through every component and pattern that uses those tokens. It’s the highest-leverage investment you can make in AI readability.

What makes tokens AI-readable

AI tools process your tokens differently than humans do. A designer browsing your token file understands context from experience. They know red means danger. They know primitives are building blocks, not final values.

AI has none of that context. It sees names and values. That’s it.

When you expose tokens via MCP, Claude accesses them through tool calls. It retrieves your token file and parses the JSON. The structure and descriptions you add are exactly what Claude reads—nothing more, nothing less.

Three things make tokens AI-readable:

1. Semantic naming (intent, not appearance)

blue.5 = color.interactive.primary

space-4 = spacing.component.button.padding

The AI-readable version tells Claude what the token is for, not just what it looks like.

2. Descriptions (when to use this token)

{
  “color-feedback-error”: {
    “value”: “#DE3E25”,
    “type”: “color”,
    “description”: “Use for error messages, destructive button backgrounds, invalid input borders”
  }
}

That single description field transforms a color value into actionable guidance. Claude now knows this token belongs on error states, not primary buttons.

3. Relationships (which tokens are connected)

{
  “color-feedback-error”: {
    “value”: “#DE3E25”,
    “type”: “color”,
    “description”: “Error state background”,
    “usage”: [”Alert.error”, “Button.destructive”, “Input.invalidBorder”],
    “pairedWith”: [”color-feedback-errorText”, “color-feedback-errorIcon”]
  }
}

Now Claude knows that when it uses this error background, it should also look for color.feedback.errorText for the text color.

The before and after

Let me show you what this looks like with real tokens.

Before: primitive-based structure

This is a typical Tokens Studio export:

{
  “red-1”: { “value”: “#FAEFEC”, “type”: “color” },
  “red-2”: { “value”: “#F9E6E2”, “type”: “color” },
  “red-3”: { “value”: “#F7D5CD”, “type”: “color” },
  “red-4”: { “value”: “#F6BFB1”, “type”: “color” },
  “red-5”: { “value”: “#F6A791”, “type”: “color” },
  “red-6”: { “value”: “#DE3E25”, “type”: “color” },
  “red-7”: { “value”: “#C42924”, “type”: “color” },
  “red-8”: { “value”: “#841815”, “type”: “color” },
  “space-4”: {
    “value”: “{space-1} * 4”,
    “type”: “spacing”,
    “description”: “20px”
  }
} 

Hard to know which token to use for error states, right?

{
  “color-feedback-error”: {
    “value”: “#DE3E25”,
    “type”: “color”,
    “description”: “Error states: alerts, destructive buttons, invalid inputs”,
    “a11y”: “Meets WCAG AA contrast on white (4.5:1)”
  },
  “color-feedback-error”: {
    “value”: “#FAEFEC”,
    “type”: “color”,
    “description”: “Light error backgrounds for inline validation”
  },
  “color-feedback-success”: {
    “value”: “#198053”,
    “type”: “color”,
    “description”: “Success states: confirmations, completed actions”
  },
.... 

and so on ... 

What Claude now understands:

• color-feedback-error is for error states

• It meets accessibility requirements

• color-feedback-error exists for lighter backgrounds

• spacing-component-button-padding is specifically for buttons

• spacing-component-input-padding is for inputs (different value)

Want to know if your tokens are AI-readable? Run this test

Prompt Claude/Cursor (make sure you connect Figma MCP first):

“Build a form with email validation that shows an error state when the email is invalid. Use my design system tokens.”

If your tokens are NOT AI-readable, Claude will:

• Use primitive colors like red-6 or #DE3E25 directly

• Pick arbitrary spacing values

• Ignore accessibility considerations

If your tokens ARE AI-readable, Claude will:

• Use color-feedback-error for the error border

• Use color-feedback-error for the background

• Use color-text-error for the message text

• Apply spacing-component-input-padding correctly

The difference is obvious. And it saves you from playing token police on every AI-generated component.

Quick exercise: add descriptions in 15 minutes

You don’t need to restructure your entire token system today. Start with descriptions.

Step 1: identify your top 10 tokens

Which tokens appear in the most components? Probably:

1. Primary button color

2. Error color

3. Text primary color

4. Background color

5. Border color

6. Button padding

7. Input padding

8. Border radius

9. Focus ring color

10. Disabled state color

Step 2: add descriptions

Open your token file. Find each token. Add a description field:

{
  “blue-5”: {
    “value”: “#1870C6”,
    “type”: “color”,
    “description”: “Primary interactive color. Use for main CTAs, links, and focus states. Meets WCAG AA on white.”
  }
}

Step 3: test with Claude or Cursor

Ask your AI tool to build something using your tokens. See if it picks the right ones.

Wohoo, I hope it works.

The companion file strategy

If you can’t change your token structure, companion files are your best option. They add the context AI needs without touching your existing tokens.

Create context files that MCP loads alongside your token data.

Examples:

token-usage-guide.md

# Token usage guide

## Color hierarchy

### When to use feedback colors
- `color-feedback-error`: Form validation failures, destructive actions, system errors
- `color-feedback-success`: Completed actions, positive confirmations
- `color-feedback-warning`: Cautions, pending states, non-critical alerts

### When to use interactive colors
- `color-interactive-primary`: Main CTAs, links, focused elements
- `color-interactive-secondary`: Secondary actions, less prominent buttons

## Spacing rules

### Component padding
- Buttons: Always use `spacing-component-button-padding` (20px)
- Inputs: Always use `spacing-component-input-padding` (15px)
- Cards: Always use `spacing-component-card-padding` (24px)

### Never do this
- Don’t use primitive spacing values directly in components
- Don’t mix spacing scales (e.g., 8px grid with 5px values)

component-token-map.md

# Component token mapping

## Button
- Background: `color-interactive-primary`
- Background hover: `color-interactive-primary-hover`
- Text: `color-text-on-primary`
- Padding: `spacing-component-button-padding`
- Border radius: `border-radius-md`

## Button (destructive variant)
- Background: `color-feedback-errorDefault`
- Background hover: `color-feedback-error-hover`
- Text: `color-text-on-error`

and so on ... 

When you add these files to your MCP server, Claude reads them alongside your tokens. It has the rules, not just the values.

This approach works even if your tokens are primitive-only. The companion files provide the semantic layer externally.

Advanced: the token metadata layer

For teams ready to go deeper, add a metadata layer that explicitly tells AI how to use your tokens.

{
  “color-feedback-errorDefault”: {
    “value”: “#DE3E25”,
    “type”: “color”,
    “meta”: {
      “description”: “Primary error state color”,
      “usage”: [
        “destructive button backgrounds”,
        “error alert borders”,
        “invalid input borders”,
        “error icon fills”
      ],
      “doNot”: [
        “use for warnings (use color-feedback-warning)”,
        “use on dark backgrounds without checking contrast”,
        “use as text color (use color-text-error instead)”
      ],
      “pairedTokens”: [
        “color-feedback-errorSubtle (for backgrounds)”,
        “color-text-error (for text)”,
        “color-feedback-errorHover (for interactive states)”
      ],
      “a11y”: {
        “contrastOnWhite”: “4.52:1”,
        “wcagLevel”: “AA”,
        “notes”: “Do not use as text on dark backgrounds”
      },
      “components”: [”Button”, “Alert”, “Input”, “Toast”]
    }
  }
}

Yesss, I know that this is more work upfront. But Claude now has everything it needs:

• What this token is for

• Where to use it

• Where NOT to use it

• What other tokens it can combine with

• Accessibility requirements

• Which components use it

Why this matters beyond AI

Making your tokens AI-readable also makes them human-readable. The documentation you add for Claude helps:

• New team members understand your system faster

• Designers make consistent choices without asking

• Developers pick the right tokens without guessing

• Audits catch incorrect token usage automatically

The work you do for AI benefits everyone.

Validating intent at the source

The same problem exists upstream. Before tokens reach AI, designers misuse them in Figma. They apply blue.500 directly to a button instead of color.interactive.primary. They use error colors on non-error components.

I was experimenting with different ways to educate teams about design tokens, and I built a Figma plugin called Token Intent Validator that catches these issues at the source.

What it catches:

* Recommends appropriate semantic tokens based on the layer’s context
* Detects when you use raw hex color -> One click “Apply” button for the suggested design token
* Flags primitive tokens
* Identifies intent-property mismatches
* Suggests text style tokens
* Show confidence level for each suggestion
* Connects with AI and gives a chat interface (you can connect any model)
* It’s context-aware
* Recommends tokens based on your codebase/Figma library
* Analyzes the document’s structure
* You can validate the selection or the whole page

I still have to improve some parts, but it is already valuable.

Your path to context-aware design systems

AI-readable tokens are the foundation of something bigger: the context-aware design system. 😊

When your tokens include intent, not just values, you unlock:

• Intelligent suggestions

• Automatic consistency

• Usage analytics

• Cross-tool validation

Okay, so your first goal is simple → start with descriptions. → test with Claude → iterate based on what the AI gets wrong.

Let me know how it goes. 🙃

Have a great weekend,
Romina

— If you enjoyed this post, please tap the Like button below 💛 This helps me see what you want to read. Thank you.

BMW Group invited me for an exclusive iX3 driving experience a few weeks ago. I expected a car launch. I got a masterclass in design. 😍 After two days with the engineers, designers, and leaders of Neue Klasse, I see why legacy brands still succeed.

↪️ The iX3 is the first with the new design language
You feel the shift immediately.
* Large monolithic surfaces
* Clean geometry
* No unnecessary noise

The philosophy is simple: reduce complexity so character can shine through.

↪️ A shift from static assets to dynamic elements.
Instead of metal accents, BMW is using digital light signatures to define identity.
The kidney grille. The four-eyed face. The depth effect.

↪️ The interior feels like a living room
* Panoramic iDrive stretching across the full width
* Wrap-around effect that feels calm, not cluttered
* Textile on the dashboard with a light effect

✨ From a systems perspective, the iX3 is a leap
* Personalized dashboards
* Haptic buttons
* Integrated AI
* Panoramic iDrive with AR clarity
* Driver Assistance
* Superbrain Computing: 20x more power for smarter decisions
* Modular OS: scalable, secure, future-proof

👆 Me trying to be faaaast on the Ascari motor racing circuit

↪️ Going backstage
BMW team is curious and deeply committed. They listened, cared, and shared everything openly.

As someone who works in design every day, that mindset hits home. You can feel it in the product.

I told my family that life would never be the same. Now, I will always compare everything to this car.

Design is not a department. Design is a mindset.
BMW proves my belief: the best products aren’t just designed to look good. They feel designed in every aspect.

I left inspired. Not just by the new BMW iX3.
But by the people building it. 💙

PS. You can see the video on my LinkedIn post →

💎 Community Gems

✨ Documenting Design Systems - Architecture Decisions Record with Claude Desktop from

Gamma AI

AI tool for making presentations.

🔗 Link

1. Gamma for presentations

Raise your hand if you love doing presentations? Haha, I thought so. I always think each presentation takes up half my year. Gamma app flipped this completely.