Design Methodology Atlas

Choose how to think before choosing how to style. Pick one discovery methodology, one system methodology, one evaluation methodology. Source: frontend-frontier-pack/codex-skill/frontend-frontier/references/design-methodology-atlas.md

Discovery Methodologies

Human-centered design -- best for new products, unclear user needs, high-risk workflow changes. Core: observe, synthesize, prototype, test. Failure mode: empathy theater with no product conviction.

Design thinking -- best for early-stage exploration, cross-functional workshops. Core: desirability, feasibility, viability. Failure mode: endless workshops without sharper bets.

Double Diamond -- best for structuring ambiguity, forcing divergence before convergence. Core: discover, define, develop, deliver. Failure mode: neat diagrams with weak synthesis.

Jobs to Be Done -- best for messaging, prioritization, positioning. Core: identify the progress the user is trying to make. Failure mode: vague job statements that do not shape design decisions.

Lean UX -- best for shipping under uncertainty. Core: assumptions, hypothesis, smallest experiment, learning. Failure mode: using "lean" as excuse for under-designed work.

Layers Diagnostic

Layers of Product Design is the missing diagnostic between broad discovery methods and surface polish. It models design as seven logically dependent layers, with reality on both ends:

observed behaviour → domain → user needs → product/service strategy → conceptual model → interaction flow → surface

The framework is not a mandatory linear process. Enter wherever the work appears to be stuck, then test whether a weaker lower layer is creating the apparent upper-layer problem. Its most valuable warning is that conceptual-model failures—unclear objects, relationships, states, and vocabulary—often masquerade as navigation or visual-design problems.

Use this route before visual polish when the team cannot tell whether the defect belongs to research, domain language, prioritization, product strategy, information model, flow, or presentation. Keep Layers as a cited methodology for now rather than installing nine additional peer skills; promote an executable local route only after repeated use proves that the atlas and existing workflow cannot carry the procedure. Source: X/@nurijanian, 2026-07-10; Source: jamiemill/layers-skills README and skills, HEAD a201dc8c2011940b9d93934abb0f40c3b226c7ca, reviewed 2026-08-10

System Methodologies

Atomic design -- atoms, molecules, organisms, templates, pages. Best when teams build screens instead of systems. Failure mode: taxonomy obsession.

Design tokens methodology -- primitive, semantic, component tokens. Best for multi-brand systems and design-to-code alignment. Failure mode: tokens without semantics.

Platform-native -- follow host patterns (Apple HIG, Fluent, Polaris, GOV.UK). Best when the ecosystem already trained the user.

Content-first -- structure language and task flow before visual flourish. Best for docs, admin tools, forms, public service.

Information architecture -- organize, label, relate information. Best when users cannot find things in fewer than 3 steps.

Evaluation Methodologies

Heuristic evaluation -- fast reviews against visibility, consistency, user control, error prevention, minimalist design. Best before formal research.

Accessibility-first -- semantic structure, keyboard support, contrast, reduced motion, assistive tech. Best for every product, always.

Performance-first -- define budgets, measure early, cut work that misses experience targets. Best for narrative pages, shader/3D, dashboards, mobile.

AI-Native Pre-Build Contract

For a greenfield product or substantial redesign, make the cheap decisions inspectable before implementation makes them expensive. The tools are interchangeable; the six review gates are not:

1. Problem evidence: name the user, job, current workaround, and evidence. Personal software may use the builder's own need; a business claim still requires user and market validation rather than search snippets alone.
2. Owned design direction: collect attributed inspiration, record the exact traits being borrowed, resolve asset/font/code rights, and write a project DESIGN.md with principles, type, color, spacing, density, and motion. Do not copy another product's expression or let a gallery become design authority.
3. Comparable key-screen variants: render at least two meaningful directions for the same key screens on one board, with the same content, viewport, and constraints. Answer clarifying questions, remove invented features, and commit to one direction with reasons.
4. One readable product/design/technical spec: bind the problem, goals, requirements, component vocabulary, design tokens, architecture, data model, privacy, security, accessibility, performance budgets, and non-goals. HTML is optional; human readability and stable source ownership are required.
5. Complete flows and states: design the core happy paths plus default, empty, loading, error, permission, interruption, narrow-viewport, keyboard, reduced-motion, and recovery states. Review the data model before persistence makes it costly to change.
6. Ambiguity gate, then code: have the implementation agent enumerate open questions and contradictions before writing code. During the build, keep the accepted spec and design authority synchronized, but require rendered, behavioral, accessibility, security, and performance proof for the product; synchronized documents are not acceptance evidence.

This sequence is a reusable artifact contract extracted from Peter Yang's Tastemaker tutorial, not an endorsement of Claude Design, a paid /spec skill, or a 50%-planning formula as a universal metric. The finished reference still required substantial iteration, and a 2026-08-12 read-only browser audit of its public landing page found contrast and landmark violations. Treat polished output as a candidate to verify, not self-certifying proof. Source: X/@petergyang and complete 25:27 transcript, 2026-07-29

Product Critique Workflow

product-design-critic is a useful reference-only skill candidate for product judgment. Its workflow is: user goal -> job to be done -> primary surface -> supporting context -> critical states -> trust/governance -> recommendation with tradeoffs. The emphasis is sharper than generic polish: decide the owning surface, clarify hierarchy, account for trust and governance, review the full state set, then use visual craft after the product call is clear. Source: X/@dhasandev, 2026-03-15; Source: Gist product-design-critic.md, checked 2026-07-02

Keep it as a reference rather than importing it as an active skill for now. Local coverage already exists across Frontend and Design Skills, Frontend and Design Skills, design-engineering-polish, and the taste skill routes, and the gist currently exposes only product-design-critic.md while referencing companion files that are not present in the gist API. Source snapshot on 2026-07-02: gist owner danialhasan, file product-design-critic.md, raw file e145e518e59ce9222f54075f0407e9a5ff182a1d, single history version 62b3ef3e8bd6f2300702c707ab5a9722fe871f9e, created 2026-03-15, updated 2026-06-06. Source: GitHub Gist API, 2026-07-02

Major Design-System Families

Recommended Combinations

Startup product: JTBD + lean UX / atomic + tokens / heuristic + a11y. Enterprise SaaS: human-centered / tokens + IA + platform-native / heuristic + a11y + performance. Docs product: IA + content-first / tokens + component-driven / a11y + searchability. Frontier marketing microsite: JTBD + design thinking / art-direction thesis + motion + tokens / performance + a11y + heuristic.

---

Timeline

• 2026-08-12 | Added the vendor-neutral six-gate AI-native pre-build contract after reviewing the full Tastemaker transcript, written walkthrough, and live desktop/mobile surface. Preserved its useful problem-to-spec sequence while adding originality, rights, user validation, accessibility, security, performance, recovery, and independent verification gates. Source: X/@petergyang, full transcript, article, and live Tastemaker surface, 2026-08-12
• 2026-08-10 | Added Layers of Product Design as the product-model diagnostic between discovery and surface work. Kept it in the canonical methodology atlas rather than installing nine new peer skills; use it to locate the lowest weak layer and especially to expose neglected conceptual-model debt. Source: X/@nurijanian, 2026-07-10; Source: jamiemill/layers-skills, reviewed 2026-08-10
• 2026-07-02 | Added product-design-critic as a reference-only product critique workflow after inspecting the X bookmark screenshot, raw gist, and gist API snapshot. Decision: candidate only, no active skill import, because local skills already cover the route and the gist references missing companion files. Source: X/@dhasandev, 2026-03-15; Source: GitHub Gist API, 2026-07-02