Everyone-Needs-A-Copilot UX Patterns
Patterns for designing task flows, service blueprints, wireframes, and user interactions with comprehensive state coverage.
Purpose
Provides patterns for:
- Task flows with all user paths
- Service blueprints (frontstage/backstage)
- Wireframe specifications
- Error and empty state design
- Accessibility from the start
Core Patterns
Pattern 1: Task Flow Structure
When to use: Defining any user interaction flow.
Implementation:
## Task Flow: [Name]
**User Goal:** What they want to accomplish
**Entry Point:** Where they start
**Success:** How they know they succeeded
### Primary Path
1. [Action] -> [Response] -> [State]
2. [Action] -> [Response] -> [State]
3. [Action] -> [Response] -> [Success]
### Alternative Paths
- [Condition] -> [Alternative flow]
### Error States
| Error | Message | Recovery |
|-------|---------|----------|
| [Error] | [What happened + How to fix] | [User action] |
Benefits:
- Clear success criteria
- All paths documented
- Error recovery built-in
Pattern 2: Service Blueprint
When to use: Mapping end-to-end service experiences.
Implementation:
## Service Blueprint: [Name]
### Journey Stages
[Awareness] -> [Consideration] -> [Purchase] -> [Use] -> [Support]
### Customer Actions (per stage)
| Stage | Actions |
|-------|---------|
| [Stage] | [What customer does] |
### Frontstage (Visible)
| [Touchpoint] | [Touchpoint] | [Touchpoint] |
### Line of Visibility
---
### Backstage (Invisible)
| [Process] | [Process] | [Process] |
### Support Processes
| [System] | [System] | [System] |
### Pain Points
- **[Stage]:** [Issue] - [Evidence]
### Opportunities
- **[Stage]:** [Improvement] - [Impact]
Pattern 3: State Coverage Matrix
When to use: Ensuring all UI states are designed.
Implementation:
| State | When | Content | Action |
|---|---|---|---|
| Default | Normal use | Full content | Primary action |
| Loading | Fetching data | Skeleton/spinner | Disabled actions |
| Empty | No data yet | Why empty + CTA | Create/Add action |
| Error | Operation failed | What + How to fix | Retry/Fix action |
| Success | Action completed | Confirmation | Next action |
| Partial | Some data | Available content | Load more |
Anti-Patterns
Anti-Pattern 1: Assumption-Based Design
| Aspect | Description |
|---|---|
| WHY | Leads to unusable products, wasted effort, user frustration |
| DETECTION | No user research cited, no evidence for design decisions |
| FIX | Ground every design decision in user research or data |
Bad Example:
Users will want a dashboard on login.
Good Example:
Research shows 78% of users check status immediately after login.
Evidence: User interviews (n=12), analytics showing /dashboard as top page.
Anti-Pattern 2: Missing States
| Aspect | Description |
|---|---|
| WHY | Users encounter undesigned situations, broken experience |
| DETECTION | Only happy path designed, no empty/error/loading states |
| FIX | Design ALL states: default, loading, empty, error, success, partial |
Anti-Pattern 3: Color as Sole Indicator
| Aspect | Description |
|---|---|
| WHY | Excludes colorblind users (8% of men), fails WCAG |
| DETECTION | Status shown only via red/green/yellow color |
| FIX | Always add icons, text, or patterns alongside color |
Bad Example:
[Red dot] Failed [Green dot] Success
Good Example:
[X icon] Failed [Checkmark icon] Success
Anti-Pattern 4: Vague Error Messages
| Aspect | Description |
|---|---|
| WHY | Users can't recover, support burden increases |
| DETECTION | "Error", "Invalid input", "Something went wrong" |
| FIX | Error format: [What happened] + [How to fix it] |
Bad Example:
Invalid input
Good Example:
Email format looks wrong. Try: name@example.com
Accessibility Requirements
Keyboard Navigation
- All interactive elements reachable via Tab
- Logical tab order (left-right, top-bottom)
- Enter/Space activate buttons
- Escape closes modals
- Arrow keys navigate within components
Focus Management
- Focus visible at all times (2px outline minimum)
- Focus moves logically (not trapped)
- Focus returns to trigger after modal closes
- Skip links for long navigation
Screen Reader Support
- Semantic HTML (button, nav, main, article)
- ARIA labels for icons and images
- Live regions for dynamic content (role="status")
- Announcements for state changes
Validation Checklist
Task Flows
- User goal clearly defined
- Entry point and success criteria specified
- All alternative paths documented
- Error states with recovery actions
States
- Default state designed
- Loading state with feedback
- Empty state with explanation + CTA
- Error state with [What happened] + [How to fix]
- Success state with confirmation
Accessibility
- Keyboard navigation tested
- Focus order is logical
- Screen reader announcements planned
- No color-only indicators
Output Templates
Task Flow
## Task Flow: [Task Name]
**User Goal:** [What user wants]
**Entry Point:** [Where they start]
**Success:** [How they know done]
### Primary Path
1. [Action] -> [Response] -> [State]
### Error States
| Error | Message | Recovery |
|-------|---------|----------|
| [Error] | [What + Fix] | [Action] |
Wireframe
## Wireframe: [Screen Name]
### Purpose
[What this screen accomplishes]
### Components
| Component | Behavior | States |
|-----------|----------|--------|
| [Name] | [Function] | Default, Hover, Focus, Error |
### Accessibility
- Tab order: [Sequence]
- Screen reader: [Announcements]
- Focus: [Visible states]
Empty State
## Empty State: [Context]
**Headline:** [What this is]
**Body:** [Why it's empty]
**CTA:** [Primary action button]
**Secondary:** [Alternative action or help]