Patterns Analysis ‐ August 2026 ‐ Design

I checked the Design category directory — it contains exactly one pattern (plus its index.md category page, not a pattern). I also grepped the full catalogue for any other font/typography content and found none, so there's no cross-category duplication risk to check here.

Pattern Assessment: "Prioritise system-first typography selection based on user needs"

Overall Assessment: Publication Ready (one minor title-tightening suggestion)

1. Fewer, Better, Broader Patterns — ✓ PASS. This is comprehensive without padding: a 3-stage decision process (identify user needs → evaluate system fonts → optimise custom fonts if genuinely required), full SCI and Cost Impact, 4 assumptions, 4 considerations, 3 references. Reads like "a chapter in a guidebook," exactly the bar the principle sets.

2. Patterns, Not Practices — ✓ PASS. It names general web standards (WOFF2, font-display, subsetting, self-hosting) rather than a specific framework, build tool, or vendor product — these are durable, universal concepts a practitioner implements however fits their stack, unlike (for comparison) the Architecture-category pattern that linked directly to a specific chip vendor's marketing page.

3. Honour the Submitter's Framing — ✓ PASS. This is the strongest example of correct category framing seen across every category assessed so far. Step 1 is pure design/UX reasoning (readability, accessibility, internationalisation) with no code in sight; only Step 3 — clearly gated behind "if a custom font is genuinely required" — touches implementation. Contrast with the Requirements-category pattern reviewed earlier ("Optimize impact on customer devices and equipment"), which the skill itself would flag as reading like "a developer task list" — this pattern is the model of what that skill guidance is asking for.

4. Action on Resource Format — ✗ FAIL (soft). Title: "Prioritise system-first typography selection based on user needs." The skill's own Title Rules section gives an explicit good example for this exact category — "Choose typefaces to minimise font payload" — Action + concrete Resource + concise purpose clause. This pattern's title is a three-part compound ("system-first" / "typography selection" / "based on user needs") where the resource is a process description rather than a concrete noun. Meaning is clear, but it doesn't match the crispness of the template's own worked example for Design titles.

5. Complete Required Sections — ✓ PASS. All seven sections present: Description, Solution, SCI Impact, Cost Impact, Assumptions, Considerations, References. This is the first pattern across all three categories reviewed so far (Requirements, Architecture, Design) with zero structural gaps.

6. Conciseness Matters — ✓ PASS. The Solution is long in raw line count, but it's organized as a sequential decision tree (identify → evaluate → optimise-if-needed) rather than a flat list of overlapping tips — the structure itself does the work of keeping it navigable, unlike some Architecture patterns reviewed earlier that piled up 7-8 flat, redundant bullets.

7. Decision Confidence — ✓ PASS. A reader finishes with an explicit, ordered path to a decision, and Considerations names concrete conditions under which the pattern doesn't fully apply (hard brand requirements, cross-platform visual consistency needs) — real "confidently rule it out" material, not just "confidently adopt" material.

8. Specific, Testable Assumptions — ✓ PASS. All four assumptions are concrete and checkable: web-based delivery over HTTP/S, designers having input before engineering font-loading decisions, design team access to user-needs data, and WOFF2 browser-support compatibility. No hedge words ("if needed," "when appropriate") anywhere — this is the best Assumptions section reviewed across every category so far.

9. Real Complications in Considerations — ✓ PASS. All four considerations are genuine, specific friction points, not restated Solution content or vague cross-references: cross-platform system font rendering variance, brand-identity conflicts, the non-obvious risk of aggressive subsetting dropping characters from user-generated/internationalised content, and the diminishing-returns nuance for high-return-visitor products. Strongest Considerations section reviewed in this whole exercise.

10. Complete Trade-off Visibility — ✓ PASS. Cost Impact is honest and specific: network egress savings, possible elimination of third-party font-service billing, and an explicit acknowledgment that design/build time may increase modestly upfront — framed correctly as a one-time cost, not an ongoing one.

11. No Significant Duplication — ✓ PASS. Verified via a full-catalogue grep for "font," "typograph," "typeface" — no other pattern touches this territory.

---

Passes on: 1, 2, 3, 5, 6, 7, 8, 9, 10, 11 (10 of 11) Fails on: 4 (Action on Resource Format) — title is a wordy compound where the skill's own reference example for this exact category is crisper.

To publish, requires:

1. Retitle to name a concrete resource rather than a process — e.g., "Choose system fonts to meet user needs" or "Prefer system fonts over custom typefaces," closer to the template's own worked example ("Choose typefaces to minimise font payload").

Recommendation: Publication ready — this is, by a clear margin, the best-constructed pattern reviewed across Requirements, Architecture, and Design so far. Fix the title, ship it.

One observation outside the 11 principles: the Design category currently holds only this single pattern. That's not a strike against this pattern, but it's worth flagging to whoever owns catalogue coverage — Design is thin as a lifecycle phase relative to Requirements (4 patterns) and Architecture (16 patterns), and this pattern's own quality bar is a good template to solicit more Design submissions against.