I was out. Had my phone in my hand. And wanted to run a competitive analysis to see how Knapsack was addressing the market issue raised in an article I’d just read. Everything I needed was in my cpo-skills suite. Context, background data sources, routing tables to know which command to pull for which task.

All sitting in my vault. Perfectly organized. Inaccessible to me.

Because Claude Code lives in my CLI. My CLI lives on my laptop. My laptop was at home.

Claude.ai was right there. And it had far less that could help me.

It made me take a closer look at what claude.ai skills could do. My assumption - skills are prompts. A few hundred words providing context, available to trigger. Useful for tasks. But a long way from the depth I’d built in Claude Code.

I’ve built for depth. My cpo-skills suite has ten discrete command files, a delivery pipeline context document, and utilizes my specialized data-gathering agents wired to Linear, Slack, Github, etc. My thought-leadership suite carries its own context file - posting cadences, metrics, content pillars, conferences I’m tracking.

When Claude Code triggers these, that’s more than a prompt. It’s loading a working system.

But I realized that a claude.ai skill can be a gateway to that same system. On trigger, instead of containing all the intelligence itself, it instructs Claude to fetch it. It reads the README from my vault, loads the context file, consults the routing table, and pulls the specific command for the task at hand.

The files live in GitHub. Claude fetches them directly during the session. The skill in claude.ai is the key. The vault on GitHub is the room it opens.

My cpo-skills and thought-leadership skills in my Claude.ai project work in exactly this way. Each one is a few dozen lines. When I trigger the skill, it expands into the full suite I built in Claude Code. That’s context, routing logic, specialized commands, and in some cases an agent. All also available in that GitHub vault.

If you’re working in claude.ai you see a simple skill with a clear description. What runs is everything in the vault, accessed remotely.

This matters beyond just my own workflow. Claude Code solves for depth. That’s complex, stateful, multi-step work with persistent context. Claude.ai solves for accessibility. No terminal, no config files, far lower technical barrier.

The bridging pattern doesn’t collapse the distinction. The complexity stays in the vault, versioned and maintainable. The interface stays simple.

The person who builds the vault and the person who opens the door don’t have to be the same.

Further reading:

• Salcan, Y. E. Claude vs Claude Code vs Cowork — Which One Do You Actually Need? Medium article, Feb 2026

Article photo by Alla Bila on Unsplash.

Not translated.

Not approximated.

Not handed off from one side and reconstructed on the other.

The same thing.

Our industry has been trying to build that for thirty years. We’ve gone from building bad versions of the right thing to building good versions of the wrong thing.

The jokes wrote themselves. Dreamweaver sites. FrontPage sites. If you were of a certain rebellious bent, HotDog sites.

These used to be mocked because they were the telltale sign of someone who didn’t really know what they were doing. Table-based layouts, inline styles, spaghetti markup so bloated that any developer would want to quietly rebuild the whole thing from scratch instead of fix it.

They were also empowering tools for a lot of people. They let you make stuff that was real. They weren’t being mocked because they were trying to unify the visual and the functional in a single interface. That instinct was right. They were mocked because of how much they corrupted the code side of the equation.

The canvas was easy to navigate.

The code output was garbage.

So industry corrected. Realistically, given the technical limitations. Built an organizational culture around the separation of disciplines.

Serious designers used serious design tools.

Serious developers wrote serious code.

And between them a handoff ritual grew - redlines, specs, prototypes, tickets.

We created a workaround dressed up as a workflow.

The separation is artificial. We’ve always known this to some extent. Design systems were an obvious admission. Design intent encoded as structured, reusable truth rather than redrawn from scratch on every new screen. Tokens, components, semantic definitions; shared language that both sides could read. I’ve often joked that the irony of the name “design system” is that its primary consumers are usually developers.

AI closes the remaining distance. When structured design context can be interpreted directly into working interfaces, the translation layer becomes unnecessary. The middle dissolves, and the destination comes into view.

It’s why I find these code-to-canvas offerings so strange. Code-to-canvas takes a working interface - real interactions, data, behavior - and converts it back into static frames.

It argues that collaboration is only possible on drawings of the real thing, not the real thing itself.

Dreamweaver and FrontPage, for all their failures, at least understood where they needed to go. The visual and the functional needed to live together. They just didn’t have the technology to make their ambition real. The code they generated was the limitation, not the vision.

You can forgive a tool for being ahead of its time. But the technology exists now to make the canvas genuinely real - connected, live, executable. And it’s harder to forgive a deliberate turn away than a premature attempt at the right destination.

Our destination hasn’t changed. A canvas as a live interface into the system. The real thing made navigable, editable, collaborative. We’ve known that’s where we were going for a long time.

Surely this time.

Further reading

• The digital workflow is obsolete, on the collapse of the handoff model.

• Code to canvas is bonkers, on Figma’s specific wrong turn.

• FrontPage vs DreamWeaver. Webmaster World.com discussion thread, July 2003.

• Smith, E. Your Code is Junky. Tedium, March 2017.

Article photo by Daniel McCullough on Unsplash.

You can read the system’s philosophy in how the tokens are organized.

The tokens aren’t what made the system work. The convictions are what made it work. The design tokens were an artifact of that conviction.

That distinction is the argument.

The W3C Design Tokens Community Group published its first stable spec at the end of 2025. It’s genuinely good work. Years of collaboration to solve a hard coordination problem. How to share design decisions without everything fracturing every time someone changes a color.

The spec is deliberately minimal. It defines tokens, their types, and a reference system that lets one token point to another — so color.text.primary can reference color.palette.black, and changing the palette propagates everywhere. It adds $extends for group inheritance, a Color module with modern color space support, and a Resolver module for theming and context.

It’s a sensible, focused infrastructure that solves real problems. It’s the kind of foundation that would underpin exactly the discipline Anna built at IBM.

What practitioners have built around that foundation is something else.

The spec is agnostic about tiers. It defines how to express token relationships, not how many layers you should have.

The community is far less agnostic. Three-tier has become doctrine: primitive tokens at the base, semantic tokens that make purposeful claims about use, component tokens scoped to specific components. This is “mature token architecture” in most design systems discourse.

The gap between doctrine and practice is instructive.

Three-tier is what gets taught and recommended. Two tiers is what the major systems actually implement.

Carbon’s architecture doesn’t map neatly onto the primitive/semantic/component model - it has its own layering logic built around UI depth. Polaris has moved away from its component token layer. Material Design 3 publishes reference tokens and system tokens, and stops there.

Three-tier is the aspiration. Two-tier is what survives contact with a real system.

That gap should be a signal. The canonical systems couldn’t fully sustain the doctrine. And yet the doctrine keeps getting taught as the definition of maturity.

The problem isn’t the spec.

The spec - unavoidably - creates a thing to make. “We’re implementing the W3C spec” can start to feel like a north star, when a real north star is missing.

At J.P. Morgan there was always a tension between a debate on token naming strategy and architecture coming before a simpler question was answered: what is this design system for?

Naming debates aren’t a path to that clarity. They can be a replacement for it.

For Anna at IBM, the tokens were downstream. Philosophy came first. Tokens encoded the philosophy.

Where I’ve seen more struggle - at JPM, at some of the design systems I’ve worked with at Knapsack - is when that order is inverted. Taxonomy comes first, the thinking is supposed to emerge from it. Sometimes it does. Often the taxonomy becomes the only explicit structure of the system, and so it becomes load-bearing.

Which leads to a design system whose deepest held opinion is how to name its hover state.

Run naming conventions workshops because mature systems have naming conventions. Produce token JSON because good systems produce token JSON. That’s a cargo cult pattern. The mechanism becomes the mission.

There is a failure mode you can identify: token counts scaling linearly with component complexity.

The Tetrisly design system acknowledged this problem. Their button component reached over 500 tokens. It enumerated every property of every state of every variant: background, border, text, icon, default, hover, focus, active, disabled, primary, secondary, danger, ghost, large, medium, small, dark mode, high contrast.

Before long you end up with button-background-color-primary-large-hover-dark, and hundreds of siblings.

The spec supports this. But at this point the abstraction provides no value over well-organized CSS. The overhead is real: tooling dependency, Figma sync, governance process. But there’s no additional leverage when your variable names map one-to-one to CSS properties you have to write anyway.

The promise of tokens is leverage - fewer, powerful constructs that express more than just flat specifics. 500 tokens is a clear failure of that promise - you may as well be writing CSS. Tetrisly acknowledged this, and they’ve very deliberately thinned their “component tier” so their model is much closer to a two-tier than three-tier model.

Phillip Lovelace recently argued that tokens are even more important in an AI-driven workflow - token taxonomy can be an API the AI agent consumes. Semantic naming lets AI stop guessing your brand.

This is a worthwhile floor argument. AI generating UI from a token file produces more consistent output than generating from nothing. The W3C spec makes that even more reliable.

A floor isn’t a ceiling.

AI can traverse a token graph and resolve a name to a hex value. It can’t tell you why that color is right for a primary hover state, or if a destructive action should use the same token. Should a payment confirmation defer to stricter contrast constraints?

Those aren’t AI limitations.

Those are limitations of the information that tokens are supposed to carry.

Tokens encode what things look like. Not why. Not when. Not the conditions that change the answer.

The convictions in the best systems come from the decisions that precede them. An AI with access to those decisions - rules, intent, context - can do more interesting things than resolve color aliases.

Tight token architecture delivers real value. Tokens are a powerful artifact of thinking, but not a substitute for it. The W3C spec describes something of genuine worth, when it’s built in the right order.

The design systems that work treat tokens as output. Philosophy first, constraints second, governance third. Tokens encode the decisions that have been made. But only if those decisions have been made.

Systems that struggle have the sequence backwards. And the quality of the spec actually makes the inversion easier. It’s a rigorous blueprint for the mechanism, and the foundation is left implicit.

Tokens with system conviction are infrastructure. Tokens that substitute for it are dogma. The difference is everything.

Further reading:

• Frost, B. The Many Faces of Themeable Design Systems. bradfrost.com

• Gonzales, A. Introducing Figma variables and a consolidated “All themes” library! Carbon Design Blog, Aug 2023.

• Design Tokens Technical Reports. W3C Community Group, Oct 2025.

• Lovelace, P. Design Systems Are Having Their Moment. Design Systems Collective, Feb 2026.

Article photo by Jan Canty on Unsplash.

Her argument is that paid design system documentation platforms like Zeroheight are obsolete. Figma’s API is accessible. LLMs can write docs. Open-source tooling is good. Build the whole thing yourself, in two weeks, for free.

It’s a practical guide. It has sound tooling advice.

The piece treats design system documentation like it’s an asset display problem. How do you surface your Figma components and code repos in one place, more cheaply than current products offer? That’s a reasonable question.

But it’s based on a definition of design systems that I think is fundamentally too shallow. That’s a starting point that leads to something that looks like a solution, but isn’t.

The article describes documentation as an “aggregator - the one place that ties everything together.”

Sit with that word.

An aggregator is passive. It collects. It displays. It points at sources and renders them side by side.

A design system isn’t an aggregator.

It’s a contract.

A design system is the authoritative agreement between disciplines - design, engineering, product - about what is true, what is intentional, and why. Documentation doesn’t just display agreement, it’s where that agreement becomes canonical. Intent becomes instruction. “We discussed this on Slack” becomes “this is how we build things.”

If your docs platform is a viewer on top of your Figma files and your code repos, that’s not a system of record. It’s a window. It doesn’t resolve disagreements.

A DIY doesn’t solve one, vital problem - and the article doesn’t name it.

Figma is not a design system.

Storybook is not a design system.

Figma is a tool for designers. Their working files, experiments, intentions, abandoned interations. A designer’s environment - rich and full of things in-progress, deprecated, aspirational.

Storybook is a tool primarily for developers. It documents what has been implemented. It’s the engineering team’s environment - authoritative about code, somewhat indifferent to design rationale.

If you point an AI agent at your Figma library you’ll train it on your designers’ hypotheses. Point it at your Storybook and you train it on engineering implementation that may lag design intent, exceed it, or quietly diverge.

Neither tool can answer the question on its own: what is true?

When the Button component in Figma has rounded corners and the one in Storybook doesn’t, what does your documentation site say? If it just faithfully renders both sources, it’s documented your misalignment.

That’s not nothing. It’s useful to know. But it’s not a source of truth. It’s published disagreement.

The design system has to adjudicate. It has to carry a philosophical underpinning. A stance. Not just visual and technical inventory. It needs the decisions and reasoning that make the inventory coherent. Why did we make these choices? What are the governing principles? Which source wins when there’s a discrepancy? Why?

And how do we strive for excellence when there isn’t a source at all? A new pattern, an edge case, a platform you haven’t built for yet. The system of record doesn’t just arbitrate what exists. It also guides what should.

That’s not something that can be generated. It requires human judgment, authority, and a platform to enforce it.

The article’s AI-readiness argument is sharp. And it’s where the initial error becomes most consequential.

The article is right to identify that design system documentation is increasingly an instruction layer for AI agents. “Robot food” as my colleague Chris Bloom would describe it. The context that makes generated UI consistent and correct. And it’s also right that static platforms unable to expose data in a structured, machine-readable way, fail at this job.

So it proposes replacing them with Docusaurus and MDX files maintained by a team. Which is also static. And manually curated. But it’s free and you own it.

But the answer to AI-readiness isn’t just a better documentation site. It’s a genuine system of record. Where documentation is generated from structured, authoritative, interconnected sources. Where the connection between intent and implementation is dynamic, not periodically reconciled.

Documentation that auto-updates when code changes isn’t a feature. It’s the entire point.

But it needs to have broader context to update in an intelligent, guided, way.

Otherwise you’re just feeding AI a snapshot. A snapshot of what was true when someone last updated a file. Or a snapshot of the AI’s guess at what a conflict resolution was. And the gap between “what the docs say”, “what the design file says” and “what is in production” is exactly the kind of ambiguity that makes AI-generated interfaces drift.

The cost argument also dissolves.

The article compares platform licensing fees to zero.

But the real cost of a design system isn’t tooling. It’s the misalignment it prevents - or fails to prevent.

That’s the denominator.

The cost of rework because design and engineering interpreted a component differently. Cost of multiple QA cycles because the implementation didn’t match the spec. Cost of onboarding time because the documentation was out of date. Cost of inconsistent experiences because there wasn’t an authoritative answer to “how does this pattern work in iOS?”

The total cost of a DIY aggregator includes engineering time to build it, maintain it, update it when APIs change, wrangle the AI writing pipeline, manually curate the output. And, if it’s being seen as an aggregator, it includes the organizational cost of having a documentation site that’s a collection of assets rather than a system of authority.

That cost might seem invisible. Then it accumulates.

None of this is an argument against open-source tooling. Or AI-assisted documentation. Or against genuine improvements in what’s accessible and buildable. Those are real changes.

Infrastructure isn’t neutral.

The choice of what you build - aggregation layer or system of record - has downstream consequences for every discipline that depends on it. It shapes what designers trust. What engineers implement. What AI agents consume. What your product becomes.

If self-building (not merely aggregating) your design system platform is the right approach, and the costs and benefits are fully considered, great. That’s IBM Carbon, and it’s one of the best design system websites out there.

And if a documentation platform can make the building of the site easier, so you can focus on the creation of the actual design system, all the better.

Design systems are not a collection of Figma components and Storybook stories, with a documentation site sitting on top. The documentation is the surface expression of something much deeper and more considered.

Decisions made. Rationale captured. Authority established.

You can build an aggregator in two weeks. Building a system of record takes longer. Because you have to decide what’s actually true.

That’s the work.

I’m not a neutral observer.

I’m VP of Product at Knapsack. We build infrastructure that makes design systems a live system of record - connecting design, code, and documentation as a unified source of truth.

I have a direct interest in this question, and you should read with that in mind. But the argument stands regardless.

Further reading:

• Rita, M. Stop paying for design system documentation you can build yourself. All about design systems, Feb 2026.

• Aizlewood, J. Design systems don’t start with components. Clearleft, July 2017.

Article photo by Lewis Keegan on Unsplash.

Let’s break that down. You use an AI coding tool to generate a working interface. Real code, real interactions, and real data. Then take the functioning reality and convert it back into a static abstraction, so that people can look at it together on that canvas.

You had a building. Now you have an architect’s drawing of that building.

Figma is telling you this is progress. It isn’t. It’s a solution to Figma’s business problem - the growing irrelevance of the static canvas - presented as though it’s a solution to yours.

In November I wrote about the collapse of the traditional digital workflow. That comfortable fiction where design happens here, code happens over there, and a handoff ritual connects the two.

AI is dissolving that middle layer. Structured design systems, and wider product context, can be interpreted into working interfaces. At that point, the abstraction layer between design intent and delivery reality becomes unnecessary. Design isn’t a stage before delivery. Design is delivery.

It’s a defining shift in how products get built.

Jonny Burch made a complementary argument last week, in his piece “Life After Figma is Coming.” His framing encompasses the tooling ecosystem: as code becomes the source of truth, design tools become interfaces on code, not the other way around. Code is the only correct source of truth - open, shared, with common standards. The canvas doesn’t disappear, but it has to become a view into reality and not a substitute for it.

These arguments point in the same direction. The canvas is no longer a staging ground for ideas that exist outside the system. It needs to be a live interface for ideas that exist within it.

Claude Code to Figma points in the opposite direction entirely.

Field’s own framing is revealing. He describes working code as “tunnel vision” and that this feature will help you “escape” it.

…the design canvas is better at navigating lots of possibilities than prompting in an IDE.

The Figma blog announcing the Claude Code to Figma feature elaborates further. Solo code exploration is a “single-player environment”.

…that speed of solo exploration can become a constraint.

And as a contrast, they describe the canvas as a “shared space” where “the conversation changes and new possibilities open up.”

That’s a neat rhetorical move.

It takes a genuine limitation of current code-first workflows - collaboration and visual comparison are harder in a terminal - but reframes it so that the working artifact is the problem, and the abstraction is the solution.

Those are not the same thing. Needing better collaboration on working artifacts isn’t the same as needing to convert the artifacts into a different, lower-fidelity format in order to collaborate at all.

The answer to “how do we collaborate on code?” is not “convert it to not-code.”

The better solution is better collaboration tooling for code. Live preview sharing. Annotation layers on running applications. Structured feedback on deployed states. As Burch points out, a tooling ecosystem is already exploding in size - design interfaces that sit on top of production code, development environments that integrate design thinking. The pieces are coming together.

When you capture something from Claude Code and bring it into Figma you don’t add information. You remove it. You remove interactions, real data, actual behavior. You replace it with a picture of what it looked like at the moment of capture.

That’s trading truth for convenience, and claiming it’s a workflow improvement.

It’s an absurd proposition.

You have a working thing. You convert it into a non-working representation. You collaborate on the representation. At some point, presumably, someone has to make into a working thing again. That’s not a workflow, that’s a detour.

This is not just a feature decision. It’s a strategic posture that serves Figma’s interests while actively working against the interests of people using it.

Figma’s business depends on it being the place where product decisions happen. Their value proposition is the collaborative canvas being the hub of product development. The more decisions happen in code-first environments - engineers and designers collaborating directly on running applications - the more Figma risks becoming peripheral.

Figma is trying to maintain its gravitational pull. Every feature needs to bring work into Figma, not enable work to happen outside it.

Field says this directly:

Whether product building begins in a terminal, a prompt box, a visual UI or a hand-drawn sketch, we want Figma to be the place where it all comes together.

That’s not a workflow insight. That’s a business objective.

Claude Code to Figma is not about improving your workflow. It’s about preventing your workflow from leaving Figma behind.

And this is the part of the framing that I find genuinely dishonest. Figma’s blog post presents this as a way to unlock creativity and open up collaboration. Something to liberate teams from the constraints of solo code exploration. But the people who are using Claude Code to build working interfaces aren’t constrained. They are ahead. They have the real thing. The feature asks them to go backwards. Sacrifice fidelity, leave something functional and return to an abstraction layer. Because Figma needs them to.

That’s a solution for Figma. It’s not a solution for the people building products.

The timing might reinforce the point. Figma went public, and the stock has dropped a lot since IPO. It’s a legitimate question whether AI-native tools make traditional design canvas less central to digital product development. So product announcements also need to be a message to investors: the canvas is still essential.

Code-to-canvas is a defensive move dressed up as innovation.

The honest version of this feature announcement might say: “More product work is starting in code. We need to pull that back into our ecosystem so we can remain relevant.” That’s a legitimate business challenge. And I have sympathy for the difficulty of Figma’s position. They built something genuinely great, and the ground is shifting beneath it.

But don’t tell me it’s for my benefit. The loss of fidelity isn’t “opening up new possibilities.” A functioning prototype being flattened into a picture isn’t “changing the conversation”. The conversation was already happening - and in a richer, more honest medium. This feature interrupts the conversation to bring it back to Figma.

It’s not about fewer canvases. It’s about more honest ones. More real. Connected to live systems, reflecting real state. Enabling collaboration on the actual artifact rather than a simulation. The future of the canvas is as an interface to code, not a destination to convert code back to.

Code to canvas is the wrong direction. The future is canvas as code. Features like this are going to look increasingly strange as the rest of industry figures that out.

I’m not a neutral observer.

I’m VP of Product at Knapsack. We’re building in the place where structured design systems and product context meet AI-driven delivery.

But the proximity is also why this absurd code-to-canvas direction is so acute for me. When you’re working on systems that make design directly executable, watching someone propose converting execution back into abstraction feels like someone printing out a Google Doc so that they can fax it.

I'm presenting an expanded version of these ideas at the Great International Developer Summit in April 2026.

Further reading:

• The digital workflow is obsolete - the end of abstraction, and the start of design as delivery.

• Burch, J. Life after Figma is coming (and it will be glorious). jonnyburch.com, Feb 2026.

• Seiz, G. & Kern, A. From Claude Code to Figma: Turning production code into editable Figma designs. Shortcut - Figma’s editorial newsletter, Feb 2026.

• Field, D. Claude Code to Figma Design. LinkedIn, Feb 2026.

• Flowers, E. If you ask a designer what they want, they will say faster horses. Zero Vector, Feb 2026.

Article photo by Rob Martin on Unsplash.

Writing code. Building components. Translating product strategy into design intent into something that ships. It’s where time went, budget, and where the frustration lived. We organized entire teams and workflows around the bottleneck of making things.

But the bottleneck is dissolving. AI tools can generate a login form in thirty seconds. They can scaffold a page layout, draft a component from a simple text description. The raw act of production is being commoditized. If we’re only measuring speed from prompt to output, we’ve never been faster!

Speed…is not the same thing as progress.

I’ve talked about this before. If you use AI to build product right now, we know the story. The tool generates something very quickly. You spend time fixing it. Wrong components, bad spacing, didn’t use the right patterns, made incorrect assumptions about how your product works. You might throw it away and write it yourself.

The generation was really fast. The correction then ate up all those savings.

This isn’t AI’s fault. The models are getting remarkably capable.

It’s a failure of context. The AI simply doesn’t know what “right” looks like for your team, or for your company. What’s your product context? What standards should it apply?

Nobody told the AI the answers. At least, not in a way that’s structured, coherent, and persistent so it can use it every time it generates something.

Our enormous investments are making execution cheaper. And not enough people are investing in making sure that cheap execution is pointed in the right direction.

There’s already a name for this

Infrastructure engineers have already solved for this problem. In a system like Kubernetes, there’s a clean split between:

• The data plane (the thing that does the work, moves traffic, runs containers)

• The control plane (the configuration, policies, and health checks that govern execution)

Hell, we can even apply this to actual airplanes. Air traffic control is an intuitive version of this. ATC isn’t flying any planes. It’s telling the pilots where to go, what to avoid, how to land safely. The planes are carrying the passengers. ATC has the rules and system-wide awareness. An airport needs both to run successfully.

AI tools are a powerful data plane. They carry out execution very effectively. But organizations are running them without a control plane. Without any kind of structured, persistent, layer of context. Something that tells the AI how this team is supposed to build this product.

Our generation requests start from near-zero. Output is technically functional but organizationally wrong. The 70-90% first-generation rejection rate isn’t necessarily a model quality problem.

It’s missing infrastructure.

What a control plane actually does

What would a control plane for digital product delivery look like?

1. Gather what’s true about what you build

Design tokens, component APIs, coding standards, accessibility rules, brand guidelines. Institutional knowledge that probably lies scattered across repos, Figma files, a Confluence page, embedded in tribal knowledge across teams. A control plane assembles those into a single layer that an AI tool can query.

2. Know which sources to trust

Your docs say that button should use an 8px padding. The shipped code uses 12px padding. Which one is right? Maybe the code, because documentation drifted and the implementation is a better reflection of reality. A control plane can apply ranking. Which sources are authoritative. Which might be more aspirational. Which are fall-backs.

3. Measuring if the output is any good

Not “did the AI generate something?” But “did the generation meet your standards?”

How many regeneration cycles did this take? What was the token cost? Does it pass linting?

Without measurement, AI-assisted development is governance by intuition. If you have measurement, you can actually govern and improve.

4. Connect to the tools your team already uses

A control plane isn’t a new tool to adopt.

It feeds context into the tools you already have. Claude, Cursor, Gemini, whatever comes next. Protocols like MCP make this control layer tool-agnostic. You keep your context layer - your control. Your execution layer becomes interchangeable.

Bigger than your components

If you’re a design systems person, maybe you hear “control plane” and think my component library is AI food. That’s true, but just a part of it.

A real control plane touches everything that shapes how a product ships. API contracts. Content strategy. Performance budgets. Security policy. Compliance and regulatory requirements. Localization. Roadmap constraints.

It’s the institutional memory of “how we do things here” that no document captures, and no new hire absorbs until at least a few months in the job. But here, we codify it for AI.

The difference really matters. Narrow integrations answer “how many components do we have?” A control plane answers “how does the organization deliver product?” Different questions, and the second one is where there’s real leverage.

Infrastructure solutions for infrastructure problems

Most organizations already possess most of the raw materials they need. Those coded components, documented standards, guidances, and repos that are full of already shipped product.

The gap isn’t source material. It’s a gap in aggregation, ranking, and feedback loops that can turn all of this scattered knowledge into usable intelligence.

Execution is going to keep getting cheaper. That’s a trajectory I don’t see reversing.

The organizations that invest in coordination infrastructure - including the kinds of systems we build at Knapsack - are the ones who’ll actually ship.

The concept isn’t unique to us. But every team using AI to build product is facing the same challenge - whether they’ve named it yet or not.

The machines work. They need to know what to build.

Further reading

• Walker, J. Kubernetes Control Plane: What It Is & How It Works. Spacelift.io Blog, Jan 2025.

• AI-Assisted Coding Reaches 29% of New US Software Code. Digital Information World, Jan 2026.

Article photo by CHUTTERSNAP on Unsplash.

Faster delivery. Fewer people. Higher output. A competitive advantage.

There are impressive demos. Confident pricing decks. And perhaps one or two clear case studies.

Then the AI systems arrive.

Suddenly there’s a lot more process than expected. More data work. We need to do more governance work. There’s much more human oversight. An increasing number of meetings about “how to use it responsibly”. There are productivity gains in pockets, but it’s not consistent. Those headcount reductions don’t quite materialize. And your operational complexity starts to increase.

This doesn’t mean the technology doesn’t work. But it does suggest that we might have been unclear about what we were buying.

The story we tell ourselves

When organizations are talking about buying AI, they’re probably thinking of it in the same way as other improved software capabilities.

• Intelligence

• Automation

• Creativity

• Replacement for labor

Those are all fairly abstract concepts, though. They’re as much a marketing category as they are an operational one.

The value organizations extract from AI tend to cluster around different - less glamorous - things. Things that are more structural, and far more dependent on context.

What organizations are really buying

1. Velocity

The most visible benefit, and almost definitely the easiest one to sell.

AI is quick to produce outputs. It can draft, summarize, code, deliver UI variants, give you some analysis. And this is great for removing friction in the early stages of work.

But this is only going to be valuable if your surrounding system is able to absorb it.

If it can’t - and that’s the case in many organizations - that early speed is just moving a bottleneck further downstream. Review, integration, governance, legal, QA, product coherence suddenly all become more complicated.

Those extra complications may well cancel out all of that early stage acceleration. Velocity without coordination doesn’t create speed, it creates noise.

Speed is a feature. It probably isn’t the product.

2. Consistency

A quiet, unglamorous, workhorse.

AI systems can produce uniform structure. They can maintain a tone, a formatting style. AI can follow rules. And that can be incredibly beneficial in larger organizations where inconsistency can be a drag on productivity.

Uniformity of style, patterns, or language. This doesn’t always come across in a demo. But it’s a really durable value.

It’s also a value that demonstrates the vital importance of context. Consistency can only exist relative to some set of shared decisions about what “correct” looks like.

3. Reshaping (not eliminating) cost

AI doesn’t necessarily remove labor. It relocates it.

That work moves into:

• Data preparation

• Labeling and taxonomy definition and design

• Prompt engineering

• Evaluation

• Policy definitions

• Monitoring and exception handling

That’s a significant shift in headcount, but not a disappearance.

The cost changes form, before it changes size.

An organization that expects labor to vanish is likely to be disappointed. An organization that understands and expects to repurpose labor will be less surprised.

4. Optionality

Think of this as the hedge against being left behind.

Executives buy AI for the same kind of reasons they might invest in cloud solutions before there’s a clear direction in what they’re going to build: it avoids being trapped later.

This has value, despite the vague use cases. But it’s not the same as buying finished capacity.

A useful memory: IBM Watson

We’ve been here before.

In 2011, IBM’s Watson defeated human champions on Jeopardy! That created a powerful narrative about the arrival of general-purpose AI (or “cognitive computing” as IBM tended to say).

Many organizations rushed to adopt it - believing that they were buying intelligence - a system they could point at a domain and begin reasoning in a productive way.

What they actually bought was something else:

• Large-scale data ingestion

• Domain-specific training

• Constructing ontologies

• Labeling efforts

• Ongoing tuning

• Critically, the need for long-term consulting engagements

Companies might spend millions of dollars a year teaching Watson how their world worked.

That’s not necessarily a failure of the technology. But it’s a very clear mismatch in expectations.

Watson didn’t fail at being intelligent. It succeeded as a machine for encoding context - slowly, expensively, and with constant human involvement.

The consulting bill ended up not as a side effect, but as the product.

Same pattern, better demos

OK, today’s models are more flexible. We’re more than a decade further on in creating friendlier interfaces. The generality of today’s AI is much more real.

But there’s an underlying dynamic that’s still the same.

AI systems still require:

• Explicit definitions of acceptable behavior

• Structured representations of domain rules

• Boundaries set for them

• Exception handling

• Ongoing evaluation

• Continuous alignment with the realities of an evolving organization

The main difference today is that the demos are better at obscuring this dependency for longer.

Language models feel general, even friendly. But there is a brittleness behind the fluency. Context gaps don’t show up until systems are more embedded into production workflows, our compliance environments, or even customer-facing surfaces.

And then all that familiar work begins.

Vendors benefit from this ambiguity

This is probably an uncomfortable truth.

The more vague a buyer is about what they’re purchasing, the more benefit for the vendor.

Ambiguity allows:

• Performance to be judged on impressions, not data

• Diffusion of responsibility

• Elastic timelines

• Reframing costs as “enablement” rather than necessary maintenance

• Recasting failure as an adoption challenge

“AI” is a particularly powerful label, because it’s a bundle of different values wrapped up in a single term. One word being used to describe speed, consistency, experimentation, automation, and strategic positioning.

If the buyer’s mental model is less precise, all those outcomes can remain more easily negotiable.

That’s not malice, but it is structural. And to some extent ambiguity might also benefit the buyer.

Organizations should be skeptical of any pitch that cannot answer clearly:

What are we actually paying for?

Context is the real budget line

Successful AI deployments are not determined on model quality alone.

The hidden constant is context creation and maintenance.

• Formalizing decisions that had been informal

• Documenting all the exceptions

• Defining boundaries

• Encoding organizational preferences

• Stabilizing coherent vocabularies

• Agreement on what “good” means

• Being able to maintain these definitions as the underlying realities change

And this is slow, organizational, arguably very human work. It doesn’t scale in the same ways. It doesn’t easily show up in benchmarks.

But without it, AI systems will remain very good at producing fast output that’s locally plausible but globally incoherent.

Better buying questions

Don’t ask…

What can this model do?

Ask…

• What decisions are we, as an organization, formalizing?

• What labor is moving somewhere else, rather than disappearing?

• Are we outsourcing our risk to our vendor? How?

• What context do we need to maintain indefinitely?

• What parts of our organization need to change to make this work?

Without answering those questions, it’s difficult to know if an AI system is succeeding.

The technology we’re looking at is very real.

But so is the work needed to make it actually useful.

If you don’t know what you’re buying then you can’t possibly know whether it’s working!

Further reading:

• 10 years ago, IBM’s Watson threatened to disrupt healthcare. What happened? Advisory Board Daily Briefing, July 2021

Article cover image by Alex Shuper on Unsplash

Not so much because there isn’t anything to say. But more because other things in life make saying less the best thing to do.

I’m dealing with some personal grief right now. Nothing I’m looking to unpack publicly right now, but deep and unexpected. It changes how my days feel at the moment - how long or short things take, whether I’m thinking clearly, or distracted, my energy for creativity.

Work culture - maybe especially in the tech industry - sometimes treats emotional disruption as a bit of an inconvenience. We’re all running around doing so much that we need to “manage around it”, or suck it up to keep our output uninterrupted.

We don’t have many systems that are built around taking a pause.

Grief isn’t a bug in a system though. It’s a natural human state, and it needs its own time. Just as we need time to be productive, we also need time to be reflective.

I’m taking a little bit of that time. I’m lucky that I work for a caring company that appreciates that need. And there’s still a bit of me that feels guilty, that I might be “letting the team down”.

Anyway, I made this week’s post deliberately short - and in part that’s supposed to be a reminder that it’s OK to slow down and tend to all parts of life, not just the deliverables!

If you’re reading this and carrying something heavy yourself - you don’t need to justify the weight of it. It doesn’t need to be turned into anything other than what it is. I hope that you have the space to stop, briefly, and have that pause be the most functional thing you can do.

Article cover image by mali desha on Unsplash

And the name has always been kinda iffy. It undersells the work involved, and muddies expectations about what the output is. The foundations are still essential, but we’re wrapping them in a scope that doesn’t match their role - especially as AI reshapes how we build products.

The containing terminology we’ve used to describe our work no longer fits what the work has become.

It’s always been a bad name

It’s been a fairly consistent undercurrent in conversations I’ve had for years. “Design systems” is not a great term.

We place “design” front and center, even though the primary consumers are often engineers. It implies visual polish rather than deep production infrastructure. It suggests a static system, not a set of evolving, critical decisions. And that doesn’t reflect all the complex labor involved - and the value delivered.

Teams have learned to work around this. Translate and explain in order to justify.

We lived with it when the system’s job was primarily standardizing UI. It’s increasingly becoming a liability when the outputs aren’t mediated solely by humans. Less exhaustive reviews, a partnership with AI quality assurance.

Design systems solved yesterday’s scaling problem

Design systems emerged to solve very real issues:

• Fragmented interfaces

• Repeated implementation work

• Fractured user experiences with inconsistent behavior

• Design and engineering drifting apart

We provided a shared foundation: components, tokens, patterns, documentation. We built upon (or created) a shared brand language that teams could rely on as their organizations scaled.

That work still matters - more than ever. But the environment those systems operate in is changing, and our definitions aren’t keeping up.

AI doesn’t consume components - it consumes context

We’re starting to talk about AI using design systems as inputs: feed the model components, tokens, guidelines, and generate output.

That’s incomplete framing.

AI doesn’t effectively recognize and implement components in isolation. What AI consumes - and amplifies - is context.

• Which decisions are encouraged, and which are merely permitted

• Where the system is strict and where flexibility is encouraged

• How to handle accessibility tradeoffs

• Which interaction patterns are preferred - and why

• Tone and voice changes in different moments

• Understand historical exceptions and justifications

This isn’t context that is cleanly surfaced in a component library. It lives all around it - in our documentation, in related guidelines, Slack discussions, and decisions that we forgot to codify.

People are better at surviving ambiguity than machines, so it was survivable when we were the only bottleneck.

But now we have machines producing at scale, that doesn’t work any more.

The risk of accelerated drift

If we don’t have strong product context, AI creates divergence rather than coherence.

• Prompts are local decisions

• Outputs are reasonable in isolation

• Product drifts at scale quickly move from subtle to structural

We can kind of identify this through instinct. AI-generated UI feels superficially correct, but we can sense that wrongness. AI follows the easily visible rules and misses the invisible constraints.

Design systems aren’t about how things look, they’re about how we propagate our decisions.

Product context is broader than we’ve allowed systems to be

If a design system is the central foundation, product context is the structure that’s built upon and around it.

Product context includes:

• Visual and technical foundations (tokens, components, layouts)

• Interaction models and behavioral patterns

• Our content principles, tone and voice, language constraints

• Accessibility decisions and requirements

• Governance and review expectations

• Regulatory boundaries and corporate risk tolerance

• Historical precedent - especially about why exceptions exist

This context is still usually pretty fragmented. Owned by different teams. Sometimes something that’s a universal reference external to the company. Uneven documentation, and enforced socially.

AI reduces the margin for error that that fragmentation brings.

A role shift not a repudiation

So this is where the work begins to change.

In AI digital delivery pipelines, the most valuable contribution isn’t another component (I’d argue that’s been the case even before AI acceleration!). It’s making explicit context implicit and operational.

And that reframes the roles and responsibilities of design system teams.

• Maintain intent, not artifacts

• Define boundaries, not enforce consistency

• Usable, machine-readable context, as much as human documentation

It’s less about expanding control as it is about expanding clarity.

AI needs better constraints, not more pixels.

The scope failed, not the name

My title is sharp, because I want to drive to a pragmatic conclusion.

Design systems aren’t obsolete. They’re foundational. But you create a foundation to support something larger.

We can’t continue to conflate design systems as component libraries. If we do, we’ll underinvest in the context that AI needs to strengthen our products. Instead, it might erode them.

Our work has grown. Our responsibility has expanded.

The opportunity is bigger than the name we’ve been using.

Product context is the work.

Further reading:

• Opperman, L. Design Systems vs. AI: will the robots take over? Medium, Jan 2024.

• Teich, D. “The Alignment Problem”, Linking Machine Learning And Human Values Forbes, Oct 2020.

For more than a decade, I’ve worked on design systems at scale.

Large organizations, building global products. Leading systems that supported thousands of contributors and potentially millions of users. And systems that - by most external measures - would be considered very successful.

Despite this, at a certain point, I hit a ceiling.

Not because there wasn’t anything left to learn. Design systems are always evolving and always interesting. But there’s a quiet glass ceiling in this space - one that’s rarely acknowledged.

Design systems are critical infrastructure. But the people who build and run them can often get stuck in a professional limbo: deeply technical, strategic, and yet not seen as design or product leaders in the traditional sense. If you don’t come from a formal design background, and maybe even if you do, there’s a limit to how far “design system expertise” alone will carry you - no matter the scale or impact of your work.

It’s not a talent ceiling. It’s about how organizations understand design systems.

Enterprises still treat design systems as design artifacts: component libraries, documentation sites, visual standards. All important - but really those are just the supporting actors. When a system works well, it fades into the background. No drama. Fewer problems.

And that invisibility is both the point, and a trap.

In reality, design systems aren’t about components. They exist to facilitate production.

That means reducing decision fatigue. They encode our standards, and lower risk. They let organizations scale digital work without scaling chaos at the same rate! They sit at the intersection of design, engineering, governance, accessibility, brand, and business constraints.

Design systems are better thought of as production infrastructure. But that isn’t how we talk about them.

This perspective didn’t emerge in isolation.

While I was building a design system consultancy offering at IBM iX, we partnered with Knapsack on a client project. It was an opportunity to view - and stress-test - their thinking inside the realities of complex enterprise engagements. I spoke at their events. I appeared on the Design Systems Podcast. I’ve watched how the company has shown up - not just what it was shipping, but how it spoke about the work.

They had a clarity to their point of view: that design systems weren’t just a design concern, and that tooling along wasn’t a solution to underlying production problems. They understood that there was an organizational gravity at play, where systems broke down during the process.

And most importantly, I trusted their leadership.

Not because they were promising easy wins or tidy narratives. But because Chris Strahl, Evan Lovely, everyone in leadership at the company, were honest about the complexity of the problem - and committed to engaging with it.

My personal inflection point coincided with a broader inflection point for industry.

AI shouldn’t just make existing workflows faster. It destabilizes them. It undermines the idea of design-to-developer handoff, or that systems are consumed only by humans. If we can increasingly automate production, the question is broader: "what are we encoding into the machinery of production?”

If design systems remain static artifacts, they’re going to become irrelevant. If they evolve into a broader product context - structured, computable sources of truth - they can become exponentially more powerful.

Knapsack understands that. Not as a feature roadmap, but as a worldview.

They - and now it’s we - don’t see design systems as a destination. We see them as inputs. Raw material for production. Something that will directly power how products are built - whether by humans, machines, most likely by both together.

That distinction matters.

I could have stayed in senior design system leadership roles inside large organizations. Those paths were open. It would have been comfortable and understandable.

But I can see where that road ends.

I’m looking toward my second year at Knapsack, and this feels like a reaffirmation rather than a retrospective. Reminding myself - and trying to explain - why I chose leverage over comfort, and long-term change over incremental optimization.

I didn’t join Knapsack to leave the enterprise world behind. I’m taking what I learned there and applying it at a point of real leverage. It’s shaping the future of digital product delivery, not by accelerating yesterday’s workflows, but by challenging the assumptions behind them.

Joining Knapsack was the evolution of a relationship already built on trust, shared understanding, and a belief that design systems can and must evolve into something far more than they’ve been before.

I didn’t join Knapsack to make design systems better. I joined to redefine how digital products get made.

This principle is closely related. But it’s not about usability. It’s about success at an organizational level. And how to avoid the temptation of deliberately raising a system’s visibility once it starts to work well.

Performative success

If you’re part of a team that works on a mature, successful system, you won’t be surprised to hear that those systems are often undervalued. There’s no drama, there’s no need for constant attention. They’re ticking along just fine.

There’s a temptation to compensate.

We publish adoption reports. A quarterly report. Maybe a newsletter. Roadmaps and presentations that celebrate the system itself more than what it’s enabling. And that visibility risks becoming the proxy for value.

It’s completely understandable. We’re all very aware that many organizations overlook the systems that work best. “We’ve got our design system, we don’t need to keep funding the design system at the same level.” It’s a genuine risk. Visibility can be more legible to leadership.

But it also risks drift, and risks the system being more about theatre than infrastructure.

Quiet systems, loud outcomes

The strongest signal of a system working isn’t that teams talk about it - it’s that people talk about what they built with it.

We want to hear things like:

• “That was easier than we’d expected”

• “We shipped faster than we thought”

• “Everything just kind of worked”

Nobody is mentioning the system by name. That’s a sign of success, not a failure of visibility.

Measure outcomes, not attention

This is uncomfortable, because it’s often cited as the core metric in system-building work.

Adoption is a vanity metric.

Adoption tells you people are touching the system - not that the system is helping them do better work. But it’s easy to count, and it can protect funding.

High adoption can coexist with frustration, workarounds, and quiet resentment. A forced mandate that pisses teams off as much as it helps them.

Low explicit adoption can coexist with deep impact. Using the values and principles of a system can often be overlooked or unmeasurable.

That’s not to say that we shouldn’t measure metrics, but we should be looking for the right signals.

• Reduced time to ship

• Less rework

• Fewer handoffs or repeat iterations

• Faster onboarding

• More consistent outcomes

Not to flatter the system, but to validate it.

The best systems don’t compete for recognition. They’re there to create the conditions for everyone else to succeed.

Doing its job quietly

There’s a particular sense of quiet satisfaction in building something and then stepping back. Letting it fade into the background from a visibility perspective, and letting the work that it facilitates speak for itself.

It’s also really hard to do. Because we’re proud of the systems we built. And we want to nurture them, and protect them.

But if what you’ve built is really getting people to the thing then the most generous and powerful move is to stop standing in front of it waving your arms for attention.

If it’s entrenched and unnoticeable, you’ve probably done it right.

Further reading

• Bell, Sarah, et al. ‘Invisible’ infrastructure is the background to our modern lives. Pursuit, June 2023.

This is the final part of a six-part series on building in a way that serves real human outcomes.

But maybe a few years can change things. What happens if we throw AI into the mix?

We don’t need a team to review all those product surfaces for design system alignment and adherence. We have a tool that can do it in real time. At scale. Across legacy and in-flight work. UI, language, accessibility, interaction patterns - it’s all in reach. Our oversight can be embedded, ambient, and always-on.

If we use this carelessly, then it’s going to become exactly what I warned against.

A surveillance system. A source of shame. A way to more easily flag exceptions and punish your drift.

The design systems police are there - and now they have a perfect memory and they never go to sleep.

But there is another way to look at it.

Can we make AI a guide instead of a gatekeeper?

Something that says:

• Want a suggestion to make this feel more like us?

• Do you want to see how other people solved this with the patterns available?

• Can I help to make this better?

We’ve still got a panopticon. But not for control, it’s for possibility.

I gave a nod to this before, in “When AI can do everything else, your job is to make it good.”

If we can pass over our auditing to AI, then we can free people up to handle the intent. Let AI support the consistency, then we have space to explore.

Our panopticon becomes one that’s about clarity.

And it starts to drive our momentum. We’ve got access to an always-on suggestion engine. The watcher that helps us move faster - not because it says “no”, but because it’s always whispering:

“Yes, and…”

Further reading

• Steadman, P. Samuel Bentham’s Panopticon. Journal of Bentham Studies, 2012.

• Mirowski, P. et al. Artificial Intelligence Improvisation. Improbiotics, ~2021.

And it’s new, powerful, and it presents as a little bit magical. So it gets treated as the centerpiece, the point of things. AI is the headline.

But (and you may have heard this already in this series!), AI is just another thing that gets us to the thing.

In this fifth part of the series, I’m focusing on the role AI should play in systems: not being a controller, but by being a translator. Something that’s getting better and better at turning human intention into motion.

When AI is a controller, it constrains us.

When AI is a translator, it amplifies our intent.

From “what I mean” to “what happens”

Most work involves translation. And that usually includes multiple iterations to ensure those translations are accurate.

intent → articulation → structure → execution

AI has immense value in its capacity to compress those stages (even to the point of collapse or their elimination as a specific step in design and delivery).

• Describe a flow, and see it appear.

• Sketch an idea - in images or in prose, and see the scaffolding form.

• Outline a page, see a worthwhile draft arrive.

The human step isn’t eliminated here. In fact it remains absolutely critical. But AI shortens the ramp between thought and action. As the slogan at Knapsack says:

Think it. Ship it.

Think about when AI actually feels magic. It’s when you’re communicating directly with the system in your own language - not needing to use special syntax, no ceremonies, no need for intermediate tooling.

Let it learn your dialect, and make suggestions

A translator proposes.

If you lean too hard on AI then it automates the decision making process - in a way that’s brittle. And if AI isn’t grounded in how your teams think, build, and speak, then it’ll become generic. Detached from your lived reality.

A translator knows the dialect. And the goal isn’t to hand the work to the AI, it’s to let AI support the work that’s already moving forward.

Good AI-supported systems:

• Offer a starting point rather than jumping straight to a conclusion

• Ask clarifying questions to call out ambiguous intent

• Provide options, not a prescriptive solution

AI speed combined with human excellence means widening the available paths, not narrowing them.

I’m sure we’ll see AI flatten many organizations into something average. AI is getting fairly capable at getting things to “OK-ish”.

But used well, it should raise the floor and the ceiling using intuition that you’ve already codified - your dialect.

(This is why Part 4 - codifying intuition - comes before this one)

Conversation, not command

I think this is one of the biggest misconceptions around AI today - and where much of the fear comes from.

The value of AI comes from interaction, not one-off prompts. Single instructions can’t capture complex intentions - that’s where we get “AI slop”. But a conversation can refine those intentions.

Translators let people correct, redirect, reinterpret, push back, encourage critique. And, perhaps more importantly, they let people take over.

AI gives the path structure, but the person stays in the loop as the owner, shaping and validating.

Here’s a simple test for whether AI is “good”.

Does it remove friction while preserving agency?

If your answer is yes, then it probably belongs there. If it’s quietly centralizing decision-making in a model nobody understands, you’ve got a problem.

AI should exist to empower humans

A healthy AI supported system increases the capability of the people who interact with it.

People get more space to think. And they can use that space, and the AI support:

• Focus on the most meaningful parts of the work

• Clear away repetition

• Reduce the cognitive challenge of starting from a blank page

• Accelerate - and thus encourage - greater exploration before committing

And it should be additive. If the system can’t function without the AI then you’ve created a dependency, not a capability.

AI is a multiplier of human judgment, not a replacement for it. And the more “the thing” comes into view, the more the AI should fade into the background.

Further reading

• Halleck, Quinn. “Does Film Survive AI?” (YouTube). TEDx Talks, 2024

• Wang, Ge. Humans in the Loop: The Design of Interactive AI Systems. Stanford University, October 2019.

Part 5 in a six-part series on building in a way that serves real human outcomes.

Part 6 will be published in two weeks.

Good systems don’t override that intuition.

Instead, they try to capture it, scale it, make it available to more people, without getting in the way.

That’s the fourth principle in our series. Part 3 was about making our system vanish. Part 4 is about making the shared knowledge - institutional understanding - visible. Quietly, and usefully.

Encode what already works

The best systems aren’t the ones that are invented from scratch. They’re the ones distilling the best of what teams are already doing successfully, and building on that.

That means noticing the patterns that show up again and again, giving them a stamp of approval, and making them more easily available.

• Layouts that reliably communicate hierarchy

• Writing that demonstrably reduces back-and-forth questions

• Coding practices that reduce recurring bugs

• The workflows that ship more consistently on time.

Codifying intuition means you’re not the one creating the rules - it’s the capture of behavior that already produces good outcomes. Not only giving others access to those behaviors, but giving rigor and metrics to them, too.

Defaults, not rules

When building systems, the best way to get adoption is to make adoption the path of least resistance. Codifying intuition supports that by making sure that people have a better starting point.

Opinionated defaults can making doing the right thing the easiest thing to do. They:

• Reduce cognitive load

• Help new contributors, and support their growing effectiveness

• Provide consistent quality without artificially enforcing uniformity

• Are flexible enough to override when it’s justifiable to do so

These defaults are your scaffolding - light, helpful, and removable. It’s about supporting success, rather than forcing compliance.

“If you build it, they will come…”

Strange how lines from old movies can stick with you. In Field of Dreams this whispered mantra was a little more mystical than we’re talking about. But ultimately it was about creating a place that people wanted to come to.

A system becomes frustrating - often to the point of failure - when it demands a particular behavior instead of merely providing support. People might comply in public, but work around it in private (this is why top-down mandates aren’t ever enough by themselves). Intuition can become accepted ceremony.

Better systems surface guidance that happens in the moment:

• Snippets that are clear and visible when you begin using a component

• Panels that offer context only when it’s relevant

• Automation suggesting steps forward rather than blocking actions

If your system is behaving like your partner and not your supervisor, you’re more likely to trust it, and to use it naturally. This “partnership” model is one of the reasons why I think AI and product design and delivery systems are a naturally beneficial pair - LLMs, with context, can lend themselves to this sense of working together.

Keeping the spirit of the law

A common mistake here is to document the expression of intuition and think that successfully captures its true essence.

Someone does something clever because it works. It gets documented. It gets formalized. It gets followed.

It still gets followed even when everyone has forgotten why it existed in the first place.

The codification of intuition needs to include the reasoning, not just the ritual steps. If we lose a record of the why, then the system can start to become brittle.

Intuition means adaptation

Any system that is codifying intuition needs to be adaptive. Intuition, by its nature, will flex and change over time as circumstances do.

That means leaning into:

• Local variation

• Overrides and escapes

• Flexible boundaries

• Places where the work is shaping the system, not the other way around

This is an important measure that should be monitored. The intuition itself can flex. But if you need to regularly break your system to do any good work, then the system is constraining intuition rather than effectively capturing it.

Shared intuition is acceleration

We want to make collective experience part of our natural infrastructure. If we do that, everything can move faster. New joiners ramp quickly and naturally, even though senior contributors also spend less time explaining. Teams don’t need to reinvent solutions that already work.

Quality becomes consistent because we’re working within the boundaries of a system that guides people towards that quality, rather than because it artificially enforces it.

Codifying intuition isn’t about perfection, or achieving uniformity. Velocity is much more important than perfection.

Then the thing that gets you to the thing becomes easier for people to trust, easier to use, and easier to build with.

Further reading:

• Kohlstedt, Kurt. Least Resistance: How Desire Paths can Lead to Better Design. 99invisible, Jan 2016.

• Polanyi, Michael. The Tacit Dimension. Chicago University Press, 2009 (orig. 1966)

Part 4 in a six-part series on building in a way that serves real human outcomes.

Part 5 will be published in two weeks.

But that’s a collapsing model now. We don’t have a linear process - canvas to code. We have a more continuous loop. We’d already started that process through the expansion of design systems and other orchestration platforms. But now AI interpreters can take structured design input from those resources and generate interfaces that are visually and functionally coherent. The canvas might still exist, but it’s no longer right at the center of the work. We had a handoff layer that defined digital product delivery, but now it’s dissolving.

That digital workflow isn’t ending because design has stopped mattering. It’s ending because design has become the vital infrastructure itself.

The canvas wasn’t the work

The canvas was an abstraction. It was a simulation of something that would eventually be built somewhere else. It existed because design and engineering spoke different languages. Designers made intent visible. Developers then translated that intent into working structure and logic. And we repeated the ritual handoff in order to reconcile two worlds that couldn’t speak to each other fluently.

The more those systems have matured, the more that separation is artificial. Tokens, semantic components, structured data, give us a shared language and more robust guidance. A well defined design system doesn’t need to be redrawn in code - it is code - and it can be read as such.

That’s not the death of the canvas. It’s time for an evolution. A non-abstracted canvas that’s connected directly to live systems, is invaluable. We’re human - we still think in terms of visual representation in order to think, collaborate, and refine our ideas. But that means a canvas has to be an actual truth - the real thing - and not a pretense. The abstraction is what needs to die.

We don’t need fewer canvases. We need more honest ones.

Figma’s fight to preserve the fiction

And this is where things might start to get uncomfortable. Figma - much-loved, brilliant, ubiquitous - has built an empire on making a canvas abstraction more accessible and easier to use. Modern product teams use it because it allows design to feel close to reality without ever being real. That was Figma’s superpower.

But now we live in a world where systems that underly design and code can interact directly. Which makes the abstraction less necessary. Which is a threat - to Figma’s business model, not to design itself.

It’s not surprising that Figma’s AI strategy seems focused on reinforcing the centrality of its own canvas. Auto-generated design screens (which then need to be “auto-generated” again into code), AI-driven component suggestions, natural language layout tools - they’re building features to keep you inside Figma.

These are impressive capabilities. But they also serve Figma’s strategic purpose - encourage designers to do more within Figma rather than reach out to collaborate directly with the systems that actually deliver products.

I don’t believe that’s malice. It’s just sensible economics. Figma’s success depends on it remaining the hub of the workflow. But what workflow? As AI and structured design systems collapse the distance between design intent and delivery reality, the workflow itself is evaporating.

We’re not working in a future where working faster within the canvas is the vital factor. It’s about questioning whether we need the canvas at all for much of the work we currently do there.

AI is collapsing the middle layer

AI doesn’t - despite the fears - replace designers or developers. It replaces the abstraction between them. It can interpret structure and make translation unnecessary. We feed design tokens, behavior definitions, rules and guidance into a working interface through orchestration systems.

The value of design isn’t in the mockup - it’s in the metadata, and it’s in the final thing. The design system is design. What was in static screens is in structured definitions - which means it can be interpreted, reasoned, and improved by machines as well as humans.

That can be liberating. It disappears the rote work - redrawing, aligning, re-specifying. Human creativity can switch to the areas it’s most valuable: judgement, craft, and care.

My colleague Carly Stevens said recently that, done well, AI “can free designers to do the jobs they were actually hired for”.

The automation of the mechanical layers doesn’t erase design. It brings it home to its true purpose.

Design is structured input, not static output

The act of defining patterns, constraints, and relationships isn’t pre-delivery work - it is the delivery. Structured systems turn these definitions into executable outcomes.

Design isn’t a set of abstracts handed off to be interpreted. It’s the structured language embedded in the delivery process. The different between “the design” and “the product” becomes semantic. The expression of intent is the same as what’s used to create reality.

This makes design more human. The sense of what’s good instead of just correct is where human excellence will continue to thrive.

Designers will be working after automation. Curating, adjusting, improving what AI systems produce. They’ll guide the system - working as stewards to ensure that what’s delivered is crafted, coherent, and feels alive.

A new creative edge for developers

Developers aren’t losing ground here, either.

When the system can handle assembly, developers get more time to focus on architecture. That means authoring the meta-systems: rules, boundaries and logic that govern AI’s interpretation and execution of design.

It’s not thinking “how do I build that screen from that design?” - the question now is “how do I build the platform to make a thousand screens possible?” It’s a different scale of artistry, and the future of engineering excellence.

Intelligent delivery elevates human roles, rather than necessarily eliminating them. Designers and developers can be genuine co-authors and co-creators of their ecosystem.

What’s next?

The end of the digital workflow shouldn’t mean chaos. It should mean more continuity.

The canvas will be a live view into the reality of the system, not a staging ground for ideas that sit outside it. Delivery needs to become intelligent, contextual, and collaborative.

To thrive here:

• Build structured systems. Resources and guidance legible to humans and machines.

• Connect canvas to code. Design tools need to be interfaces for living systems, not static artifacts.

• Focus on human excellence. Automation can get you to “good” (well, maybe “ok”) faster. Invest human judgement into making it great.

• Question your tools. If any platform’s roadmap is pulling you deeper into its own walls, ask who benefits most from that dependence.

The digital workflow that we’ve known was a bridge between silos. But the silos are disappearing. We don’t have product pipelines, we have shared environments of systems and craft.

Design isn’t a stage before delivery.

Design is delivery.

Further reading

• Figma’s Q3, recently LinkedIn post, Nov 2025.

When something actually matches the way people already think and act, it starts to fade into the background. Nobody has to say, “I’m using the sytem.” They’re just doing the work system was supposed to enable in the first place.

The quiet success

We like to celebrate launches. Demos. Dashboards. Looking at adoption curves. Common workplace rituals. But the quiet success of a system isn’t in how many people are talking about it. It’s how little they have to.

Success is when people stop noticing it’s there at all.

Just do the thing

Every release you make to a tool or piece of infrastructure, every update, should make it feel less like “using software”. We want to make it feel like “doing the thing.”

That means:

• Fewer steps from intent to outcome.

• Less translation between though and action.

• Immediacy between what someone thinks and what actually happens.

When you reduce friction, you make the system smaller and the work bigger. That’s the direction you always want to be moving.

When the system intrudes

It’s fairly obvious when a system has too much of a presence:

• People are asking, “how do I use it?” and not “what can I do with it?”

• Teams talk about the process more than they talk about the output.

• Success is about compliance, not delivery.

• The ritual exists - tickets, status updates, checkboxes - without making progress.

The problem is that’s not structure or culture. It’s just bureaucracy disguised as enablement.

Absorb, don’t instruct

The greatest of systems feel like intuition. They don’t need onboarding decks, mandatory training - you learn through doing. They’re a mirror to how people already think and work.

Start looking, and you’ll start to see this principle everywhere:

• Docs begin to emerge naturally from the work.

• Slack bots surface what’s next when it’s needed.

• GitHub Copilot fills in behind you while you focus on logic.

• A design system isn’t something you adopt - it’s just how we build things here.

It’s not magic. It’s empathy. Designing for active fluency, not academic literacy.

Invisibility

You’re closer to success when:

• New team members learn by watching and doing, not reading.

• Every sprint has fewer “how do I…?” questions than the last.

• You hear “this was easy,” not “I finally figured it out.”

• Nobody discusses the system in retros.

Invisibility isn’t the same as absence. It means that you’ve got a took or system that’s so well aligned with your intent that it’s becoming unspoken.

The direction, not the destination

Look, you’re never going to make these systems completely invisible. That’s fine. It’s about having a goal to continually reduce its footprint - keep shifting everyone’s energy away from using the system toward doing the thing.

The first moment that people outright forget they’re “using” something, that’s when it’s finally doing its job.

Further reading:

• The thing that gets you to the thing - why the tool isn’t the point

• Krug, Steve. Don’t Make Me Think, Revisited. New Riders, 2014.

Part 3 in a six-part series on building in a way that serves real human outcomes.

Part 4 will be published in two weeks.

But a system that exists for its own sake, no matter how polished it is, is just a black hole. Drawing in time, attention, energy, resources…without any clear proportional value.

Goal collapse

If you don’t have a goal, that means there’s no definition of what the work is for. Which means the work itself starts masquerading as the reason for the work.

• “We need a design system,” rather than what the design system enables.

• “We’re implementing AI,” should be a project, not an outcome.

This is goal collapse. Infrastructure becomes the obsession, and eventually you’ll reach a point where you’re building somebody and genuinely nobody remembers why.

Honor desire paths

People already know how they work best. So if you come barreling in with something that breaks their natural flow, you create resistance. Or maybe even worse, surface compliance while they ignore you and work around things in the background.

So instead of asking “how should everyone work?”, perhaps start by asking “how does everyone work today?”

That includes the hacks and workarounds, hidden docs, side Slack conversations, team-specific shared templates. Those should be a starting point to build from, not an obstacle to destroy.

Don’t break desire paths, build on them.

It’s a tool, not a temple

You’re not building a monument to how great you are. You’re building a wrench for someone else to use.

That means creating something that people will use, not something that people will stand back and admire from afar.

If there’s any sense that the system you built is “sacred”, fragile, forced…then it probably isn’t doing what it’s supposed to do. The best systems are probably a little bit messy, a little bit lived-in, which makes them comfortable.

Systems are for people, not the reverse

People who do the work should have the capacity to shape the system. Not just through giving their feedback, but by how we observe their behavior and adjust.

• Watch how teams successfully ship things.

• Identify and realize that’s slowing them down.

• Build what actually addresses that friction.

• Let parts of the system stay informal and flexible, if the work demands.

A rigid, top-down system looks efficient on paper. I’ve seen design system teams in particular fall into this ivory tower trap many times - even with the best of intentions. It fails when reality intrudes.

Would you build it if nobody saw it?

If there was no deck for you to present what you were launching. No internal applause. If there was no roadmap to celebrate “we did the thing”…

Would it still be worth it?

If the answer is yes - it enables better work and smoother delivery, shipping things faster - build it.

If the answer is no - then maybe you don’t need to build it at all.

Further reading:

• Three Common Problems in Enterprise System User Experience. IxDF, Feb 2016.

• The design system purity trap - Life isn’t tidy - why design systems fail by chasing neatness instead of reality.

Part 2 in a six-part series on building in a way that serves real human outcomes.

Part 3 will be published in two weeks.

Start with what it enables for someone.

If you’re not doing that, then you’re just assembling parts in a vacuum.

That applies whether you’re talking about a design system, a new service, implementing AI tooling, or shipping a working feature to a consumer product. If you can’t say who it helps, how it helps them, what it makes possible that wasn’t possible before…it probably won’t stick. It won’t matter how elegant the architecture is, how impressive the technical implementation.

It’s the first principle in our series on building systems and tools that serve human goals. It’s the foundation we build our other principles on.

What changes because this exists?

Here are questions to ask before you write code, name components, or integrate AI.

• What should people be able to do that they couldn’t do before?

• What will it make easier, faster, or more consistent?

• What friction does this remove?

• What outcome does this unlock?

Crucially, who benefits from this, and how will they feel that benefit?

If we skip this step, we create things that feel important simply because we’re working on them! That’s seductive to the builders, irrelevant to the people they’re ultimately being built for.

Our focus is NOT “what are we building?”

It sounds like semantics, but it’s not. Our focus is:

What is made possible when this thing exists?

You’re not building a system. You’re creating the conditions for better outputs.

You’re not building a product. You’re helping someone do something better, faster, or more meaningfully.

You’re not building a pipeline. You’re giving a team confidence that their work will ship.

We start from outcomes. Everything else then flows with more clarity.

Try the “Who/What/Wow” model

I learned this framing at IBM, and it’s deceptively simple.

“This thing will allow [who] to do [what] in a way that [wows them].”

It forces clarity. It centers people on the purpose. It’s a great gut-check for if your work is valuable, or if it just exists. And the demand for a “wow” encourages us to push for real value, not just iterative utility.

Some adapted examples:

• “This AI product delivery tool helps product teams ship ten times faster than they did before.”

• “A recipe app lets a home chef order all the ingredients needed for a single delivery in a single transaction.”

The point isn’t exactly getting the syntax, so much as forcing intentionality.

Start your build with one sentence

Steve Wozniak was a proponent of simplicity, exploring problems he wanted to solve.

Start with one sentence that says what this does, what it enables.

You can validate, build, explain, and iterate. Create your five-page strategy document from that first sentence.

Systems, tools, AI flows, finished products, all benefit from this grounding. If you can’t say what they enable then:

• You won’t know if it worked.

• Your users won’t feel the value.

• Your team won’t know if it mattered.

The thing that gets you to the thing needs a reason to exist. You should start that reason here.

Further reading:

• Mochari, Ilan, 2 Lessons From Steve Wozniak’s Early Creative Experiments. Inc, May 2014.

Part 1 in a six-part series on building in a way that serves real human outcomes.

Part 2 will be published in two weeks.

If you work on a design system, you don’t need to be an AI expert. But it will make a huge difference to show that you can work with it. Staying relevant isn’t necessarily mastery, it’s about readiness.

1. Build your prompt library

The clearer your instructions, the better AI will work. Don’t start from scratch every time, collect the prompts that deliver useful output; generating test cases, summarizing breaking changes, scaffolding new component code. Reuse them, refine them, share them with your team. Maybe even version them.

You might think of prompts like design tokens. Consistent, reusable, and of increasing value the more they’re shared.

2. Run AI on your own work

Don’t wait to be told how to use AI “right”. You can start with your own output. Run pull requests through AI for accessibility flags. Or ask for a simplified version of documentation before it’s time to ship. It’ll be a good way to understand where AI can add more clarity, and when it might struggle.

Treat AI like an extra reviewer, not an oracle.

3. Automate the most boring stuff

Every person, every team, has tasks that eat time without adding much value. Format changelogs, drafting migration notes. Why not let AI take that sting out of the last 10%. Find a task, automate it, and share the results.

Show your team that you’re not just experimenting, you’re using your results to make everyone’s life easier.

4. Track the pitfalls

AI isn’t a magic fix-all. It hallucinates, writes inaccessible code, and can product misleading or tone-deaf copy. Keep logs of where it fails for you - snippets and examples. Then you’re positioning yourself not just as a cheerleader, but someone who understands limits, too.

When you suggest adopting AI in a workflow, you’ll know when it can and can’t be trusted.

5. Talk about AI in your standup

AI exploration isn’t a secret side project.

Share what you tried to do, talk about it with your team. “I asked AI to draft our migration docs, but I still had to fix the accessibility notes.”

It isn’t about branding yourself as the AI person, but being open about experiments that you’re leaning into.

6. Celebrate your wins

It’s easy to worry about AI use being seen as “cheating”. If an AI assistant helped you find a bug faster or draft docs that shipped…celebrate it.

Accelerated work with AI is still your work. You shaped the input, you judged the output, and you made the call. The more you can celebrate those successes, the easier it gets for the whole team to embrace AI.

Final takeaway

Getting AI ready isn’t about being a master of the future. You’re showing today that you can use the tools, filter out the noise, and celebrate the successes. Help your team move faster without losing trust.

The thing is what people do, make, discover, or become…once the system itself fades away into the background.

This piece is a follow up. A little more of a practical guide. That previous piece was about why we build. This is about how.

1. Start with what it enables

You’re not building something if you don’t know what it enables. You’re just assembling parts in a vacuum and hoping they come together as a product or a system.

Good systems begin with a clear sense of what the desired outcome is, the problem that you’re solving.

• What should people be able to do that they couldn’t do before?

• What will be easier, faster, and more consistent to do?

• Who benefits from this…and how?

When you start designing something, start with a sentence of intent.

When I was at IBM, we used a “who, what, wow” model.

“This system will allow [who] to [do what] in a way that [wows them].”

2. Don’t build a thing to have a thing

Nobody builds a design system for the sake of having a design system. We build design systems to enable people to do better work. That same logic applies to everything from AI integration to internal documentation.

So if your goal is “to implement AI” or “stand up a new system,” then you’ve already missed the point.

And if the system you build doesn’t reflect real behavior, not an idealized way of working, then you’re building something that looks right instead of being actually fit for purpose. Systems should honor desire paths, not try to break them.

3. Make the system vanish

The best systems are invisible. They disappear. Not in a literal sense, but they recede from being the center of attention. If people talk about the system, more than what they built with it, then there’s probably something wrong.

I’m not talking about lack of adoption. In fact, it’s the point at which adoption is so natural, because the system has become infrastructure. Think of it like electricity - we don’t think often about “using electricity”, it’s infrastructure to our lives.

In a system that’s working, you should be able to do things like:

• Create something useful without fully knowing how the system works.

• Be able to move from expressing your goal in natural language to starting to build.

• Take action without needing to translate between your intent and the system interface.

4. Codify your intuition

Really good systems are the ones that encode what works so that other people don’t have to guess. The best ones do that and also support improvisation.

In practice that means:

• Safe defaults, but adjustable.

• Documented practices that are governed, not enforced.

• The kind of guidance that surfaces before someone asks the question.

If a system starts to represent the shared intuition, and scales it, you’re helping people get the best possible start.

5. AI is a translator, not a controller

The promise of AI in all this isn’t just automating it for automation’s sake. We want to use it to translate. To help us turn our raw intent into structured output.

A good AI-supported system doesn’t try to replace creativity. It wants to accelerate it.

• Turn sketches into code.

• Turn briefs into outlines.

• Turn documentation into conversation.

At its best, we should be thinking of AI as a helpful translator between human intent and a digital structure.

6. You’re doing it right if nobody talks about it

You’ve built the right thing when people stop noticing it. When teams just get on with the work; moving faster, asking fewer questions.

The thing that gets you to the thing? It doesn’t need applause, it really just needs to work.

So when you do it right, people spend less time learning, and more time building what matters.

Over the coming weeks, I plan to expand on each of these six ideas in more detail. Breaking down the practical and messy work of building systems that serve people. One of these principles per post, using real examples and honest pitfalls (including cautionary tales from my own mistakes!). Maybe even a checklist or two.

The thing that gets you to the thing? It’s not just a philosophy. It needs a blueprint.