A news publisher's design system has role tokens named color-red-breaking, color-blue-link and font-serif-headline, and a rebrand is coming; what is wrong with these names and how would you restructure them?
answer
- which word in each name is a value
- the rebrand changes exactly those words
- one red token, several roles
- split by role, then apply the grammar
- fix names before values move
basics
~20 sEach name spells its value - red, blue, serif - so the rebrand makes them lie or forces renames. Inventory usages, split each token into one intent token per role, and rename with the system's grammar before the new values ship.
solid answer
~40 sAll three names embed the current value: `red`, `blue` and `serif` are exactly what a rebrand changes, so afterwards they either lie or must be renamed. They also skip the property segment and use an inconsistent order. I would inventory every usage across the web, native apps and design files, then group usages by role - a single `color-red-breaking` often also colors form errors and the live-blog dot. Each role that may change independently becomes its own intent token in the fixed grammar: `news-color-background-breaking`, `news-color-text-error`, `news-color-icon-live`, `news-color-text-link`, `news-font-family-headline`. Descriptions record each intent. The renames then go through the normal migration process, and they should land before the rebrand so names and values do not change at the same time.
go deeper
Recall that red, blue and serif are values, and that a rebrand changes exactly those words, so the names will stop being true.
Explain how to parse each name against the grammar and why a missing property segment lets one token be used for text, fill and icons alike.
Demonstrate the audit: usage inventory across platforms, splitting one token into several roles, renaming with the grammar, and sequencing renames ahead of the rebrand.
Frame the cost trade-off: how much splitting the organisation can absorb now versus the coupling it keeps, and who owns the naming vocabulary afterwards.
## Diagnosing the names A **role token** (often called a semantic token) represents a decision about where a value is used. Its name should describe that use. In this news publisher's set, each name smuggles in the current value: | Token | Value word | What the rebrand does to it | |---|---|---| | `color-red-breaking` | red | breaking news moves to a new brand hue; the name lies | | `color-blue-link` | blue | links adopt the new accent; the name lies | | `font-serif-headline` | serif | a new sans-serif headline face arrives; the name lies | Three further problems show up on a closer read: - **No property segment.** `color-red-breaking` does not say whether it is a text, background or icon color, so teams use it for all three. - **Inconsistent order.** Category, value, role here; elsewhere the set probably has role first. Readers cannot guess names. - **Hidden coupling.** Because the name says red, it has been reused wherever red looked right. ## A method for the audit 1. **Inventory usages** of every role token across the web front end, the native apps and the design files. Usage, not the name, reveals what each token actually means. 2. **Parse names against the grammar** - namespace, category, property, variant, state, scale - and flag any segment that is a value: hue words, lightness words (`dark`, `white`), typeface classifications, literal numbers. 3. **Group each flagged token's usages by role.** One value-named token usually serves several: `color-red-breaking` turns out to fill the breaking-news label, color form error text and mark the live-blog dot. 4. **Split or merge.** Give each role that could change independently its own token, even if the values match today. Merge two tokens that turn out to be the same role under different names. 5. **Rename with the grammar**, choosing words native and web teams both recognise. 6. **Record the intent** in each token's description so the reasoning survives the people who made it. 7. **Hand the renames to the migration process** - keeping old names working for a while and retiring them later is its own discipline and is not part of choosing the names. ## The restructured set | Old name | Roles found in usage | New names | |---|---|---| | `color-red-breaking` | breaking label fill, form error text, live-blog dot | `news-color-background-breaking`, `news-color-text-error`, `news-color-icon-live` | | `color-blue-link` | article links, visited links | `news-color-text-link`, `news-color-text-link-visited` | | `font-serif-headline` | headline typeface | `news-font-family-headline` | The rebrand now becomes a value change only: breaking news can take the new hue while errors stay red, and the new headline face drops into `news-font-family-headline` without anyone touching code. ## Judgement calls - **How far to split.** Split where roles plausibly diverge - editorial urgency versus validation errors clearly do. Do not create a token per screen or per instance; that multiplies names that never differ. - **Relative words are not value words.** `inverse`, `strong` and `subtle` describe emphasis relative to a surface and survive a rebrand; `dark` and `white` promise a lightness and do not. - **Palette names stay.** The raw palette can keep `red-500`; that layer exists to name values. The audit targets role tokens only. - **Timing.** Renaming during the rebrand means names and values change in one release, so a consumer cannot tell a deliberate new color from a broken mapping. Renaming first, with values unchanged, makes the later rebrand a visible, reviewable value diff. - **Guarding the result.** Once the taxonomy is written down, reviews and automated checks can reject new value words in role names; how those checks are built is a separate concern. ## What the interviewer is looking for A senior answer does not stop at 'use semantic names'. It finds the **roles hidden behind one value-named token** by looking at usage, applies one grammar, keeps palette names honest, and sequences the work so the rebrand is safe. It also recognises that the same diagnosis applies to spacing (`space-16` used as a role) and to mode words such as `surface-white`, which will read wrongly the moment a second brand or mode assigns that token a different value.
- Why rename design tokens before the rebrand rather than during it?If names and values change in one release, consumers cannot tell a deliberate new color from a broken mapping, and visual reviews become noisy. Renaming first with unchanged values produces no visual change at all, which is easy to verify; the rebrand then ships as a pure value change that reviewers can judge on its own.
- How do you find which roles hide behind one value-named design token?Look at usage, not the name: search the web code, the native code and the design files for every reference, then classify each by what it is doing - a label fill, error text, a status icon. Clusters of usages with the same purpose become one role; each cluster that could change independently becomes its own token.
saying these in an interview costs you the question
- Renaming color-red-breaking to color-orange-breaking fixes the problem.
- One token per shared value is enough; roles can be split later.
- The raw palette must also lose its hue names in the audit.
- Renaming and revaluing tokens in one release is the efficient path.
- Words like inverse or strong are value words and must be removed.