diff --git a/.claude/skills/audit/SKILL.md b/.claude/skills/audit/SKILL.md new file mode 100644 index 0000000..741885b --- /dev/null +++ b/.claude/skills/audit/SKILL.md @@ -0,0 +1,119 @@ +--- +name: audit +description: Run technical quality checks across accessibility, performance, theming, responsive design, and anti-patterns. Generates a scored report with P0-P3 severity ratings. Adapted from impeccable (Apache 2.0). +user-invocable: true +argument-hint: "[component or area to audit]" +--- + +Run systematic **technical** quality checks on a component or area and generate a scored report. This is assessment-only — don't fix issues, document them. + +**Target:** $ARGUMENTS + +## Preparation + +1. Read `docs/design-system.md` for FA design conventions +2. Read the component/area source files +3. Reference `docs/reference/impeccable/` for detailed design guidelines when scoring + +## Diagnostic Scan + +Score each dimension 0-4. + +### 1. Accessibility (A11y) + +**Check for**: +- Contrast ratios < 4.5:1 for text, < 3:1 for large text and UI components +- Missing ARIA: interactive elements without proper roles, labels, or states +- Keyboard navigation: missing focus-visible indicators, illogical tab order +- Semantic HTML: divs instead of buttons, missing landmarks, heading hierarchy +- Form issues: inputs without labels, poor error messaging +- Touch targets < 44px (critical for FA's audience — elderly, distressed) + +**Score**: 0=Fails WCAG A, 1=Major gaps, 2=Partial effort, 3=AA mostly met, 4=AA fully met + +### 2. Performance + +**Check for**: +- Expensive animations: animating layout properties instead of transform/opacity +- Missing optimisation: unoptimised assets, missing lazy loading +- Bundle concerns: unnecessary imports, unused dependencies +- Render performance: unnecessary re-renders, missing memoisation + +**Score**: 0=Severe issues, 1=Major problems, 2=Partial, 3=Mostly optimised, 4=Excellent + +### 3. Theming & Token Compliance + +**Check for**: +- Hardcoded colours not using theme palette or CSS variables +- Hardcoded spacing not using theme.spacing() or token values +- Hardcoded typography not using theme.typography variants +- Inconsistent token usage: wrong tier (primitive instead of semantic) +- Component tokens missing `$description` fields + +**Score**: 0=Hardcoded everything, 1=Minimal tokens, 2=Inconsistent, 3=Good with minor gaps, 4=Full token compliance + +### 4. Responsive Design + +**Check for**: +- Fixed widths that break on mobile +- Touch targets < 44px on interactive elements +- Horizontal scroll/overflow on narrow viewports +- Text scaling: layouts that break when text size increases +- Missing responsive padding (mobile vs desktop) + +**Score**: 0=Desktop-only, 1=Major issues, 2=Partial, 3=Good, 4=Fluid and responsive + +### 5. Design Quality + +**Check against these anti-patterns** (from impeccable frontend-design guidelines): +- Gray text on coloured backgrounds (looks washed out) +- Cards nested inside cards (visual noise) +- Identical card grids with no variation +- Bounce/elastic easing (dated, tacky) +- Every button styled as primary (no hierarchy) +- Redundant copy (headers restating the same info) +- Glassmorphism/blur used decoratively +- Missing interactive states (hover without focus, or vice versa) + +**Score**: 0=Multiple anti-patterns, 1=Several issues, 2=A couple, 3=Mostly clean, 4=Intentional, distinctive design + +## Report Format + +### Audit Health Score + +| # | Dimension | Score | Key Finding | +|---|-----------|-------|-------------| +| 1 | Accessibility | ? | | +| 2 | Performance | ? | | +| 3 | Theming & Tokens | ? | | +| 4 | Responsive Design | ? | | +| 5 | Design Quality | ? | | +| **Total** | | **??/20** | **[Rating]** | + +**Ratings**: 18-20 Excellent, 14-17 Good, 10-13 Acceptable, 6-9 Poor, 0-5 Critical + +### Executive Summary +- Score and rating +- Issue count by severity (P0/P1/P2/P3) +- Top 3-5 critical issues +- Recommended next steps + +### Detailed Findings + +Tag each issue **P0-P3**: +- **P0 Blocking**: Prevents task completion — fix immediately +- **P1 Major**: WCAG AA violation or significant UX issue — fix before release +- **P2 Minor**: Annoyance, workaround exists — fix in next pass +- **P3 Polish**: Nice-to-fix — address if time permits + +For each issue: +- **[P?] Issue name** +- **Location**: Component, file, line +- **Category**: Accessibility / Performance / Theming / Responsive / Design Quality +- **Impact**: How it affects users +- **Recommendation**: How to fix it + +### Positive Findings +Note what's working well — good practices to maintain. + +**NEVER**: Report issues without explaining impact. Provide generic recommendations. Skip positive findings. Mark everything as P0. diff --git a/.claude/skills/critique/SKILL.md b/.claude/skills/critique/SKILL.md new file mode 100644 index 0000000..2f19e3e --- /dev/null +++ b/.claude/skills/critique/SKILL.md @@ -0,0 +1,124 @@ +--- +name: critique +description: UX design review — evaluates visual hierarchy, emotional journey, cognitive load, and overall quality using Nielsen's heuristics (scored 0-40). Adapted from impeccable (Apache 2.0). +user-invocable: true +argument-hint: "[component or area to critique]" +--- + +Conduct a holistic UX design critique. Think like a design director giving feedback — evaluate whether the interface actually works as a designed experience, not just technically. + +**Target:** $ARGUMENTS + +## Preparation + +1. Read `docs/design-system.md` for FA design context and brand guidelines +2. Read `docs/memory/decisions-log.md` for design rationale +3. Read the target component/area source and stories +4. Reference `docs/reference/impeccable/cognitive-load.md` for the 8-item checklist +5. Reference `docs/reference/impeccable/heuristics-scoring.md` for scoring criteria + +**FA context reminder**: Funeral Arranger serves families often in grief or distress. The design must feel warm, trustworthy, transparent, and calm. Clarity over cleverness. Accessibility is critical — users may be elderly, emotional, or unfamiliar with technology. + +## Phase 1: Design Critique + +Evaluate across these dimensions: + +### 1. Visual Hierarchy +- Does the eye flow to the most important element first? +- Is there a clear primary action visible within 2 seconds? +- Do size, colour, and position communicate importance correctly? +- Is there visual competition between elements of different weights? + +### 2. Information Architecture & Cognitive Load +- Is the structure intuitive for a first-time user? +- Is related content grouped logically? +- Are there too many choices at once? (>4 at a decision point = flag it) +- **Run the 8-item cognitive load checklist** from `docs/reference/impeccable/cognitive-load.md` +- Report failure count: 0-1 = low (good), 2-3 = moderate, 4+ = critical + +### 3. Emotional Journey +- Does the interface feel warm and trustworthy (appropriate for FA)? +- Would a grieving family member feel "this is for me"? +- Are there design interventions at anxiety-prone moments (pricing, commitment, forms)? +- Does the experience end well (confirmation, clear next step)? + +### 4. Discoverability & Affordance +- Are interactive elements obviously interactive? +- Would a user know what to do without instructions? +- Are hover/focus states providing useful feedback? + +### 5. Composition & Balance +- Does the layout feel balanced? +- Is whitespace used intentionally? +- Is there visual rhythm in spacing and repetition? + +### 6. Typography as Communication +- Does the type hierarchy signal what to read first, second, third? +- Is body text comfortable to read? (line length 45-75ch, adequate size) +- Do font choices reinforce FA's warm, professional tone? + +### 7. Colour with Purpose +- Is colour used to communicate, not just decorate? +- Does the warm gold/copper brand palette feel cohesive? +- Are accent colours drawing attention to the right things? +- Does it work for colourblind users? + +### 8. States & Edge Cases +- Empty states: Do they guide users toward action? +- Loading states: Do they reduce perceived wait time? +- Error states: Are they helpful and non-blaming? (critical for FA — no aggressive red labels) +- Success states: Do they confirm and guide next steps? + +### 9. Microcopy & Voice +- Is the writing clear and concise? +- Does it sound warm and professional (FA's tone)? +- Are labels and buttons unambiguous? +- Does error copy help users fix the problem without distress? + +## Phase 2: Present Findings + +### Design Health Score + +Score each of Nielsen's 10 heuristics 0-4 (consult `docs/reference/impeccable/heuristics-scoring.md`): + +| # | Heuristic | Score | Key Issue | +|---|-----------|-------|-----------| +| 1 | Visibility of System Status | ? | | +| 2 | Match System / Real World | ? | | +| 3 | User Control and Freedom | ? | | +| 4 | Consistency and Standards | ? | | +| 5 | Error Prevention | ? | | +| 6 | Recognition Rather Than Recall | ? | | +| 7 | Flexibility and Efficiency | ? | | +| 8 | Aesthetic and Minimalist Design | ? | | +| 9 | Error Recovery | ? | | +| 10 | Help and Documentation | ? | | +| **Total** | | **??/40** | **[Rating]** | + +**Ratings**: 36-40 Excellent, 28-35 Good, 20-27 Acceptable, 12-19 Poor, 0-11 Critical + +### Overall Impression +Brief gut reaction — what works, what doesn't, the single biggest opportunity. + +### What's Working +2-3 things done well. Be specific about why they work. + +### Priority Issues +3-5 most impactful design problems, ordered by importance. + +For each issue, tag **P0-P3**: +- **[P?] What**: Name the problem +- **Why it matters**: How it hurts users (especially in FA's sensitive context) +- **Fix**: Concrete recommendation + +### FA Audience Check +Walk through the primary user flow as: +1. **Bereaved family member** (60+, first time, emotional, possibly on mobile) +2. **Arrangement planner** (30-50, comparing options, price-sensitive, wants transparency) + +For each persona, list specific pain points found. + +### Minor Observations +Quick notes on smaller issues worth addressing. + +**Remember**: Be direct and specific. Say what's wrong AND why it matters. Prioritise ruthlessly. Don't soften criticism — honest feedback ships better design. diff --git a/.claude/skills/preflight/SKILL.md b/.claude/skills/preflight/SKILL.md index b205330..526120c 100644 --- a/.claude/skills/preflight/SKILL.md +++ b/.claude/skills/preflight/SKILL.md @@ -78,3 +78,14 @@ Result: PASS (safe to commit) Use `PASS`, `FAIL`, or `WARN`. If any critical check fails, the result is `FAIL (do not commit)`. If only warnings, result is `PASS (safe to commit)` with warnings listed. If `--fix` was passed, attempt to fix issues automatically (e.g., run `npm run build:tokens` for stale tokens) and re-check. + +### 6. Visual QA spot-check (manual review, non-blocking) + +If a component was recently modified, do a quick visual review of the source code for these common issues (adapted from impeccable /polish): + +- **Transition consistency**: All interactive state changes should use `150ms ease-in-out` (FA convention). Flag mismatches. +- **Focus-visible**: Every interactive element should have a `:focus-visible` style. Flag any that rely only on hover. +- **Touch targets**: Interactive elements should have `minHeight >= 44px` for the largest size (or the mobile-intended size). +- **Spacing consistency**: Padding/gap values should use `theme.spacing()` or token CSS variables, not raw px. + +These are advisory — report as `INFO` lines after the main results. Do not block commit for these. diff --git a/.claude/skills/review-component/SKILL.md b/.claude/skills/review-component/SKILL.md index 178d5ff..b9146a9 100644 --- a/.claude/skills/review-component/SKILL.md +++ b/.claude/skills/review-component/SKILL.md @@ -46,4 +46,22 @@ Review a component against FA Design System conventions and report pass/fail for - [ ] Long content / overflow - [ ] autodocs tag present +### Interactive states (ref: docs/reference/impeccable/interaction-design.md) +- [ ] Default (resting) state is styled +- [ ] Hover state provides visual feedback (not just cursor change) +- [ ] Focus-visible state is distinct from hover (keyboard users never see hover) +- [ ] Active/pressed state feels responsive +- [ ] Disabled state is visually diminished but still distinguishable +- [ ] Transitions use 150ms ease-in-out (FA convention) + +### Design anti-patterns (ref: docs/reference/impeccable/frontend-design-skill.md) +- [ ] No grey text on coloured backgrounds (use a shade of the background colour instead) +- [ ] No cards nested inside cards (flatten hierarchy with spacing/typography) +- [ ] No identical card grids with zero variation (vary content, size, or emphasis) +- [ ] No bounce/elastic easing (use ease-out-quart or ease-in-out) +- [ ] Not every button is primary (use variant hierarchy: contained > soft > outlined > text) +- [ ] No redundant copy (headings don't restate content below them) +- [ ] No glassmorphism/blur used purely as decoration +- [ ] Whitespace is intentional, not leftover + **Report format:** List each check with pass/fail and specific issues found. End with a summary and recommended fixes. diff --git a/docs/reference/impeccable/audit-skill.md b/docs/reference/impeccable/audit-skill.md new file mode 100644 index 0000000..afc1685 --- /dev/null +++ b/docs/reference/impeccable/audit-skill.md @@ -0,0 +1,147 @@ +--- +name: audit +description: Run technical quality checks across accessibility, performance, theming, responsive design, and anti-patterns. Generates a scored report with P0-P3 severity ratings and actionable plan. Use when the user wants an accessibility check, performance audit, or technical quality review. +user-invocable: true +argument-hint: "[area (feature, page, component...)]" +--- + +## MANDATORY PREPARATION + +Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first. + +--- + +Run systematic **technical** quality checks and generate a comprehensive report. Don't fix issues — document them for other commands to address. + +This is a code-level audit, not a design critique. Check what's measurable and verifiable in the implementation. + +## Diagnostic Scan + +Run comprehensive checks across 5 dimensions. Score each dimension 0-4 using the criteria below. + +### 1. Accessibility (A11y) + +**Check for**: +- **Contrast issues**: Text contrast ratios < 4.5:1 (or 7:1 for AAA) +- **Missing ARIA**: Interactive elements without proper roles, labels, or states +- **Keyboard navigation**: Missing focus indicators, illogical tab order, keyboard traps +- **Semantic HTML**: Improper heading hierarchy, missing landmarks, divs instead of buttons +- **Alt text**: Missing or poor image descriptions +- **Form issues**: Inputs without labels, poor error messaging, missing required indicators + +**Score 0-4**: 0=Inaccessible (fails WCAG A), 1=Major gaps (few ARIA labels, no keyboard nav), 2=Partial (some a11y effort, significant gaps), 3=Good (WCAG AA mostly met, minor gaps), 4=Excellent (WCAG AA fully met, approaches AAA) + +### 2. Performance + +**Check for**: +- **Layout thrashing**: Reading/writing layout properties in loops +- **Expensive animations**: Animating layout properties (width, height, top, left) instead of transform/opacity +- **Missing optimization**: Images without lazy loading, unoptimized assets, missing will-change +- **Bundle size**: Unnecessary imports, unused dependencies +- **Render performance**: Unnecessary re-renders, missing memoization + +**Score 0-4**: 0=Severe issues (layout thrash, unoptimized everything), 1=Major problems (no lazy loading, expensive animations), 2=Partial (some optimization, gaps remain), 3=Good (mostly optimized, minor improvements possible), 4=Excellent (fast, lean, well-optimized) + +### 3. Theming + +**Check for**: +- **Hard-coded colors**: Colors not using design tokens +- **Broken dark mode**: Missing dark mode variants, poor contrast in dark theme +- **Inconsistent tokens**: Using wrong tokens, mixing token types +- **Theme switching issues**: Values that don't update on theme change + +**Score 0-4**: 0=No theming (hard-coded everything), 1=Minimal tokens (mostly hard-coded), 2=Partial (tokens exist but inconsistently used), 3=Good (tokens used, minor hard-coded values), 4=Excellent (full token system, dark mode works perfectly) + +### 4. Responsive Design + +**Check for**: +- **Fixed widths**: Hard-coded widths that break on mobile +- **Touch targets**: Interactive elements < 44x44px +- **Horizontal scroll**: Content overflow on narrow viewports +- **Text scaling**: Layouts that break when text size increases +- **Missing breakpoints**: No mobile/tablet variants + +**Score 0-4**: 0=Desktop-only (breaks on mobile), 1=Major issues (some breakpoints, many failures), 2=Partial (works on mobile, rough edges), 3=Good (responsive, minor touch target or overflow issues), 4=Excellent (fluid, all viewports, proper touch targets) + +### 5. Anti-Patterns (CRITICAL) + +Check against ALL the **DON'T** guidelines in the frontend-design skill. Look for AI slop tells (AI color palette, gradient text, glassmorphism, hero metrics, card grids, generic fonts) and general design anti-patterns (gray on color, nested cards, bounce easing, redundant copy). + +**Score 0-4**: 0=AI slop gallery (5+ tells), 1=Heavy AI aesthetic (3-4 tells), 2=Some tells (1-2 noticeable), 3=Mostly clean (subtle issues only), 4=No AI tells (distinctive, intentional design) + +## Generate Report + +### Audit Health Score + +| # | Dimension | Score | Key Finding | +|---|-----------|-------|-------------| +| 1 | Accessibility | ? | [most critical a11y issue or "--"] | +| 2 | Performance | ? | | +| 3 | Responsive Design | ? | | +| 4 | Theming | ? | | +| 5 | Anti-Patterns | ? | | +| **Total** | | **??/20** | **[Rating band]** | + +**Rating bands**: 18-20 Excellent (minor polish), 14-17 Good (address weak dimensions), 10-13 Acceptable (significant work needed), 6-9 Poor (major overhaul), 0-5 Critical (fundamental issues) + +### Anti-Patterns Verdict +**Start here.** Pass/fail: Does this look AI-generated? List specific tells. Be brutally honest. + +### Executive Summary +- Audit Health Score: **??/20** ([rating band]) +- Total issues found (count by severity: P0/P1/P2/P3) +- Top 3-5 critical issues +- Recommended next steps + +### Detailed Findings by Severity + +Tag every issue with **P0-P3 severity**: +- **P0 Blocking**: Prevents task completion — fix immediately +- **P1 Major**: Significant difficulty or WCAG AA violation — fix before release +- **P2 Minor**: Annoyance, workaround exists — fix in next pass +- **P3 Polish**: Nice-to-fix, no real user impact — fix if time permits + +For each issue, document: +- **[P?] Issue name** +- **Location**: Component, file, line +- **Category**: Accessibility / Performance / Theming / Responsive / Anti-Pattern +- **Impact**: How it affects users +- **WCAG/Standard**: Which standard it violates (if applicable) +- **Recommendation**: How to fix it +- **Suggested command**: Which command to use (prefer: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive) + +### Patterns & Systemic Issues + +Identify recurring problems that indicate systemic gaps rather than one-off mistakes: +- "Hard-coded colors appear in 15+ components, should use design tokens" +- "Touch targets consistently too small (<44px) throughout mobile experience" + +### Positive Findings + +Note what's working well — good practices to maintain and replicate. + +## Recommended Actions + +List recommended commands in priority order (P0 first, then P1, then P2): + +1. **[P?] `/command-name`** — Brief description (specific context from audit findings) +2. **[P?] `/command-name`** — Brief description (specific context) + +**Rules**: Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended. + +After presenting the summary, tell the user: + +> You can ask me to run these one at a time, all at once, or in any order you prefer. +> +> Re-run `/audit` after fixes to see your score improve. + +**IMPORTANT**: Be thorough but actionable. Too many P3 issues creates noise. Focus on what actually matters. + +**NEVER**: +- Report issues without explaining impact (why does this matter?) +- Provide generic recommendations (be specific and actionable) +- Skip positive findings (celebrate what works) +- Forget to prioritize (everything can't be P0) +- Report false positives without verification + +Remember: You're a technical quality auditor. Document systematically, prioritize ruthlessly, cite specific code locations, and provide clear paths to improvement. diff --git a/docs/reference/impeccable/cognitive-load.md b/docs/reference/impeccable/cognitive-load.md new file mode 100644 index 0000000..313df16 --- /dev/null +++ b/docs/reference/impeccable/cognitive-load.md @@ -0,0 +1,106 @@ +# Cognitive Load Assessment + +Cognitive load is the total mental effort required to use an interface. Overloaded users make mistakes, get frustrated, and leave. This reference helps identify and fix cognitive overload. + +--- + +## Three Types of Cognitive Load + +### Intrinsic Load — The Task Itself +Complexity inherent to what the user is trying to do. You can't eliminate this, but you can structure it. + +**Manage it by**: +- Breaking complex tasks into discrete steps +- Providing scaffolding (templates, defaults, examples) +- Progressive disclosure — show what's needed now, hide the rest +- Grouping related decisions together + +### Extraneous Load — Bad Design +Mental effort caused by poor design choices. **Eliminate this ruthlessly** — it's pure waste. + +**Common sources**: +- Confusing navigation that requires mental mapping +- Unclear labels that force users to guess meaning +- Visual clutter competing for attention +- Inconsistent patterns that prevent learning +- Unnecessary steps between user intent and result + +### Germane Load — Learning Effort +Mental effort spent building understanding. This is *good* cognitive load — it leads to mastery. + +**Support it by**: +- Progressive disclosure that reveals complexity gradually +- Consistent patterns that reward learning +- Feedback that confirms correct understanding +- Onboarding that teaches through action, not walls of text + +--- + +## Cognitive Load Checklist + +Evaluate the interface against these 8 items: + +- [ ] **Single focus**: Can the user complete their primary task without distraction from competing elements? +- [ ] **Chunking**: Is information presented in digestible groups (≤4 items per group)? +- [ ] **Grouping**: Are related items visually grouped together (proximity, borders, shared background)? +- [ ] **Visual hierarchy**: Is it immediately clear what's most important on the screen? +- [ ] **One thing at a time**: Can the user focus on a single decision before moving to the next? +- [ ] **Minimal choices**: Are decisions simplified (≤4 visible options at any decision point)? +- [ ] **Working memory**: Does the user need to remember information from a previous screen to act on the current one? +- [ ] **Progressive disclosure**: Is complexity revealed only when the user needs it? + +**Scoring**: Count the failed items. 0–1 failures = low cognitive load (good). 2–3 = moderate (address soon). 4+ = high cognitive load (critical fix needed). + +--- + +## The Working Memory Rule + +**Humans can hold ≤4 items in working memory at once** (Miller's Law revised by Cowan, 2001). + +At any decision point, count the number of distinct options, actions, or pieces of information a user must simultaneously consider: +- **≤4 items**: Within working memory limits — manageable +- **5–7 items**: Pushing the boundary — consider grouping or progressive disclosure +- **8+ items**: Overloaded — users will skip, misclick, or abandon + +**Practical applications**: +- Navigation menus: ≤5 top-level items (group the rest under clear categories) +- Form sections: ≤4 fields visible per group before a visual break +- Action buttons: 1 primary, 1–2 secondary, group the rest in a menu +- Dashboard widgets: ≤4 key metrics visible without scrolling +- Pricing tiers: ≤3 options (more causes analysis paralysis) + +--- + +## Common Cognitive Load Violations + +### 1. The Wall of Options +**Problem**: Presenting 10+ choices at once with no hierarchy. +**Fix**: Group into categories, highlight recommended, use progressive disclosure. + +### 2. The Memory Bridge +**Problem**: User must remember info from step 1 to complete step 3. +**Fix**: Keep relevant context visible, or repeat it where it's needed. + +### 3. The Hidden Navigation +**Problem**: User must build a mental map of where things are. +**Fix**: Always show current location (breadcrumbs, active states, progress indicators). + +### 4. The Jargon Barrier +**Problem**: Technical or domain language forces translation effort. +**Fix**: Use plain language. If domain terms are unavoidable, define them inline. + +### 5. The Visual Noise Floor +**Problem**: Every element has the same visual weight — nothing stands out. +**Fix**: Establish clear hierarchy: one primary element, 2–3 secondary, everything else muted. + +### 6. The Inconsistent Pattern +**Problem**: Similar actions work differently in different places. +**Fix**: Standardize interaction patterns. Same type of action = same type of UI. + +### 7. The Multi-Task Demand +**Problem**: Interface requires processing multiple simultaneous inputs (reading + deciding + navigating). +**Fix**: Sequence the steps. Let the user do one thing at a time. + +### 8. The Context Switch +**Problem**: User must jump between screens/tabs/modals to gather info for a single decision. +**Fix**: Co-locate the information needed for each decision. Reduce back-and-forth. diff --git a/docs/reference/impeccable/color-and-contrast.md b/docs/reference/impeccable/color-and-contrast.md new file mode 100644 index 0000000..77aaf03 --- /dev/null +++ b/docs/reference/impeccable/color-and-contrast.md @@ -0,0 +1,132 @@ +# Color & Contrast + +## Color Spaces: Use OKLCH + +**Stop using HSL.** Use OKLCH (or LCH) instead. It's perceptually uniform, meaning equal steps in lightness *look* equal—unlike HSL where 50% lightness in yellow looks bright while 50% in blue looks dark. + +```css +/* OKLCH: lightness (0-100%), chroma (0-0.4+), hue (0-360) */ +--color-primary: oklch(60% 0.15 250); /* Blue */ +--color-primary-light: oklch(85% 0.08 250); /* Same hue, lighter */ +--color-primary-dark: oklch(35% 0.12 250); /* Same hue, darker */ +``` + +**Key insight**: As you move toward white or black, reduce chroma (saturation). High chroma at extreme lightness looks garish. A light blue at 85% lightness needs ~0.08 chroma, not the 0.15 of your base color. + +## Building Functional Palettes + +### The Tinted Neutral Trap + +**Pure gray is dead.** Add a subtle hint of your brand hue to all neutrals: + +```css +/* Dead grays */ +--gray-100: oklch(95% 0 0); /* No personality */ +--gray-900: oklch(15% 0 0); + +/* Warm-tinted grays (add brand warmth) */ +--gray-100: oklch(95% 0.01 60); /* Hint of warmth */ +--gray-900: oklch(15% 0.01 60); + +/* Cool-tinted grays (tech, professional) */ +--gray-100: oklch(95% 0.01 250); /* Hint of blue */ +--gray-900: oklch(15% 0.01 250); +``` + +The chroma is tiny (0.01) but perceptible. It creates subconscious cohesion between your brand color and your UI. + +### Palette Structure + +A complete system needs: + +| Role | Purpose | Example | +|------|---------|---------| +| **Primary** | Brand, CTAs, key actions | 1 color, 3-5 shades | +| **Neutral** | Text, backgrounds, borders | 9-11 shade scale | +| **Semantic** | Success, error, warning, info | 4 colors, 2-3 shades each | +| **Surface** | Cards, modals, overlays | 2-3 elevation levels | + +**Skip secondary/tertiary unless you need them.** Most apps work fine with one accent color. Adding more creates decision fatigue and visual noise. + +### The 60-30-10 Rule (Applied Correctly) + +This rule is about **visual weight**, not pixel count: + +- **60%**: Neutral backgrounds, white space, base surfaces +- **30%**: Secondary colors—text, borders, inactive states +- **10%**: Accent—CTAs, highlights, focus states + +The common mistake: using the accent color everywhere because it's "the brand color." Accent colors work *because* they're rare. Overuse kills their power. + +## Contrast & Accessibility + +### WCAG Requirements + +| Content Type | AA Minimum | AAA Target | +|--------------|------------|------------| +| Body text | 4.5:1 | 7:1 | +| Large text (18px+ or 14px bold) | 3:1 | 4.5:1 | +| UI components, icons | 3:1 | 4.5:1 | +| Non-essential decorations | None | None | + +**The gotcha**: Placeholder text still needs 4.5:1. That light gray placeholder you see everywhere? Usually fails WCAG. + +### Dangerous Color Combinations + +These commonly fail contrast or cause readability issues: + +- Light gray text on white (the #1 accessibility fail) +- **Gray text on any colored background**—gray looks washed out and dead on color. Use a darker shade of the background color, or transparency +- Red text on green background (or vice versa)—8% of men can't distinguish these +- Blue text on red background (vibrates visually) +- Yellow text on white (almost always fails) +- Thin light text on images (unpredictable contrast) + +### Never Use Pure Gray or Pure Black + +Pure gray (`oklch(50% 0 0)`) and pure black (`#000`) don't exist in nature—real shadows and surfaces always have a color cast. Even a chroma of 0.005-0.01 is enough to feel natural without being obviously tinted. (See tinted neutrals example above.) + +### Testing + +Don't trust your eyes. Use tools: + +- [WebAIM Contrast Checker](https://webaim.org/resources/contrastchecker/) +- Browser DevTools → Rendering → Emulate vision deficiencies +- [Polypane](https://polypane.app/) for real-time testing + +## Theming: Light & Dark Mode + +### Dark Mode Is Not Inverted Light Mode + +You can't just swap colors. Dark mode requires different design decisions: + +| Light Mode | Dark Mode | +|------------|-----------| +| Shadows for depth | Lighter surfaces for depth (no shadows) | +| Dark text on light | Light text on dark (reduce font weight) | +| Vibrant accents | Desaturate accents slightly | +| White backgrounds | Never pure black—use dark gray (oklch 12-18%) | + +```css +/* Dark mode depth via surface color, not shadow */ +:root[data-theme="dark"] { + --surface-1: oklch(15% 0.01 250); + --surface-2: oklch(20% 0.01 250); /* "Higher" = lighter */ + --surface-3: oklch(25% 0.01 250); + + /* Reduce text weight slightly */ + --body-weight: 350; /* Instead of 400 */ +} +``` + +### Token Hierarchy + +Use two layers: primitive tokens (`--blue-500`) and semantic tokens (`--color-primary: var(--blue-500)`). For dark mode, only redefine the semantic layer—primitives stay the same. + +## Alpha Is A Design Smell + +Heavy use of transparency (rgba, hsla) usually means an incomplete palette. Alpha creates unpredictable contrast, performance overhead, and inconsistency. Define explicit overlay colors for each context instead. Exception: focus rings and interactive states where see-through is needed. + +--- + +**Avoid**: Relying on color alone to convey information. Creating palettes without clear roles for each color. Using pure black (#000) for large areas. Skipping color blindness testing (8% of men affected). diff --git a/docs/reference/impeccable/critique-skill.md b/docs/reference/impeccable/critique-skill.md new file mode 100644 index 0000000..5b66f72 --- /dev/null +++ b/docs/reference/impeccable/critique-skill.md @@ -0,0 +1,201 @@ +--- +name: critique +description: Evaluate design from a UX perspective, assessing visual hierarchy, information architecture, emotional resonance, cognitive load, and overall quality with quantitative scoring, persona-based testing, and actionable feedback. Use when the user asks to review, critique, evaluate, or give feedback on a design or component. +user-invocable: true +argument-hint: "[area (feature, page, component...)]" +--- + +## MANDATORY PREPARATION + +Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first. Additionally gather: what the interface is trying to accomplish. + +--- + +Conduct a holistic design critique, evaluating whether the interface actually works — not just technically, but as a designed experience. Think like a design director giving feedback. + +## Phase 1: Design Critique + +Evaluate the interface across these dimensions: + +### 1. AI Slop Detection (CRITICAL) + +**This is the most important check.** Does this look like every other AI-generated interface from 2024-2025? + +Review the design against ALL the **DON'T** guidelines in the frontend-design skill — they are the fingerprints of AI-generated work. Check for the AI color palette, gradient text, dark mode with glowing accents, glassmorphism, hero metric layouts, identical card grids, generic fonts, and all other tells. + +**The test**: If you showed this to someone and said "AI made this," would they believe you immediately? If yes, that's the problem. + +### 2. Visual Hierarchy +- Does the eye flow to the most important element first? +- Is there a clear primary action? Can you spot it in 2 seconds? +- Do size, color, and position communicate importance correctly? +- Is there visual competition between elements that should have different weights? + +### 3. Information Architecture & Cognitive Load +> *Consult [cognitive-load](reference/cognitive-load.md) for the working memory rule and 8-item checklist* +- Is the structure intuitive? Would a new user understand the organization? +- Is related content grouped logically? +- Are there too many choices at once? Count visible options at each decision point — if >4, flag it +- Is the navigation clear and predictable? +- **Progressive disclosure**: Is complexity revealed only when needed, or dumped on the user upfront? +- **Run the 8-item cognitive load checklist** from the reference. Report failure count: 0–1 = low (good), 2–3 = moderate, 4+ = critical. + +### 4. Emotional Journey +- What emotion does this interface evoke? Is that intentional? +- Does it match the brand personality? +- Does it feel trustworthy, approachable, premium, playful — whatever it should feel? +- Would the target user feel "this is for me"? +- **Peak-end rule**: Is the most intense moment positive? Does the experience end well (confirmation, celebration, clear next step)? +- **Emotional valleys**: Check for onboarding frustration, error cliffs, feature discovery gaps, or anxiety spikes at high-stakes moments (payment, delete, commit) +- **Interventions at negative moments**: Are there design interventions where users are likely to feel frustrated or anxious? (progress indicators, reassurance copy, undo options, social proof) + +### 5. Discoverability & Affordance +- Are interactive elements obviously interactive? +- Would a user know what to do without instructions? +- Are hover/focus states providing useful feedback? +- Are there hidden features that should be more visible? + +### 6. Composition & Balance +- Does the layout feel balanced or uncomfortably weighted? +- Is whitespace used intentionally or just leftover? +- Is there visual rhythm in spacing and repetition? +- Does asymmetry feel designed or accidental? + +### 7. Typography as Communication +- Does the type hierarchy clearly signal what to read first, second, third? +- Is body text comfortable to read? (line length, spacing, size) +- Do font choices reinforce the brand/tone? +- Is there enough contrast between heading levels? + +### 8. Color with Purpose +- Is color used to communicate, not just decorate? +- Does the palette feel cohesive? +- Are accent colors drawing attention to the right things? +- Does it work for colorblind users? (not just technically — does meaning still come through?) + +### 9. States & Edge Cases +- Empty states: Do they guide users toward action, or just say "nothing here"? +- Loading states: Do they reduce perceived wait time? +- Error states: Are they helpful and non-blaming? +- Success states: Do they confirm and guide next steps? + +### 10. Microcopy & Voice +- Is the writing clear and concise? +- Does it sound like a human (the right human for this brand)? +- Are labels and buttons unambiguous? +- Does error copy help users fix the problem? + +## Phase 2: Present Findings + +Structure your feedback as a design director would: + +### Design Health Score +> *Consult [heuristics-scoring](reference/heuristics-scoring.md)* + +Score each of Nielsen's 10 heuristics 0–4. Present as a table: + +| # | Heuristic | Score | Key Issue | +|---|-----------|-------|-----------| +| 1 | Visibility of System Status | ? | [specific finding or "—" if solid] | +| 2 | Match System / Real World | ? | | +| 3 | User Control and Freedom | ? | | +| 4 | Consistency and Standards | ? | | +| 5 | Error Prevention | ? | | +| 6 | Recognition Rather Than Recall | ? | | +| 7 | Flexibility and Efficiency | ? | | +| 8 | Aesthetic and Minimalist Design | ? | | +| 9 | Error Recovery | ? | | +| 10 | Help and Documentation | ? | | +| **Total** | | **??/40** | **[Rating band]** | + +Be honest with scores. A 4 means genuinely excellent. Most real interfaces score 20–32. + +### Anti-Patterns Verdict +**Start here.** Pass/fail: Does this look AI-generated? List specific tells from the skill's Anti-Patterns section. Be brutally honest. + +### Overall Impression +A brief gut reaction — what works, what doesn't, and the single biggest opportunity. + +### What's Working +Highlight 2–3 things done well. Be specific about why they work. + +### Priority Issues +The 3–5 most impactful design problems, ordered by importance. + +For each issue, tag with **P0–P3 severity** (consult [heuristics-scoring](reference/heuristics-scoring.md) for severity definitions): +- **[P?] What**: Name the problem clearly +- **Why it matters**: How this hurts users or undermines goals +- **Fix**: What to do about it (be concrete) +- **Suggested command**: Which command could address this (from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive) + +### Persona Red Flags +> *Consult [personas](reference/personas.md)* + +Auto-select 2–3 personas most relevant to this interface type (use the selection table in the reference). If `CLAUDE.md` contains a `## Design Context` section from `teach-impeccable`, also generate 1–2 project-specific personas from the audience/brand info. + +For each selected persona, walk through the primary user action and list specific red flags found: + +**Alex (Power User)**: No keyboard shortcuts detected. Form requires 8 clicks for primary action. Forced modal onboarding. ⚠️ High abandonment risk. + +**Jordan (First-Timer)**: Icon-only nav in sidebar. Technical jargon in error messages ("404 Not Found"). No visible help. ⚠️ Will abandon at step 2. + +Be specific — name the exact elements and interactions that fail each persona. Don't write generic persona descriptions; write what broke for them. + +### Minor Observations +Quick notes on smaller issues worth addressing. + +**Remember**: +- Be direct — vague feedback wastes everyone's time +- Be specific — "the submit button" not "some elements" +- Say what's wrong AND why it matters to users +- Give concrete suggestions, not just "consider exploring..." +- Prioritize ruthlessly — if everything is important, nothing is +- Don't soften criticism — developers need honest feedback to ship great design + +## Phase 3: Ask the User + +**After presenting findings**, use targeted questions based on what was actually found. STOP and call the AskUserQuestion tool to clarify. These answers will shape the action plan. + +Ask questions along these lines (adapt to the specific findings — do NOT ask generic questions): + +1. **Priority direction**: Based on the issues found, ask which category matters most to the user right now. For example: "I found problems with visual hierarchy, color usage, and information overload. Which area should we tackle first?" Offer the top 2–3 issue categories as options. + +2. **Design intent**: If the critique found a tonal mismatch, ask whether it was intentional. For example: "The interface feels clinical and corporate. Is that the intended tone, or should it feel warmer/bolder/more playful?" Offer 2–3 tonal directions as options based on what would fix the issues found. + +3. **Scope**: Ask how much the user wants to take on. For example: "I found N issues. Want to address everything, or focus on the top 3?" Offer scope options like "Top 3 only", "All issues", "Critical issues only". + +4. **Constraints** (optional — only ask if relevant): If the findings touch many areas, ask if anything is off-limits. For example: "Should any sections stay as-is?" This prevents the plan from touching things the user considers done. + +**Rules for questions**: +- Every question must reference specific findings from Phase 2 — never ask generic "who is your audience?" questions +- Keep it to 2–4 questions maximum — respect the user's time +- Offer concrete options, not open-ended prompts +- If findings are straightforward (e.g., only 1–2 clear issues), skip questions and go directly to Phase 4 + +## Phase 4: Recommended Actions + +**After receiving the user's answers**, present a prioritized action summary reflecting the user's priorities and scope from Phase 3. + +### Action Summary + +List recommended commands in priority order, based on the user's answers: + +1. **`/command-name`** — Brief description of what to fix (specific context from critique findings) +2. **`/command-name`** — Brief description (specific context) +... + +**Rules for recommendations**: +- Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive +- Order by the user's stated priorities first, then by impact +- Each item's description should carry enough context that the command knows what to focus on +- Map each Priority Issue to the appropriate command +- Skip commands that would address zero issues +- If the user chose a limited scope, only include items within that scope +- If the user marked areas as off-limits, exclude commands that would touch those areas +- End with `/polish` as the final step if any fixes were recommended + +After presenting the summary, tell the user: + +> You can ask me to run these one at a time, all at once, or in any order you prefer. +> +> Re-run `/critique` after fixes to see your score improve. diff --git a/docs/reference/impeccable/frontend-design-skill.md b/docs/reference/impeccable/frontend-design-skill.md new file mode 100644 index 0000000..62a11c6 --- /dev/null +++ b/docs/reference/impeccable/frontend-design-skill.md @@ -0,0 +1,147 @@ +--- +name: frontend-design +description: Create distinctive, production-grade frontend interfaces with high design quality. Generates creative, polished code that avoids generic AI aesthetics. Use when the user asks to build web components, pages, artifacts, posters, or applications, or when any design skill requires project context. +license: Apache 2.0. Based on Anthropic's frontend-design skill. See NOTICE.md for attribution. +--- + +This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices. + +## Context Gathering Protocol + +Design skills produce generic output without project context. You MUST have confirmed design context before doing any design work. + +**Required context** — every design skill needs at minimum: +- **Target audience**: Who uses this product and in what context? +- **Use cases**: What jobs are they trying to get done? +- **Brand personality/tone**: How should the interface feel? + +Individual skills may require additional context — check the skill's preparation section for specifics. + +**CRITICAL**: You cannot infer this context by reading the codebase. Code tells you what was built, not who it's for or what it should feel like. Only the creator can provide this context. + +**Gathering order:** +1. **Check current instructions (instant)**: If your loaded instructions already contain a **Design Context** section, proceed immediately. +2. **Check .impeccable.md (fast)**: If not in instructions, read `.impeccable.md` from the project root. If it exists and contains the required context, proceed. +3. **Run teach-impeccable (REQUIRED)**: If neither source has context, you MUST run /teach-impeccable NOW before doing anything else. Do NOT skip this step. Do NOT attempt to infer context from the codebase instead. + +--- + +## Design Direction + +Commit to a BOLD aesthetic direction: +- **Purpose**: What problem does this interface solve? Who uses it? +- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction. +- **Constraints**: Technical requirements (framework, performance, accessibility). +- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember? + +**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work—the key is intentionality, not intensity. + +Then implement working code that is: +- Production-grade and functional +- Visually striking and memorable +- Cohesive with a clear aesthetic point-of-view +- Meticulously refined in every detail + +## Frontend Aesthetics Guidelines + +### Typography +→ *Consult [typography reference](reference/typography.md) for scales, pairing, and loading strategies.* + +Choose fonts that are beautiful, unique, and interesting. Pair a distinctive display font with a refined body font. + +**DO**: Use a modular type scale with fluid sizing (clamp) +**DO**: Vary font weights and sizes to create clear visual hierarchy +**DON'T**: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults +**DON'T**: Use monospace typography as lazy shorthand for "technical/developer" vibes +**DON'T**: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated + +### Color & Theme +→ *Consult [color reference](reference/color-and-contrast.md) for OKLCH, palettes, and dark mode.* + +Commit to a cohesive palette. Dominant colors with sharp accents outperform timid, evenly-distributed palettes. + +**DO**: Use modern CSS color functions (oklch, color-mix, light-dark) for perceptually uniform, maintainable palettes +**DO**: Tint your neutrals toward your brand hue—even a subtle hint creates subconscious cohesion +**DON'T**: Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead +**DON'T**: Use pure black (#000) or pure white (#fff)—always tint; pure black/white never appears in nature +**DON'T**: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds +**DON'T**: Use gradient text for "impact"—especially on metrics or headings; it's decorative rather than meaningful +**DON'T**: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions + +### Layout & Space +→ *Consult [spatial reference](reference/spatial-design.md) for grids, rhythm, and container queries.* + +Create visual rhythm through varied spacing—not the same padding everywhere. Embrace asymmetry and unexpected compositions. Break the grid intentionally for emphasis. + +**DO**: Create visual rhythm through varied spacing—tight groupings, generous separations +**DO**: Use fluid spacing with clamp() that breathes on larger screens +**DO**: Use asymmetry and unexpected compositions; break the grid intentionally for emphasis +**DON'T**: Wrap everything in cards—not everything needs a container +**DON'T**: Nest cards inside cards—visual noise, flatten the hierarchy +**DON'T**: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly +**DON'T**: Use the hero metric layout template—big number, small label, supporting stats, gradient accent +**DON'T**: Center everything—left-aligned text with asymmetric layouts feels more designed +**DON'T**: Use the same spacing everywhere—without rhythm, layouts feel monotonous + +### Visual Details +**DO**: Use intentional, purposeful decorative elements that reinforce brand +**DON'T**: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully +**DON'T**: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional +**DON'T**: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful +**DON'T**: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output +**DON'T**: Use modals unless there's truly no better alternative—modals are lazy + +### Motion +→ *Consult [motion reference](reference/motion-design.md) for timing, easing, and reduced motion.* + +Focus on high-impact moments: one well-orchestrated page load with staggered reveals creates more delight than scattered micro-interactions. + +**DO**: Use motion to convey state changes—entrances, exits, feedback +**DO**: Use exponential easing (ease-out-quart/quint/expo) for natural deceleration +**DO**: For height animations, use grid-template-rows transitions instead of animating height directly +**DON'T**: Animate layout properties (width, height, padding, margin)—use transform and opacity only +**DON'T**: Use bounce or elastic easing—they feel dated and tacky; real objects decelerate smoothly + +### Interaction +→ *Consult [interaction reference](reference/interaction-design.md) for forms, focus, and loading patterns.* + +Make interactions feel fast. Use optimistic UI—update immediately, sync later. + +**DO**: Use progressive disclosure—start simple, reveal sophistication through interaction (basic options first, advanced behind expandable sections; hover states that reveal secondary actions) +**DO**: Design empty states that teach the interface, not just say "nothing here" +**DO**: Make every interactive surface feel intentional and responsive +**DON'T**: Repeat the same information—redundant headers, intros that restate the heading +**DON'T**: Make every button primary—use ghost buttons, text links, secondary styles; hierarchy matters + +### Responsive +→ *Consult [responsive reference](reference/responsive-design.md) for mobile-first, fluid design, and container queries.* + +**DO**: Use container queries (@container) for component-level responsiveness +**DO**: Adapt the interface for different contexts—don't just shrink it +**DON'T**: Hide critical functionality on mobile—adapt the interface, don't amputate it + +### UX Writing +→ *Consult [ux-writing reference](reference/ux-writing.md) for labels, errors, and empty states.* + +**DO**: Make every word earn its place +**DON'T**: Repeat information users can already see + +--- + +## The AI Slop Test + +**Critical quality check**: If you showed this interface to someone and said "AI made this," would they believe you immediately? If yes, that's the problem. + +A distinctive interface should make someone ask "how was this made?" not "which AI made this?" + +Review the DON'T guidelines above—they are the fingerprints of AI-generated work from 2024-2025. + +--- + +## Implementation Principles + +Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. + +Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices across generations. + +Remember: Claude is capable of extraordinary creative work. Don't hold back—show what can truly be created when thinking outside the box and committing fully to a distinctive vision. diff --git a/docs/reference/impeccable/heuristics-scoring.md b/docs/reference/impeccable/heuristics-scoring.md new file mode 100644 index 0000000..fd5b1b0 --- /dev/null +++ b/docs/reference/impeccable/heuristics-scoring.md @@ -0,0 +1,234 @@ +# Heuristics Scoring Guide + +Score each of Nielsen's 10 Usability Heuristics on a 0–4 scale. Be honest — a 4 means genuinely excellent, not "good enough." + +## Nielsen's 10 Heuristics + +### 1. Visibility of System Status + +Keep users informed about what's happening through timely, appropriate feedback. + +**Check for**: +- Loading indicators during async operations +- Confirmation of user actions (save, submit, delete) +- Progress indicators for multi-step processes +- Current location in navigation (breadcrumbs, active states) +- Form validation feedback (inline, not just on submit) + +**Scoring**: +| Score | Criteria | +|-------|----------| +| 0 | No feedback — user is guessing what happened | +| 1 | Rare feedback — most actions produce no visible response | +| 2 | Partial — some states communicated, major gaps remain | +| 3 | Good — most operations give clear feedback, minor gaps | +| 4 | Excellent — every action confirms, progress is always visible | + +### 2. Match Between System and Real World + +Speak the user's language. Follow real-world conventions. Information appears in natural, logical order. + +**Check for**: +- Familiar terminology (no unexplained jargon) +- Logical information order matching user expectations +- Recognizable icons and metaphors +- Domain-appropriate language for the target audience +- Natural reading flow (left-to-right, top-to-bottom priority) + +**Scoring**: +| Score | Criteria | +|-------|----------| +| 0 | Pure tech jargon, alien to users | +| 1 | Mostly confusing — requires domain expertise to navigate | +| 2 | Mixed — some plain language, some jargon leaks through | +| 3 | Mostly natural — occasional term needs context | +| 4 | Speaks the user's language fluently throughout | + +### 3. User Control and Freedom + +Users need a clear "emergency exit" from unwanted states without extended dialogue. + +**Check for**: +- Undo/redo functionality +- Cancel buttons on forms and modals +- Clear navigation back to safety (home, previous) +- Easy way to clear filters, search, selections +- Escape from long or multi-step processes + +**Scoring**: +| Score | Criteria | +|-------|----------| +| 0 | Users get trapped — no way out without refreshing | +| 1 | Difficult exits — must find obscure paths to escape | +| 2 | Some exits — main flows have escape, edge cases don't | +| 3 | Good control — users can exit and undo most actions | +| 4 | Full control — undo, cancel, back, and escape everywhere | + +### 4. Consistency and Standards + +Users shouldn't wonder whether different words, situations, or actions mean the same thing. + +**Check for**: +- Consistent terminology throughout the interface +- Same actions produce same results everywhere +- Platform conventions followed (standard UI patterns) +- Visual consistency (colors, typography, spacing, components) +- Consistent interaction patterns (same gesture = same behavior) + +**Scoring**: +| Score | Criteria | +|-------|----------| +| 0 | Inconsistent everywhere — feels like different products stitched together | +| 1 | Many inconsistencies — similar things look/behave differently | +| 2 | Partially consistent — main flows match, details diverge | +| 3 | Mostly consistent — occasional deviation, nothing confusing | +| 4 | Fully consistent — cohesive system, predictable behavior | + +### 5. Error Prevention + +Better than good error messages is a design that prevents problems in the first place. + +**Check for**: +- Confirmation before destructive actions (delete, overwrite) +- Constraints preventing invalid input (date pickers, dropdowns) +- Smart defaults that reduce errors +- Clear labels that prevent misunderstanding +- Autosave and draft recovery + +**Scoring**: +| Score | Criteria | +|-------|----------| +| 0 | Errors easy to make — no guardrails anywhere | +| 1 | Few safeguards — some inputs validated, most aren't | +| 2 | Partial prevention — common errors caught, edge cases slip | +| 3 | Good prevention — most error paths blocked proactively | +| 4 | Excellent — errors nearly impossible through smart constraints | + +### 6. Recognition Rather Than Recall + +Minimize memory load. Make objects, actions, and options visible or easily retrievable. + +**Check for**: +- Visible options (not buried in hidden menus) +- Contextual help when needed (tooltips, inline hints) +- Recent items and history +- Autocomplete and suggestions +- Labels on icons (not icon-only navigation) + +**Scoring**: +| Score | Criteria | +|-------|----------| +| 0 | Heavy memorization — users must remember paths and commands | +| 1 | Mostly recall — many hidden features, few visible cues | +| 2 | Some aids — main actions visible, secondary features hidden | +| 3 | Good recognition — most things discoverable, few memory demands | +| 4 | Everything discoverable — users never need to memorize | + +### 7. Flexibility and Efficiency of Use + +Accelerators — invisible to novices — speed up expert interaction. + +**Check for**: +- Keyboard shortcuts for common actions +- Customizable interface elements +- Recent items and favorites +- Bulk/batch actions +- Power user features that don't complicate the basics + +**Scoring**: +| Score | Criteria | +|-------|----------| +| 0 | One rigid path — no shortcuts or alternatives | +| 1 | Limited flexibility — few alternatives to the main path | +| 2 | Some shortcuts — basic keyboard support, limited bulk actions | +| 3 | Good accelerators — keyboard nav, some customization | +| 4 | Highly flexible — multiple paths, power features, customizable | + +### 8. Aesthetic and Minimalist Design + +Interfaces should not contain irrelevant or rarely needed information. Every element should serve a purpose. + +**Check for**: +- Only necessary information visible at each step +- Clear visual hierarchy directing attention +- Purposeful use of color and emphasis +- No decorative clutter competing for attention +- Focused, uncluttered layouts + +**Scoring**: +| Score | Criteria | +|-------|----------| +| 0 | Overwhelming — everything competes for attention equally | +| 1 | Cluttered — too much noise, hard to find what matters | +| 2 | Some clutter — main content clear, periphery noisy | +| 3 | Mostly clean — focused design, minor visual noise | +| 4 | Perfectly minimal — every element earns its pixel | + +### 9. Help Users Recognize, Diagnose, and Recover from Errors + +Error messages should use plain language, precisely indicate the problem, and constructively suggest a solution. + +**Check for**: +- Plain language error messages (no error codes for users) +- Specific problem identification ("Email is missing @" not "Invalid input") +- Actionable recovery suggestions +- Errors displayed near the source of the problem +- Non-blocking error handling (don't wipe the form) + +**Scoring**: +| Score | Criteria | +|-------|----------| +| 0 | Cryptic errors — codes, jargon, or no message at all | +| 1 | Vague errors — "Something went wrong" with no guidance | +| 2 | Clear but unhelpful — names the problem but not the fix | +| 3 | Clear with suggestions — identifies problem and offers next steps | +| 4 | Perfect recovery — pinpoints issue, suggests fix, preserves user work | + +### 10. Help and Documentation + +Even if the system is usable without docs, help should be easy to find, task-focused, and concise. + +**Check for**: +- Searchable help or documentation +- Contextual help (tooltips, inline hints, guided tours) +- Task-focused organization (not feature-organized) +- Concise, scannable content +- Easy access without leaving current context + +**Scoring**: +| Score | Criteria | +|-------|----------| +| 0 | No help available anywhere | +| 1 | Help exists but hard to find or irrelevant | +| 2 | Basic help — FAQ or docs exist, not contextual | +| 3 | Good documentation — searchable, mostly task-focused | +| 4 | Excellent contextual help — right info at the right moment | + +--- + +## Score Summary + +**Total possible**: 40 points (10 heuristics × 4 max) + +| Score Range | Rating | What It Means | +|-------------|--------|---------------| +| 36–40 | Excellent | Minor polish only — ship it | +| 28–35 | Good | Address weak areas, solid foundation | +| 20–27 | Acceptable | Significant improvements needed before users are happy | +| 12–19 | Poor | Major UX overhaul required — core experience broken | +| 0–11 | Critical | Redesign needed — unusable in current state | + +--- + +## Issue Severity (P0–P3) + +Tag each individual issue found during scoring with a priority level: + +| Priority | Name | Description | Action | +|----------|------|-------------|--------| +| **P0** | Blocking | Prevents task completion entirely | Fix immediately — this is a showstopper | +| **P1** | Major | Causes significant difficulty or confusion | Fix before release | +| **P2** | Minor | Annoyance, but workaround exists | Fix in next pass | +| **P3** | Polish | Nice-to-fix, no real user impact | Fix if time permits | + +**Tip**: If you're unsure between two levels, ask: "Would a user contact support about this?" If yes, it's at least P1. diff --git a/docs/reference/impeccable/interaction-design.md b/docs/reference/impeccable/interaction-design.md new file mode 100644 index 0000000..19d6809 --- /dev/null +++ b/docs/reference/impeccable/interaction-design.md @@ -0,0 +1,195 @@ +# Interaction Design + +## The Eight Interactive States + +Every interactive element needs these states designed: + +| State | When | Visual Treatment | +|-------|------|------------------| +| **Default** | At rest | Base styling | +| **Hover** | Pointer over (not touch) | Subtle lift, color shift | +| **Focus** | Keyboard/programmatic focus | Visible ring (see below) | +| **Active** | Being pressed | Pressed in, darker | +| **Disabled** | Not interactive | Reduced opacity, no pointer | +| **Loading** | Processing | Spinner, skeleton | +| **Error** | Invalid state | Red border, icon, message | +| **Success** | Completed | Green check, confirmation | + +**The common miss**: Designing hover without focus, or vice versa. They're different. Keyboard users never see hover states. + +## Focus Rings: Do Them Right + +**Never `outline: none` without replacement.** It's an accessibility violation. Instead, use `:focus-visible` to show focus only for keyboard users: + +```css +/* Hide focus ring for mouse/touch */ +button:focus { + outline: none; +} + +/* Show focus ring for keyboard */ +button:focus-visible { + outline: 2px solid var(--color-accent); + outline-offset: 2px; +} +``` + +**Focus ring design**: +- High contrast (3:1 minimum against adjacent colors) +- 2-3px thick +- Offset from element (not inside it) +- Consistent across all interactive elements + +## Form Design: The Non-Obvious + +**Placeholders aren't labels**—they disappear on input. Always use visible `