Why Design Tools Are Not Design Systems
They are often spoken of together. They are not the same thing. The distinction matters more now than it ever has.
A design tool is software a designer uses. A design system is a shared set of decisions a team abides by. Conflating them has always been imprecise. In the age of AI agents, the imprecision becomes consequential.
For most of software history, the distinction was academic. The designer used a tool. The team built a system. The tool often housed the system. The conceptual lines blurred because the practical lines rarely mattered – a human was always in the loop, making judgment calls that smoothed the gaps between the two.
That human is no longer always there. Coding agents build interfaces at a scale and speed that makes per-decision human review impossible. In that world, the difference between a tool and a system is the difference between something that works when you hold it and something that works while you sleep.
What a design tool is
A design tool is software that enables a human designer to compose visual interfaces. Figma, Sketch, Adobe XD – these are tools. They are powerful, nuanced, and irreplaceable for human creative work. They amplify a designer's capability. They store and display design artifacts. Some of them, like Figma, have begun to incorporate systems-level features like shared component libraries and token management.
But at their core, they require human attention at every moment of use. They do not produce design decisions without a hand on the controls. Close the application, and design stops. The tool is a lever. It magnifies force. It does not generate it.
This is not a criticism. It is a description. Design tools are extraordinary at what they are designed to do. Their limit is not quality – it is dependency. They depend on the presence of a human who knows how to use them.
What a design system is
A design system is a shared agreement about design decisions. It defines which typefaces a product uses, which colors carry which meanings, which component patterns are canonical, which spacing rhythms are expected. It is a set of constraints that distributes consistency across a team without requiring a senior designer to review every output.
Design systems can live in tools – and often do. But the system itself is the agreement, not the artifact. A design system encoded only in Figma is still a tool-dependent artifact. A design system encoded in tokens, published as a package, referenced by engineers, and enforced in code review – that is infrastructure. It operates whether or not anyone has a design application open.
The difference is where the judgment lives. In a tool, judgment lives in the designer's hands. In a system, judgment is encoded and distributed. Anyone – or anything – that consumes the system inherits the decisions.
Why the distinction matters for AI agents
When a coding agent builds an interface, it needs a design system, not a design tool. It needs encoded decisions, not a canvas. The agent cannot "open Figma" – and even if it could navigate the interface, it would encounter the designer's artifacts, not the designer's judgment about how those artifacts should be applied to new contexts.
This is why the category distinction matters. A team that equips its agents with links to their Figma workspace has given them a tool they cannot use. A team that equips its agents with a published design system – tokens, documented patterns, enforceable constraints – has given them something they can actually build from.
And yet even a well-published design system has limits that become visible only in the agentic context. Understanding those limits is the subject of why design systems are not expression infrastructure.
The hierarchy, clearly stated
Design tools create design artifacts. Design systems encode design decisions. Expression infrastructure makes design judgment available as a runtime service.
Each category builds on the previous. Design systems could not exist without design tools to author the components they encode. Expression infrastructure could not exist without the vocabulary that design systems established. But each category is distinct, and each serves a different consumer: the tool serves the designer, the system serves the team, the infrastructure serves the agent.
Getting these categories right is not semantic housekeeping. It determines which investments actually solve the problem at hand. A team that wants its AI agents to build with taste does not need a better Figma workflow. It needs infrastructure.