73 posts tagged with “design systems”

When does a repeated element deserve its own component? Anton Sten is using an AI agent to build his design system. He measures its value by the decisions it saves people. Here’s his filter for what belongs:

Lately I’ve been using a simple filter before adding anything to a system. Does it show up often enough to deserve a shared solution? Does it have behavior or states that need to stay consistent? Is there an actual rule here that we want to encode rather than leave to individual judgment? And, just as importantly, is this something someone is willing to own over time?

The third question is the one I keep coming back to. Repetition alone isn’t enough. Something becomes valuable as part of a system when it captures a decision we don’t want humans or agents to keep making independently.

I’d treat the owner question as part of that decision, too. Someone has to remain responsible for the rule as the product changes. Otherwise, the team has standardized something without deciding who can resolve the next exception.

Once a rule is shared, people and agents still need to recognize when it applies. Sten uses token names to show how:

Take naming. green-600 tells you what something looks like. text/success tells you what it’s for. A designer with years of context may know which green is appropriate, and an engineer may remember which one the team normally uses, but an agent only has the system in front of it.

The more intent the system contains, the less any of its users have to infer. Semantic naming is not just a preference in that context; it carries the decision across design, code and the agents working between them. That clarity helps people too, but agents expose just how much ambiguity we’ve historically allowed humans to compensate for.

It took Marek Minor about a year to redraw Cursor’s icon system: more than 600 icons in two sizes and two styles, with every exploration and final variant drawn by hand.

The scale only hints at the effort. Minor tested differences as small as 0.25 pixels, made 156 explorations of the hamburger icon, and tracked more than 155 recurring elements and visual properties. He also built the Figma files, migration dashboard, companion site, and release pipeline needed to migrate an old font with 645 codepoints without breaking references. Writing on his blog, he explains the construction method that holds the set together:

The icons in this set are closer to technical drawings than to organic shapes – diagrams with a friendly finish. The construction method is consistent across the set: start with lines that run horizontally, vertically, or at 45°, allow other angles where the concept demands them, then round the corners until the shape follows the idea. A cloud, for example, isn’t built from circles. It starts as straight segments that get rounded joins. A fire icon is built the same way, from angled segments with rounded corners. Freeform curves, or curves taken from circles, are extremely rare in the set.

This construction logic is what makes 600+ icons feel like the work of one hand. It also suits a coding tool: precise and engineered, with the rounded corners and round stroke caps keeping it from turning cold.

Patrick Morgan, writing in his newsletter Unknown Arts, starts with the boundary his system is designed around:

The problem is that prototype code and production code serve fundamentally different purposes. Production code needs to optimize for shipping and maintaining a performant product at scale while prototype code needs to optimize for speed, flexibility, and divergence. I wrote more about this distinction in my article Prototype Code Is Not Production Code (And That’s Okay).

You need both sides of that spectrum to design and ship a good product. A prototype should be able to change direction quickly, without worrying about scale or production constraints, while still benefiting from shared foundations, reusable primitives, and a connection to the product it may influence. So I started looking for an environment with the freedom of a prototype, but enough shared structure for the work to compound over time.

Morgan argues for giving exploratory code enough shared structure that designers can move quickly without severing each experiment from what the team already knows.

As more people used the environment, I started curating more of the context around the work directly into it, including our design principles, personas, and project briefs. As I wrote in AI Needs a Plan, the best agent work usually starts with a written brief, not a one-shot prompt.

By then, the environment had grown from a place to make prototypes into a shared foundation of tools and context that helps people and agents understand how our team designs.

In Morgan’s account, the prototype is not the only thing that compounds. The team’s principles, personas, briefs, foundations, and prior decisions do too, because people and agents can reach them from the same working environment. That shared home is the Design OS: a codebase separate from production where people and agents can reuse the team’s context instead of starting each prototype from scratch.

A codebase gives the Design OS somewhere to live. It lets design intent be shared, connected to other assets, and put into practice.

That has always been possible in theory, but until recently code wasn’t very accessible to designers. Agents change that dynamic by acting as translators into and out of code. They can turn a designer’s plain-English intent into working software, then translate that software back into something the designer can use and evaluate.

This builds on the argument I made in AI Runs on Text. So Should You.: when your thinking lives in plain text, it becomes an asset that both you and AI can read, reuse, and extend. Code just happens to be a more structured form of plain text, which makes it easier for agents to interpret and act on reliably.

The goal here is not to make designers write code. It’s to make design intent executable. When a codebase holds the team’s foundations, conventions, and decisions, an agent can translate a designer’s instructions into working artifacts and carry that context forward. Each new piece of work can then build on what came before it.

Yep! Type Foundry has a useful two-part check for choosing a UI typeface. It gets past whether the typeface looks like a clean sans-serif and tests whether labels will sit properly inside controls:

TL;DR, two things make a UI font easy to work with:

1. Cap-centered vertical metrics—the space above the cap height equals the space below the baseline. Result: labels center optically on buttons and align with icons, and you can use a single padding token instead of hand-tuned CSS.
2. Tall x-height—lowercase letters reach 70–75% of cap height. Result: the word nearly fills its box, so it looks evenly centered.

Jem Gold’s encounter-language—describing how a design should feel rather than what it is made of—puts the intended experience into words. Design systems leader Yesenia Perez-Cruz, who led Shopify’s Polaris system, takes the next step: giving a team enough shared structure to express product meaning coherently, screen after screen.

Many design languages are really style guides. They define typography, color, spacing, shadows, illustrations, and icons, but say little about how to represent the concepts at the center of the product.

If you remove the opinions from container components while the design language still teaches people to place text and controls inside boxes, you will simply end up with more text and controls inside boxes.

Composability creates room to shape. A design language teaches teams what to shape toward.

Instead of treating a design language as a collection of visual rules, we should think of it as a tool for solving communication problems.

It can help to compare it to written language.

Written language has subject matter, vocabulary, grammar, emphasis, and voice. A product design language needs the same: a model of what it must communicate, recognizable visual signs, rules for composing them, ways to direct attention, and a distinct visual character.

Perez-Cruz starts with the product model: the objects, states, actions, and relationships the interface must make understandable. From there, her language needs a vocabulary that makes those concepts recognizable wherever they appear.

A language needs recognizable signs with stable meanings.

You might think of them as:

• Nouns: visual signifiers for orders, customers, articles, or projects
• Verbs: symbols and labels for adding, removing, deleting, publishing, or fulfilling
• Attributes and states: draft, published, paid, delayed, fulfilled, or critical
• Semantic roles: informational, cautionary, destructive, selected, or inactive

At Shopify, an order was most recognizably identified by its order number. A customer could be identified through a consistent customer symbol and name. These signifiers followed the resource wherever it appeared, helping merchants recognize it across different workflows.

The vocabulary also included consistent symbols and labels for common actions, distinct treatments for static attributes and changing lifecycle states, and semantic color roles for informational, cautionary, destructive, successful, and active states.

A product’s visual vocabulary creates recognizable forms.

But vocabulary alone can’t communicate a complete thought.

In Perez-Cruz’s model, stable signs solve recognition; grammar explains how those signs relate. That dependency is what turns a collection of reusable elements into a language capable of expressing a product’s structure.

After defining the vocabulary, you need to define how to combine it into meaningful compositions.

To me, this boils down to a basic question: what do you primarily use to create structure? Shapes, lines, or space?

The combination that you use depends on what relationships and information need to be understandable at a glance.

Those might include:

• Sequential relationships: steps in a workflow, stages of delivery, or progress over time
• Linked relationships: dependencies, inputs and outputs, or causes and effects
• Nested relationships: items within orders, files within folders, or variants within products
• Comparisons: choices, performance between periods, or a value relative to a benchmark
• Movement and change: work velocity, article engagement, momentum, or growth

Grammar describes the recurring visual structures used to communicate those ideas.

Perez-Cruz’s model lets a product’s personality grow from its own logic rather than decoration laid on top.

Have you ever walked into a fast food restaurant lit with overhead fluorescent lights and knew immediately that it might be a bad idea? Or if you walk into a slightly more upscale eatery with warm, incandescent light and it immediately feels inviting?

Creative technologist Jem Gold illustrates a similar phenomenon in UI design. There are mechanical specs about pixel values and hex colors. And there are guidelines for the experiential quality of the product.

Good design absolutely talks about feeling, atmosphere, taste, mood, audience, pacing, the embodied experience of arrival. But that work gets compressed too early into machine-readable implementation language. The moment a design intent becomes a token, the temperature drops out of it.

I keep coming back to this distinction:

Object-language describes the artifact. Warm neutral palette. Elegant serif typography. Subtle texture. Soft cards. Generous spacing.

Encounter-language describes the experience of meeting the artifact. Stepping out of your car into a eucalyptus grove. The taste of the pacific air in Mendocino. Golden hour sunshine kissing your forehead. Copal smoke wafting through a mountain cabin. The page has already exhaled before you arrive. A room prepared for attention. Clarity without sterility. Intellect without deadness.

The second kind of language contains more design direction. It carries sensation, mood, pacing, social meaning, and implied structure all at once. A single sensory scene can encode color, spacing, contrast, materiality, ornament, and density without naming any of those directly.

It is precise along a different axis.

That difference becomes real once models can turn atmosphere into visual form. Encounter-language gives the model a clearer target, but you still need taste to decide whether the result feels right. Gold extends the argument from direction to judgment:

The model generates possibilities, but taste remains in the loop as judgment. Does this still feel like the intent, or did it collapse into aesthetic costume? Only after a design tastes right do you derive tokens, typography scales, spacing rules, and component behavior. If our design specs only teach the model what the interface is made of, they have already forgotten what the interface is for.

Most software companies organize product work around squads. Users don’t care. Their workflows cut across the boundaries we draw between teams, so a local decision about a table, filter, or bulk action can become a product-wide inconsistency.

In my conversation with Denis Cristea on UX Spotlight by Userlytics, I described how this happens:

We have this notion in modern software companies around squads and how a squad will own a particular surface area in a product. You’ve got your product manager, product designer, engineering lead, and then a bunch of engineers. So that’s your classic triad and team makeup. Theoretically everyone owns their roadmaps, talks to customers, and decides what to build.

Users don’t just work in one module. Users often work in multiple modules. So they’re already crossing the org chart, if you will. […] When thinking about the entire user experience, you already have to coordinate across different teams.

Meanwhile, you’ve got another module, another group, another team who wants to work on something similar, but they’re not talking to each other. When that happens, that’s when you get the inconsistent user experience. They might solve the same interaction differently.

A design system standardizes the components each squad uses. Weekly critique lets designers see the decisions being made across those squads before separate implementations harden.

I used the example of bulk actions at BuildOps:

The other thing that we’ve been doing a lot on my team at BuildOps, the design team, is the weekly design crit. That’s a way for us to keep the connective tissue together and ensure that the experience across the different modules stays as consistent as we can.

Going back to the bulk actions example, if one team needs it and a designer builds that experience, other designers will see it and say, “Okay, that will actually help my area too. After you design it and create the components, let me take that and put it in my area too, and argue with my product manager to prioritize that work.”

Critique coordinates the product while the squads remain autonomous. It gives teams a shared view of unfinished decisions and a place to resolve them before users have to deal with the seams.

Product managers can use the same ritual:

I would recommend that product managers think about implementing something that designers do, which is critiques. I don’t think product managers have this ritual of sharing what they’re working on and how they’re thinking through problems.

When you build a culture of sharing and oversharing, and also wanting to make everyone else’s work better by giving them good constructive feedback, that’s when the whole product is going to get lifted up.

Quotes lightly edited for clarity.

Ben Callahan on what a design system can and can’t guarantee:

A design system can only raise the quality floor. It sets the baseline below which nothing should ship. An accessible-by-default button, a holistic and thoughtful approach to spacing, a template that starts a consuming team ten steps ahead.

But a design system alone can’t raise the quality ceiling. That’s not something you can do by delivering assets. The worst product teams can make awful experiences with the best design systems. That’s because the quality ceiling is set by the choices product teams make with what you give them. It’s their restraint, it’s where they push, and it’s knowing when to deviate from the standard because the standard isn’t serving the end user.

Callahan’s title invokes AI, though the essay only touches it indirectly. The connection follows from his distinction: faster generation and stronger defaults can produce more acceptable work, but neither can decide when the standard is failing the user. That decision still requires careful judgment.

Callahan on the loop:

And, of course, this loop just continues to run. Over time, the quality floor and the quality ceiling are raised.

The most important step here isn’t the shipping of a new component. It’s the time in conversation that results in alignment on a definition of quality.

Your system sets the floor. The way your system is used sets the ceiling. If you’ve poured everything into the first and bowed out of the second, it’s time to step back into ring.

Patrick Neeman, writing for UX Collective, compares today’s AI interfaces to the browser wars:

[Jeffrey] Zeldman did not invent the specifications, he did something harder: He convinced an entire industry that shared conventions were worth fighting for, and he won. Zeldman changed the world with a stance, not a specification and we should thank him for it.

We are living through that moment again, this time for the interfaces we wrap around models, the skills we scaffold on top of them and representations they mean.

The browsers have new names: ChatGPT, Claude, Gemini, and Copilot each handle the same task their own way, with their own conventions for parsing content, showing reasoning, citing a source, and asking permission before they act.

The connection to design systems is structural. Browser standards gave different products a shared foundation without forcing them to look identical. Neeman doesn’t claim that the conventions for AI interfaces are settled; he proposes design systems as the way practitioners can develop and share them:

The core move was to pull structure, presentation, and behavior into distinct layers so each could change without breaking the others. That one idea outlived every specific technology it was built on.

It is why a design system works at all.

When Brad Frost introduced atomic design, he was extending the same instinct: stop shipping pages, start composing interfaces from small, shared, recombinable parts. Design systems are the standards movement’s direct descendant, and they are the closest thing we have to a working model for AI interface conventions.

That working model is already appearing in the Markdown files agents use as project-level contracts:

Agents increasingly take their instructions from plain text files that sit beside the work — AGENTS.md for how an agent should behave in a project, SKILL.md for what a capability can do, README.md for the context around both.

This is the new semantic layer. It is markup again, written in Markdown and read by a model instead of a browser.

[…]

A design.md that carries your design system’s patterns, tokens, and rules into every agent that touches the product. An accessibility.md that states the non-negotiables in language a model can follow. A content.md that fixes voice, terminology, and the content model.

Neeman also points to a broader protocol stack taking shape:

You are not waiting for this to begin. It has begun. A partial map of the standards taking shape right now:

• Model Context Protocol — a shared way for a model to reach tools, data, and context, already adopted across rival platforms and now stewarded by a neutral foundation.
• A2UI — a declarative protocol for agents to describe interfaces that render natively across web, mobile, and desktop, keeping what the interface is separate from how each client draws it.
• Agent2Agent — an open protocol for agents to discover one another and collaborate across frameworks and vendors, launched by Google and handed to the Linux Foundation.
• The W3C AI Agent Protocol Community Group — a grassroots group drafting open rules for a trustworthy web of agents.
• Agent identity work — cross-body efforts, at the W3C and beyond, to verify who an agent is and what it is allowed to do before it acts.

None of these is finished, and that is the opening. The conventions are still soft enough to shape, which is exactly where Zeldman’s coalition made its difference.

Christine Vallaure, a UI designer who teaches Figma and AI workflows, offers designers a map of the hidden infrastructure between a convincing Figma-to-code demo and a production workflow:

The demos show you one clean layer working under perfect conditions. Your actual work needs three or four layers stacked together, and nobody shows you the stack, because the stack is where it gets messy and half-solved. The confusion comes from not knowing they are separate things at different stages that need different skills.

A useful distinction is between context and connection. Figma’s Model Context Protocol (MCP) connection can expose the file, markdown can preserve working rules, and skills can make repeated tasks more consistent. None of those guarantees that a generated button is the button already maintained in the product. That takes an explicit mapping to the codebase, plus someone responsible for keeping it current.

Look at the whole stack. Each layer covers the hole under it. The pipe lets Claude see your design. The note carries your rules. The recipe keeps your repeated jobs consistent. And the mapping, the top layer, is the only one that truly welds design and code together so they never drift.

But that top layer needs a codebase, developers, and constant upkeep. Most people do not have that, and should not pretend to. So for almost everyone, the design and the code will drift the moment either side changes, and that is not a sign you set it up wrong. It is simply what these tools are without the expensive wire: they take a snapshot and build from it. When things drift, you regenerate. You do not try to hand-repair a connection that was never really there.

That makes the stack an ownership map as much as a technology map. Each added layer creates another artifact that can become stale. The right setup is the most infrastructure a team can actually maintain, rather than the most complete diagram it can assemble.

And the flip side holds: if you are not this team, do not build like this team, or you will spend your life maintaining a machine you never needed and cannot keep up with.

The easy story about AI in creative work is that it closes distance: idea, prompt, output, iteration, all compressed. It’s Nice That gets at the more designerly version of that question by putting creative technology’s appetite for “happy accidents” next to design’s need for control:

“From the technology approach, the metaphor I equate it to is the classic ‘happy accidents’ you have when you are in a design tool,” Seth says, finding expected moments of creativity. “The best happy accidents aren’t just between a person and a tool; they happen between people.” It’s perhaps in this notion that co-creation is at its most visible, not in the technology itself, but rather in the conversations and unexpected developments that occur when people with different perspectives work closely together. For Talia, however, this isn’t the case. “Nothing we do is experimental by nature,” Talia says, “everything is incredibly controlled – or, better yet, ‘designed’,” stressing the importance of the role of the designer and the meaning behind design itself. “Design is about creating solutions; there is a sense of control, there is a purpose, there is a function,” she continues, “even the beauty is controlled to a degree.” An example is the generative motion graphics system that Talia created, in collaboration with Mother, for the Crypto coin USDC.

Designer and coder Talia Cotton’s line clarifies the whole piece: “controlled – or, better yet, ‘designed’.” Cotton’s point is that the speed of generation only makes the designer’s eye more important, because someone still has to decide the boundaries before the machine starts producing variations.

Cotton’s USDC system makes that concrete:

Within the visual identity, Talia developed a custom tool that generated guilloché patterns, in reference to the historical patterns used in traditional finance. Alongside set, systematic parameters – including height, width, density, and speed – Talia had to create algorithmically constrained rules within those limitations. “As you adjusted one parameter, another parameter would automatically change its available range,” Talia says, “that ensured every possible output looked good.” As Talia suggests, especially considering the ease with which people can generate things, the “designer’s eye” is now more important than ever. “The designer’s job is to create an airtight generative system that considers every possible case and every possible output,” she says, “so that every single output always looks great, no matter how different it is.”

Sen Lin, writing in UX Collective, has a useful reference for designers who want Claude Code to fit their workflow instead of acting like a generic engineering agent:

Claude Code is an agent, and an agent is only as good as how you configure it. That’s the part worth paying attention to as a designer: Out of the box it leans engineering, but you can set it up to fit how you actually work — to understand design, respect your workflow, and carry the right capabilities — so it produces better results, faster.

A technical stack is the set of technologies you decide on before writing a line of application code. A design stack is the same idea, applied to Claude Code: the brief, the design knowledge, and the tools you hand the agent upfront.

The useful move is treating Claude Code setup as a design operation, not a prompt-writing trick. Give it a project brief, a design-system guide, and the right tools before it starts touching the work.

If CLAUDE.md is the brief, DESIGN.md is your design system translated into something an agent can read and obey. It’s a format specification that describes your visual identity to a coding agent: the exact values, and the reasoning behind them.

The file works on two layers, and both matter.

The first is machine-readable design tokens, written as YAML front matter — the exact values, so the agent never has to guess what gray-500 resolves to or which surface color a modal should use: […] The second is human-readable design rationale, written as prose — the part that explains why a value exists and how to apply it. Tokens tell the agent what primary is. The prose tells it there should never be more than one primary button per view, that a primary action is always paired with a neutral or subtle one for cancel, that button width is set by the parent and never hardcoded.

The tool/instruction split is the part worth saving:

MCP gives the agent access to tools.

Skills give it the knowledge to use those tools well.

Where MCP is access, a Skill is a markdown-based guide that teaches Claude how to perform a specific task in a specific way. It’s a set of instructions, scripts, and resources — a training manual that keeps the agent from wandering down expensive detours and burning tokens on the wrong approach.

Good checklist. The designer’s job is not just to ask Claude Code for UI. It is to onboard the agent into the product, the design system, and the working style before generation begins.

Figma’s own Config 2026 recap makes its strategy clear: it shipped code layers that bring editable, inspectable code onto the canvas; Figma Motion with timelines, keyframes, exports, Dev Mode inspection, and MCP compatibility; shader fills and effects generated by the Figma agent; generative plugins that let teams create canvas-native tools by describing them; Weave tools for reusable generative workflows; and a broader Figma agent with skills, connectors, attachments, and shared chats. The through-line is not one more AI feature. It is Figma trying to make the canvas the place where code, motion, generative media, team-specific tools, and agent context all live together.

The old design-tool space was mostly canvas versus canvas: Sketch, Figma, XD, Framer, whichever product made design teams move faster. Darren Yeo, writing in UX Collective, is looking at a different fight: Figma against the possibility that the canvas becomes optional.

Figma’s enterprise strength has always depended on breadth. Designers used it first, then product managers, engineers, marketers, writers, and executives followed. The more people needed to review, comment, inspect, or reference design work, the more seats Figma could sell. The same applies for the product bench, with the rapid expansion of Slides, Buzz, Sites, and now Motion and Weave.

AI complicates that logic. If an engineer can generate or inspect UI directly inside a coding environment, or if a product team can translate structured design intent into working software without opening a shared canvas or applications, the need for passive, underutilised seats weakens. Config 2026 actually confirms this tension by bringing code layers and agent workflows closer to the main product, Figma Design. In other words, Figma is acknowledging that an increasing number of people want to participate in product and code creation without relying on traditional file-based design behaviour.

That does not kill Figma’s seat model overnight, but it does chip away at the assumption that every stakeholder must enter Figma to participate or experience design. Thus, the deeper issue goes beyond whether the team has seats at the table (canvas). The table of collaboration resides in a code-native environment and workflow, where the moment of truth shifts closer to implementation, and that reduces the number of times a team needs to return to a design file as the source of record.

The handoff-is-dead argument usually shows up as a claim about what designers can do now: move closer to implementation, write production-minded specs, and stay in the work longer. Yeo adds the business-model version of that argument. If collaboration moves into code-native environments, Figma is not just losing a handoff step. It is losing the shared room that made every reviewer, PM, engineer, and executive need a paid license.

Figma is not standing still. Even before Config 2026, the company pushed beyond static collaboration and into AI-connected workflows. Features like MCP, Code Connect, and Figma Make on local code point toward a future where design data can move more fluidly into development environments and AI tools.

That is a smarter response than pretending the canvas can win by becoming a slightly better canvas. Figma’s best path is to become the system that preserves design intent, component logic, and implementation alignment across tools. In that model, Figma is becoming an operating layer.

This is also why the company’s product strategy feels more important than its individual features. A single new AI button will not change the story. What matters is whether Figma can make design data more portable, more structured, and more useful outside the file itself. Config 2026 suggests that Figma understands this, but it also shows how hard the transition is: the company still has to make the canvas relevant in a world where many teams want to begin and finish elsewhere.

Yeo’s warning is blunt: “if teams can skip past the canvas by accelerating from intent to implementation with less translation, the value of designing to handoff vanishes.” The answer he points toward is less about file ownership and more about whether design intent can survive the trip across tools. For designers, that shifts the work from drawing the artifact to making the intent durable enough for other tools to read.

The future of design is likely to be built around reusable tokens, readable structures, and tool-agnostic metadata rather than locked files that only live well inside one platform. The winning systems will be the ones that can travel between editors, browsers, codebases, and AI agents without losing meaning.

Designer and writer Christopher Butler is writing about AI, but this also lands on the mechanics of agent loops. A loop can keep running, but useful output still depends on the constraints, preferences, success criteria, and taste made explicit before it starts.

Butler, on what stays human:

The more interesting situation is the one where we keep the thinking and hand off only the doing — and what happens when we do.

What happens is more than speed. When you have to describe what you want to the agent — with enough precision that what comes back is what you actually wanted — you begin to think about the thing differently. Description, it turns out, is where the idea often actually gets made. You start by knowing roughly what you want, and the act of articulating it produces a clearer want, which produces a sharper specification, which produces a better thing. Then you do it again. The thing improves; so does the thought.

That maps to the AI bottleneck I keep seeing: production speeds up, but judgment still happens at human speed. Butler isn’t arguing for slower tools. He’s arguing that useful AI makes the thinking more explicit, not less.

The friction is part of the point:

The agent’s current maturity requires a level of input precision that a competent colleague does not. At first, this can be a frustrating blocker; we’ve depended upon a different kind of intelligence in our peers — the kind that requires no elicitation. The machine does. But in a sense, this is a gift. It forces you to think the thing through in places you might otherwise have left fuzzy.

That’s the designerly translation. The machine doesn’t infer your hierarchy, tone, edge cases, or tolerance for risk unless you put them somewhere it can use. That friction is useful because the agent forces you to specify the fuzzy parts before it starts generating the same mistake everywhere.

Butler’s word for that retained work is investment:

This system depends upon me to provide the thinking. The agent does the doing. The structure is, I think, the practical form of the argument: the systems carry the doing, and they carry it well precisely because I have spent the time to think them carefully through. We like to call this intellectual property, which I think is a bit obnoxious. It’s really intellectual investment. Every technological advance should be measured not by the measure of intellectual property it absorbs — how much it can do without us — but by how much intellectual investment is worth sowing in it.

That’s the useful correction to “AI will do the work for us.” It will, but only the part of the work that can be expressed well enough to delegate. For a design system, that means brand rules, component logic, editorial standards, and good taste have to become rules, prompts, specs, tokens, and checklists the agent can actually use.

That leaves the tool in its proper place. Using AI lazily will produce plenty of forgettable output. The more interesting use treats it as a medium that rewards the thinking you put into it.

Of course, there is tension between expressing our specs as words and spatial manipulation as visual thinkers.

There are two versions of the same design-systems worry. One is about craft: AI can make an interface look considered without teaching anyone how the system works. Design-systems expert TJ Pitre pushes on the governance version: once the system is machine-legible and agent-friendly, who owns the calls the machines are allowed to make?

So when I say I have a beef with “agentic design systems,” understand that it isn’t a beef with agents. It’s a beef with one specific move that the term smuggles in, and that most people repeating it haven’t noticed they’re endorsing.

Here’s the move: handing the judgment layer of a design system to an autonomous agent loop that no human owns.

That’s the whole problem. Everything else is just tooling, and the tooling is great.

Design systems as AI infrastructure only works when the infrastructure still has an owner. Make the system machine-readable. Let agents generate, document, test, and check against it. But Pitre is correct that the library is only useful if the standards still have an accountable owner.

Strip away the Figma libraries and the Storybook instances and ask what a design system actually is. It’s a set of decisions an organization has agreed to and committed to enforcing over time. What does “primary action” mean here. When do we break our own grid. Does this thing deserve to exist as a component at all, or are we about to enshrine a one-off into the canon forever.

Those aren’t generation problems. They’re judgment calls, and they carry consequences the organization is accountable for, to its users, its engineers, its brand. A design system is, underneath all the tooling, a way of encoding collective judgment and holding people to it.

Pitre turns that into a test:

Which gives you a clean test for any “agentic design system” claim you encounter. Ask: what rejects the agent’s output, and who decided the rule it’s being rejected against? If the answer is a human-owned gate, it’s the real thing. If the answer is “another agent checks it” all the way down, you’ve built vibe coding with extra infrastructure and a more confident logo.

And that version is arguably worse than a person vibe coding in a scratch repo, because it launders drift through the authority of the system. The output looks sanctioned. It came from “the design system.” Nobody chose it.

In the end the invisible hand of the designer must still be felt.

Murphy Trueman isn’t worried that AI makes bad design. She’s worried that it can make passable designs, enabling designers to bypass contact with the material that teaches them how systems actually behave:

UI is starting to feel disposable in a way that unsettles me. Not as a complaint about quality. Structurally.

The pace of generation means nobody dwells in a screen long enough to notice whether it’s actually considered or just plausible, and plausible is increasingly good enough because the bar for “does this look designed” keeps dropping when the tools do the designing. The decisions are still there, technically, but the attention that turns decisions into craft has somewhere else to be.

You can produce a lot of considered-looking work without any of it being considered.

This is the craft problem hiding inside the productivity story. The danger isn’t only that teams will ship screens faster. It’s that they may lose the habit of noticing the small decisions that make an interface hold together after the first glance.

Trueman gets more specific about what Figma gave her:

But the specific thing that made Figma matter to me wasn’t efficiency. It gave me a way to hold abstract structural ideas in my hands — the relationship between a component and a style, between a token and a decision, between a change made in one place and every instance that inherits from it, made visible, made editable, made something you could touch and understand by touching it. That’s how I learned to think about the work.

That’s the part I don’t want AI tools to flatten. The best design tools don’t just make results; they make relationships inspectable. You learn by manipulating the system, getting it wrong, and seeing which decision moved. Difficult to do in code and see it cascade in the product.

Designer and writer MC Dean thinks most AI design demos are still asking the old workflow question: can the machine draw the screen I had in my head?

For Dean, that is too small. The useful shift is underneath it: if an agent is composing the interface, the designer’s job moves from final artifact to operating conditions.

Right now, in design teams everywhere, the same experiment is running. Someone feeds a prompt to Claude Design, or one of its cousins, and waits to see whether it can produce the screen they would have designed themselves. Some people are delighted. Some are frightened by how good it is. Some are disappointed in the results. A few are furious, and I understand why. When a machine can do in 10 seconds the thing you trained 10 years for, it’s annoying.

I want to move us off this question for now, because (nearly) all of us are asking it wrong.

Here is what we are really doing. We have been handed a tool that can grow an interface out of intent, something genuinely new in the world, and we are pointing it at the oldest task we know. Draw a fixed screen. Convert the canvas to code. Hand it down the line, faster and cleaner and with fewer late nights. Useful but look closely at what we are optimising for: We’ve been given something revolutionary, and we are using it to do old school design. A better-preserved version of the old way of doing things.

Dean’s line about “old school design” gets at the trap in a lot of canvas-to-code excitement. Faster handoff is useful, but it still treats the UI as the thing to preserve instead of the thing a system can produce when the context changes.

Dean again:

Canvas to code is a brilliant answer to a question that is already on its way out.

You can watch the whole industry racing to perfect it. Figma put an agent right on the canvas that generates and remixes and respects your design system, then made it possible to push those changes into a real codebase and open a pull request without ever leaving the file. It is clever work, and if your job today is getting a fixed design into fixed code, you should use it. Just notice what it is for. It is the most beautiful possible version of the handoff we have always done. It is the road getting smoother, right before it all changes.

Because here is where this is all heading, and it is so much more interesting than a faster mockup.

This is where designers have to be careful. If the interface becomes runtime output, then judgment has to live in components, constraints, refusal rules, and briefs the agent can actually use. The screen is still how the user experiences the product. It just stops being the primary thing designers hand over.

For a design team, that changes the evaluation. The first pass can be rough and still useful if it exposes which rules, components, and intentions are missing. The important artifact is the environment you can improve, not the individual screen you can rescue.

Dean on the method:

You stop finishing screens and start preparing materials. A set of components an agent can compose from, with the rules of combination written down: what sits next to what, how space behaves, which piece to use and when. Then you write your intentions in plain language, the way you would brief a thoughtful designer who is about to make a thousand small decisions without you in the room. How should this treat someone who is rushed. What does it never do, whatever happens. What should it feel like when the news on the screen is bad. You are not producing the outcome any more. You are designing the infrastructure, architecting the full experience, and curating the best outcomes.

Then you do the part that surprises people. You let it build, and you watch what comes back across many different moments. You correct the environment and the intentions, never the single screen. It is closer to coaching than to drawing. You train judgment into a system, and then you trust it in the places you will never get to enter.

You could start with one flow. Instead of designing the screen, write down everything an agent would need to know to design it well: the taste, the priorities, the hard refusals. Hand it over. Look at what it makes. Then resist every instinct to fix the pixels, and fix the instructions instead. That small discipline, correcting the brief rather than the output, is the whole new craft in miniature.

B. Prendergast revisits atomic design:

Atomic design is nearly ten years old. Brad Frost’s atoms, molecules, organisms hierarchy did something genuinely useful when it arrived: it gave teams a shared language for the idea that components are made of other components, all the way down. For a lot of people, including me, that was the conceptual unlock they needed to start building modular reusable front ends instead of pasting the same button in seventeen places. It worked. The industry absorbed it wholesale.

But I think we can probably retire the metaphor now.

Brad Frost’s watershed atomic design concept solved a real communication problem. It helped designers and engineers talk about components as things that compose, not screens that get pasted together. The problem starts when a teaching metaphor becomes the operating model.

Prendergast describes the tax teams pay when that happens:

The problem I keep running into with teams over the years isn’t that they don’t understand atomic design. It’s that they’ve understood it too literally. They’ve set up their Figma and Storybook libraries with Atoms, Molecules, and Organisms sections. They’ve had the naming convention conversations. And then, reliably, they get stuck arguing about whether a card with an avatar and a label is a molecule or an organism. That conversation is a tax. It doesn’t produce better components. It produces friction, disagreements, and the occasional afternoon lost to taxonomy instead of building.

That’s the part I care about in design systems. A good library should make the useful path obvious: which pieces can be reused and which contracts they have to honor. If the library mostly teaches people to sort objects into clever buckets…well, that’s a distraction from the work.

Prendergast closes with the on-ramp caveat:

I’m not arguing against atomic design as an on-ramp. If someone on your team is new to component-based thinking, the atoms/molecules/organisms scaffold is still a powerful and reasonable way to introduce it. Use it. Just don’t park there. The abstraction to keep is composability. Components compose up from smaller components. There are no real required levels between the smallest useful unit and a whole page or view. Whether an intermediate component is a molecule or an organism is a naming problem, not a design problem. We can stop solving it now.

The real test of a design system isn’t whether every component sits neatly in the correct layer of a hierarchy. It’s whether people can understand it, trust it, use it, and extend it without breaking it.

Nobody ships a better product because they correctly identified a component as an organism instead of a molecule. Atomic design succeeded because it taught people to think in terms of composition. Components built from components. Small pieces combined into larger ones. Clear contracts. Predictable behaviour.

Everything else is bookkeeping.

Emma Webster, writing for Figma, argues that AI tools are pulling prototyping earlier in the product process: teams can validate with more fidelity, then carry design context forward instead of recreating it at handoff.

Product teams are rapidly adapting to the new way of working in the AI era. They’re prototyping before writing specs, testing in code before designing, exploring at unprecedented scale, and shipping with design system context that used to get lost in the handoff. We talked to product builders at FloQast, Merkle, Affirm, and Accor about how that’s playing out in practice.

The shift is about when the hard questions show up. Specs used to be the artifact that let teams pretend they had alignment. The team behind Claude Design skipped the PRD entirely and prototyped its way to the answer instead. With AI tools, a prototype can become the first serious question: does this flow hold up when the data, logic, motion, and system constraints are present?

Webster describes the code-to-canvas loop this way:

Testing an idea against intricate constraints—things like multi-step flows where one action triggers the next, or interfaces that behave differently depending on the data behind them—used to require significant developer investment. Today, AI coding tools have made it possible for more people on a product team to quickly build and test these kinds of interactions before committing to a direction. That’s opened up a new workflow. A product builder can create a working prototype in code, then move it onto the Figma canvas using Codex to Figma to see the full picture and refine it together. From there, if more work needs to happen in code, they can move back via MCP with the design context intact.

This is the version of AI-assisted design I care about. Not “prompt a shiny UI from a blank page.” A working model becomes the place where designers, PMs, and engineers can see the same problem at once. Figma is still the canvas for style exploration and visualizing complex flows, but the decision surface is becoming more product-shaped.

That matters because prototype fidelity changes what a team is allowed to learn. A flat mockup can test preference and comprehension. A working prototype can test sequencing, edge cases, permissions, motion, and whether the idea survives contact with real constraints. Bringing that earlier into the process should make design less speculative, not less thoughtful.

The Accor example shows why this matters before anyone commits to a build:

Justine opened Figma Make and prototyped something she wouldn’t have had time to build by hand—a webpage that reorganizes itself based on what the user types. Search for “golf” and the page reshapes around properties with golf courses, curated outings, and relevant experiences. Make handled the micro-interactions and transitions, and the Figma MCP server kept everything connected to the brand’s design system. Within days, she had a working prototype ambitious enough to show leadership what was possible—and concrete enough to start a real conversation about what to build next.

Webster’s Affirm example carries the same logic all the way into production:

A PM prototyped the badge variations in Figma Make—going from idea to working prototype in two days instead of the usual six weeks. Designers refined the winning direction on the canvas, and when the team was ready to move that design into production, they loaded the design artifacts into the Figma MCP server and connected it to Cursor. MCP passed the components, tokens, and layout structure directly into the coding environment, where an AI agent generated the front-end implementation. Developers used that as their starting point, building production code that already reflected the designs instead of reinterpreting them from scratch.

Preserving components, tokens, and layout structure turns the prototype into a rehearsal for the real build. It has enough fidelity to expose bad directions early and enough context to keep the winning direction from being rebuilt from memory.

The artifact-to-intent argument has been working its way through design writing for a while now. What Jakob Nielsen adds to it, writing in UX Tigers, is a name for the failure mode that comes with the territory:

We used to accumulate design debt when teams shipped inconsistent components or patched over poor flows. Now we will accumulate intent debt: undocumented assumptions, vague brand guidance, missing escalation rules, untested agent permissions, and research insights that never become usable by the systems doing the work. Intent debt will be harder to see than visual inconsistency, but it will be more damaging because it compounds invisibly through every generated output.

Nielsen’s prior writing on intent-based UX argued that evaluation has become the new bottleneck for the user. A chat completes the task in seconds, and you spend the next half hour checking whether it actually did what you meant. Intent debt extends that bottleneck to the organization. The team ships ten variants in an afternoon, and nobody can tell which ones violated a brand rule that was never written down, or bypassed an escalation path that only lived in a senior designer’s head.

Nielsen puts the failure plainly:

The new danger is that AI will produce many adequate screens that all seem defensible in isolation and incoherent in aggregate. Mediocrity will arrive well-dressed. The designer’s role is to prevent the organization from drowning in plausible options.

Which is why the design system has to grow up:

The design system thus stops being a component library and becomes an operating system for taste. Tokens, components, and usage rules are only the visible layer. Underneath must be a deeper set of instructions about brand behavior, interaction philosophy, accessibility standards, motion logic, content tone, escalation patterns, and product judgment. The system must know not only which button to use, but when not to add a button at all.

Developer Mark Anthony Cianfrani has argued that LLMs finally let us ship the reasoning behind a token alongside the token. Nielsen draws the consequence of skipping that work: a weak design system in the AI era becomes an active liability. Agents will faithfully build with whatever’s encoded, and faithfully invent the rest.

After watching six agents design an app together in Pencil and spending a little time in Paper, I’ve been waiting for Figma to answer. Rodrigo Davies and Tammy Taabassum, writing on the Figma blog, finally announce it: a native design agent on the canvas, not bolted on through a separate app or a third-party MCP client.

Davies and Taabassum open with the pitch:

Designers need purpose-built tools that serve the essentials: exploration, experimentation, collaboration, and precision. Figma was built as a multiplayer canvas to make all of that possible. As teams adopt agentic tools to build products more quickly, false choices are emerging: Speed or precision? AI generation or direct manipulation? You shouldn’t have to choose.

Earlier this year Figma opened the canvas to third-party agents through its MCP server, letting Claude Code, Codex, and other agents push designs into a Figma file. That move covered the integration story. This one covers the in-app story:

That’s why we built the Figma agent. Our goal was to create an agent fluent in Figma and native to the way teams work. That meant making Figma itself legible to a model in ways that aren’t possible with third-party tools—with deep context on your components, tokens, standards, and best practices.

A third-party agent reaching in through MCP has to translate every request through a protocol; a native agent already speaks the file format. It knows your components, your tokens, your variables. That’s the gap between an agent that can edit a Figma file and an agent that lives in one.

The use cases Davies and Taabassum walk through—going wide on style explorations, bulk-updating variables across a design system, distilling comment threads into actionable plans—are the work designers were already paying the tax on. On exploration specifically:

The best designs rarely come from the first idea—or the first prompt. Exploring directions, comparing approaches, and iterating is already core to how designers work. Our agent will help you cover more ground in less time.

Renaming variables across a file, repeating padding changes through an entire flow, swapping one component for another across a dozen screens: that’s the busywork the agent is perfect for. The taste call on which direction to ship stays with the designer.

Davies and Taabassum close with:

Figma’s agent is embedded where the work already happens. There’s no toggle tax, no context switching, no learning curve. You stay in Figma and your team stays in the loop. We built this with one goal: to help you work faster without compromising on quality and craft.

That’s the competitive answer to Paper and Pencil. Agent-native canvases get a head start by not carrying any legacy assumptions; Figma carries millions of files and the design systems inside them. The bet is that the install base plus a fluent-in-Figma agent beats a greenfield canvas plus a generic one. We’ll see who’s right once the beta opens up.

Nick Babich, writing in UX Planet, takes inventory of where Figma still earns its place once teams stop treating the mockup as the deliverable:

One thing is clear: the conventional process in which UI and UX designers spend hours and days pushing pixels to create perfect layouts is no longer the reality for many organizations. The reason is simple: in the AI era, time-to-market has become a critical metric, and most companies would rather ship a “good enough” product quickly than spend extra time perfecting every detail.

The concept of Figma as a design tool originated from the conventional design process. You could say that Figma is an almost perfect design companion for designers who follow a traditional UI/UX workflow.

But the problem is that the conventional design process is no longer the reality for most organizations.

Organizations that embrace rapid prototyping are switching to tools that allow them to build and ship quickly. Instead of starting with static UI mockups in Figma, they jump straight into the prototyping phase using tools like Claude Code. In this phase, teams create coded prototypes that later evolve into fully functional products.

Figma’s role is narrowing from everything-tool to exploration-and-iteration tool, and narrowing is not the same as dying. Babich is now drawing the lines around what that specialized future actually looks like: design systems (especially the ones already living in Figma), complex enterprise workflows with real business logic, and the brand and visual-identity work where taste is the whole point.

On Figma Make, Babich is blunt:

But the problem is that Figma Make is still nowhere near tools like Codex or Claude Code in terms of output quality and overall user experience. Claude Code and Codex are significantly more capable, flexible, and comfortable for rapid product development workflows. Even for simple tasks like creating a prototype of design imported from Figma, Make tends to add a lot of visual defects.

I scored Figma Make 58 out of 100 at launch. It has improved since, but Babich is right about the gap. Make is competing against tools that were born for code generation against a working repo; Make was retrofitted onto a vector editor. That difference shows up in every prototype that looks fine until you zoom in.

On design systems, Babich:

In other words, you don’t necessarily need to maintain your design system in Figma; as long as you can provide access to a GitHub repository containing your design system, you’re in a good position to generate consistent interfaces.

If the design system can live in the repo and the agent can read it directly, the Figma library becomes a mirror rather than the source. That doesn’t kill the Figma file. It does change who has to maintain it and why.

Owen Williams, a design manager at Stripe, sat down with Claire Vo on How I AI to walk through Protodash, the internal prototyping tool he has spent the last eighteen months building. What sticks is what Protodash has done to the handoff. Williams, describing the Radar fraud-detection team:

They literally have a pull request of a prototype that I had I see an engineer working on and I’m like this has never happened ever in my career as a design manager. They’re like “I’ll just use the prototype as the source of truth” and they can just take it and do that. There’s a huge change — not having to red line a Photoshop file or all of that stuff.

That’s the part that matters. The prototype is the code, in the same components, ready to be picked up. Protodash gets there by constraining generation: a bundle of Cursor rules, a router and chrome scaffold, and Stripe’s design system (Sail) exposed via an MCP server. The off-the-shelf tools—v0, Cursor by itself, Claude Design—produce what Williams calls “blurple slop” because they hallucinate components. Wire the generator to the actual system and the output stops looking like a Tailwind demo and starts looking like Stripe.

The fidelity jump changes the room, too:

It’s sort of been this very transformative thing because all of a sudden I’m sitting in these design reviews and it’s so convincing that I’m like, is this the real product or am I looking at something fake?

This is what Tara Tan predicted: the moat in AI design tooling is the design-system graph, and whoever makes that graph machine-readable for agents wins the enterprise. Stripe just did it, internally, with a homemade stack, meaning it’s really an uphill battle for anyone trying to make a generic tool for this use case.

The interesting thing is who shows up to use it. Williams says Protodash is now used more by PMs than designers; PMs paste a PRD from Google Docs and get back a working flow before designers are pulled in. That tracks with the Figma Make case studies — PM-led prototyping isn’t theoretical anymore.

Williams is clear-eyed about what the tool can’t do:

How can I make sure that the tool knows enough to be dangerous? It gets to 80%. But like that taste, that craft is like, that’s why designers will always exist, in my opinion. Like they know how to elevate the experience. Like this thing knows how to use the components. The components are well designed, but it’s not going to be perfect. And we are here to steer them.

I wrote about this whole family of files in my recent newsletter: DESIGN.md, SKILL.md, SOUL.md, the markdown artifacts you write so an agent can read them. Nick Babich has the practitioner walkthrough for the DESIGN.md flavor of it, specifically the version that Google Stitch reads when it generates a screen. He describes the format directly:

DESIGN.md is a markdown file with two layers: YAML front matter that contains machine-readable design tokens (exact hex values, font properties, spacing scales) and Body that features a human-readable design rationale.

The two-layer split is right. The YAML is the part the agent can’t argue with: primary: "#d97706" is #d97706. The body is where you tell the agent why, and it has to be written like prose, not a config file. Babich’s philosophy section is where I’d point a designer who’s about to write their first one:

Unlike a traditional specification that often has very specific details that designers should follow when crafting a new design, DESIGN.md is less prescriptive in its nature. It creates a solution foundation for AI tools (colors, typography, corner radius) while providing enough freedom to alter the format for domain-specific needs. Another thing is that DESIGN.md is a living artifact, not a static config file. It should evolve as your design evolves.

The “less prescriptive” line is counterintuitive. You’d think the whole point of feeding rules to an agent is to be more prescriptive, not less. But Babich is right about the shape: pin down the tokens, leave the application loose, refine the file as the agent surfaces edge cases you didn’t think about. These files hold what we used to keep in our heads and call taste, and you don’t write taste like a requirements doc. You write it like a brief, and you keep editing it.

Emil Kowalski, a design engineer at Linear, takes the case for designers who can articulate why a choice works one step further. Once you can explain it, you can hand the rule to an agent.

An engineer has never been more leveraged than today thanks to a fleet of agents. But when it comes to more visual work, like animations, coding agents don’t quite know what great feels like.

My way of getting there is to create a skill file for each aspect of the interface. If you know what great feels like, describe the rules, then give them to your agents so they can follow them.

Kowalski shows two animations side by side, one scaling from scale(0) and one from scale(0.95), and walks the reader from “this feels right” to a real-world reason why:

With enough experience, you can not only tell what feels better, but also why. By then you’ve not only built your taste, but also the ability to articulate it.

The correct animation below feels right, because it animates from a higher initial scale value. It makes the movement feel more gentle, natural, and elegant.

scale(0) on the left feels wrong because it looks like the element comes out of nowhere. A higher initial value resembles the real world more. Just like a balloon, even when deflated it has a visible shape, it never disappears completely.

This is what Ian Guisard at Uber does as a design systems lead: encoding expertise, writing agent skills, defining validation rules, deciding what “correct” means. Nick Babich’s piece on agentic product design covers what makes an agent an agent; Kowalski’s piece shows what an agent actually runs on.

That’s the why. There’s no magic involved. Almost every “taste” decision has a logical reason if you look close enough. This applies to any other discipline really.

Of course the more creative part of the job is still up to you, but the more you can package into a skill, the more leverage you can get out of your agents.