Speaking Design at Scale
I work on design systems at a big company. Much of the job is making sure the product still feels like one product when different teams build different parts of it. You Don’t Have a Design System was about the decisions a system has to capture: recurring decisions about structure and behavior, not just components. This is about how those decisions reach the next builder.
Names make that handoff possible. Overview, PageHeader, and SettingsFrame are not merely labels for components. They are shorthand for decisions the team should not have to reopen in every planning meeting, design review, or implementation loop. The documentation for each pattern should say what problem it solves, what rules it follows, and when not to use it.
For a person, fluency in this shorthand language is expensive. You acquire it through repetition: seeing the components, learning the exceptions, remembering why a certain page has a particular shape. That keeps the language concentrated among the people closest to the system.
An agent has a different advantage. Give it access to the repository and it can inspect the implementation behind the vocabulary, the guidance beside it, and examples of the pattern in use. A name alone only tells it where to look. The rationale tells it why the pattern exists, when it fits, and when it does not. As the pattern appears across the product, the agent has more evidence for how it is meant to work. It does not magically have taste, but it can retrieve the precedents and constraints that would otherwise take a new collaborator months to accumulate. That makes it a useful translator between someone describing a screen and the system that already knows how similar screens are built.
layout: row, , section, no action in the .
A shared vocabulary narrows the gap
Ordinary product language leaves too much open. Ask for “a page that lists firewall rules” and every listener pictures something slightly different. Then the team spends a meeting on decisions the system may have made already, or slowly arrives at a page it could have described from the start. AI shortens the path from a description to a screen. It still needs the system’s vocabulary to work from.
Marc is right. As the boundaries between PM, designer, and engineer blur, more people can make the product directly. A design system gives them a way to refer to decisions that already exist. An agent can work in that language before a person has learned all of it.
Imagine a PM asking for a projects page. They can describe the job without knowing every layout and component. The agent can inspect the available patterns and make a screen with them. Then the people involved can decide whether it serves the intended experience. The agent does the assembly. The team still makes the call.
Writing in a system's vocabulary takes experience. Recognizing whether a proposed pattern fits the product is a smaller, but still essential, job.
hey — PRD for the Projects page is ready. can we grab 30 min with design eng this week to figure out how we should build it?
asked the design system agent about the Projects page. it recommends the standard Overview layout: MetricCard row up top, a ChartCard under it, then a Table section for the projects (name, status, usage, plan), no action in the PageHeader. sound right?
Overview names a layout with a header, metrics, a chart, and a table. PageHeader can carry a rule about where primary actions belong. A Table section can establish its default columns. None of these rules is remarkable on its own. They matter because someone made the call once, gave it a name, and left it for the next builder.
Generate from the system
Once the system’s patterns have names, an agent can turn a short request into a screen. The shorthand points from a product request to the code behind it. Ask for Overview and the agent can find the code that makes up that layout. It can then use it to make a screen that stays, theoretically, within the system. If the request does not fit anything named, that gap is visible instead of buried in an improvised page.
Overview: MetricCard row, ChartCard, Table section.
Overview empty state: MetricCard row, EmptyState.
PageHeader, ChartCard, Table.
SettingsFrame: SettingRow group, DangerZone last.
SettingsFrame: ValidatedInput, SettingRow group.
PageHeader, EmptyState.
What agents make visible
Most people will never know a design system the way its maintainers do. They will not remember which page uses what, or why a pattern has the shape it does. They should not have to. The vocabulary is an interface to that knowledge.
Overview and SettingsFrame let someone name an intent without locating the files or remembering the rules. An agent can follow those names into the component, its documentation, and existing examples, then use what it finds to make a screen. Everyone else can spend their time deciding whether the result is right.
That is the useful version of speaking design. The system’s complexity is still there. The language gives people a way to address it.