# Hierarchy And Scale > Use when building or fixing a type scale, choosing heading sizes, or when a screen's importance ordering is unclear — everything looks the same weight, users miss the primary action, or headings compete. Also use when a design has drifted into a dozen ad-hoc font sizes. - Skill: `jpoindexter/hierarchy-and-scale` (Agent Skill) - Install (CLI): `npx skillmds@latest add jpoindexter/hierarchy-and-scale` - Raw SKILL.md: https://api.skillmd.com/api/skills/jpoindexter/hierarchy-and-scale/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: jpoindexter (https://skillmd.com/u/jpoindexter) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/jpoindexter/hierarchy-and-scale --- # Hierarchy and scale Hierarchy is the reader's answer to "what do I look at, and in what order." Scale is the finite set of sizes you allow yourself so that answer stays consistent. ## 1. When to invoke - Defining a type scale for a product, site, or design system. - Headings compete, or everything reads at the same importance. - A codebase has accumulated arbitrary sizes (13px, 15px, 17px, 22px…). - Content structure exists but is not visible. **Do not** invoke for body-copy tuning alone (`body-text-and-reading`) or for spacing detail (`microtypography`). ## 2. Required context - The **content's real structure** — how many genuine levels exist? Most interfaces need 3–4, not 8. - Whether a **design system or token set** already constrains sizes. - The **densest** screen the scale must serve, and the **most editorial** one. - Whether headings must survive translation (German/Finnish run long). - Body size, since the scale should be anchored to it. ## 3. Invariant principles - **Hierarchy is relative, not absolute.** A 20px heading is only a heading because the body is 16px. Define relationships, not values. - **Size is the weakest hierarchy tool available, and the most overused.** Weight, spacing, colour, position, and case all carry hierarchy. Reach for space and weight before size. - **A scale is a constraint, not a menu.** Its value is in what it forbids. If every size is available, there is no scale. - **Fewer levels read faster.** If two levels are hard to tell apart, you have one level with a spacing problem. - **Proximity outranks size.** A label sitting close to its value is bound to it more strongly than any size difference can express. ## 4. Context-dependent heuristics **Anchor to body size, then step outward.** The body size is determined by `body-text-and-reading`. The scale extends from it in both directions. **Ratio selection.** A modular scale multiplies each step by a fixed ratio. Brown describes it as "like a ruler… a system of measurement you can refer to as you decide on sizes and spaces." | Ratio | Character | Fits | |---|---|---| | 1.125 (major second) | Very tight | Dense product UI, data tools | | 1.200 (minor third) | Tight | App interfaces, dashboards | | 1.250 (major third) | Balanced | General product + marketing | | 1.333 (perfect fourth) | Open | Content sites, docs | | 1.414–1.500 | Dramatic | Editorial, landing pages | | 1.618 (golden) | Very dramatic | Display-led pages; too coarse for UI | Larger ratios give obvious hierarchy and too few usable mid sizes. Smaller ratios give many usable sizes and weak distinction. **Dense UI wants a small ratio; editorial wants a large one.** A product with both often needs a small ratio plus a few deliberate display sizes outside it. **The classic scale is a legitimate alternative.** 6, 7, 8, 9, 10, 11, 12, 14, 16, 18, 21, 24, 36, 48, 60, 72 — not a constant ratio, but centuries of use, with a recurring 2:1 (6/12/24/48). Rutter notes the musical analogy. Its irregularity is a feature: it's denser where you need choices and coarser where you don't. **Don't ship raw ratio output.** A 1.25 scale from 16 gives 31.25, 39.0625… Round to whole or half pixels and keep the rounded value as the token. **Baseline grid.** A horizontal rhythm every *n* pixels that every text element aligns to, so unrelated columns share a common baseline. Stocks' concrete version: a 24px baseline grid — "literally, a line every 24 vertical pixels" — suits body type with a 24px line-height. Smaller text at 12px line-height can use a 12px sub-grid, with body type aligning every two lines. Worth it for editorial, print, and multi-column layouts where cross-column alignment is visible. Usually **not** worth it for dense product UI, where forcing every component onto a baseline fights the component's own padding and produces worse spacing than a simple 4/8px spacing scale. Decide deliberately rather than adopting one by default — and note that a baseline grid constrains your line-height choices, which `body-text-and-reading` may have already fixed for readability. If they conflict, readability wins (rule 2 over convention). **Weight and space do the work size can't.** Once you have 3–4 sizes, express further distinction with weight (400/600/700), space above (a heading belongs to what follows it, so space above > space below), and case. ## 5. Failure patterns | Pattern | Cause | Fix | |---|---|---| | Eight heading levels, six indistinguishable | Scale generated, not designed | Cut to the levels content actually has | | Everything looks equally important | Only size varies, and barely | Add weight and spacing contrast | | Heading looks attached to the paragraph above it | Symmetric margins | More space above than below | | Scale looks fine in English, breaks in German | Tested on short strings | Test with longest supported locale | | Marketing hero and dashboard can't share a scale | One ratio forced on both | Small ratio for UI + explicit display steps | | 22px appears once, off-scale | No enforcement | Tokenize; make off-scale values impossible | | h1 chosen for size, not structure | Visual level conflated with semantic level | Keep heading *level* semantic; style separately | ## 6. Evaluation procedure 1. List the **real** content levels. Name them by role, not by number. 2. Confirm each level has a distinct job. Merge any that don't. 3. Squint at the rendered screen. Does the intended reading order emerge? 4. Grayscale it. Hierarchy that depends on colour alone fails here — and fails for colour-blind users. 5. Grep the codebase for font-size declarations. Every one must be on-scale. 6. Render the longest real string at each level, in the longest locale. 7. Zoom to 200%. Confirm levels remain distinguishable. 8. Verify heading *semantics* (h1…h6) are sequential and independent of visual size. ## 7. Output format ``` Body anchor: Ratio: () — chosen because Scale: / ... Levels: semantic, visual Non-size hierarchy: Checks: squint · grayscale · 200% · longest-locale Off-scale values found: ``` ## 8. Examples **Analytics dashboard, dense, body 14px.** > Dense data UI, so a small ratio: 1.2 (minor third). From a 14px body: 14 → 16.8 > → 20 → 24, rounded to 14/17/20/24. Only three levels above body, because the > content has exactly three (page title, section, card title). Distinction between > card title and section comes mostly from weight (600 vs 400) and space above, > not size — at 1.2 the size step alone is too subtle to carry it. **Marketing site sharing a design system with that dashboard.** > Don't re-ratio the system. Keep the 1.2 UI scale for all interface chrome and > add two explicit display steps (48, 64) outside it for hero use only, tokenized > as `display-1`/`display-2` so they can't leak into UI. This keeps one system > while letting the editorial surfaces breathe. ## 9. Counterexamples - ❌ "Use the golden ratio, it's the most harmonious." — 1.618 from a 16px body gives 16 → 25.9 → 41.9 → 67.8. There is no usable size between body and a large heading. Fine for a poster, unusable for an interface. - ❌ "Generate the scale and use every step." — A scale's value is exclusion. - ❌ "Make it an h1 because it should be big." — Heading level is document structure and is read by assistive technology. Style is separate. - ❌ "Add a size between 16 and 20 for this one label." — That's how a scale dies. Solve it with weight or space. - ❌ "The hierarchy works — the primary action is blue." — Fails in grayscale and for colour-blind users. Colour may reinforce hierarchy, never carry it alone. ## 10. Source citations - Lupton, *Thinking with Type* 3e — modular scales; "a type scale is a selection of type sizes based on history or mathematics"; preset sizes reflect historical type sizes. - Rutter, *Web Typography* — the classic scale (6…72), the recurring 2:1 ratio, and the musical analogy. - Brown, *Flexible Typesetting* — the modular scale as a ruler, a system of measurement tailored to the composition. - Latin, *Better Web Typography* — modular scale and meaningful typography; heading relationships. - Santa Maria, *On Web Typography* — typographic scales and rhythm; eyeballers vs. system-builders. - Stocks, *Universal Principles of Typography* — a typographic scale is already a design system; size, weight, and spacing imply order.