Design systems exist to rein in unnecessary drift, but there is more than one way to bring order to the chaos.
One path is to enforce consistency through configuration, managing variation through long lists of toggles, variants, and props.
The industry is moving away from highly configurable components for good reason. When components control layout and content structure too tightly, they undermine good information design.
We saw this problem a few years ago in Shopify Polaris. Even with a wide range of components, the end result was that everything started to look the same.
Order previews, shipping profiles, and CSV importers each contained different information and required different actions. But instead of reflecting the meaning of their content, they all took on the shape of the component.
This was a problem because it increased the time that merchants needed to read the UI to form a mental model. In a complex enterprise product, all that reading compounds into wasted time.
Design systems should help designers find the right shape for information, not just drag components into predefined boxes.
Assembling is not shaping
Putting information inside components is not the same as shaping it to fit its meaning.
An assembled interface starts with the structure that’s available. The title goes in the header, the content in the body, and the actions in the footer. The component makes most of the compositional decisions before the designer does.
A shaped interface starts with the meaning of the information.
What does the user need to understand? Which relationships matter? Is there a form that makes the concept recognizable before anyone reads the labels?
Much of interface design comes down to familiar parts such as input fields. A from-to field pairing, for example, appears in my bank’s app, in Uniswap, and in Uber.
Now remove the text and focus only on the visual forms that remain. What do you see?
Uniswap turns its input pairing into a swap: two plates joined by a central hinge. Uber uses the familiar node-and-line language of maps to create a route. My bank’s interface is simply a white box divided by a gray line.
All three contain similar underlying controls. But only two give the relationship between those controls a recognizable form.
A configurable component API limits how much designers can shape information. This was the central problem with our Polaris Card and Modal components.
We wanted teams to shape information, so we moved toward a more composable Card API. The component became a flexible shell with open slots.
But composability only removes the predetermined outline. It doesn’t teach designers what to create in its place.
When teams make this switch, designers don’t automatically become more inventive. They may play it safe and reconstruct the familiar card manually. The component strategy changed, but the design language did not evolve with it.
Many design languages are really style guides. They define typography, color, spacing, shadows, illustrations, and icons, but say little about how to represent the concepts at the center of the product.
If you remove the opinions from container components while the design language still teaches people to place text and controls inside boxes, you will simply end up with more text and controls inside boxes.
Composability creates room to shape. A design language teaches teams what to shape toward.
Instead of treating a design language as a collection of visual rules, we should think of it as a tool for solving communication problems.
It can help to compare it to written language.
Written language has subject matter, vocabulary, grammar, emphasis, and voice. A product design language needs the same: a model of what it must communicate, recognizable visual signs, rules for composing them, ways to direct attention, and a distinct visual character.
A model for product design language
1. Product model: what the language needs to convey
Before defining the visual language, start with the shape of the product itself.
What are its core product primitives? What attributes and states belong to them? How do they relate to one another? Most importantly, what are people trying to understand or accomplish as they move through that model?
Different products have fundamentally different shapes.
Shopify is an interconnected commerce graph. Products, customers, orders, variants, locations, inventory, and fulfillment appear across many workflows, sometimes independently and sometimes nested within one another. The interface needs to preserve each resource’s identity while making those changing relationships and states legible—often for merchants managing thousands of resources on a wide desktop screen.
Linear is organized around work moving through states over time. Issues progress through workflows, cycles, projects, and teams. The important questions are: Where is the work now? Where is it going? How quickly is it moving? People need to scan large amounts of work, change its state quickly, and perceive momentum without visual friction.
Uber is organized around journeys moving through geography and real-time states. A trip progresses from requested to matching, pickup, in-trip, and completed. The interface needs to communicate live position, direction, ETA, driver information, safety controls, and changing actions.
These product models create different visual demands:
Shopify needs to preserve resource identity and clarify relationships, nesting, and state.
Linear needs to minimize friction and make progression and momentum visible.
Uber needs to communicate movement through space and changing operational states.
The visual language should grow from those demands. This is essentially taking the concepts from concept modeling popularized by Dan Brown and object-oriented UX by Sophia V. Prater and applying them to visual design, so that the visual language feels native to the product.
2. Vocabulary and semantics: what the visual elements mean
A language needs recognizable signs with stable meanings.
You might think of them as:
Nouns: visual signifiers for orders, customers, articles, or projects
Verbs: symbols and labels for adding, removing, deleting, publishing, or fulfilling
Attributes and states: draft, published, paid, delayed, fulfilled, or critical
Semantic roles: informational, cautionary, destructive, selected, or inactive
At Shopify, an order was most recognizably identified by its order number. A customer could be identified through a consistent customer symbol and name. These signifiers followed the resource wherever it appeared, helping merchants recognize it across different workflows.
The vocabulary also included consistent symbols and labels for common actions, distinct treatments for static attributes and changing lifecycle states, and semantic color roles for informational, cautionary, destructive, successful, and active states.
A product’s visual vocabulary creates recognizable forms.
But vocabulary alone can’t communicate a complete thought.
3. Grammar and syntax: how elements form compositions
After defining the vocabulary, you need to define how to combine it into meaningful compositions.
To me, this boils down to a basic question: what do you primarily use to create structure? Shapes, lines, or space?
The combination that you use depends on what relationships and information need to be understandable at a glance.
Those might include:
Sequential relationships: steps in a workflow, stages of delivery, or progress over time
Linked relationships: dependencies, inputs and outputs, or causes and effects
Nested relationships: items within orders, files within folders, or variants within products
Comparisons: choices, performance between periods, or a value relative to a benchmark
Movement and change: work velocity, article engagement, momentum, or growth
Grammar describes the recurring visual structures used to communicate those ideas.
At Shopify, shaped objects, nested surfaces, and semantic color became the primary structural building blocks. This is because we were often representing real physical objects with real boundaries. Physical products, brick-and-mortar stores, warehouses, shipping boxes. We needed to convey the tangible weight of these objects while also communicating ownership, boundaries, and deep relationships. Bounded shapes made each resource feel distinct, while inset surfaces and semantic color helped communicate nesting, ownership, and state without relying on a screen full of divider lines.
Linear uses a different grammar. It relies more heavily on space, alignment, and rhythm. Dense rows, consistent alignment, typographic hierarchy, subtle hover states, and compact progress symbols allow people to scan and update work without interrupting their momentum. The composition emphasizes flow rather than containment. Lines are only used to depict momentum and connections, not structure.
Uber’s grammar uses symbols, lines, and shapes to communicate movement and progress. A deliberate hierarchy of divider lines separates dense groups of trip information without consuming the limited vertical space of a mobile screen. As the trip changes state, the contents and emphasis of the UI change with it.
A component library might provide a table, card, grid, sheet, stack, or chart. Grammar explains which structure communicates the idea and how to combine the visual vocabulary within it.
4. How the product speaks
Most design languages already describe the product’s visual character: its color, typography, spacing, shape, depth, motion, and iconography. But the guidance is more useful when it explains what those tools help designers communicate, not just which tokens are available.
A design language should help designers answer practical questions: How do I show that two things belong together? How do I create hierarchy without adding another divider? How much space should this decision occupy? What should feel prominent, compact, urgent, or quiet?
That is how we approached the Shopify layout guidance. The first sections focused on design problems: creating proximity, establishing hierarchy, choosing the right scale, and matching the size of an element to the importance of the task. The space tokens came last. The goal was to teach designers what to reach for and why, rather than asking them to assemble the interface from a reference sheet of values.
The product’s personality should follow the same principle. Delight should not feel like decoration applied on top of the interface; it should feel native to how the product works.
Shopify’s buttons were deliberately tactile, weighty, and satisfying because commerce is rooted in physical objects and actions. Linear’s personality comes through differently. Its speed, continuity, and near-frictionless interactions reinforce a product model centered on momentum and work moving forward.
How a product emphasizes information and how it expresses personality are both part of how it speaks. The visual language should give designers a shared set of tools for making a point clearly and distinctly.
Here’s what that shift looked like in practice. As the design language matured, screens across Shopify moved away from generic containers and toward clearer visual identity, more legible relationships, and stronger hierarchy.
From components to meaning
Finding the right shape for an interface is a journey. Designers need to try different options: arrange information, expose relationships, choose meaningful symbols, and decide what to emphasize or allow to recede.
One designer can rely on intuition and experience. But when 300 designers work on a single product, they need to act as one team. They don’t need rigid constraints, but they do need a clear path that helps them make aligned design decisions.
A design language is that compass.
When designers understand the logic behind a product’s visual language, they stop guessing and start designing with clarity. They gain a sharper set of tools, along with firmer ground from which to challenge the system when the established answer no longer fits.
In Think Like a Chef: How to Use a Design System, Stephanie Poce captures this distinction:
“A cook knows what to do to create an enjoyable dish, then they use that knowledge and repeat what works to create a consistent experience. A chef not only knows what to do, but why it’s done.”
A cook can assemble ingredients. A chef understands how to transform them.
The way we present a design system shapes how teams use it. When we present its elements as rigid building blocks, we imply that the important decisions have already been made. When we present them as materials within a shared language, we give designers permission—and the judgment—to shape them around the problem.
The goal is not to maximize how many generic screens a team can assemble. It is to help many designers create new forms without making the product feel like it was designed by hundreds of different hands.
Components give teams reusable parts.
A design language gives them the confidence to say something meaningful with those parts.
This is great Yesenia. How do you get teams to transition from shaping to assembling? And how have you aligned with the dev teams on the same path? My org is struggling with assembling new components since components are shaped and predefined in our code base.