In a design system serving several brands, what should a brand theme change, and what should stay shared across every brand?
answer
- same components, different faces
- values vary, names do not
- identity versus function
- behavior and accessibility are shared
- one fix reaches every brand
basics
~20 sA brand theme swaps values such as colors, typefaces, corner radius and illustration style behind shared token names. Component structure, behavior, accessibility, layout rules and the names themselves stay shared, so one fix reaches every brand.
solid answer
~40 sPicture a food-delivery company running a restaurant-delivery brand and a grocery-delivery brand on one design system. Each brand supplies a **value set** for the same shared token names: its primary action color, its typeface, its corner radius, its illustration style. What stays **shared** is everything that carries function — component anatomy, interaction and keyboard behavior, screen-reader semantics, layout rules, content structure and the token names themselves. The split is **identity versus function**: brands must look distinct, but a cart stepper should behave identically in both apps so users and engineers learn it once, and a bug fixed in the core reaches both brands in one release. Brand values are still bound by shared rules, such as meeting contrast requirements against the surfaces they sit on.
go deeper
Recall the split: brands change values like color, typeface and radius behind shared names, while behavior, accessibility and component structure stay the same for every brand.
Explain why components stay brand-blind and read values through shared names, and which layers are usually brand-specific, usually shared, or constrained.
Show how you would judge a proposed brand difference — identity or function — and how shared rules such as contrast bind every brand's values.
Discuss how much brand expression the core should permit before the shared system stops paying for itself across brands.
## One system, several faces A **multi-brand design system** serves more than one brand from a single shared core. Take a food-delivery company that runs two consumer apps: a restaurant-delivery brand with a warm, playful look and a grocery-delivery brand with a calmer, fresher one. Both apps show menus and aisles, carts, delivery tracking and receipts. Building two separate systems would mean building and fixing every cart stepper, address field and order-status card twice. A shared core lets both brands reuse the same components while still looking unmistakably like themselves. The mechanism is simple: components reference **shared token names**, and each brand supplies its own **value set** for those names. The restaurant brand's primary action resolves to its tomato red; the grocery brand's resolves to its leaf green. The component never knows which brand it is rendering. ## What a brand theme typically changes | Layer | Usually brand-specific? | Example | |---|---|---| | Brand and accent colors | Yes | Primary action, highlights, selected states | | Typeface family | Yes | A rounded display face for one brand, a geometric one for the other | | Corner radius and shape | Often | Pill-shaped buttons versus softly rounded ones | | Illustration and imagery style | Yes | Empty-cart illustration, onboarding art | | Spacing and sizing scale | Usually shared | Keeps layouts and touch targets consistent | | Status colors (error, success) | Constrained | A brand may tune the hue, but the meaning must stay recognisable | | Component anatomy and behavior | No | How a quantity stepper increments, where its label sits | ## What stays shared, and why - **Behavior and interaction.** A dialog traps focus, a stepper responds to the same keys, a list announces the same way to a screen reader, whichever brand is showing. - **Accessibility contracts.** Focus indicators, accessible names and target sizes are part of the core's quality bar, not a brand choice. - **Layout logic and structure.** Grids, breakpoints and component anatomy are shared so screens can be built once and branded twice. - **The token names.** Brands change values, never names; a component written once must resolve correctly under every brand. - **Content structure.** Where an error message goes and what a receipt contains are product decisions, even though each brand words them in its own voice. The payoff is concentrated maintenance: an accessibility fix to the order-tracking card, made once in the core, ships to both brands in the same release. ## Rules that bind every brand Brand values are free within limits. A brand's primary color still has to meet the system's contrast requirements against the surfaces it appears on — under WCAG 2.2, at least 4.5:1 for normal text at Level AA — and a brand's typeface still has to be legible at the smallest text size the system uses. The core defines those rules once, and every brand value set is checked against them. ## Where the line blurs - **Spacing and density** are usually shared, but some systems let a brand choose a slightly more generous or more compact feel; that is a separate theming axis with its own rules. - **Motion character** — snappier or softer easing — is sometimes branded, while durations that affect usability stay shared. - **Voice and tone** differ by brand, but writing guidance is a brand and content concern rather than a token value. A useful test for any proposed brand difference: *does it express identity, or does it change how something works?* Identity belongs in the brand value set; function belongs in the shared core.
- Why should a component in a multi-brand system never check which brand is active?Because the value set is supposed to carry every brand difference. Once a component branches on brand identity, each new brand means editing and retesting core components, and the brands start drifting apart in behavior, not just looks. Keeping components brand-blind means adding a brand is a data change — a new value set — rather than a code change across the library.
- Can two brands in one system use different typefaces with different metrics without breaking shared layouts?Usually, if the core treats type as values rather than fixed sizes: line heights, sizes and weights come from the brand's value set, and components let text wrap instead of assuming a fixed width. Brands whose typefaces run much wider or taller than the core was tested with need their own visual checks, because truncation and wrapping differences show up only with real content.
saying these in an interview costs you the question
- Each brand should get its own copy of the components to stay flexible.
- A brand theme may change how a component behaves, not just how it looks.
- Brand colors are exempt from contrast rules because the brand guidelines set them.
- Token names should be prefixed per brand so components know which brand they serve.
- Keyboard and screen-reader behavior is part of what a brand can customise.