For a design system's seven-step type scale, how would you consolidate a freelance job marketplace's 23 ad hoc font sizes and publish the scale as tokens?

seniorshould knowfreq 33%

answer

audit sizes with counts and contexts
map by role, not by distance
clusters may reveal a missing step
store final values, not the formula
record the ratio in the description

basics

~20 s

Audit every size with where and how often it is used, map each to a scale step by its role, and add a step only if a recurring role has none. Publish the final rounded values as size tokens that every platform references.

solid answer

~50 s

Start with an audit: every font size in code and design files, with usage counts and the context each appears in. Then map by role, not only by numeric distance — a 15 used for proposal body text becomes the 16 base, a 14 used for job-card metadata becomes 13, a 22 used as a section heading goes to 20 or 24 depending on the hierarchy it needs. Where many uses cluster between two steps, investigate before deciding: it can be drift, or a real role the scale lacks. Publish the scale as tokens holding the final rounded values, not a ratio that each platform recomputes, so web and native products get identical sizes and hand-tuned steps survive; record the base, ratio and deviations in the token descriptions. Roll out screen by screen with visual review, and let components reference the tokens so off-scale sizes stop being expressible in the normal path.

Start with an **audit**: every font size in code and design files, with usage counts and the context each appears in. Then **map by role, not only by numeric distance** — a 15 used for proposal body text becomes the 16 base, a 14 used for job-card metadata becomes 13, a 22 used as a section heading goes to 20 or 24 depending on the hierarchy it needs. Where many uses cluster between two steps, investigate before deciding: it can be drift, or a real role the scale lacks. Publish the scale as **tokens holding the final rounded values**, not a ratio that each platform recomputes, so web and native products get identical sizes and hand-tuned steps survive; record the base, ratio and deviations in the token descriptions. Roll out screen by screen with visual review, and let components reference the tokens so off-scale sizes stop being expressible in the normal path.

code

json · 13 lines

json

{
  "font-size": {
    "$type": "dimension",
    "$description": "Type scale: base 16, ratio 1.25, rounded. Bottom computed step (10.24) dropped as illegible.",
    "100": { "$value": { "value": 13, "unit": "px" }, "$description": "Computed 12.8" },
    "200": { "$value": { "value": 16, "unit": "px" }, "$description": "Base: body text" },
    "300": { "$value": { "value": 20, "unit": "px" } },
    "400": { "$value": { "value": 24, "unit": "px" }, "$description": "Computed 25, rounded to 24" },
    "500": { "$value": { "value": 32, "unit": "px" }, "$description": "Computed 31.25" },
    "600": { "$value": { "value": 40, "unit": "px" }, "$description": "Computed 39.06" },
    "700": { "$value": { "value": 48, "unit": "px" }, "$description": "Computed 48.83" }
  }
}

go deeper

for a junior

Recall that a type scale's values are published as tokens, and that products should reference those tokens instead of typing raw sizes.

for a middle

Explain why tokens hold the final rounded values rather than a formula, and why mapping follows the text's role rather than numeric distance.

for a senior

Demonstrate running the audit, reading clusters as evidence, mapping by role across web and native, and rolling out without breaking layouts.

for a principal

Discuss who decides whether a cluster becomes a new step, and how to balance a fixed scale's consistency against product teams' legitimate needs.

The situation

A freelance job marketplace has a design system whose type scale defines seven sizes — 13, 16, 20, 24, 32, 40 and 48, derived from a base of 16 and a ratio of 1.25, then rounded. Yet an audit of its web app, its native mobile apps and its design files finds 23 distinct font sizes, many a single unit apart: 14 and 15 near body text, 17 and 18 around card titles, 22, 26 and 28 among headings. Each arose from a local decision that looked reasonable at the time. The goal is to get back to seven sizes without breaking layouts, and to stop the drift recurring.

Audit before you map

Collect every size from code and design files on every platform, not only the web.
Record usage count and context for each: which screens, which text role, which component.
Cluster by role. Group uses into roles such as metadata, body, card title, section heading, page title and display.
Flag outliers that appear once or twice; these are usually local accidents rather than needs.

Design files matter as much as code: a size that exists only in mockups will reach code with the next feature unless it is mapped too.

Map by role, not only by distance

Numeric nearness alone gives wrong answers, because the same number can serve different roles and different numbers can serve the same role.

Found size	Where it is used	Maps to	Why
14	Posting date and budget on job cards	13	Secondary metadata role
15	Proposal form body text	16	It is body text, and body text is the base
17	Message thread body text	16	Same role as other body text
18	Job card title	20	Title role one step above body
22	Section headings in the dashboard	20 or 24	Chosen by the hierarchy each page needs
26 and 28	Page titles	32	Page-title role

When the audit says the scale is wrong

A cluster of many uses between two steps is evidence, not automatically drift. If dozens of screens use 18 for card titles and designers insist 20 is too large, ask whether the product has a card-title role the scale never served. Add a step only when a recurring role has no suitable size and the new step stays visibly different from its neighbours; otherwise map the cluster and explain why. Either outcome should be documented.

Publish final values, not the formula

The scale is published as design tokens, one per step, holding the final rounded values.

Every platform receives the same numbers, so web and native products cannot drift apart through different rounding.
Hand-tuned steps, such as a dropped or raised bottom step, survive; a formula would regenerate the untuned value.
In the Design Tokens Community Group format, token references point to another token's value and do not compute arithmetic, so a ratio cannot be expressed as a live calculation there anyway.
The base, ratio and every deviation go in $description, where people reading the token file can see the origin of each value.

The fragment in the code example shows the scale as dimension tokens. The $type set on the group applies to every token inside it, and the format's unit field is translated by build tooling into each platform's equivalent unit.

Roll out and hold the line

Change components first, so most screens move through shared parts rather than one by one.
Review visually screen by screen; line wrapping and truncation change when sizes move by a unit or two.
Move platform by platform, keeping web and native in step so they converge on the same seven sizes.
Make the tokens the normal path: components reference size tokens or the text styles built on them, so an off-scale size requires deliberately bypassing the system. Automated checks that flag raw sizes in code are a separate guardrail worth adding afterwards.

The consolidation is done when every size in every product maps to one of the published steps, and every exception has a written reason.

## The situation A freelance job marketplace has a design system whose **type scale** defines seven sizes — 13, 16, 20, 24, 32, 40 and 48, derived from a base of 16 and a ratio of 1.25, then rounded. Yet an audit of its web app, its native mobile apps and its design files finds **23 distinct font sizes**, many a single unit apart: 14 and 15 near body text, 17 and 18 around card titles, 22, 26 and 28 among headings. Each arose from a local decision that looked reasonable at the time. The goal is to get back to seven sizes without breaking layouts, and to stop the drift recurring. ## Audit before you map 1. **Collect every size** from code and design files on every platform, not only the web. 2. **Record usage count and context** for each: which screens, which text role, which component. 3. **Cluster by role.** Group uses into roles such as metadata, body, card title, section heading, page title and display. 4. **Flag outliers** that appear once or twice; these are usually local accidents rather than needs. Design files matter as much as code: a size that exists only in mockups will reach code with the next feature unless it is mapped too. ## Map by role, not only by distance Numeric nearness alone gives wrong answers, because the same number can serve different roles and different numbers can serve the same role. | Found size | Where it is used | Maps to | Why | |---|---|---|---| | 14 | Posting date and budget on job cards | 13 | Secondary metadata role | | 15 | Proposal form body text | 16 | It is body text, and body text is the base | | 17 | Message thread body text | 16 | Same role as other body text | | 18 | Job card title | 20 | Title role one step above body | | 22 | Section headings in the dashboard | 20 or 24 | Chosen by the hierarchy each page needs | | 26 and 28 | Page titles | 32 | Page-title role | ## When the audit says the scale is wrong A cluster of many uses between two steps is **evidence**, not automatically drift. If dozens of screens use 18 for card titles and designers insist 20 is too large, ask whether the product has a card-title role the scale never served. Add a step only when a recurring role has no suitable size and the new step stays visibly different from its neighbours; otherwise map the cluster and explain why. Either outcome should be documented. ## Publish final values, not the formula The scale is published as **design tokens**, one per step, holding the **final rounded values**. - Every platform receives the same numbers, so web and native products cannot drift apart through different rounding. - Hand-tuned steps, such as a dropped or raised bottom step, survive; a formula would regenerate the untuned value. - In the Design Tokens Community Group format, token references point to another token's value and do not compute arithmetic, so a ratio cannot be expressed as a live calculation there anyway. - The base, ratio and every deviation go in `$description`, where people reading the token file can see the origin of each value. The fragment in the code example shows the scale as dimension tokens. The `$type` set on the group applies to every token inside it, and the format's unit field is translated by build tooling into each platform's equivalent unit. ## Roll out and hold the line 1. **Change components first**, so most screens move through shared parts rather than one by one. 2. **Review visually** screen by screen; line wrapping and truncation change when sizes move by a unit or two. 3. **Move platform by platform**, keeping web and native in step so they converge on the same seven sizes. 4. **Make the tokens the normal path**: components reference size tokens or the text styles built on them, so an off-scale size requires deliberately bypassing the system. Automated checks that flag raw sizes in code are a separate guardrail worth adding afterwards. The consolidation is done when every size in every product maps to one of the published steps, and every exception has a written reason.

Why not store the ratio and let each platform compute the sizes?
Each platform might round differently, hand-tuned steps would be lost, and the token format's references do not do arithmetic anyway. Storing final values guarantees identical sizes everywhere; the ratio lives in the description as documentation of where the values came from.
How do you handle screens that break when their size moves by one or two units?
Fix the layout, not the size: text that truncates or wraps badly at 16 instead of 15 usually reveals a fixed-width container or missing wrapping rule. Review those screens before release and adjust their layout, rather than granting an exception that restarts the drift.
What evidence would justify adding an eighth step?
A recurring role used across many screens and platforms, where both neighbouring steps have been tried and rejected for concrete reasons, and where the new size stays visibly different from its neighbours. One team's preference or one screen's fit is not enough.

saying these in an interview costs you the question

Each ad hoc size should simply snap to the numerically nearest step.
Tokens should store the ratio so platforms compute sizes at runtime.
A cluster of uses between two steps always proves the scale is missing a step.
Consolidation can be done on the web app alone, since native apps follow later.
Adding a step for every size found in the audit is the safest way to avoid breakage.

For a design system's seven-step type scale, how would you consolidate a freelance job marketplace's 23 ad hoc font sizes and publish the scale as tokens?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The situation

Audit before you map

Map by role, not only by distance

When the audit says the scale is wrong

Publish final values, not the formula

Roll out and hold the line

▾common follow-ups3 questions

▾red flags5 flags

The situation

Audit before you map

Map by role, not only by distance

When the audit says the scale is wrong

Publish final values, not the formula

Roll out and hold the line

answer

go deeper