readable-measure
The readable-measure skill guides designers and developers in setting optimal text column widths for comfortable reading by maintaining 45 to 75 characters per line across devices. It provides context-specific targets, CSS implementation patterns using the `ch` unit, and responsive strategies ensuring text remains legible on mobile, tablet, and desktop layouts without eye strain.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/readable-measure && cp -r /tmp/readable-measure/ui-design/skills/readable-measure ~/.claude/skills/readable-measureSKILL.md
# Readable Measure You are an expert in typographic measure and its effect on reading comfort and comprehension. ## What You Do You apply the principle of readable measure to ensure text columns are sized for comfortable, uninterrupted reading across devices and type scales. ## The Principle **Measure** is the length of a line of text. The optimal range is **45–75 characters per line** (including spaces), with 66 characters often cited as the ideal. - Below 45 characters: too short — the eye jumps lines too frequently, disrupting rhythm - Above 75 characters: too long — the eye loses its place returning to the start of the next line - 45–75 is the target zone for body copy; tighter ranges (50–60) suit sustained reading like articles or docs ## Measuring in Practice - Use the `ch` CSS unit (width of the `0` glyph) as a rough proxy: `max-width: 65ch` - Count actual characters in a representative paragraph to validate — `ch` is approximate - Adjust for typeface: wide faces (Georgia) need narrower columns; condensed faces allow slightly wider - Display type and short UI strings are exempt — this applies to body copy and reading contexts ## Responsive Behavior - Single-column mobile: full width is usually fine at 16px+ (rarely exceeds 70 chars on small screens) - Tablet and desktop: constrain column width explicitly; don't let text stretch to container edge - Multi-column layouts: each column should independently satisfy the 45–75 rule ## By Context | Context | Target | |---|---| | Long-form articles, docs | 55–70 characters | | UI body copy, descriptions | 45–65 characters | | Captions, helper text | 40–60 characters | | Pull quotes, callouts | 30–45 characters | ## Best Practices - Set `max-width` on text containers, not just font size - Increase line-height slightly as column width grows (wider measure needs more leading) - Test with real content — synthetic lorem obscures measure problems - Revisit measure whenever typeface or type size changes
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.