Why is it a problem that a ride-hailing driver app's design system has grown to 34 text styles, many differing only in color or weight, and how do you reduce it?
answer
- choice becomes guesswork
- roles times colors
- separate orthogonal properties
- merge by role, retire the unused
- a bar for adding a style
basics
~20 sToo many near-duplicate styles make choice guesswork, blur hierarchy and multiply maintenance on every platform. Audit usage, pull color and emphasis out as separate modifiers, merge styles that serve the same role, retire unused ones and require a recurring role before adding a style.
solid answer
~50 sA large style set stops doing the job styles exist for. With 34 options, two teams building similar screens pick different near-duplicates, hierarchy blurs because several styles look almost alike, and every style must be maintained in design files and in each platform's code. Sprawl usually has identifiable causes: **color baked into styles** (so every role multiplies by every color), emphasis variants treated as new styles, one-off styles for a single screen, and platform-specific duplicates. To reduce it, **audit** where each style is used and for what role; **separate orthogonal properties**, so color and emphasis become modifiers applied to a role rather than new styles; **merge** styles that serve the same role for the reader; **retire** unused ones through the system's normal deprecation process; and set a bar for additions: a new style needs a recurring role no existing style serves. Many systems settle around a dozen or so styles — a convention, not a rule.
go deeper
Recall that a small style set is easier to use consistently, and that color and emphasis variants are common causes of sprawl.
Explain how baking color or weight into styles multiplies the count, and why merging should follow role rather than numeric closeness.
Demonstrate running the audit, consolidating across design files and every platform, and setting a bar that keeps the set from regrowing.
Weigh simplicity of application against set size, and decide who approves new styles so the system stays small without blocking real new roles.
## Why the count matters A **text style** is a named typographic role — heading, body, label, caption — that bundles size, weight, line height and letter spacing. The value of a style set comes from being **small enough to choose from confidently**. As it grows, that value erodes: - **Choice becomes guesswork.** With 34 options, two teams building an earnings screen and a trip history screen pick different near-duplicates. - **Hierarchy blurs.** Many styles sit a unit or one weight apart, so levels no longer read as distinct. - **Maintenance multiplies.** Every style lives in design files and in the code of each platform, and each change must be applied and verified everywhere. - **Change becomes risky.** When nobody knows which of three similar styles a screen uses, editing any of them has unpredictable reach. ## Where sprawl comes from | Cause | What it looks like | Why it multiplies | |---|---|---| | Color baked in | body-default, body-muted, body-inverse, body-error | Every role times every color | | Emphasis as a style | body, body-bold, body-medium | Every role times every weight | | One-off styles | trip-card-fare-special | A new style per screen | | Platform duplicates | Separate web and native versions of the same role | Every role times every platform | | Legacy never retired | Styles from an old redesign still listed | Nothing ever leaves the set | A useful signal is that the Design Tokens Community Group format's typography type bundles font family, size, weight, letter spacing and line height, and no color — a hint that color is commonly treated as a separate concern. Keeping color in styles is a defensible choice for simplicity, but in this driver app it is the largest single cause of the 34. ## Audit before cutting 1. **List every style** with its properties, from design files and from each platform's code. 2. **Record usage**: which screens and components use each style, and how often. 3. **Label the role** each use serves — primary number, screen title, card title, body, control label, metadata. 4. **Group by role.** Styles serving the same role with trivial differences are merge candidates; styles with no uses are retirement candidates. ## Consolidate - **Pull color out.** body-default, body-muted and body-inverse become one body style plus color roles applied separately. - **Treat emphasis as a modifier** where the system supports it: body with a strong emphasis, rather than a separate body-bold style — or keep one explicit emphasized variant if the product uses it heavily. - **Merge by role, not by numeric closeness.** Two styles one unit apart that serve different roles may both be needed; two that serve the same role become one. - **Retire unused and one-off styles** through the system's usual deprecation path, mapping each use to its replacement. - **Unify platforms.** One role, one style, published to every platform rather than defined twice. In this driver app, the audit might end with around a dozen styles: display, two headings, two titles, two body sizes, label, caption, and a numeric style for fares and earnings. The exact number is the product's; the point is that each surviving style serves a distinct role. ## Keep it small afterwards Sprawl returns unless adding a style has a bar. A common rule: a new style needs a **recurring role**, seen across several screens or teams, that no existing style can serve even with a color or emphasis modifier. Requests for one screen's taste are answered by pointing to the existing role. Freezing the set entirely goes too far — products gain real new roles — so the goal is a deliberate path for additions, not a ban. ## Rolling out Map each retired style to its replacement, change shared components first so most screens move at once, and review screens where the merge changed size or weight visibly. Consolidation is complete when every piece of text in every platform references one of the surviving styles. Expect some visible change, and plan for it. Merging body-medium into body, or two nearly identical titles into one, shifts a few screens by a unit or a weight. Show product teams the before and after for their most-used screens early; a consolidation that surprises teams tends to be quietly undone by local overrides.
- Isn't keeping color in text styles simpler for designers?It is simpler to apply, because one pick sets everything. The cost is multiplication: every role needs a version per color, so the set grows with each new color role. Keeping color separate means two picks per use but a far smaller, clearer style set; which trade-off wins depends on how many colors text appears in.
- How do you decide between merging two close styles and keeping both?By role. If both serve the same role for the reader, merge them and accept a small visual change. If they serve different roles, such as a card title and body text that happen to be close, keep both but widen the gap so the levels are visibly distinct.
- What stops the set from growing back to 34?A clear bar for additions — a recurring role across screens that no existing style serves with a color or emphasis modifier — plus usage tracking so unused styles are noticed and retired. Without both, each team's one-off need quietly becomes a permanent style.
saying these in an interview costs you the question
- More text styles give teams more flexibility with no real downside.
- Two styles within a unit of each other should always be merged regardless of role.
- A new text style should be added whenever one screen needs a slightly different look.
- The style set should be frozen permanently once consolidated.
- Consolidating styles is a design-file cleanup and does not require touching code.