In a food-delivery design system shared by two brands, one brand needs a component the other will not use. Where should it live, and what should you avoid?
answer
- behavior need or brand expression
- would a second brand use it
- a brand layer on top of core
- no brand branches inside core
- promotion path into core
basics
~20 sPut it in a brand extension layer built from core primitives and tokens and owned by that brand, promoting it to the core if a second brand needs it. Avoid brand checks inside core components and forked copies.
solid answer
~50 sFirst ask whether the need is **behavior** or **expression**. If the grocery brand needs a substitution-preference picker — genuinely grocery-only behavior — it belongs in a **brand extension layer**: a component owned by that brand team, built from core primitives and tokens and held to the core's quality bar, but not shipped or tested for the restaurant brand. If a second brand later needs it, **promote** it into the core. If the request is really a look — a brand-shaped promotional ribbon — try to meet it with the brand's value set or a generic core variant instead. Avoid two things: **brand conditionals inside core components**, which leak brand knowledge into shared code and force every change to be tested for every brand, and **forking** a core component into a brand copy, which doubles maintenance and lets the two drift apart.
go deeper
Recall the options — core, brand layer, or app code — and that brand-only components should be built from core pieces rather than copied from core components.
Explain why brand conditionals inside core components and forked copies both hurt, and how a brand extension layer avoids them while keeping quality.
Walk through deciding where a brand-only component lives, holding it to the core's quality bar, and promoting it into the core when a second brand needs it.
Discuss how brand layers change core release obligations and how strictly to police promotion so the core neither bloats nor stays too thin.
## The request A food-delivery group runs a restaurant-delivery brand and a grocery-delivery brand on one design system. The grocery team asks for a **substitution-preference picker**: for each item in the basket, the shopper chooses whether the picker may substitute a similar product, must ask first, or should refund instead. Restaurant orders never need it. Where should it live? ## Four places a brand-only component can go | Option | What it means | When it fits | Main cost | |---|---|---|---| | **Core component with a brand check** | Core code branches on which brand is active | Never a good fit | Brand knowledge leaks into shared code; every change tested for every brand | | **Generic core variant** | A brand-neutral option any brand could turn on | The behavior is general, only one brand uses it today | Core carries and tests it for everyone | | **Brand extension layer** | Brand-owned component built from core primitives and tokens | Brand-specific behavior with no second consumer yet | Brand team maintains it; core changes may ripple into it | | **Product-local component** | Lives only in the brand's app code | A one-screen experiment | Nothing enforces the system's quality bar | For the substitution picker, the **brand extension layer** is the usual answer: grocery-specific behavior, a single consumer, and enough reuse inside the grocery app to deserve system-grade quality. ## What the brand layer must follow - **Built from core pieces.** It composes the core's radio group, list rows and text, and reads the grocery brand's values through shared token names. It invents no private colors or spacing. - **Same quality bar.** Accessibility, keyboard behavior, documentation and tests meet the core's release-readiness standard, so shoppers get the same quality everywhere. - **Clear ownership.** The grocery team owns it; the core team reviews it but does not maintain it. - **Visible to the core team.** Core changes that could break brand-layer components are checked against them, the same way the core checks its other consumers. ## The promotion path 1. The component lives in the brand layer while one brand uses it. 2. A second brand — perhaps a new pharmacy-delivery brand with the same substitution problem — asks for it. 3. The core team generalises it: removes grocery-specific assumptions, names it neutrally, and adds it to the core with tests for every brand. 4. The brand layer's copy is deprecated in favour of the core version. Promotion on the second real consumer, not on speculation, keeps the core from filling up with components only one brand ever uses. ## What to avoid - **Brand conditionals in the core.** A branch that shows a different layout when the brand is grocery means the core now knows about brands. Each new brand adds another branch, each change must be verified under every branch, and the value-set model — where adding a brand is data, not code — is gone. - **Forking a core component.** Copying the core list row into a grocery version to tweak one detail creates two components that drift apart; accessibility fixes land in one and not the other. - **Solving a look with a component.** If the restaurant brand wants its promotional ribbon to have a distinctive notched shape, first see whether a brand value — a shape or radius token — or a generic core variant covers it. A brand component for pure expression is usually the most expensive way to get a look. ## A quick decision list - Is the difference behavior or expression? Expression goes to the value set first. - Would a second brand plausibly use it within the planning horizon? If yes, design it generically in the core. - Does it need system-grade quality? If not, it can stay product-local as an experiment. - Who will maintain it in a year? A component with no owner does not belong in any shared layer.
- The grocery brand's extension component breaks after a core release changed a primitive it composes. Whose problem is it?Both teams share it by design. The core team should have known the brand layer is a consumer and checked the change against it, or announced it as breaking; the grocery team owns the fix inside its component. Treating brand layers as registered consumers of the core — tested in the core's release checks — prevents most of these surprises.
- When is a generic core variant better than a brand extension component, even if only one brand uses it today?When the behavior is clearly general and a second use is foreseeable — a delivery-slot picker any delivery brand needs, say. Designing it generically from the start avoids a later promotion and migration. The price is that the core carries and tests it for every brand now, so the foreseeable second use should be concrete, not hypothetical.
saying these in an interview costs you the question
- Add a brand check inside the core component; it is only one branch.
- Copy the core component into the brand's app and modify it there.
- Every brand request should become a core component so nothing is duplicated.
- Brand extension components can skip the core's accessibility and quality bar.
- A purely visual brand difference is best solved with a new brand component.