skip to content

In a multi-brand design system, how do you decide which tokens a brand may override and which stay locked, and how do you enforce that?

level: seniorimportance: must knowfreq 40%

answer

  1. identity versus function again
  2. overridable, constrained, locked
  3. accessibility is not a brand choice
  4. schema rejects unknown overrides
  5. the surface is a contract

basics

~20 s

Let brands override what expresses identity — brand colors, typeface, radius, imagery — constrain status colors with validation, and lock what carries function or accessibility. Enforce it with a value-set schema that rejects locked keys plus automated contrast checks per brand.

solid answer

~50 s

Sort every token into three groups. **Overridable**: identity values like brand and accent colors, typeface family, corner radius and illustration style. **Constrained**: values a brand may tune only within rules — status colors that must stay recognisable as error or success, brand fills that must meet contrast against their text. **Locked**: values that carry function or accessibility — the focus indicator's treatment, the spacing and sizing scale that keeps touch targets usable, layering order, motion durations and reduced-motion behavior. Enforce it mechanically: the brand value set is validated against a **schema that lists only overridable keys**, so a brand file touching a locked token fails the build; every brand's color pairs run through **automated contrast checks**; and requests for a new override go through review. Treat the override list as a **versioned contract** — widening it is easy, narrowing it breaks brands that relied on it.

go deeper

for a junior

Recall that brands may change identity values like color and typeface, but not values that keep the product usable and accessible, such as focus indicators and spacing.

for a middle

Explain the overridable, constrained and locked groups with examples, and why status colors are constrained rather than fully locked or fully free.

for a senior

Describe enforcing the split with a value-set schema, per-brand contrast checks and a review path for new overrides, and how you would handle a brand's request to unlock something.

for a principal

Argue how narrow to start the override surface, knowing that widening it is cheap and narrowing it later breaks every brand that relied on it.

## Why not let brands override everything In a multi-brand design system, each brand supplies a **value set** for shared token names. The tempting answer to brand requests is to make every token overridable. That fails in two ways: - **Every overridable value multiplies the combinations** the core must support and test. A food-delivery group with a restaurant brand and a grocery brand might test two themes; if each brand can also change spacing, focus rings and animation timing, the shared components have to work under every mixture. - **Some values are not identity at all.** They carry function, accessibility or layout guarantees. Letting a brand change them lets a brand break things the core promised every user. ## Three groups of tokens | Group | What belongs here | Example in the food-delivery apps | |---|---|---| | **Overridable** | Values that express identity | Brand primary and accent colors, typeface family, corner radius, illustration style | | **Constrained** | Brand may tune within rules | Error and success colors (must stay recognisable and meet contrast), brand fills that carry text | | **Locked** | Values that carry function or accessibility | Focus indicator treatment, spacing and sizing scale, layering order, motion durations and reduced-motion behavior | The test is the same one that separates brand from core everywhere: **does this value express who the brand is, or does it change how the product works?** ## Why the locked group is locked - **Focus indicators.** WCAG 2.2 success criterion 2.4.7 Focus Visible (Level AA) requires a visible keyboard focus indicator. If a brand can restyle focus rings, one brand's subtle ring can quietly stop being visible. The core owns the treatment; at most, the ring's color follows a constrained brand color that is checked against 3:1 non-text contrast. - **Spacing and sizing.** Target sizes, tap areas and layout rhythm depend on the shared scale; a brand that shrinks it breaks touch usability and every shared layout. - **Layering order.** Which surface sits above which — sheets over content, toasts over sheets — is behavior, not style. - **Motion timing.** Durations and the reduced-motion alternative affect usability and vestibular safety, not brand identity. ## Why some tokens are constrained rather than locked Status colors show the nuance. The grocery brand may want its error red to harmonise with its green palette, and that is a legitimate identity request. But an error must still read as an error, and its text must still meet contrast — at least 4.5:1 for normal text under WCAG 2.2 Level AA (1.4.3), and 3:1 for component boundaries and state indicators (1.4.11). So the brand may supply a value, and validation decides whether it is acceptable. ## Enforcing the split 1. **Schema for brand value sets.** The core publishes the list of overridable and constrained keys; a brand value set that sets a locked or unknown key fails validation in the build. 2. **Automated contrast checks per brand.** Every documented color pair — text on brand fill, icon on surface, focus ring on background — is computed for each brand on every build. 3. **Visual checks on brand-sensitive screens** for each brand before release. 4. **A review path for new overrides.** A brand that needs something locked makes a case; if granted, the key moves to the constrained or overridable group for everyone, not as a one-brand exception. 5. **Documentation** that tells brand designers what they can change, so requests arrive already inside the rules. ## The override list is a contract Once a key is overridable, brands build on it. Adding a key later is backward compatible; removing one breaks every brand that set it and must be handled like any breaking change. That asymmetry is the argument for starting narrow and widening deliberately.

  • A brand asks to override the spacing scale because it wants a more spacious feel. How do you respond?
    Ask what problem the feel solves. If it is about density across the whole product, that is a separate, system-wide density axis with its own rules, not a brand override. If it is about a few hero surfaces, a brand-level layout choice within the shared scale usually achieves it. Letting one brand redefine the scale would break shared layouts and target-size guarantees.
  • Why should a granted override apply to every brand rather than being a one-brand exception?
    An exception creates a code path only one brand exercises, so it is tested less and surprises the next maintainer. Moving the key into the overridable or constrained group keeps one set of rules, documents it, and makes the core's tests cover it for every brand, which keeps the system predictable as brands are added.

saying these in an interview costs you the question

  • Every token should be overridable so no brand ever feels constrained.
  • Focus ring styling is a brand decision like any other color.
  • Locking a token means brands can never influence its value in any way.
  • A brand override granted once is private to that brand and needs no documentation.
  • Removing an overridable key later is a harmless cleanup.