In a design system shared by several product teams, when does adding a component token tier pay off, and when is it just overhead?
answer
- divergence from the shared decision
- one part changes on its own
- mirror tokens add only hops
- published names become promises
basics
~20 sA component tier pays off when a component must diverge from a shared semantic decision, or have parts tuned separately, for a real brand or product. It is overhead when its tokens only mirror semantic ones and are never set differently.
solid answer
~40 sComponent tokens such as `button.primary.background` let a system change one component without touching a semantic token that many components share. That pays off when there is real divergence: a brand whose buttons need a different radius than its cards, a complex part like a ride-request card whose sub-parts designers tune separately, or consumers who would otherwise override library internals. It is overhead when every component token aliases the obvious semantic token and nobody sets it differently: hundreds of names, multiplied by variants and states, that only add hops. Published component tokens also become part of the system's contract, so each one is a name that must stay stable. A sensible middle path is to add them on demand, keep most internal to the library, and publish only those with a real consumer.
go deeper
Know what a component token is and that it usually aliases a semantic token, so a component follows shared decisions unless deliberately set apart.
Explain the trade: a knob for one component in exchange for more names and hops, and why a mirror token adds cost without benefit.
Decide per component from real divergence, add tokens on demand, keep most internal, and use usage data to fold unused ones back.
Frame published component tokens as contract surface, and set a policy on which components expose them given the brands and teams the system serves.
## What a component tier is In a tiered design-token system, **primitive** tokens hold raw values, **semantic** tokens alias them by purpose, and **component tokens** narrow a decision to one part of one component: `button.primary.background`, `ride-card.fare.text`, `badge.radius`. A component token usually aliases a semantic token, so by default it simply inherits the shared decision. Its value appears when someone needs that one part to differ from the shared decision without changing the semantic token other components also use. That makes the component tier an option on the future: it costs names and hops today in exchange for the ability to adjust a single component later. Whether the option is worth buying depends on whether that later actually arrives. ## When it pays off - **A brand or product needs one component to diverge.** A second brand in a white-label ride-hailing product wants fully rounded buttons while keeping square cards. If both read the same semantic radius token, only a component token can separate them. - **A complex component has parts tuned independently.** A ride-request card in the driver app has a pickup label, a fare, a distance line, an accept action and a countdown bar. Designers adjust these parts separately, and component tokens give each a stable knob. - **Consumers configure at component granularity.** Some consuming teams adjust the library by setting a few component tokens rather than changing semantic ones, which keeps their changes local to the components they meant to change. - **The library needs a documented styling surface.** Component tokens can serve as the published list of what a consumer may adjust, instead of consumers overriding internals in undocumented ways. ## When it is overhead - **Mirror tokens.** A component token that aliases the obvious semantic token and is never set differently in any brand, theme or product adds a hop and a name and nothing else. - **Multiplication.** Tokens multiply by components, properties, variants and states. Forty components with five styled properties across six states is already 1,200 names before variants — most of them mirrors. - **Contract weight.** A published component token is a name consumers may depend on. Renaming or removing it later is a breaking change, so each one adds to what the system must keep stable. - **A bypass of the semantic tier.** Component tokens that alias primitives directly skip the shared decisions, so the next system-wide change must be repeated component by component. ## A decision table | Situation | Component tier? | Why | |---|---|---| | One product, one brand, components follow shared decisions | Usually not yet | Nothing diverges; mirrors only add hops | | Several brands where specific components differ | Yes, for those components | The divergence cannot be expressed at the semantic tier without affecting others | | Complex component with many independently tuned parts | Yes, for that component | Each part needs its own stable knob | | Consumers overriding library internals to restyle parts | Yes, as a sanctioned surface | A documented knob beats undocumented overrides | | Tokens for every property of every component, for completeness | No | An explosion of names with no consumer | ## A middle path Systems that handle this well tend to follow a similar pattern: 1. **Start with two tiers.** Primitives and semantic tokens cover the shared decisions. 2. **Add component tokens on demand.** When a real consumer needs one part to differ, add the token for that part, aliasing the semantic token so default behaviour is unchanged. 3. **Keep most internal.** Component tokens can live inside the library as implementation detail; publish only those with a known external consumer. 4. **Review usage.** A component token that no brand, theme or consumer has ever set differently is a candidate to fold back into its semantic alias through the system's normal deprecation process. ## What a strong answer shows The judgement is not "component tokens good" or "component tokens bad". It is matching the tier to real divergence and accepting that every published name is a promise. A candidate who asks how many brands, themes and consuming teams exist, and which components have actually needed per-part changes, is answering as a system owner would. A candidate who proposes a token for every property of every component on day one, or who refuses component tokens even when a second brand plainly needs them, is optimising for tidiness rather than for the consumers.
- What is the risk of letting product teams set component tokens freely per screen?Each per-screen setting is a local fork of a shared decision: the same button looks different across screens, and later system changes may not reach the forked spots. If many teams set the same component token the same way, treat it as a signal that the default or a variant is missing, and fix it in the system instead of multiplying overrides.
- How can you tell that a published component token is not earning its place?Look at where it is set, not where it is read. If no brand, theme or consuming team has ever given it anything but its default alias, it is a mirror that adds a hop and a public name. It is a candidate to fold back into the semantic token it aliases, through the system's deprecation process rather than a silent removal.
saying these in an interview costs you the question
- Every component needs its own tokens for every property from day one.
- More tokens always mean more flexibility, at no real cost.
- Publishing a component token that mirrors a semantic token costs nothing.
- Component tokens exist so each screen can restyle its own buttons.
- Adding a component tier never changes what the system must keep stable.