SKILL.md
Design Perspective
Core Philosophy
Apply design evidence wherever it can change discovery, validation, requirements, or reflection.
| 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 |
Design Principles Reference
Before making a UX or product-design decision, read docs/product/design-principles.md when it exists. An accessibility-only check does not require it unless the check also changes a product-specific trade-off.
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
See product-principles skill for the authoritative State Design definition (Loading / Empty / Error / Partial / Success).
Implement the states that can occur and affect the acceptance decision.
In practice:
- PRDs should specify behavior for the states relevant to each acceptance boundary
- Prototypes should demonstrate the states needed to test the current hypothesis
- User stories addressing Usability risk should consider all relevant states
Accessibility Standards
Baseline: WCAG 2.2 AA compliance
Key requirements:
- Perceivable: Text alternatives for non-text content, sufficient color contrast (4.5:1 for normal text, 3:1 for large text), content adaptable to different presentations
- Operable: All functionality available via keyboard, sufficient time for interactions, no content that causes seizures, clear navigation mechanisms
- Understandable: Readable text, predictable behavior, input assistance for error prevention
- Robust: Compatible with assistive technologies, valid markup
Accessibility is a Usability risk dimension — factor it into confidence scoring.
Persona and Context Integration
When they can change the design decision, reference:
- Personas (
docs/product/personas/) — Who is using this? What's their context, skill level, environment? - Journey Maps (
docs/discovery/journeys/) — Where in their journey does this interaction happen?
When creating or updating personas, use references/persona-template.md for decision-relevant context, jobs, behavioral evidence, and validation gaps.
Treat design decisions without persona or context evidence as assumptions requiring validation.
Blueprint Integration
See blueprint-standards Artifact Overview for the full blueprint artifact list.
When docs/product/design/ exists, blueprint artifacts provide shared structural context:
information-architecture.md— page hierarchy and navigationcontent-model.md— entities, relationships, and stateful databrand-direction.md— tone, visual direction, and Visual Tokensflows/— critical user flows and edge pathsai-interaction-model.md— AI interaction patterns, guardrails, and error taxonomy
Prototypes and PRDs should reference these artifacts when available instead of re-inferring structure from scratch.
Design in Hypothesis Validation
When validating Usability risk through prototypes:
- Define what "usable" means for this specific user story (tied to persona/context)
- Identify the critical interaction path to test
- Specify success criteria (task completion rate, time-on-task, error rate)
- Generate prototype with design context injected (see prototype-guide skill)
- Record results with specific UX learnings