Purpose
Analyze a collection of product surfaces or data flows to surface the interaction patterns that repeat, the ones that quietly diverge, and the design debt worth paying down — producing a pattern inventory and a leverage-ranked debt register that tells a design lead exactly where consolidation returns the most consistency per unit of effort.
When to Use
Invoke this skill when the user asks to:
- Audit a platform or product for UX consistency across surfaces
- Identify repeating interaction patterns to codify into a design system
- Find where similar tasks are handled inconsistently across the product
- Build the case for a design system or component library investment
- Diagnose why a growing product feels fragmented or "stitched together"
- Prioritize design debt paydown before a major redesign or platform expansion
Inputs Required
Before starting, collect:
- Surfaces in scope: The screens, flows, components, or data flows to analyze (list, descriptions, or references)
- Product type: Platform, infrastructure product, admin console, developer tool, internal tooling, etc.
- Primary user roles: Who uses these surfaces and what they're trying to accomplish
- Known pain points: Any consistency complaints, support themes, or design friction already surfaced
- Existing system maturity: Design system status — none, informal, partial, mature
- Constraints: Team size, upcoming roadmap pressure, or platform areas that are off-limits to change
If existing system maturity or constraints are missing, assume an informal/partial system and a resource-constrained team, and note the assumption.
Instructions
Step 1: Decompose Surfaces Into Interaction Primitives
Break each surface down into its constituent UX patterns rather than treating screens as monoliths. For every surface, tag which primitives it contains:
- Navigation & wayfinding: Global nav, breadcrumbs, tabs, sidebars, back/cancel behavior
- Data display: Tables, lists, cards, detail views, empty states, density
- Input & configuration: Forms, inline editing, wizards, filters, search
- Feedback & status: Loading, success/error, toasts, validation, confirmations
- Action patterns: Primary/secondary CTAs, bulk actions, destructive confirmations, undo
- State & flow control: Progressive disclosure, modals vs. inline, save models (autosave vs. explicit)
Produce a coverage matrix: surfaces as rows, primitive categories as columns, noting how each surface handles each primitive.
Step 2: Cluster Into Repeating Patterns
Group instances that are solving the same interaction problem. For each cluster, record:
- Pattern name: A neutral, descriptive label (e.g., "list-to-detail drill-down")
- Where it appears: The surfaces using it
- Variant count: How many distinct implementations exist for the same job
- Convergence status: Consistent / Drifting / Fragmented
A pattern with one implementation across many surfaces is a codification candidate. A pattern with many implementations of the same job is a debt candidate.
Step 3: Identify Inconsistencies and Their Cost
For each Drifting or Fragmented pattern, characterize the divergence and its impact:
- Type of inconsistency: Visual (looks different), behavioral (acts different), structural (organized differently), or semantic (same word/icon means different things)
- User cost: Relearning, error risk, broken mental model, trust erosion
- Team cost: Duplicated build/maintenance, unclear source of truth, slowed onboarding
- Severity: High (behavioral/semantic inconsistency on high-traffic flows) → Low (cosmetic variance on rarely-used surfaces)
Behavioral and semantic inconsistencies are always more expensive than visual ones — rank accordingly.
Step 4: Build the Design Debt Register
Compile each debt item as a structured entry:
- Item: What the debt is
- Pattern affected: Which pattern cluster
- Surfaces impacted: Count and names
- Inconsistency type & severity
- Leverage score: High / Medium / Low — a function of (surfaces impacted × user traffic × severity) ÷ estimated effort to resolve
Sort the register by leverage descending. Leverage — not severity alone — drives the ranking, because a high-severity issue on one obscure surface loses to a medium-severity issue replicated across twenty.
Step 5: Recommend Consolidation Moves
For the top leverage items, specify the resolution:
- Canonical choice: Which existing variant should become the standard, and why (favor the most robust, accessible, and traffic-proven implementation)
- Codification path: Component, pattern guideline, or documented convention
- Migration approach: Big-bang vs. incremental; which surfaces to convert first
- Guardrail: What prevents re-divergence (component, lint rule, review checkpoint, ownership)
Step 6: Frame the Investment Case
Summarize what codifying the top patterns buys the team: consistency gains, maintenance reduction, and onboarding/velocity effects. Name the single highest-leverage consolidation to start with and why. Be opinionated about sequencing.
Output Format
- Structure: Coverage matrix → pattern clusters → inconsistency analysis → leverage-ranked debt register → consolidation recommendations → investment summary
- Length: 1,000–1,400 words
- Format: Tables for the coverage matrix and debt register; structured bullets for pattern clusters and recommendations; short prose for the investment case
- Sections: Primitive Coverage Matrix → Repeating Pattern Inventory → Inconsistency & Cost Analysis → Design Debt Register (ranked) → Consolidation Recommendations → Investment Case & Starting Point
- Tone: Design systems lead — systems-first, evidence-driven, decisive about tradeoffs; never hand-wavy about "consistency" without naming the specific divergence
Quality Checklist
Before delivering output, verify:
- [ ] Every surface in scope appears in the coverage matrix across all primitive categories
- [ ] Each pattern cluster records its variant count and convergence status
- [ ] Every debt register item has an inconsistency type, severity, and leverage score
- [ ] The debt register is sorted by leverage, not by severity or arbitrary order
- [ ] Each top recommendation names a canonical variant and a re-divergence guardrail
- [ ] The investment case names one specific highest-leverage starting move — no hedging
Notes
- Semantic inconsistencies (same icon or label meaning different things across surfaces) are the most under-reported and most damaging — check for them explicitly, not just visual variance.
- On infrastructure and developer-facing products, behavioral consistency (how save, undo, and destructive actions work) matters more than visual polish; weight severity accordingly.
- The most defensible starting move is usually the pattern with the highest variant count on high-traffic flows — it maximizes consistency gained per component built.
- If surfaces are described only vaguely, ask one clarifying question: "Which two surfaces feel the most inconsistent with each other today?" — that pair usually reveals the deepest debt.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills