# UX Heuristic Audit Template

Structured template for conducting heuristic evaluations. Use this to systematically audit any interface.

---

## Audit Information

**Product/Feature:** ________________
**Auditor:** ________________
**Date:** ________________
**Page/Screen:** ________________
**User Context:** ________________ (who is using this, what's their goal?)

---

## Severity Scale Reference

| Rating | Severity | Priority | Description |
|--------|----------|----------|-------------|
| 0 | Not a problem | — | Cosmetic or disagreement |
| 1 | Cosmetic | Low | Minor annoyance |
| 2 | Minor | Medium | Delays or frustrates |
| 3 | Major | High | Significant task failure |
| 4 | Catastrophic | Critical | Prevents task completion |

---

## Heuristic Checklist

### 1. Visibility of System Status

| Check | Pass? | Issue | Severity |
|-------|-------|-------|----------|
| Loading states are shown | [ ] | | |
| Actions provide immediate feedback | [ ] | | |
| Errors are communicated clearly | [ ] | | |
| Success is confirmed | [ ] | | |
| Progress is visible for long tasks | [ ] | | |

**Notes:**

---

### 2. Match Between System and Real World

| Check | Pass? | Issue | Severity |
|-------|-------|-------|----------|
| Uses user's language (not jargon) | [ ] | | |
| Icons are recognizable | [ ] | | |
| Order follows real-world logic | [ ] | | |
| Metaphors are appropriate | [ ] | | |
| Terms are consistent with industry | [ ] | | |

**Notes:**

---

### 3. User Control and Freedom

| Check | Pass? | Issue | Severity |
|-------|-------|-------|----------|
| Undo is available | [ ] | | |
| Cancel/Exit is always accessible | [ ] | | |
| Back button works as expected | [ ] | | |
| Users can skip optional steps | [ ] | | |
| Modals have clear close options | [ ] | | |

**Notes:**

---

### 4. Consistency and Standards

| Check | Pass? | Issue | Severity |
|-------|-------|-------|----------|
| Same terms for same concepts | [ ] | | |
| Buttons/links styled consistently | [ ] | | |
| Follows platform conventions | [ ] | | |
| Layout is predictable | [ ] | | |
| Same actions work the same way | [ ] | | |

**Notes:**

---

### 5. Error Prevention

| Check | Pass? | Issue | Severity |
|-------|-------|-------|----------|
| Destructive actions require confirmation | [ ] | | |
| Inline validation prevents bad submissions | [ ] | | |
| Constrained inputs prevent errors | [ ] | | |
| Defaults are sensible | [ ] | | |
| "Unsaved changes" warning exists | [ ] | | |

**Notes:**

---

### 6. Recognition Rather Than Recall

| Check | Pass? | Issue | Severity |
|-------|-------|-------|----------|
| Options are visible (not hidden) | [ ] | | |
| Recent items/history is accessible | [ ] | | |
| Icons have labels | [ ] | | |
| Instructions are in context | [ ] | | |
| Previous input is remembered | [ ] | | |

**Notes:**

---

### 7. Flexibility and Efficiency

| Check | Pass? | Issue | Severity |
|-------|-------|-------|----------|
| Keyboard shortcuts for power users | [ ] | | |
| Bulk actions available | [ ] | | |
| Customization options exist | [ ] | | |
| Frequent tasks are quick | [ ] | | |
| Advanced features don't clutter basics | [ ] | | |

**Notes:**

---

### 8. Aesthetic and Minimalist Design

| Check | Pass? | Issue | Severity |
|-------|-------|-------|----------|
| Only essential info is shown | [ ] | | |
| Visual hierarchy is clear | [ ] | | |
| Whitespace is used effectively | [ ] | | |
| No unnecessary decoration | [ ] | | |
| Primary action is obvious | [ ] | | |

**Notes:**

---

### 9. Error Recovery

| Check | Pass? | Issue | Severity |
|-------|-------|-------|----------|
| Error messages are in plain language | [ ] | | |
| Errors explain what went wrong | [ ] | | |
| Errors suggest how to fix | [ ] | | |
| User input is preserved on error | [ ] | | |
| Error location is highlighted | [ ] | | |

**Notes:**

---

### 10. Help and Documentation

| Check | Pass? | Issue | Severity |
|-------|-------|-------|----------|
| Help is searchable | [ ] | | |
| Contextual help is available | [ ] | | |
| Documentation is task-focused | [ ] | | |
| Tooltips explain non-obvious features | [ ] | | |
| Support is accessible | [ ] | | |

**Notes:**

---

## Summary

### Issue Count by Severity

| Severity | Count |
|----------|-------|
| 4 (Catastrophic) | |
| 3 (Major) | |
| 2 (Minor) | |
| 1 (Cosmetic) | |

### Top Issues (Severity 3-4)

| # | Issue | Heuristic | Severity | Recommendation |
|---|-------|-----------|----------|----------------|
| 1 | | | | |
| 2 | | | | |
| 3 | | | | |
| 4 | | | | |
| 5 | | | | |

### Quick Wins (Low effort, high impact)

| Issue | Fix | Effort |
|-------|-----|--------|
| | | |
| | | |
| | | |

---

## Task-Based Audit (Optional)

Test specific user tasks and note where issues occur.

### Task 1: ________________

| Step | Expected | Actual | Issue | Severity |
|------|----------|--------|-------|----------|
| 1 | | | | |
| 2 | | | | |
| 3 | | | | |

### Task 2: ________________

| Step | Expected | Actual | Issue | Severity |
|------|----------|--------|-------|----------|
| 1 | | | | |
| 2 | | | | |
| 3 | | | | |

---

## Navigation/Trunk Test

Can users answer these questions immediately?

| Question | Can Answer? | Notes |
|----------|-------------|-------|
| What site is this? | [ ] Yes [ ] No | |
| What page am I on? | [ ] Yes [ ] No | |
| What are the major sections? | [ ] Yes [ ] No | |
| What are my options here? | [ ] Yes [ ] No | |
| Where am I in the site structure? | [ ] Yes [ ] No | |
| How can I search? | [ ] Yes [ ] No | |

---

## Recommendations Summary

### Immediate (Severity 4)
1.
2.

### Short-term (Severity 3)
1.
2.
3.

### Medium-term (Severity 2)
1.
2.
3.

### Low Priority (Severity 1)
1.
2.

# Cultural UX Considerations

Designing for global audiences: RTL languages, color meanings, form conventions, and localization.


## Table of Contents
1. [Right-to-Left (RTL) Languages](#right-to-left-rtl-languages)
2. [Color Meanings Across Cultures](#color-meanings-across-cultures)
3. [Form Conventions](#form-conventions)
4. [Text Considerations](#text-considerations)
5. [Icons and Imagery](#icons-and-imagery)
6. [Localization Best Practices](#localization-best-practices)
7. [Quick Reference Checklist](#quick-reference-checklist)

---

## Right-to-Left (RTL) Languages

### Languages That Use RTL

- Arabic
- Hebrew
- Persian (Farsi)
- Urdu

### What to Mirror

| Element | LTR | RTL |
|---------|-----|-----|
| Text alignment | Left | Right |
| Navigation | Left side | Right side |
| Progress indicators | Left to right | Right to left |
| Icons with direction | → | ← |
| Checkmarks | ✓ on right | ✓ on left |
| Back buttons | ← | → |
| Carousels/sliders | Swipe left for next | Swipe right for next |

### What NOT to Mirror

| Element | Reason |
|---------|--------|
| Numbers | Always LTR (123, not ٣٢١) |
| Phone numbers | Universal format |
| Clocks | Universal format |
| Video player controls | Universal convention |
| Brand logos | Design integrity |
| Math equations | Universal notation |

### CSS for RTL

```css
/* Modern approach using logical properties */
.element {
  /* Instead of margin-left: 16px */
  margin-inline-start: 16px;

  /* Instead of padding-right: 8px */
  padding-inline-end: 8px;

  /* Instead of text-align: left */
  text-align: start;

  /* Instead of float: left */
  float: inline-start;
}

/* Or use dir attribute */
[dir="rtl"] .element {
  /* RTL-specific overrides */
}
```

### RTL Icons

Icons with inherent direction need mirroring:

| Icon | Mirror? | Reason |
|------|---------|--------|
| Back arrow | Yes | Directional navigation |
| Forward arrow | Yes | Directional navigation |
| Reply icon | Yes | Shows direction of response |
| Search icon | No | Magnifying glass is universal |
| Home icon | No | House has no direction |
| Settings gear | No | Symmetric |
| Play button | No | Universal media convention |

---

## Color Meanings Across Cultures

### Red

| Culture | Meaning |
|---------|---------|
| Western | Danger, stop, error, love |
| China | Good luck, prosperity, happiness |
| India | Purity, fertility |
| South Africa | Mourning |
| Japan | Life, anger |

**Design implication:** Don't use red for error states in apps targeting Chinese markets without context.

### White

| Culture | Meaning |
|---------|---------|
| Western | Purity, cleanliness, peace |
| China/Japan | Death, mourning |
| India | Unhappiness, mourning |

**Design implication:** White space may have different connotations; "clean" design may feel empty or cold.

### Green

| Culture | Meaning |
|---------|---------|
| Western | Go, success, nature, money |
| Islamic | Sacred, paradise |
| China | Infidelity (green hat = cuckold) |
| Ireland | National identity |

**Design implication:** Green success states work globally, but be careful with green accessories or hats in Chinese contexts.

### Yellow

| Culture | Meaning |
|---------|---------|
| Western | Caution, happiness |
| Japan | Courage, royalty |
| Egypt | Mourning |
| Latin America | Death, mourning |

### Blue

| Culture | Meaning |
|---------|---------|
| Most cultures | Trust, calm, professionalism |
| Iran | Mourning, spirituality |

**Design implication:** Blue is relatively safe globally; commonly used for links and primary actions.

### General Guidelines

1. **Test with local users** - Color perception varies
2. **Don't rely on color alone** - Add icons and text
3. **Provide customization** - Let users choose colors where possible
4. **Research target markets** - Specific meanings in your target regions

---

## Form Conventions

### Name Fields

| Culture | Name Structure |
|---------|----------------|
| Western | First + Last (given + family) |
| China/Japan/Korea | Family + Given |
| Iceland | Given + Patronymic |
| Spanish | Given + Father's surname + Mother's surname |
| Arabic | Given + Father's + Grandfather's + Family |

**Best practices:**
- Use single "Full Name" field when possible
- If splitting, use "Given Name" and "Family Name" (not First/Last)
- Don't assume first/last order
- Allow long names (>50 characters)

### Address Fields

| Region | Considerations |
|--------|----------------|
| US | State, ZIP code (5 or 9 digits) |
| UK | County optional, postcode format varies |
| Japan | Prefecture, address reads large→small |
| Brazil | CEP codes |
| Countries without postal codes | 50+ countries don't use them |

**Best practices:**
- Don't require postal code universally
- Use country-appropriate field labels
- Allow flexible formats
- Consider address autocomplete services

### Phone Numbers

| Consideration | Approach |
|---------------|----------|
| Country codes | Allow input or select separately |
| Length | Varies widely (7-15 digits) |
| Format | Don't enforce specific format |
| Mobile vs landline | Labels may not translate |

**Best practices:**
- Accept multiple formats
- Store in E.164 format internally (+1234567890)
- Display in local format
- Don't validate too strictly

### Dates

| Region | Format |
|--------|--------|
| US | MM/DD/YYYY |
| Most of world | DD/MM/YYYY |
| Japan, China, Korea | YYYY/MM/DD |
| ISO standard | YYYY-MM-DD |

**Best practices:**
- Use date pickers instead of text input
- Show month names (not numbers) to avoid confusion
- Store in ISO format (YYYY-MM-DD)
- Display in user's locale

### Currency

| Consideration | Examples |
|---------------|----------|
| Symbol position | $100 vs 100€ vs 100 kr |
| Decimal separator | $1,234.56 vs €1.234,56 |
| Thousands separator | 1,000 vs 1.000 vs 1 000 |
| Currency names | Dollar, Yuan, Rupee |

**Best practices:**
- Format according to user locale
- Always show currency symbol/code
- Be clear about which currency
- Handle conversion if multi-currency

---

## Text Considerations

### Text Expansion

Translated text is often longer than English:

| Language | Expansion Factor |
|----------|------------------|
| German | 1.3x |
| French | 1.2x |
| Russian | 1.2x |
| Spanish | 1.2x |
| Chinese | 0.8x |
| Japanese | 0.9x |

**Design implications:**
- Don't design to exact English text length
- Allow buttons and labels to expand
- Test layouts with longest expected translations
- Use flexible grid/flexbox layouts

### Text in Images

Avoid text in images because:
- Can't be translated easily
- Not accessible to screen readers
- Doesn't scale with user preferences
- Complicates localization workflow

**Alternative:** Use CSS text over images.

### Numbers and Units

| Element | Consideration |
|---------|---------------|
| Measurement | Metric (most world) vs Imperial (US) |
| Paper size | A4 (most world) vs Letter (US, Canada) |
| Temperature | Celsius vs Fahrenheit |
| Time | 24-hour vs 12-hour (AM/PM) |

---

## Icons and Imagery

### Potentially Problematic Icons

| Icon | Issue | Alternative |
|------|-------|-------------|
| Mailbox | US-specific design | Envelope |
| Check mark | Means "wrong" in some cultures | Consider context |
| Thumbs up | Offensive in some cultures | Hearts, stars |
| Hand gestures | Vary widely in meaning | Avoid gestures |
| Animals | Religious/cultural sensitivities | Research target market |
| Religious symbols | May exclude or offend | Use neutral symbols |

### Photography

| Consideration | Approach |
|---------------|----------|
| Diversity | Represent target audience |
| Gestures | Avoid culture-specific gestures |
| Clothing | Consider cultural norms |
| Settings | Use locally relevant contexts |
| Food | Be aware of dietary restrictions |

---

## Localization Best Practices

### Technical

```javascript
// Use internationalization libraries
const formatter = new Intl.DateTimeFormat('de-DE');
const date = formatter.format(new Date());

const currencyFormatter = new Intl.NumberFormat('ja-JP', {
  style: 'currency',
  currency: 'JPY'
});
const price = currencyFormatter.format(1000);
```

### Content

- Use simple, clear language (easier to translate)
- Avoid idioms and colloquialisms
- Don't hardcode strings (use translation keys)
- Provide context for translators
- Test with pseudo-localization during development

### Design

- Design for flexibility (expanding text)
- Use icons with text (not alone)
- Test layouts in RTL and longest languages
- Consider reading order in complex layouts

---

## Quick Reference Checklist

Before launching internationally:

**Layout:**
- [ ] Supports RTL if targeting Arabic, Hebrew, Persian
- [ ] Text can expand 30% without breaking
- [ ] No text in images
- [ ] Icons are culturally neutral

**Forms:**
- [ ] Name fields are flexible
- [ ] Addresses work without postal codes
- [ ] Phone numbers accept various formats
- [ ] Dates use pickers or clear formats

**Content:**
- [ ] Colors don't carry unintended meaning
- [ ] Images represent target audience
- [ ] No culture-specific idioms
- [ ] Units match target region

**Technical:**
- [ ] Dates, numbers, currency use locale formatting
- [ ] All strings externalized for translation
- [ ] Character encoding supports target languages
- [ ] Font supports required character sets

# Dark Patterns in UX Design

Understanding manipulative design practices to recognize and avoid them. Ethical alternatives that achieve business goals without deceiving users.


## Table of Contents
1. [What Are Dark Patterns?](#what-are-dark-patterns)
2. [Categories of Dark Patterns](#categories-of-dark-patterns)
3. [Regulatory Context](#regulatory-context)
4. [How to Audit for Dark Patterns](#how-to-audit-for-dark-patterns)
5. [Ethical Alternatives That Work](#ethical-alternatives-that-work)
6. [The Business Case Against Dark Patterns](#the-business-case-against-dark-patterns)

---

## What Are Dark Patterns?

Dark patterns are user interface designs that trick users into doing things they didn't intend. They exploit cognitive biases and psychological vulnerabilities for business benefit at user expense.

**Key distinction:**
- Persuasion = helping users make decisions aligned with their goals
- Dark patterns = tricking users into decisions against their interests

---

## Categories of Dark Patterns

### 1. Forced Continuity

**Definition:** Making it easy to sign up for a free trial but difficult to cancel.

**Examples:**
- Require phone call to cancel (but signup was online)
- Bury cancellation in settings maze
- Show "Are you sure?" modals repeatedly
- Require cancellation 30 days before renewal

**Why it's harmful:**
- Users pay for services they don't want
- Exploits inertia and forgetfulness
- Damages trust when discovered

**Ethical alternative:**
- Cancel button as easy to find as signup
- Clear cancellation confirmation (not guilt trips)
- Email reminder before renewal charge
- Allow pause instead of forcing cancel

### 2. Roach Motel

**Definition:** Easy to get into a situation, hard to get out.

**Examples:**
- Account creation takes 1 minute, deletion takes 30 days and support tickets
- Subscribing to emails requires one click, unsubscribing requires login + multiple confirmations
- Joining is free, but exported data costs money

**Why it's harmful:**
- Traps users against their will
- Violates user autonomy
- Often illegal under GDPR and similar regulations

**Ethical alternative:**
- Symmetric design: if X is easy, reversing X should be easy
- Account deletion should be self-service
- Data export should be free and complete
- Unsubscribe = one click

### 3. Privacy Zuckering

**Definition:** Tricking users into sharing more information than intended.

**Examples:**
- Default settings share everything publicly
- "Connect with friends" imports entire contact list
- Profile completion gamification encourages oversharing
- Confusing privacy controls that require expertise

**Why it's harmful:**
- Users lose control of personal information
- Can lead to real-world harm (stalking, discrimination)
- Exploits the complexity of privacy settings

**Ethical alternative:**
- Privacy-respecting defaults (share nothing by default)
- Clear, plain-language privacy explanations
- Granular, understandable controls
- Regular privacy checkups that surface settings

### 4. Bait and Switch

**Definition:** User sets out to do one thing, but something different happens.

**Examples:**
- "X" button that triggers action instead of closing
- "Download" button that's actually an ad
- "Free trial" that immediately charges
- Changing terms after user commits to purchase

**Why it's harmful:**
- Directly deceives users about consequences
- Violates fundamental expectations
- Often results in unwanted charges or actions

**Ethical alternative:**
- Buttons do exactly what they say
- Clear labeling distinguishes ads from content
- Free trials are genuinely free until stated conversion point
- Terms are locked at time of agreement

### 5. Confirmshaming

**Definition:** Using guilt or shame to manipulate users into opting in.

**Examples:**
- "No thanks, I don't want to save money"
- "I'll stay ignorant" (for newsletter)
- "I don't care about my health"
- Imagery showing sad faces for decline option

**Why it's harmful:**
- Manipulates emotions to override rational decision
- Disrespects user autonomy
- Creates negative brand association

**Ethical alternative:**
- Neutral decline options: "No thanks" or "Maybe later"
- Equal visual weight for both choices
- Respect the "no" without comment
- Focus on value proposition, not guilt

### 6. Hidden Costs

**Definition:** Prices or fees revealed only at final checkout.

**Examples:**
- Service fees added at last step
- Required "convenience fees"
- Shipping costs revealed after entering payment info
- "Processing fees" on top of advertised price

**Why it's harmful:**
- Users commit time/effort before learning true cost
- Exploits sunk cost fallacy
- Illegal in many jurisdictions (price must be clear)

**Ethical alternative:**
- Show total cost including all fees upfront
- If fees depend on choices, show estimates early
- Price transparency builds trust
- All-in pricing where possible

### 7. Misdirection

**Definition:** Design draws attention away from important information.

**Examples:**
- Terms and conditions in tiny gray text
- "Yes" button prominent, "No" button hidden
- Pre-selected add-ons that require unchecking
- Important disclaimers below the fold

**Why it's harmful:**
- Prevents informed decision-making
- Hides information users would want to know
- Exploits visual hierarchy against users

**Ethical alternative:**
- Important information is visually prominent
- Both options equally accessible
- Nothing pre-selected that costs money
- Disclaimers at point of relevance, not hidden

### 8. Trick Questions

**Definition:** Confusing wording that leads to unintended choices.

**Examples:**
- "Uncheck to not receive no emails" (double negative)
- Checkboxes that mean opposite things mixed together
- "Continue" meaning "I agree" without stating so
- Questions worded to confuse opt-in vs opt-out

**Why it's harmful:**
- Deliberately confuses users
- Results in choices user didn't mean to make
- Exploits cognitive load

**Ethical alternative:**
- Clear, simple language
- Consistent meaning (check = yes, uncheck = no)
- Explicit confirmation language
- User testing to catch confusing wording

### 9. Sneak into Basket

**Definition:** Items added to cart without user action.

**Examples:**
- Insurance pre-selected during checkout
- "Protection plan" added by default
- Donation to charity checked by default
- Accessories added when buying main product

**Why it's harmful:**
- Users pay for things they didn't choose
- Exploits inattention during checkout
- Often hidden in long checkout flows

**Ethical alternative:**
- Nothing added without explicit user action
- Optional items clearly offered (not pre-selected)
- Cart contents always visible and editable
- Confirmation of what's being purchased

### 10. Urgency & Scarcity (False)

**Definition:** Creating fake urgency or scarcity to pressure decisions.

**Examples:**
- "Only 2 left!" (restocked hourly)
- "This deal expires in 10:00" (resets on refresh)
- "15 people viewing this" (fabricated)
- "Prices increase tomorrow" (they don't)

**Why it's harmful:**
- Pressures users into hasty decisions
- Based on lies (not real scarcity)
- Prevents price comparison and consideration
- Particularly harmful for high-stakes purchases

**Ethical alternative:**
- Only show real inventory counts
- Honest sale end dates
- If scarcity is real, explain why
- Give users time to decide

---

## Regulatory Context

### GDPR (Europe)

Dark patterns affecting consent are illegal:
- Consent must be freely given
- Rejecting must be as easy as accepting
- Pre-ticked boxes invalid for consent
- Bundled consent (all-or-nothing) invalid

### FTC (United States)

The FTC has taken action against:
- Hidden subscription fees
- Difficult cancellation processes
- Misleading "free trial" offers
- Fake urgency and scarcity

### California Privacy Rights Act (CPRA)

Specifically prohibits:
- Dark patterns in opt-out processes
- Requires symmetry in design
- Consent obtained through dark patterns is invalid

---

## How to Audit for Dark Patterns

### Checklist

**Signup/Subscription:**
- [ ] Can users cancel as easily as they signed up?
- [ ] Are renewal terms clear at signup?
- [ ] Is the "free" trial genuinely free?

**Checkout:**
- [ ] Is the total price clear before final step?
- [ ] Are all added items explicitly chosen by user?
- [ ] Are opt-outs as prominent as opt-ins?

**Data/Privacy:**
- [ ] Are privacy settings understandable?
- [ ] Are defaults privacy-respecting?
- [ ] Can users export/delete their data easily?

**General:**
- [ ] Does every button do what it says?
- [ ] Is important information visually prominent?
- [ ] Are decline options neutral (no shaming)?
- [ ] Is urgency/scarcity real?

### The Mirror Test

Ask: "Would I feel comfortable if a journalist wrote about how this works?"

If the answer is no, it's probably a dark pattern.

---

## Ethical Alternatives That Work

### Instead of Forced Continuity

**Business goal:** Retain subscribers

**Ethical approach:**
- Make the product so good they don't want to cancel
- Offer pause option instead of cancel
- Win-back campaigns for churned users
- Ask why they're leaving and address it

### Instead of Hidden Costs

**Business goal:** Competitive-looking prices

**Ethical approach:**
- All-in pricing (include fees in advertised price)
- Compete on value, not deceptive pricing
- Explain what fees cover (transparency builds trust)
- Offer fee-free options (digital delivery, etc.)

### Instead of Confirmshaming

**Business goal:** Higher opt-in rates

**Ethical approach:**
- Stronger value proposition
- Social proof (join 100k subscribers)
- Clear benefit statement
- Respect "no" and try again later

### Instead of False Urgency

**Business goal:** Faster purchase decisions

**Ethical approach:**
- Genuine limited-time offers (and honor them)
- Waitlists for genuinely scarce items
- Early access for committed customers
- Value-based urgency (limited capacity, real deadlines)

---

## The Business Case Against Dark Patterns

### Short-term vs Long-term

| Metric | Dark Pattern Impact | Ethical Design Impact |
|--------|---------------------|----------------------|
| Initial conversion | ↑ Higher | Slightly lower |
| Customer trust | ↓ Lower | ↑ Higher |
| Churn rate | ↑ Higher | ↓ Lower |
| Customer lifetime value | ↓ Lower | ↑ Higher |
| Word of mouth | Negative | Positive |
| Regulatory risk | High | Low |

### Real Costs of Dark Patterns

1. **Support costs** - Dealing with angry customers
2. **Chargeback rates** - Users disputing unwanted charges
3. **Reputation damage** - Social media exposure
4. **Legal fees** - Defending against lawsuits
5. **Regulatory fines** - Increasing enforcement
6. **Employee morale** - Good people don't want to deceive users

### Companies That Changed

Several major companies have eliminated dark patterns after backlash:
- LinkedIn simplified privacy controls after criticism
- Amazon made "Subscribe & Save" more transparent
- Apple added App Store subscription management

The pattern: Short-term thinking creates dark patterns; long-term thinking removes them.

# Resolving Heuristic Conflicts

When usability principles contradict each other—frameworks for making trade-off decisions.

## The Nature of Conflicts

Usability heuristics are guidelines, not laws. In real design, they often pull in opposite directions. Good UX design requires recognizing these tensions and making thoughtful trade-offs.

**Common tension patterns:**
- Simplicity vs. Power
- Consistency vs. Optimal for context
- Efficiency vs. Error prevention
- User control vs. Guidance
- Discoverability vs. Clean interface

---

## Major Heuristic Conflicts

### 1. Simplicity vs. Flexibility

**The tension:**
- "Keep it simple" (Krug, Nielsen)
- "Support user control and freedom" (Nielsen #3)
- "Flexibility and efficiency of use" (Nielsen #7)

**Example:** Photo editing app
- Simple: Few options, quick editing
- Flexible: Many controls, professional results

**Resolution framework:**

| Factor | Lean Simple | Lean Flexible |
|--------|-------------|---------------|
| User expertise | Novice | Expert |
| Task frequency | Occasional | Daily |
| Consequences of error | Low | High |
| Time pressure | High | Low |

**Design patterns:**
- Progressive disclosure (simple default, power underneath)
- Personas-based modes (Basic/Advanced)
- Contextual features (show when relevant)

### 2. Consistency vs. Context Optimization

**The tension:**
- "Consistency and standards" (Nielsen #4)
- "Match between system and real world" (Nielsen #2)

**Example:** Destructive actions
- Consistent: Red "Delete" button everywhere
- Context-optimized: Prominent delete for items that should be deleted, hidden for critical data

**Resolution framework:**

| Factor | Lean Consistent | Lean Contextual |
|--------|-----------------|-----------------|
| User base diversity | High | Low |
| Learning curve concern | Yes | No |
| Action frequency | Common | Rare |
| Mental model strength | Established | Forming |

**Design patterns:**
- Consistent patterns, contextual prominence
- Same actions, different emphasis
- Gradual introduction of contextual variations

### 3. Efficiency vs. Error Prevention

**The tension:**
- "Error prevention" (Nielsen #5)
- "Flexibility and efficiency of use" (Nielsen #7)

**Example:** Checkout flow
- Error prevention: Confirmation at every step
- Efficiency: One-click purchase

**Resolution framework:**

| Factor | Lean Error Prevention | Lean Efficiency |
|--------|----------------------|-----------------|
| Reversibility | Irreversible | Easily undone |
| Cost of error | High (money, data) | Low |
| User familiarity | New users | Power users |
| Frequency | Rare | Very frequent |

**Design patterns:**
- Undo instead of confirm (efficient + safe)
- Confidence-based friction (add steps for risky actions)
- User-controlled safety level

### 4. Discoverability vs. Clean Interface

**The tension:**
- "Recognition rather than recall" (Nielsen #6)
- "Aesthetic and minimalist design" (Nielsen #8)

**Example:** Feature-rich application
- Discoverable: Show all options visibly
- Clean: Hide features until needed

**Resolution framework:**

| Factor | Lean Discoverable | Lean Clean |
|--------|-------------------|------------|
| Feature frequency | Core features | Edge cases |
| User expertise | Beginner | Expert |
| Task complexity | Simple | Complex |
| Screen real estate | Generous | Limited |

**Design patterns:**
- Primary actions visible, secondary in menus
- Progressive disclosure
- Contextual menus
- Search/command palettes for power users

### 5. Guidance vs. User Control

**The tension:**
- Help users avoid errors
- Respect user autonomy

**Example:** Form validation
- Guidance: Prevent submission until valid
- Control: Let users submit and see what happens

**Resolution framework:**

| Factor | Lean Guidance | Lean Control |
|--------|---------------|--------------|
| User expertise | Novice | Expert |
| Error recovery | Difficult | Easy |
| System tolerance | Low (strict rules) | High (flexible) |
| User frustration with restrictions | Low | High |

**Design patterns:**
- Inline guidance (not blocking)
- Warnings vs. blockers
- "Are you sure?" rather than "You can't"

---

## Resolution Framework

### Step 1: Identify the Conflict

Name the specific heuristics in tension:
- Which principle says do A?
- Which principle says do B?
- Why can't we fully satisfy both?

### Step 2: Assess the Context

Consider:
- **User type:** Novice vs. expert
- **Task criticality:** Browsing vs. financial transaction
- **Frequency:** One-time vs. daily
- **Reversibility:** Can they undo?
- **Consequence:** What happens if wrong?

### Step 3: Prioritize for This Context

| Context | Usually Prioritize |
|---------|-------------------|
| Critical data, irreversible | Error prevention > Efficiency |
| Frequent actions, low stakes | Efficiency > Error prevention |
| New users, unfamiliar domain | Guidance > Control |
| Expert users, familiar domain | Flexibility > Simplicity |
| Limited screen, focused task | Minimalism > Discoverability |
| Learning interface | Discoverability > Minimalism |

### Step 4: Design for Both When Possible

Often, clever design satisfies both:

| Conflict | Both-And Solution |
|----------|-------------------|
| Simple vs. Powerful | Progressive disclosure |
| Efficient vs. Safe | Undo instead of confirm |
| Clean vs. Discoverable | Contextual reveal |
| Consistent vs. Optimal | Consistent patterns, variable emphasis |
| Guided vs. Controlled | Warnings, not blockers |

### Step 5: Test the Trade-off

Validate with real users:
- Does the chosen priority work for target users?
- Are edge cases handled acceptably?
- Do users understand why limitations exist?

---

## Common Conflict Scenarios

### Scenario: Onboarding Flow

**Conflict:** Efficiency (skip it) vs. Guidance (require it)

**Resolution:**
- Allow skip but show value
- Defer to contextual moments
- Progressive onboarding during natural use

### Scenario: Mobile Navigation

**Conflict:** Discoverability (show all options) vs. Minimalism (hamburger menu)

**Resolution:**
- Bottom navigation for 3-5 key items
- Hamburger for secondary items
- Tab bar > hamburger for primary navigation

### Scenario: Form Validation

**Conflict:** Error prevention (validate immediately) vs. Efficiency (let them type)

**Resolution:**
- Validate on blur (not on keystroke)
- Show errors inline, not modal
- Allow submission, show all errors

### Scenario: Confirmation Dialogs

**Conflict:** Error prevention (confirm everything) vs. Efficiency (just do it)

**Resolution:**
- Confirm only irreversible/high-cost actions
- Provide undo instead of confirm
- Use clear language about consequences

### Scenario: Default Settings

**Conflict:** User control (let them configure) vs. Simplicity (sensible defaults)

**Resolution:**
- Smart defaults that work for 80%
- Easy access to change settings
- Don't require configuration to start

---

## Decision Documentation

When making trade-off decisions, document:

```markdown
## Design Decision: [Feature]

### Conflict
[Heuristic A] suggests we should...
[Heuristic B] suggests we should...

### Context
- User type: [Novice/Expert]
- Task: [Critical/Casual]
- Frequency: [Daily/Occasional]
- Reversibility: [Yes/No]

### Decision
We chose to prioritize [Heuristic] because...

### Mitigation
We addressed the other concern by...

### Validation
We'll know this is right when...
```

---

## Key Principles

### 1. Context Is King

The same conflict should be resolved differently in different contexts. A banking app and a social media app may reach opposite conclusions.

### 2. Know Your Users

The trade-off depends heavily on user expertise and expectations. Test with real users, not assumptions.

### 3. Design for Both When Possible

Often, the conflict is artificial and clever design can satisfy both principles.

### 4. Make Conscious Trade-offs

Don't accidentally violate a heuristic. Violate it consciously with reasoning.

### 5. Document Decisions

Future you (and your team) will want to know why choices were made.

### 6. Revisit Trade-offs

As products and users evolve, optimal trade-offs may shift. Periodically review past decisions.

# Krug's Usability Principles

Full methodology from "Don't Make Me Think" for creating intuitive, usable interfaces.

## The Reality of How Users Use the Web

### Fact 1: We Don't Read, We Scan

**Why users scan:**
- They're on a mission (have a goal)
- They know they don't need to read everything
- They're good at scanning from years of practice

**Design implications:**
- Create visual hierarchy (important things bigger, bolder)
- Use headings and subheadings liberally
- Keep paragraphs short
- Use bulleted lists
- Highlight key terms

### Fact 2: We Don't Make Optimal Choices, We Satisfice

**Satisficing** = "satisfying" + "sufficing"

Users click the first reasonable option, not the best option.

**Why satisficing:**
- Optimizing is hard and takes time
- The penalty for guessing wrong is low (back button)
- Weighing options doesn't improve results much
- Guessing is more fun

**Design implications:**
- Make the right choice obvious
- Don't rely on users reading all options
- Make consequences clear before clicking

### Fact 3: We Don't Figure Out How Things Work, We Muddle Through

Users don't read instructions. They try things until something works.

**Why muddling through:**
- It's not important to them to know how it works
- If they find something that works, they stick with it
- It rarely matters if they don't use something optimally

**Design implications:**
- Make things obvious so "figuring out" isn't needed
- Expect users to use things "wrong"
- Design for recovery from mistakes

---

## Things You Should Never Do

### Don't Make Users Think

Signs that your page makes users think:

| Symptom | Example |
|---------|---------|
| Puzzling labels | "Solutions" (solutions to what?) |
| Links that could go anywhere | "Click here" |
| Unexplained options | Checkboxes without context |
| Unfamiliar terminology | Industry jargon |
| Gratuitous cleverness | Puns, wordplay in navigation |

### Don't Waste Users' Goodwill

Users have a finite reservoir of goodwill:

**Things that diminish goodwill:**
- Hiding info they need (phone numbers, prices)
- Punishing them for not doing things your way
- Asking for unnecessary information
- Making them feel stupid
- Making them repeat themselves
- Sites that look like an afterthought
- Amateur errors (broken links, typos)

**Things that increase goodwill:**
- Know what questions they have and answer them
- Minimize steps
- Put effort into UI quality
- Know what they're likely to struggle with
- Make it easy to recover from errors
- Apologize when things go wrong

### Don't Make Words Seem Important If They're Not

**Happy talk example:**
> "Welcome to our website! We're excited to help you find exactly what you're looking for. Our team of dedicated professionals is committed to providing you with the best possible experience."

**Reality:** Users skip this. It says nothing.

**Rule:** If users will skip it, remove it.

---

## Navigation Must-Haves

### The Permanent Navigation

Every page needs:

1. **Site ID** (logo/name) - Top left corner
2. **Page name** - Prominent, matches link that brought them
3. **Sections** - Major site areas
4. **Local navigation** - What's in this section
5. **Utilities** - Sign in, Search, Help, Cart
6. **"You are here" indicator** - Highlighted nav item

### The Trunk Test

Can users answer these on any random page?

| Question | Element That Answers It |
|----------|------------------------|
| What site is this? | Logo/Site ID |
| What page am I on? | Page title |
| What major sections exist? | Main navigation |
| What are my options here? | Local navigation |
| Where am I in the structure? | Breadcrumbs, highlighted nav |
| How can I search? | Search box |

### Breadcrumbs

**Good breadcrumbs:**
```
Home > Products > Shoes > Running > Men's Trail Runners
```

**Rules:**
- Put them at the top
- Use ">" between levels
- Make the current page name visible but not a link
- Use small text (secondary importance)

---

## Homepage Guidelines

The homepage has to do too many things:

1. Site identity and mission
2. Site hierarchy (navigation)
3. Search
4. Teases (content, features)
5. Timely content
6. Deals
7. Shortcuts (popular items)
8. Registration/Sign in

### Homepage Priorities

**Must do:**
- Tell me what this site is
- Tell me what I can do here
- Tell me why I should be here (and not somewhere else)
- Start me on my way

**Should do:**
- Show me what I'm looking for
- Show me where to start
- Establish credibility and trust

### The Big Bang Theory of Web Design

**You have 3-4 seconds to answer:**
1. What is this?
2. What can I do here?
3. Why should I be here?

### Tagline Guidelines

| Good Tagline | Bad Tagline |
|--------------|-------------|
| Conveys unique value | Generic platitude |
| Specific and informative | Vague and fluffy |
| 6-8 words | Too long or too short |
| Instantly understandable | Requires thought |

Examples:
- Good: "Find anything from thousands of stores"
- Bad: "Welcome to the future of shopping"

---

## Mobile Usability

### Mobile Considerations

**Constraints:**
- Smaller viewport
- Fat fingers (need bigger targets)
- Single-column layout
- No hover states
- Variable attention and context

### Mobile Specifics

| Issue | Solution |
|-------|----------|
| Tiny tap targets | Minimum 44×44 px |
| Crowded nav | Hamburger or bottom nav |
| Long forms | Break into steps |
| Hover-dependent UI | Alternative for touch |
| Text too small | 16px minimum body text |

### Mobile Trade-offs

**What to prioritize:**
- Primary tasks front and center
- Essential content visible
- Fast load times
- Easy to tap, hard to mis-tap

**What to hide/remove:**
- Secondary navigation
- Non-essential images
- Decorative elements
- Long-form content

---

## Usability Testing on $0

### How Many Users?

**3-4 users catches most issues.**

Testing with more users has diminishing returns. Better to test with 3, fix issues, then test again with 3.

### What to Test

1. Can they complete core tasks?
2. Where do they get stuck?
3. What do they say out loud?
4. What did they expect vs. what happened?

### Test Protocol

**Before:**
- "I'm testing the site, not you"
- "Think out loud as you go"
- "There are no wrong answers"

**During:**
- Don't help. Don't explain. Just watch.
- Note hesitations and confusions
- Write down what they say

**After:**
- Ask what was confusing
- Ask what they expected
- Ask how they'd describe the site

### Common Findings

| What Users Do | What It Means |
|---------------|---------------|
| Click wrong thing | Label is confusing |
| Hesitate | Decision isn't obvious |
| Look around lost | "You are here" is unclear |
| Read everything | Design isn't self-evident |
| Use search immediately | Navigation is failing |
| Express confusion | Copy is unclear |

---

## Accessibility Basics

### Why It Matters

- 15-20% of population has some disability
- Accessible sites are better for everyone
- It's often required by law
- It's the right thing to do

### Quick Wins

| Fix | Benefit |
|-----|---------|
| Add alt text to images | Screen readers can describe |
| Use sufficient contrast | Low-vision users can read |
| Allow keyboard navigation | Motor-impaired users can navigate |
| Use semantic HTML | Assistive tech understands structure |
| Add focus indicators | Keyboard users know where they are |
| Make touch targets large | Everyone benefits |

# Nielsen's 10 Usability Heuristics

Jakob Nielsen's 10 general principles for interaction design, with practical examples and common violations.

## Table of Contents
1. [1. Visibility of System Status](#1-visibility-of-system-status)
2. [2. Match Between System and Real World](#2-match-between-system-and-real-world)
3. [3. User Control and Freedom](#3-user-control-and-freedom)
4. [4. Consistency and Standards](#4-consistency-and-standards)
5. [5. Error Prevention](#5-error-prevention)
6. [6. Recognition Rather Than Recall](#6-recognition-rather-than-recall)
7. [7. Flexibility and Efficiency of Use](#7-flexibility-and-efficiency-of-use)
8. [8. Aesthetic and Minimalist Design](#8-aesthetic-and-minimalist-design)
9. [9. Help Users Recognize, Diagnose, and Recover from Errors](#9-help-users-recognize-diagnose-and-recover-from-errors)
10. [10. Help and Documentation](#10-help-and-documentation)

---

## 1. Visibility of System Status

**Principle:** The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

### Examples of Good Implementation

| Situation | Good Feedback |
|-----------|---------------|
| File uploading | Progress bar with percentage |
| Form submitted | "Your message has been sent" |
| Action processing | Loading spinner |
| Background task | "Syncing 3 files..." notification |
| Successful action | Green checkmark confirmation |

### Common Violations

| Violation | Problem | Fix |
|-----------|---------|-----|
| No loading indicator | User thinks it's broken | Add spinner/progress |
| Silent failures | User thinks action worked | Show error message |
| Delayed feedback | User clicks again | Immediate visual response |
| No confirmation | "Did that work?" | Confirm successful actions |
| Hidden status | User can't find progress | Surface status prominently |

### Severity Examples

- **Minor (1):** Save button has no "saved" confirmation
- **Major (3):** Payment processing with no indicator
- **Catastrophic (4):** Form submit shows nothing, user submits multiple times

---

## 2. Match Between System and Real World

**Principle:** The system should speak the users' language, with words, phrases, and concepts familiar to the user, rather than system-oriented terms.

### Examples of Good Implementation

| System Term | User-Friendly Term |
|-------------|-------------------|
| Authenticate | Sign in |
| Terminate | Cancel / End |
| Query | Search |
| Repository | Folder |
| Navigate to | Go to |
| Initiate | Start |

### Real-World Metaphors

| Digital Element | Real-World Match |
|-----------------|------------------|
| Trash/Recycle bin | Waste basket |
| Folder | File folder |
| Desktop | Physical desk |
| Shopping cart | Store cart |
| Bookmark | Physical bookmark |

### Common Violations

| Violation | Problem | Fix |
|-----------|---------|-----|
| Technical jargon | Confusion | Use plain language |
| Internal names | Meaningless to users | User-tested labels |
| Inconsistent terms | Same thing, different names | One term per concept |
| Unfamiliar icons | Users guess wrong | Add labels or tooltips |
| Illogical order | Not matching expectations | Follow real-world sequences |

---

## 3. User Control and Freedom

**Principle:** Users often choose system functions by mistake and need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue.

### Examples of Good Implementation

| Action | Escape Route |
|--------|--------------|
| Accidentally deleted email | Undo button (Gmail) |
| Wrong menu opened | Click outside to close |
| Filled form incorrectly | Clear form / Reset |
| Navigated wrong | Back button works |
| Started wrong workflow | Cancel / Exit anytime |

### Common Violations

| Violation | Problem | Fix |
|-----------|---------|-----|
| No undo | Users afraid to act | Add undo for all actions |
| Forced wizards | Can't skip or go back | Allow non-linear navigation |
| Modal traps | Can't escape | Clear close/cancel buttons |
| Broken back button | Frustration | Never hijack browser history |
| Immediate deletion | No recovery | Soft delete + undo option |

### Key Principle

**Undo > Confirmation dialogs**

Users click through "Are you sure?" without reading. Undo lets them act confidently.

---

## 4. Consistency and Standards

**Principle:** Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

### Types of Consistency

| Type | Example |
|------|---------|
| **Internal** | Same button style throughout your app |
| **External** | Same patterns as other apps |
| **Visual** | Same colors mean same things |
| **Functional** | Same action = same result |
| **Linguistic** | Same terms for same concepts |

### Platform Conventions

| Element | Convention |
|---------|------------|
| Logo | Top left, links to home |
| Search | Top right, magnifying glass |
| Cart | Top right, shopping cart icon |
| Menu (mobile) | Hamburger icon |
| Primary action | Right side or bottom of form |
| Cancel | Left of primary action (or text link) |

### Common Violations

| Violation | Problem | Fix |
|-----------|---------|-----|
| Different button styles | Confusion about importance | Consistent button hierarchy |
| Same word, different meanings | Misunderstanding | One term per concept |
| Unexpected link behavior | New tab when expecting same tab | Follow conventions |
| Non-standard icons | Guessing game | Use recognized icons |
| Inconsistent layouts | Relearning each page | Template-based layouts |

---

## 5. Error Prevention

**Principle:** Even better than good error messages is a careful design which prevents a problem from occurring in the first place.

### Prevention Strategies

| Strategy | Example |
|----------|---------|
| **Constraints** | Date picker instead of text field |
| **Suggestions** | Autocomplete |
| **Defaults** | Pre-fill common values |
| **Confirmation** | "Delete permanently?" for destructive actions |
| **Warnings** | "Unsaved changes" before leaving |

### Types of Errors to Prevent

| Error Type | Prevention |
|------------|------------|
| **Slips** (accidental) | Confirmation, undo, large targets |
| **Mistakes** (wrong intention) | Clear instructions, better defaults |
| **Data errors** | Validation, formatting help |
| **Navigation errors** | Clear labels, undo |

### Common Violations

| Violation | Problem | Fix |
|-----------|---------|-----|
| Free text for constrained data | Invalid entries | Dropdowns, pickers |
| No save warning | Lost work | "Unsaved changes" prompt |
| Easy destructive actions | Accidental deletion | Require confirmation |
| Accepting bad input | Garbage data | Inline validation |
| Ambiguous choices | Wrong selection | Clear differentiation |

---

## 6. Recognition Rather Than Recall

**Principle:** Minimize the user's memory load by making objects, actions, and options visible. Don't require users to remember information.

### Recognition Techniques

| Instead of | Do This |
|------------|---------|
| User remembers command | Show menu of options |
| User types from memory | Dropdown/autocomplete |
| User remembers where they were | Breadcrumbs, recent history |
| User remembers codes | Show decoded values |
| User recalls previous info | Show previous entries |

### Examples

| Bad (Recall) | Good (Recognition) |
|--------------|-------------------|
| "Enter country code" | Dropdown with country names |
| Command-line interface | Graphical menus |
| "See page 47 for options" | Options shown in context |
| "Re-enter your email" | Pre-filled from previous step |
| Complex keyboard shortcuts | Visible toolbar buttons |

### Common Violations

| Violation | Problem | Fix |
|-----------|---------|-----|
| Empty form fields | User must remember format | Placeholder examples |
| Hidden actions | User forgets they exist | Keep visible or in menus |
| No recent items | User re-searches | Show search history |
| Unlabeled icons | User guesses meaning | Add text labels |
| Disconnected workflows | User loses context | Show progress, breadcrumbs |

---

## 7. Flexibility and Efficiency of Use

**Principle:** Accelerators—unseen by the novice user—may often speed up the interaction for the expert user. Allow users to tailor frequent actions.

### Accelerators for Experts

| Feature | Example |
|---------|---------|
| **Keyboard shortcuts** | Ctrl+S to save |
| **Touch gestures** | Swipe to archive |
| **Recent/Favorites** | Quick access to common items |
| **Saved searches** | One-click complex queries |
| **Customization** | Personalized dashboard |
| **Bulk actions** | Select all + action |

### Progressive Disclosure

| User Level | What They See |
|------------|---------------|
| Novice | Essential features only |
| Intermediate | Common advanced options |
| Expert | Full power (shortcuts, customization) |

### Common Violations

| Violation | Problem | Fix |
|-----------|---------|-----|
| No shortcuts | Experts slowed down | Add keyboard shortcuts |
| No bulk operations | Tedious repetition | Add multi-select |
| Required tutorials | Experts frustrated | Allow skipping |
| Hidden power features | Experts don't find them | Discoverable advanced mode |
| No customization | Forced workflows | Allow personalization |

---

## 8. Aesthetic and Minimalist Design

**Principle:** Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information competes with the relevant units.

### Principles

| Principle | Application |
|-----------|-------------|
| **Signal/Noise** | Increase signal, reduce noise |
| **Visual hierarchy** | Important things stand out |
| **Whitespace** | Give elements room to breathe |
| **Content priority** | Show what matters, hide what doesn't |
| **Progressive disclosure** | Complexity on demand |

### What to Remove

| Remove | Why |
|--------|-----|
| Rarely-used features | Clutter |
| Decorative elements | Distraction |
| Redundant text | Noise |
| Unnecessary options | Decision fatigue |
| Instructions users skip | Wasted space |

### Common Violations

| Violation | Problem | Fix |
|-----------|---------|-----|
| Cluttered screens | Overwhelming | Remove/hide secondary |
| Everything is "important" | Nothing stands out | Create hierarchy |
| Long blocks of text | Nobody reads | Break up, summarize |
| Too many colors | Visual noise | Limit palette |
| Dense layouts | Hard to scan | Add whitespace |

---

## 9. Help Users Recognize, Diagnose, and Recover from Errors

**Principle:** Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

### Good Error Message Components

1. **What happened** (plain language)
2. **Why it happened** (if helpful)
3. **How to fix it** (specific action)

### Examples

| Bad Error | Good Error |
|-----------|------------|
| "Error 500" | "Something went wrong. Please try again." |
| "Invalid input" | "Email must include @" |
| "Failed" | "Payment declined. Check card number or try different card." |
| "Null reference exception" | "We couldn't load your data. Refresh the page." |

### Error Message Guidelines

| Guideline | Example |
|-----------|---------|
| Use plain language | "Connection failed" not "ECONNREFUSED" |
| Be specific | "Password too short" not "Invalid password" |
| Provide action | "Try again" button visible |
| Don't blame user | "Card declined" not "You entered wrong info" |
| Maintain context | Keep filled data, highlight error field |

### Common Violations

| Violation | Problem | Fix |
|-----------|---------|-----|
| Technical jargon | Confusion | Translate to plain English |
| No solution | User stuck | Include next steps |
| Generic messages | Not helpful | Be specific |
| Blaming language | Defensive users | Neutral, helpful tone |
| Clearing form on error | Punishment | Preserve user input |

---

## 10. Help and Documentation

**Principle:** Even though it's better if the system can be used without documentation, it may be necessary to provide help and documentation. Such information should be easy to search, focused on the user's task, and not be too large.

### Characteristics of Good Help

| Characteristic | Implementation |
|----------------|----------------|
| **Searchable** | Full-text search |
| **Task-focused** | "How to..." format |
| **Contextual** | In-page tooltips |
| **Scannable** | Short paragraphs, lists |
| **Actionable** | Step-by-step instructions |

### Types of Help

| Type | When to Use |
|------|-------------|
| **Inline help** | Tooltips, hints | Next to complex fields |
| **Contextual help** | "?" icons | For non-obvious features |
| **Searchable docs** | Knowledge base | For detailed questions |
| **Guided tours** | Onboarding | First-time users |
| **Chat/Support** | Complex issues | When self-service fails |

### Common Violations

| Violation | Problem | Fix |
|-----------|---------|-----|
| No search in docs | Can't find answers | Add search |
| Long documentation | Nobody reads | Concise, task-focused |
| Generic help | Doesn't answer question | Specific to feature/page |
| Hidden help | Users can't find it | Visible help links |
| No contextual help | Users leave page | Inline tooltips |

# WCAG 2.1 AA Checklist

Complete checklist for WCAG 2.1 Level AA compliance with testing guidance.


## Table of Contents
1. [Perceivable](#perceivable)
2. [Operable](#operable)
3. [Understandable](#understandable)
4. [Robust](#robust)
5. [Testing Tools](#testing-tools)
6. [Quick Reference: Common Failures](#quick-reference-common-failures)
7. [Testing Checklist Summary](#testing-checklist-summary)

---

## Perceivable

Content must be presentable in ways users can perceive.

### 1.1 Text Alternatives

| Criterion | Requirement | How to Test |
|-----------|-------------|-------------|
| 1.1.1 Non-text Content | All images, icons, and visual content have text alternatives | Inspect alt attributes; use screen reader |

**Pass criteria:**
- [ ] Informative images have descriptive alt text
- [ ] Decorative images have empty alt (`alt=""`)
- [ ] Complex images (charts, diagrams) have extended descriptions
- [ ] Icons have accessible names
- [ ] CAPTCHA provides audio alternative

### 1.2 Time-based Media

| Criterion | Requirement | How to Test |
|-----------|-------------|-------------|
| 1.2.1 Audio/Video (prerecorded) | Captions and/or transcripts | Check video player for captions |
| 1.2.2 Captions | Synchronized captions for video | Watch with captions on |
| 1.2.3 Audio Description | Description of visual content | Check for AD track |
| 1.2.5 Audio Description (AA) | Audio description for all video | Verify AD available |

**Pass criteria:**
- [ ] Videos have synchronized captions
- [ ] Captions are accurate and complete
- [ ] Audio descriptions available for important visual content
- [ ] Transcripts available for audio-only content

### 1.3 Adaptable

| Criterion | Requirement | How to Test |
|-----------|-------------|-------------|
| 1.3.1 Info and Relationships | Semantic structure preserved | Inspect HTML; use screen reader |
| 1.3.2 Meaningful Sequence | Content order makes sense | Disable CSS; read in DOM order |
| 1.3.3 Sensory Characteristics | Don't rely on shape/color/position alone | Check instructions |
| 1.3.4 Orientation (AA) | Works in portrait and landscape | Rotate device |
| 1.3.5 Identify Input Purpose (AA) | Input fields have autocomplete | Check `autocomplete` attributes |

**Pass criteria:**
- [ ] Headings use proper h1-h6 hierarchy
- [ ] Lists use `<ul>`, `<ol>`, `<dl>` elements
- [ ] Forms have proper labels associated with inputs
- [ ] Tables have headers marked with `<th>`
- [ ] Reading order is logical without CSS
- [ ] Works in both orientations
- [ ] Input fields have appropriate autocomplete values

### 1.4 Distinguishable

| Criterion | Requirement | How to Test |
|-----------|-------------|-------------|
| 1.4.1 Use of Color | Color not sole means of info | View in grayscale |
| 1.4.2 Audio Control | Auto-playing audio can be stopped | Check for controls |
| 1.4.3 Contrast (Minimum) | 4.5:1 text, 3:1 large text | Use contrast checker |
| 1.4.4 Resize Text | Readable at 200% zoom | Zoom browser |
| 1.4.5 Images of Text | Use real text, not images | Inspect for text images |
| 1.4.10 Reflow (AA) | No horizontal scroll at 320px | Test at narrow width |
| 1.4.11 Non-text Contrast (AA) | 3:1 for UI components | Check buttons, inputs |
| 1.4.12 Text Spacing (AA) | Survives increased text spacing | Apply spacing override |
| 1.4.13 Content on Hover/Focus (AA) | Hoverable, dismissible, persistent | Test tooltips, menus |

**Pass criteria:**
- [ ] Normal text has 4.5:1 contrast ratio minimum
- [ ] Large text (18pt+) has 3:1 contrast ratio minimum
- [ ] UI components have 3:1 contrast
- [ ] Text resizes to 200% without loss
- [ ] No horizontal scrolling at 320px width
- [ ] Tooltips are dismissible, hoverable, persistent
- [ ] Color alone doesn't convey meaning

---

## Operable

Users must be able to operate the interface.

### 2.1 Keyboard Accessible

| Criterion | Requirement | How to Test |
|-----------|-------------|-------------|
| 2.1.1 Keyboard | All functionality works with keyboard | Navigate with Tab, Enter, Space |
| 2.1.2 No Keyboard Trap | Focus can always move away | Tab through everything |
| 2.1.4 Character Key Shortcuts (AA) | Single-key shortcuts can be disabled | Check for shortcut conflicts |

**Pass criteria:**
- [ ] All interactive elements are focusable
- [ ] All actions can be performed via keyboard
- [ ] Focus is never trapped
- [ ] Single-key shortcuts can be disabled or remapped
- [ ] Tab order follows logical sequence

### 2.2 Enough Time

| Criterion | Requirement | How to Test |
|-----------|-------------|-------------|
| 2.2.1 Timing Adjustable | Users can extend/disable time limits | Check for timeouts |
| 2.2.2 Pause, Stop, Hide | Auto-updating content can be controlled | Check carousels, animations |

**Pass criteria:**
- [ ] Session timeouts have 20-second warning
- [ ] Users can extend time limits
- [ ] Auto-playing content has pause control
- [ ] Animations can be stopped

### 2.3 Seizures

| Criterion | Requirement | How to Test |
|-----------|-------------|-------------|
| 2.3.1 Three Flashes | No content flashes >3 times/second | Measure flash rate |

**Pass criteria:**
- [ ] No flashing content above threshold
- [ ] Animations don't cause seizure risk

### 2.4 Navigable

| Criterion | Requirement | How to Test |
|-----------|-------------|-------------|
| 2.4.1 Bypass Blocks | Skip links to bypass repeated content | Check for skip link |
| 2.4.2 Page Titled | Pages have descriptive titles | Check `<title>` element |
| 2.4.3 Focus Order | Focus sequence is logical | Tab through page |
| 2.4.4 Link Purpose | Link text describes destination | Read links out of context |
| 2.4.5 Multiple Ways (AA) | Multiple ways to find pages | Check nav, search, sitemap |
| 2.4.6 Headings and Labels (AA) | Headings and labels are descriptive | Review all headings |
| 2.4.7 Focus Visible (AA) | Focus indicator is visible | Tab through interface |

**Pass criteria:**
- [ ] Skip link present at top of page
- [ ] Page titles are unique and descriptive
- [ ] Tab order follows visual order
- [ ] Link text is meaningful ("Read more about X" not "Click here")
- [ ] Multiple navigation methods available
- [ ] All headings are descriptive
- [ ] Focus indicator is clearly visible

### 2.5 Input Modalities

| Criterion | Requirement | How to Test |
|-----------|-------------|-------------|
| 2.5.1 Pointer Gestures (AA) | Complex gestures have simple alternatives | Check for alternatives |
| 2.5.2 Pointer Cancellation (AA) | Actions on up-event, cancelable | Test click/drag behavior |
| 2.5.3 Label in Name (AA) | Accessible name contains visible label | Compare visible/accessible names |
| 2.5.4 Motion Actuation (AA) | Motion-based actions have alternatives | Check for non-motion options |

**Pass criteria:**
- [ ] Pinch, swipe have tap alternatives
- [ ] Click actions happen on release (up-event)
- [ ] Dragging outside target cancels action
- [ ] Accessible names include visible text
- [ ] Shake/tilt actions have button alternatives

---

## Understandable

Content must be understandable to users.

### 3.1 Readable

| Criterion | Requirement | How to Test |
|-----------|-------------|-------------|
| 3.1.1 Language of Page | Page language specified | Check `<html lang="">` |
| 3.1.2 Language of Parts (AA) | Foreign text marked with lang | Check multilingual content |

**Pass criteria:**
- [ ] HTML has lang attribute
- [ ] Foreign language passages have lang attribute

### 3.2 Predictable

| Criterion | Requirement | How to Test |
|-----------|-------------|-------------|
| 3.2.1 On Focus | Focus doesn't cause unexpected changes | Tab through all elements |
| 3.2.2 On Input | Input doesn't cause unexpected changes | Fill forms without submitting |
| 3.2.3 Consistent Navigation (AA) | Navigation is consistent across pages | Compare pages |
| 3.2.4 Consistent Identification (AA) | Same functions have same labels | Compare repeated elements |

**Pass criteria:**
- [ ] Focus doesn't trigger context changes
- [ ] Selecting options doesn't submit forms
- [ ] Navigation is in same location on all pages
- [ ] Same icons/labels used for same functions

### 3.3 Input Assistance

| Criterion | Requirement | How to Test |
|-----------|-------------|-------------|
| 3.3.1 Error Identification | Errors clearly identified | Submit invalid forms |
| 3.3.2 Labels or Instructions | Labels and instructions provided | Review all forms |
| 3.3.3 Error Suggestion (AA) | Suggestions for fixing errors | Trigger errors |
| 3.3.4 Error Prevention (AA) | Confirmation for legal/financial actions | Test critical submissions |

**Pass criteria:**
- [ ] Errors are clearly described in text
- [ ] Error messages explain how to fix
- [ ] All inputs have visible labels
- [ ] Required fields are indicated
- [ ] Legal/financial submissions are reversible or confirmed

---

## Robust

Content must work with assistive technologies.

### 4.1 Compatible

| Criterion | Requirement | How to Test |
|-----------|-------------|-------------|
| 4.1.1 Parsing | Valid HTML | Run HTML validator |
| 4.1.2 Name, Role, Value | ARIA used correctly | Inspect with accessibility tools |
| 4.1.3 Status Messages (AA) | Status updates announced | Test with screen reader |

**Pass criteria:**
- [ ] HTML is valid (no duplicate IDs, proper nesting)
- [ ] Custom controls have appropriate roles
- [ ] States (expanded, selected) are programmatically set
- [ ] Status messages use aria-live regions

---

## Testing Tools

### Automated Testing

| Tool | What It Catches | Use For |
|------|-----------------|---------|
| axe DevTools | ~30% of issues | Quick scan |
| WAVE | Similar to axe | Visual overlay |
| Lighthouse | Basic accessibility | CI/CD integration |
| Pa11y | CLI-based | Automated testing |

### Manual Testing Required

| Area | How to Test |
|------|-------------|
| Keyboard navigation | Unplug mouse, use only keyboard |
| Screen reader | VoiceOver (Mac), NVDA (Windows) |
| Zoom | Browser zoom to 200%, 400% |
| Color contrast | WebAIM Contrast Checker |
| Color blindness | Sim Daltonism, Chrome DevTools |

### Screen Reader Testing

**VoiceOver (Mac):**
1. Enable: Cmd + F5
2. Navigate: VO (Ctrl + Opt) + arrows
3. Rotor: VO + U (headings, links, forms)

**NVDA (Windows):**
1. Download free from nvaccess.org
2. Navigate: Arrow keys, Tab
3. Elements list: NVDA + F7

---

## Quick Reference: Common Failures

| Issue | Failure | Fix |
|-------|---------|-----|
| Missing alt text | 1.1.1 | Add descriptive alt or `alt=""` |
| Low contrast | 1.4.3 | Increase to 4.5:1 (text) or 3:1 (large/UI) |
| No focus indicator | 2.4.7 | Add visible :focus-visible styles |
| Keyboard inaccessible | 2.1.1 | Make interactive, add tabindex=0 |
| Missing form labels | 1.3.1, 3.3.2 | Add `<label>` with `for` attribute |
| No skip link | 2.4.1 | Add "Skip to content" link |
| Missing page title | 2.4.2 | Add descriptive `<title>` |
| Color-only meaning | 1.4.1 | Add icon or text alongside |
| No lang attribute | 3.1.1 | Add `<html lang="en">` |
| Ambiguous links | 2.4.4 | Use descriptive link text |

---

## Testing Checklist Summary

Before launch, verify:

**Automated scan:**
- [ ] axe DevTools shows 0 issues
- [ ] Lighthouse accessibility score >90

**Keyboard:**
- [ ] All functionality works with keyboard
- [ ] Focus visible on all elements
- [ ] No keyboard traps
- [ ] Skip link works

**Screen reader:**
- [ ] All content announced correctly
- [ ] Form fields have labels
- [ ] Images have alt text
- [ ] Headings create logical outline

**Visual:**
- [ ] All text meets contrast requirements
- [ ] Works at 200% zoom
- [ ] Works at 320px width (mobile)
- [ ] Color not sole indicator