Field note · Design systems
A design system should preserve differences
Shared infrastructure should remove accidental inconsistency without flattening the brand and product choices that carry meaning.
Consistency is not sameness
Design systems are often asked to make products consistent. The request sounds straightforward until one system supports several brands, audiences, or editorial voices.
Then consistency can become a flattening force. Every surface gets the same geometry, motion, density, and tone because those are the choices the shared components happen to encode.
A useful multi-brand system should preserve meaningful differences while making accidental differences unnecessary.
Start with shared behavior
Behavior is often the strongest common foundation.
A button can share keyboard interaction, focus treatment, disabled semantics, loading behavior, and test coverage across brands without sharing every visual detail. A card can preserve its content structure and responsive logic while allowing different type, color, border, and elevation decisions.
This separation creates leverage. Accessibility and interaction quality improve once at the shared layer. Brand expression remains available through controlled variation.
The system becomes more coherent without asking every product to look identical.
Name the dimensions that may vary
Variation becomes difficult when it exists only as exceptions inside components.
It is easier to support when the system names its dimensions deliberately:
- Semantic color roles can resolve to different palettes.
- Typography roles can preserve hierarchy while changing family and scale.
- Density modes can adapt spacing without rewriting structure.
- Shape and elevation roles can express different visual attitudes.
- Content guidance can distinguish editorial voice from component behavior.
These are not theme switches added after the fact. They are part of the component contract.
Not every difference belongs in the system
Preserving difference does not mean turning every local choice into a global option.
Some differences are unique to one experience and should remain composed at the product layer. If a shared component accumulates a prop for every historical variation, the system stops offering guidance. It becomes an archive of unresolved decisions.
I like to ask two questions before adding a variant:
- Does this difference express a durable product or brand need?
- Can the system support it without making the common path harder to understand?
If the answer to either is no, composition may be healthier than configuration.
Multi-brand testing needs a matrix
A component that works in one theme may fail in another. Text grows differently across typefaces. Focus indicators disappear against new surfaces. A compact layout that feels intentional for one brand may feel cramped for another.
Testing needs to cover the combinations that the system promises, not every theoretical combination of every token.
A practical matrix identifies representative components, states, content lengths, breakpoints, and brands. Visual review can catch expression and hierarchy. Automated checks can protect semantics, interaction, and contrast where appropriate.
The matrix is also a governance tool: it makes the supported contract visible.
A system can hold a family resemblance
The goal is not to make each brand unrecognizable from the others. Shared products should still feel related where that relationship helps people understand and use them.
Family resemblance can come from interaction principles, content structure, accessibility standards, and a consistent level of finish. Identity can come from the visual and editorial decisions that matter most to each brand.
That balance is more demanding than uniformity, but it produces a healthier system. Teams gain shared infrastructure without losing the reasons their products are distinct.
A mature design system does not merely enforce consistency. It knows which consistency creates trust and which differences carry meaning.