From discover
Integrates design principles, WCAG 2.2 AA accessibility, persona context, and state design into product decisions. Use when reviewing UX decisions, checking accessibility, applying design principles, or ensuring state coverage in acceptance criteria.
npx claudepluginhub shinpr/claude-code-workflows --plugin discoverThis skill uses the workspace's default tool permissions.
Design is not a phase — it is a **perspective applied across all product processes**.
Evaluates UI designs using Nielsen's 10 Usability Heuristics and Norman's principles. Guides writing UX acceptance criteria and reviewing wireframes/mockups.
Sets project context for UX and design strategy, routes to specialized skills, loads foundational UX knowledge. For UX/product design, evaluation, strategy, ethics, dark patterns.
Guides pre-design discovery for features, components, or UI: explores problem, users, intent, constraints. Quick mode for POCs; full process for products.
Share bugs, ideas, or general feedback.
Design is not a phase — it is a perspective applied across all product processes.
| Process | Design's Role |
|---|---|
| Opportunity Discovery | Journey maps, pain point visualization |
| Solution Generation | Design principle-driven ideation |
| Assumption Validation | Prototype generation → usability testing |
| PRD Definition | Usability risk confirmation for user stories |
| Reflection | UX learning accumulation |
Always reference docs/product/design-principles.md for this product's design principles (3-5 principles).
Design principles are product-specific guardrails that guide all design decisions. They are not generic best practices but choices that reflect this product's values and trade-offs.
State Design defines five states every user-facing interaction must account for: Loading / Empty / Error / Partial / Success.
In practice:
Baseline: WCAG 2.2 AA compliance
Key requirements:
Accessibility is a Usability risk dimension — factor it into confidence scoring.
When making design decisions, always reference:
docs/product/personas/) — Who is using this? What's their context, skill level, environment?docs/discovery/journeys/) — Where in their journey does this interaction happen?When creating or updating personas, use references/persona-template.md for the standard structure (demographics, JTBD, pains/gains, behavioral patterns, validation status).
Design decisions without persona/context grounding are assumptions that need validation.
When docs/product/design/ exists, blueprint artifacts provide shared structural context (information architecture, brand direction, content model, user flows, AI interaction model). Prototypes reference these artifacts to ensure consistency across multiple hypothesis validations.
When validating Usability risk through prototypes:
Treating design as a phase (something done after requirements and before development) leads to surface-level UI work disconnected from user needs. As a perspective: