Initial commit
This commit is contained in:
Zhongwei Li
@@ -0,0 +1,611 @@
|
||||
# Accessibility Guidelines for Design Briefs
|
||||
|
||||
Comprehensive accessibility requirements and best practices for design projects.
|
||||
|
||||
---
|
||||
|
||||
## Why Accessibility Matters
|
||||
|
||||
**Legal:** ADA, Section 508, AODA compliance
|
||||
**Business:** 15% of the world has a disability - that's your potential users
|
||||
**Ethical:** Everyone deserves equal access to digital experiences
|
||||
**Technical:** Accessible design is better design for everyone
|
||||
|
||||
---
|
||||
|
||||
## WCAG 2.1 Overview
|
||||
|
||||
### Compliance Levels
|
||||
|
||||
**Level A (Minimum):**
|
||||
- Basic web accessibility features
|
||||
- Legal requirement in many jurisdictions
|
||||
- Addresses most critical barriers
|
||||
|
||||
**Level AA (Recommended):**
|
||||
- Addresses most common barriers
|
||||
- Gold standard for most organizations
|
||||
- Required by many laws (EU, Canada, US Section 508)
|
||||
|
||||
**Level AAA (Enhanced):**
|
||||
- Highest level of accessibility
|
||||
- Not required for general compliance
|
||||
- Often not feasible for all content
|
||||
|
||||
**Recommendation:** Target WCAG 2.1 Level AA for most projects.
|
||||
|
||||
---
|
||||
|
||||
## Four Principles (POUR)
|
||||
|
||||
### 1. Perceivable
|
||||
Information and UI components must be presentable to users in ways they can perceive.
|
||||
|
||||
### 2. Operable
|
||||
UI components and navigation must be operable by all users.
|
||||
|
||||
### 3. Understandable
|
||||
Information and UI operation must be understandable.
|
||||
|
||||
### 4. Robust
|
||||
Content must be robust enough to work with current and future technologies.
|
||||
|
||||
---
|
||||
|
||||
## Key Requirements by Category
|
||||
|
||||
### Visual Design
|
||||
|
||||
#### Color & Contrast
|
||||
**Requirement:** Minimum contrast ratios
|
||||
- **Normal text:** 4.5:1 (Level AA) or 7:1 (Level AAA)
|
||||
- **Large text (18pt+):** 3:1 (Level AA) or 4.5:1 (Level AAA)
|
||||
- **UI components:** 3:1 for active elements
|
||||
|
||||
**Best Practices:**
|
||||
- Don't rely on color alone to convey information
|
||||
- Use patterns, icons, or labels in addition to color
|
||||
- Test in grayscale to verify information hierarchy
|
||||
- Consider color blindness (8% of males, 0.5% of females)
|
||||
|
||||
**Tools:**
|
||||
- [WebAIM Contrast Checker](https://webaim.org/resources/contrastchecker/)
|
||||
- [Contrast Ratio](https://contrast-ratio.com/)
|
||||
- Figma plugins: Stark, A11y - Color Contrast Checker
|
||||
|
||||
#### Typography
|
||||
**Requirements:**
|
||||
- Text must be resizable up to 200% without loss of content
|
||||
- Line height at least 1.5x font size
|
||||
- Paragraph spacing at least 2x font size
|
||||
- Letter spacing at least 0.12x font size
|
||||
- Word spacing at least 0.16x font size
|
||||
|
||||
**Best Practices:**
|
||||
- Minimum body text size: 16px
|
||||
- Use relative units (rem, em) not absolute (px)
|
||||
- Avoid ALL CAPS for long text
|
||||
- Left-align text (not justified)
|
||||
- Break long content into shorter paragraphs
|
||||
- Use clear, simple language
|
||||
|
||||
#### Focus Indicators
|
||||
**Requirement:** Keyboard focus must be visible
|
||||
|
||||
**Best Practices:**
|
||||
- Focus indicator contrast ratio: 3:1 minimum
|
||||
- Don't remove default focus styles without replacement
|
||||
- Use outline or border (not just background color change)
|
||||
- Maintain focus order that follows visual layout
|
||||
- Show focus on all interactive elements
|
||||
|
||||
---
|
||||
|
||||
### Interaction Design
|
||||
|
||||
#### Keyboard Navigation
|
||||
**Requirements:**
|
||||
- All functionality available via keyboard
|
||||
- No keyboard traps
|
||||
- Logical tab order
|
||||
- Skip links for repetitive content
|
||||
|
||||
**Tab Order:**
|
||||
1. Header navigation
|
||||
2. Main content
|
||||
3. Sidebar (if present)
|
||||
4. Footer
|
||||
|
||||
**Keyboard Shortcuts:**
|
||||
- `Tab` - Move forward through interactive elements
|
||||
- `Shift + Tab` - Move backward
|
||||
- `Enter` - Activate buttons/links
|
||||
- `Space` - Activate buttons, toggle checkboxes
|
||||
- `Arrow keys` - Navigate within components (menus, radio groups)
|
||||
- `Esc` - Close modals/menus
|
||||
|
||||
**Best Practices:**
|
||||
- Add "Skip to main content" link
|
||||
- Ensure modals trap focus appropriately
|
||||
- Return focus when closing overlays
|
||||
- Document custom keyboard shortcuts
|
||||
|
||||
#### Touch Targets
|
||||
**Requirements:**
|
||||
- Minimum touch target size: 44×44px (Level AA)
|
||||
- Adequate spacing between targets
|
||||
|
||||
**Best Practices:**
|
||||
- 48×48px or larger for important actions
|
||||
- At least 8px spacing between touch targets
|
||||
- Enlarge hit areas beyond visible element
|
||||
- Consider thumb reach zones on mobile
|
||||
|
||||
#### Time Limits
|
||||
**Requirements:**
|
||||
- Users can extend, adjust, or turn off time limits
|
||||
- 20-hour minimum for inactive sessions
|
||||
- Warning before timeout
|
||||
|
||||
**Best Practices:**
|
||||
- Avoid auto-advancing carousels
|
||||
- Pause auto-playing media
|
||||
- Save user progress
|
||||
- Warn 60+ seconds before timeout
|
||||
|
||||
#### Motion & Animation
|
||||
**Requirements:**
|
||||
- Respect `prefers-reduced-motion` setting
|
||||
- No flashing content (> 3 flashes/second)
|
||||
- Provide pause controls for moving content
|
||||
|
||||
**Best Practices:**
|
||||
```css
|
||||
@media (prefers-reduced-motion: reduce) {
|
||||
* {
|
||||
animation-duration: 0.01ms !important;
|
||||
transition-duration: 0.01ms !important;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Content & Information
|
||||
|
||||
#### Alternative Text
|
||||
**Requirements:**
|
||||
- All images have alt text
|
||||
- Decorative images have empty alt (`alt=""`)
|
||||
- Complex images have detailed descriptions
|
||||
|
||||
**Alt Text Guidelines:**
|
||||
- Describe content and function, not appearance
|
||||
- Keep under 150 characters
|
||||
- Don't start with "Image of" or "Picture of"
|
||||
- For decorative images: `alt=""`
|
||||
- For complex diagrams: Use `aria-describedby` or long description
|
||||
|
||||
**Examples:**
|
||||
- ❌ "Image of a dog"
|
||||
- ✅ "Golden retriever playing fetch in a park"
|
||||
- ❌ "Click here button"
|
||||
- ✅ "Submit registration form"
|
||||
|
||||
#### Headings
|
||||
**Requirements:**
|
||||
- Logical heading structure (H1 → H2 → H3)
|
||||
- Don't skip heading levels
|
||||
- H1 used once per page
|
||||
|
||||
**Best Practices:**
|
||||
```html
|
||||
<h1>Page Title</h1>
|
||||
<h2>Section 1</h2>
|
||||
<h3>Subsection</h3>
|
||||
<h2>Section 2</h2>
|
||||
<h3>Subsection</h3>
|
||||
```
|
||||
|
||||
#### Links
|
||||
**Requirements:**
|
||||
- Link text describes destination
|
||||
- Links distinguishable from surrounding text
|
||||
|
||||
**Best Practices:**
|
||||
- ❌ "Click here" or "Read more"
|
||||
- ✅ "Read the design brief guidelines"
|
||||
- ❌ URL as link text (https://example.com)
|
||||
- ✅ Descriptive text with URL in title
|
||||
- Indicate when links open in new windows
|
||||
- Underline links in body text
|
||||
|
||||
#### Forms
|
||||
**Requirements:**
|
||||
- Labels for all inputs
|
||||
- Error messages clearly identify problems
|
||||
- Instructions provided where needed
|
||||
- Group related form elements
|
||||
|
||||
**Best Practices:**
|
||||
```html
|
||||
<label for="email">Email Address</label>
|
||||
<input id="email" type="email" required
|
||||
aria-describedby="email-hint">
|
||||
<span id="email-hint">We'll never share your email</span>
|
||||
```
|
||||
|
||||
- Place labels above or beside inputs (not inside)
|
||||
- Use `<fieldset>` and `<legend>` for groups
|
||||
- Provide inline validation
|
||||
- Clear error messages with solutions
|
||||
- Disable submit until required fields complete
|
||||
|
||||
#### Tables
|
||||
**Requirements:**
|
||||
- Use table headers (`<th>`)
|
||||
- Associate headers with data cells
|
||||
- Provide table caption or summary
|
||||
|
||||
**Best Practices:**
|
||||
```html
|
||||
<table>
|
||||
<caption>Project Timeline</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th scope="col">Phase</th>
|
||||
<th scope="col">Duration</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th scope="row">Discovery</th>
|
||||
<td>2 weeks</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Component-Specific Guidelines
|
||||
|
||||
#### Modals & Dialogs
|
||||
- Focus first element when opened
|
||||
- Trap focus within modal
|
||||
- Close with Esc key
|
||||
- Return focus when closed
|
||||
- Use `role="dialog"` and `aria-modal="true"`
|
||||
- Provide accessible close button
|
||||
|
||||
#### Carousels
|
||||
- Pause on hover/focus
|
||||
- Keyboard controls to navigate
|
||||
- Don't auto-advance (or make stoppable)
|
||||
- Indicate current slide
|
||||
- All controls keyboard accessible
|
||||
|
||||
#### Navigation
|
||||
- Skip to main content link
|
||||
- Keyboard accessible dropdowns
|
||||
- Clear current page indicator
|
||||
- Breadcrumb trail when appropriate
|
||||
- Mobile menu keyboard accessible
|
||||
|
||||
#### Forms with Multiple Steps
|
||||
- Indicate current step and total steps
|
||||
- Allow navigation between steps
|
||||
- Save progress
|
||||
- Review before submit
|
||||
- Accessible progress indicator
|
||||
|
||||
#### Search
|
||||
- Label search input clearly
|
||||
- Announce results to screen readers
|
||||
- Show result count
|
||||
- Support keyboard navigation of results
|
||||
|
||||
---
|
||||
|
||||
## Screen Reader Considerations
|
||||
|
||||
### ARIA (Accessible Rich Internet Applications)
|
||||
|
||||
**Core Principles:**
|
||||
1. **Use semantic HTML first** - ARIA should enhance, not replace
|
||||
2. **Don't override native semantics**
|
||||
3. **All interactive elements must be keyboard accessible**
|
||||
4. **Don't use ARIA to make elements focusable**
|
||||
|
||||
**Common ARIA Attributes:**
|
||||
|
||||
```html
|
||||
<!-- Landmarks -->
|
||||
<nav aria-label="Main navigation">
|
||||
<main aria-label="Main content">
|
||||
<aside aria-label="Related articles">
|
||||
|
||||
<!-- Live regions -->
|
||||
<div aria-live="polite">Status updated</div>
|
||||
<div aria-live="assertive">Error: Invalid input</div>
|
||||
|
||||
<!-- Labels & descriptions -->
|
||||
<button aria-label="Close dialog">×</button>
|
||||
<input aria-describedby="password-requirements">
|
||||
|
||||
<!-- States -->
|
||||
<button aria-pressed="true">Bold</button>
|
||||
<div aria-expanded="false">Menu collapsed</div>
|
||||
<input aria-invalid="true">
|
||||
```
|
||||
|
||||
**Common Roles:**
|
||||
- `role="button"` - For clickable non-button elements
|
||||
- `role="navigation"` - Navigation landmarks
|
||||
- `role="search"` - Search landmarks
|
||||
- `role="alert"` - Important messages
|
||||
- `role="dialog"` - Modal dialogs
|
||||
- `role="tablist"`, `role="tab"`, `role="tabpanel"` - Tab components
|
||||
|
||||
### Screen Reader Testing
|
||||
|
||||
**Test with:**
|
||||
- **NVDA** (Windows, free)
|
||||
- **JAWS** (Windows, paid)
|
||||
- **VoiceOver** (macOS/iOS, built-in)
|
||||
- **TalkBack** (Android, built-in)
|
||||
|
||||
**Testing Checklist:**
|
||||
- [ ] Can navigate entire page with keyboard alone
|
||||
- [ ] All interactive elements announced correctly
|
||||
- [ ] Heading structure makes sense
|
||||
- [ ] Form labels associated properly
|
||||
- [ ] Error messages announced
|
||||
- [ ] Dynamic content updates announced
|
||||
- [ ] Images have appropriate alt text
|
||||
|
||||
---
|
||||
|
||||
## Design Handoff Checklist
|
||||
|
||||
### For Designers to Specify
|
||||
|
||||
- [ ] **Color contrast ratios** for all text and UI elements
|
||||
- [ ] **Focus indicator styles** for interactive elements
|
||||
- [ ] **Touch target sizes** (minimum 44×44px)
|
||||
- [ ] **Alt text** for all meaningful images
|
||||
- [ ] **Heading hierarchy** clearly marked
|
||||
- [ ] **Form labels** positioned and associated
|
||||
- [ ] **Error states** designed and documented
|
||||
- [ ] **Keyboard navigation** flow specified
|
||||
- [ ] **Motion** alternatives for animations
|
||||
- [ ] **Responsive text** sizing behavior
|
||||
|
||||
### Documentation to Provide
|
||||
|
||||
```markdown
|
||||
## Accessibility Specifications
|
||||
|
||||
### Color Contrast
|
||||
- Primary text on background: 8.2:1 (AAA)
|
||||
- Button text on primary color: 5.1:1 (AA)
|
||||
- All tested with [tool name]
|
||||
|
||||
### Interactive States
|
||||
- Default: [specs]
|
||||
- Hover: [specs]
|
||||
- Focus: 2px solid blue outline, 3:1 contrast
|
||||
- Active: [specs]
|
||||
- Disabled: [specs]
|
||||
|
||||
### Keyboard Navigation
|
||||
1. Tab order: Header → CTA → Form → Footer
|
||||
2. Skip link to main content
|
||||
3. Escape closes modal
|
||||
|
||||
### Screen Reader Content
|
||||
- "Menu" button: aria-label="Open navigation menu"
|
||||
- Close button: aria-label="Close dialog"
|
||||
- Loading state: aria-live="polite" announcement
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Testing & Validation
|
||||
|
||||
### Automated Testing Tools
|
||||
|
||||
**Browser Extensions:**
|
||||
- [axe DevTools](https://www.deque.com/axe/devtools/) - Free, comprehensive
|
||||
- [WAVE](https://wave.webaim.org/) - Visual feedback
|
||||
- [Lighthouse](https://developers.google.com/web/tools/lighthouse) - Built into Chrome
|
||||
|
||||
**Design Tools:**
|
||||
- Figma: Stark, A11y - Focus Orderer
|
||||
- Sketch: Stark
|
||||
- Adobe XD: Accessibility features built-in
|
||||
|
||||
**Limitations:**
|
||||
- Automated tools catch ~30-40% of issues
|
||||
- Manual testing required for full compliance
|
||||
|
||||
### Manual Testing Checklist
|
||||
|
||||
- [ ] **Keyboard only** - Can you complete all tasks?
|
||||
- [ ] **Screen reader** - Does it make sense?
|
||||
- [ ] **Zoom to 200%** - Is content still readable?
|
||||
- [ ] **Color blindness** - Information still conveyed?
|
||||
- [ ] **Resize text** - Layout still works?
|
||||
- [ ] **Disable CSS** - Content still logical?
|
||||
- [ ] **Motion reduced** - Animations simplified?
|
||||
|
||||
### User Testing with People with Disabilities
|
||||
|
||||
**Include diverse participants:**
|
||||
- Screen reader users (blind/low vision)
|
||||
- Keyboard-only users (motor disabilities)
|
||||
- Voice control users
|
||||
- Cognitive disabilities
|
||||
- Older adults
|
||||
- Low bandwidth/assistive tech users
|
||||
|
||||
---
|
||||
|
||||
## Common Accessibility Mistakes
|
||||
|
||||
### ❌ Don't Do This
|
||||
|
||||
1. **Using placeholders as labels**
|
||||
```html
|
||||
<!-- Bad -->
|
||||
<input placeholder="Email address">
|
||||
|
||||
<!-- Good -->
|
||||
<label for="email">Email address</label>
|
||||
<input id="email" type="email">
|
||||
```
|
||||
|
||||
2. **Icon-only buttons without labels**
|
||||
```html
|
||||
<!-- Bad -->
|
||||
<button><svg>...</svg></button>
|
||||
|
||||
<!-- Good -->
|
||||
<button aria-label="Close menu">
|
||||
<svg aria-hidden="true">...</svg>
|
||||
</button>
|
||||
```
|
||||
|
||||
3. **Disabled buttons without explanation**
|
||||
```html
|
||||
<!-- Bad -->
|
||||
<button disabled>Submit</button>
|
||||
|
||||
<!-- Good -->
|
||||
<button disabled aria-describedby="submit-hint">Submit</button>
|
||||
<span id="submit-hint">Complete all required fields to submit</span>
|
||||
```
|
||||
|
||||
4. **Auto-playing media**
|
||||
```html
|
||||
<!-- Bad -->
|
||||
<video autoplay>
|
||||
|
||||
<!-- Good -->
|
||||
<video controls>
|
||||
<track kind="captions" src="captions.vtt">
|
||||
</video>
|
||||
```
|
||||
|
||||
5. **Removing focus indicators**
|
||||
```css
|
||||
/* Bad */
|
||||
:focus { outline: none; }
|
||||
|
||||
/* Good */
|
||||
:focus {
|
||||
outline: 2px solid blue;
|
||||
outline-offset: 2px;
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Accessibility Statement Template
|
||||
|
||||
Include on your website:
|
||||
|
||||
```markdown
|
||||
## Accessibility Statement
|
||||
|
||||
[Organization] is committed to ensuring digital accessibility for people with disabilities. We are continually improving the user experience for everyone and applying the relevant accessibility standards.
|
||||
|
||||
### Conformance Status
|
||||
The Web Content Accessibility Guidelines (WCAG) defines requirements to improve accessibility. We aim for WCAG 2.1 Level AA conformance.
|
||||
|
||||
### Feedback
|
||||
We welcome your feedback on the accessibility of [product name]. Please contact us:
|
||||
- Email: [accessibility@example.com]
|
||||
- Phone: [phone number]
|
||||
|
||||
### Technical Specifications
|
||||
[Product] accessibility relies on the following technologies:
|
||||
- HTML
|
||||
- CSS
|
||||
- JavaScript
|
||||
- ARIA
|
||||
|
||||
### Assessment Approach
|
||||
[Organization] assessed the accessibility of [product] by:
|
||||
- Self-evaluation
|
||||
- External evaluation by [company]
|
||||
- User testing with people with disabilities
|
||||
|
||||
### Date
|
||||
This statement was created on [date] and last reviewed on [date].
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Resources
|
||||
|
||||
### Guidelines & Standards
|
||||
- [WCAG 2.1](https://www.w3.org/WAI/WCAG21/quickref/)
|
||||
- [ARIA Authoring Practices](https://www.w3.org/WAI/ARIA/apg/)
|
||||
- [Section 508](https://www.section508.gov/)
|
||||
- [A11Y Project Checklist](https://www.a11yproject.com/checklist/)
|
||||
|
||||
### Testing Tools
|
||||
- [axe DevTools](https://www.deque.com/axe/)
|
||||
- [WAVE](https://wave.webaim.org/)
|
||||
- [Color Contrast Analyzer](https://www.tpgi.com/color-contrast-checker/)
|
||||
- [NVDA Screen Reader](https://www.nvaccess.org/)
|
||||
|
||||
### Learning
|
||||
- [WebAIM](https://webaim.org/)
|
||||
- [Deque University](https://dequeuniversity.com/)
|
||||
- [Inclusive Components](https://inclusive-components.design/)
|
||||
- [A11ycasts (YouTube)](https://www.youtube.com/playlist?list=PLNYkxOF6rcICWx0C9LVWWVqvHlYJyqw7g)
|
||||
|
||||
### Component Patterns
|
||||
- [Inclusive Components](https://inclusive-components.design/)
|
||||
- [A11Y Style Guide](https://a11y-style-guide.com/)
|
||||
- [GOV.UK Design System](https://design-system.service.gov.uk/)
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference
|
||||
|
||||
### Minimum Requirements (WCAG 2.1 AA)
|
||||
|
||||
| Category | Requirement |
|
||||
|----------|-------------|
|
||||
| **Color Contrast** | 4.5:1 (text), 3:1 (UI) |
|
||||
| **Touch Targets** | 44×44px minimum |
|
||||
| **Text Resize** | 200% without loss |
|
||||
| **Keyboard** | Full functionality |
|
||||
| **Focus Visible** | Clear indicators |
|
||||
| **Alt Text** | All images |
|
||||
| **Labels** | All form inputs |
|
||||
| **Headings** | Logical structure |
|
||||
| **Link Text** | Descriptive |
|
||||
| **Time Limits** | User controllable |
|
||||
| **Motion** | Reduced option |
|
||||
| **Error Messages** | Clear & helpful |
|
||||
|
||||
### Priority Checklist for Design Briefs
|
||||
|
||||
- [ ] Target WCAG 2.1 Level AA
|
||||
- [ ] Specify color contrast ratios
|
||||
- [ ] Design clear focus indicators
|
||||
- [ ] Ensure 44×44px touch targets
|
||||
- [ ] Plan keyboard navigation flow
|
||||
- [ ] Include motion alternatives
|
||||
- [ ] Document ARIA requirements
|
||||
- [ ] Design error states
|
||||
- [ ] Consider screen reader experience
|
||||
- [ ] Plan accessibility testing
|
||||
|
||||
---
|
||||
|
||||
Remember: **Accessibility is not a feature, it's a fundamental requirement.** Build it in from the start, not as an afterthought.
|
||||
@@ -0,0 +1,459 @@
|
||||
# Design Brief Template
|
||||
|
||||
A comprehensive template for creating design project briefs.
|
||||
|
||||
---
|
||||
|
||||
## Project Overview
|
||||
|
||||
### Project Name
|
||||
[Project name]
|
||||
|
||||
### Problem Statement
|
||||
[What user problem or business need are we addressing?]
|
||||
|
||||
### Background & Context
|
||||
[Why now? What led to this project?]
|
||||
|
||||
### Project Type
|
||||
- [ ] New Feature
|
||||
- [ ] Redesign
|
||||
- [ ] Design System
|
||||
- [ ] Brand/Visual Design
|
||||
- [ ] UX Research
|
||||
- [ ] Other: ___________
|
||||
|
||||
---
|
||||
|
||||
## Design Goals & Objectives
|
||||
|
||||
### Primary Goal
|
||||
[The main design objective - what success looks like]
|
||||
|
||||
### Secondary Goals
|
||||
1. [Goal 2]
|
||||
2. [Goal 3]
|
||||
3. [Goal 4]
|
||||
|
||||
### Business Objectives
|
||||
- [How does this support business goals?]
|
||||
- [What business metrics will this impact?]
|
||||
|
||||
### User Objectives
|
||||
- [What user needs does this address?]
|
||||
- [How will this improve the user experience?]
|
||||
|
||||
---
|
||||
|
||||
## Target Users
|
||||
|
||||
### Primary Audience
|
||||
**Who:** [User segment or persona name]
|
||||
**Characteristics:**
|
||||
- Demographics: [Age, location, role, etc.]
|
||||
- Technical proficiency: [Beginner, intermediate, expert]
|
||||
- Current behavior: [How they currently solve this problem]
|
||||
- Pain points: [Specific frustrations]
|
||||
|
||||
### Secondary Audience
|
||||
**Who:** [Additional user segment]
|
||||
**Characteristics:**
|
||||
- [Key characteristics]
|
||||
- [Specific needs]
|
||||
|
||||
### User Personas
|
||||
**Persona 1: [Name]**
|
||||
- Role: [Job title/role]
|
||||
- Goals: [What they want to achieve]
|
||||
- Frustrations: [Current pain points]
|
||||
- Quote: "[A representative quote]"
|
||||
|
||||
**Persona 2: [Name]**
|
||||
- Role: [Job title/role]
|
||||
- Goals: [What they want to achieve]
|
||||
- Frustrations: [Current pain points]
|
||||
- Quote: "[A representative quote]"
|
||||
|
||||
---
|
||||
|
||||
## User Research
|
||||
|
||||
### Research Completed
|
||||
- [ ] User interviews (n = [number])
|
||||
- [ ] Surveys (n = [number])
|
||||
- [ ] Analytics review
|
||||
- [ ] Competitor analysis
|
||||
- [ ] Usability testing
|
||||
- [ ] Other: ___________
|
||||
|
||||
### Key Findings
|
||||
1. **Finding 1:** [Insight from research]
|
||||
- Evidence: [Data/quotes supporting this]
|
||||
|
||||
2. **Finding 2:** [Insight from research]
|
||||
- Evidence: [Data/quotes supporting this]
|
||||
|
||||
3. **Finding 3:** [Insight from research]
|
||||
- Evidence: [Data/quotes supporting this]
|
||||
|
||||
### Research Gaps
|
||||
[What don't we know yet? What assumptions need validation?]
|
||||
|
||||
---
|
||||
|
||||
## Scope
|
||||
|
||||
### In Scope
|
||||
**Features/Experiences:**
|
||||
- [Feature/flow 1]
|
||||
- [Feature/flow 2]
|
||||
- [Feature/flow 3]
|
||||
|
||||
**Platforms:**
|
||||
- [ ] Web (Desktop)
|
||||
- [ ] Web (Mobile)
|
||||
- [ ] iOS Native
|
||||
- [ ] Android Native
|
||||
- [ ] Other: ___________
|
||||
|
||||
**Deliverables:**
|
||||
- [Wireframes]
|
||||
- [High-fidelity mockups]
|
||||
- [Prototypes]
|
||||
- [Design system components]
|
||||
|
||||
### Out of Scope
|
||||
[What we are explicitly NOT doing in this phase]
|
||||
- [Excluded feature 1]
|
||||
- [Excluded feature 2]
|
||||
- [Future consideration 1]
|
||||
|
||||
### Constraints
|
||||
**Technical:**
|
||||
- [Technical limitations or requirements]
|
||||
|
||||
**Business:**
|
||||
- [Budget, timeline, resource constraints]
|
||||
|
||||
**Design:**
|
||||
- [Brand guidelines, existing patterns to maintain]
|
||||
|
||||
---
|
||||
|
||||
## User Flows & Journeys
|
||||
|
||||
### Primary User Flow
|
||||
**Goal:** [What the user wants to accomplish]
|
||||
|
||||
**Steps:**
|
||||
1. [Entry point]
|
||||
2. [Step 2]
|
||||
3. [Step 3]
|
||||
4. [Success state]
|
||||
|
||||
**Alternative paths:**
|
||||
- [Edge case or alternative flow]
|
||||
|
||||
### Secondary Flows
|
||||
**Flow 2:** [Brief description]
|
||||
1. [Key steps]
|
||||
|
||||
**Flow 3:** [Brief description]
|
||||
1. [Key steps]
|
||||
|
||||
### Critical Interactions
|
||||
- **Interaction 1:** [Description of key interaction]
|
||||
- Current experience: [How it works now]
|
||||
- Desired experience: [How it should work]
|
||||
|
||||
- **Interaction 2:** [Description]
|
||||
- Current experience: [How it works now]
|
||||
- Desired experience: [How it should work]
|
||||
|
||||
---
|
||||
|
||||
## Design Principles
|
||||
|
||||
### Project-Specific Principles
|
||||
1. **[Principle 1]:** [Description]
|
||||
- Example: [How this applies]
|
||||
|
||||
2. **[Principle 2]:** [Description]
|
||||
- Example: [How this applies]
|
||||
|
||||
3. **[Principle 3]:** [Description]
|
||||
- Example: [How this applies]
|
||||
|
||||
### Brand Principles (if applicable)
|
||||
- [Existing brand principle that applies]
|
||||
- [Existing brand principle that applies]
|
||||
|
||||
---
|
||||
|
||||
## Visual Direction
|
||||
|
||||
### Design Style
|
||||
- [ ] Follow existing design system
|
||||
- [ ] Extend design system
|
||||
- [ ] New visual direction
|
||||
|
||||
### Visual References
|
||||
- [Link to inspiration/reference 1]
|
||||
- [Link to inspiration/reference 2]
|
||||
- [Link to competitor examples]
|
||||
|
||||
### Key Visual Elements
|
||||
- **Color palette:** [Specific colors or guidance]
|
||||
- **Typography:** [Typefaces and hierarchy]
|
||||
- **Imagery style:** [Photography, illustration, icons]
|
||||
- **Motion:** [Animation principles if applicable]
|
||||
|
||||
---
|
||||
|
||||
## Accessibility Requirements
|
||||
|
||||
### WCAG Level Target
|
||||
- [ ] WCAG 2.1 Level A
|
||||
- [ ] WCAG 2.1 Level AA (recommended)
|
||||
- [ ] WCAG 2.1 Level AAA
|
||||
|
||||
### Specific Requirements
|
||||
- [ ] Keyboard navigation
|
||||
- [ ] Screen reader support
|
||||
- [ ] Color contrast (4.5:1 minimum)
|
||||
- [ ] Focus indicators
|
||||
- [ ] Alternative text for images
|
||||
- [ ] Captions for video/audio
|
||||
- [ ] Responsive text sizing
|
||||
- [ ] Reduced motion support
|
||||
|
||||
### Accessibility Considerations
|
||||
[Any specific accessibility challenges or requirements for this project]
|
||||
|
||||
---
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Qualitative Metrics
|
||||
- [ ] Users can complete [primary task] without assistance
|
||||
- [ ] Users express positive sentiment about [feature]
|
||||
- [ ] Design passes usability testing with < 3 critical issues
|
||||
- [ ] Stakeholders approve design direction
|
||||
- [ ] Design is consistent with brand guidelines
|
||||
|
||||
### Quantitative Metrics
|
||||
**Primary Metrics:**
|
||||
- [Metric 1]: [Target] (e.g., Task completion rate > 90%)
|
||||
- [Metric 2]: [Target] (e.g., Time on task < 2 minutes)
|
||||
|
||||
**Secondary Metrics:**
|
||||
- [Metric 3]: [Target] (e.g., Error rate < 5%)
|
||||
- [Metric 4]: [Target] (e.g., User satisfaction score > 4/5)
|
||||
|
||||
**Business Metrics:**
|
||||
- [Metric 5]: [Target] (e.g., Conversion rate increase by 15%)
|
||||
|
||||
### Measurement Plan
|
||||
- **How:** [How will we measure success?]
|
||||
- **When:** [Timeline for measuring]
|
||||
- **Baseline:** [Current metrics if available]
|
||||
|
||||
---
|
||||
|
||||
## Deliverables
|
||||
|
||||
### Design Artifacts
|
||||
- [ ] User flow diagrams
|
||||
- [ ] Wireframes (low-fidelity)
|
||||
- [ ] Wireframes (high-fidelity)
|
||||
- [ ] Visual design mockups
|
||||
- [ ] Interactive prototype
|
||||
- [ ] Design specifications
|
||||
- [ ] Component documentation
|
||||
- [ ] Design system updates
|
||||
- [ ] Accessibility documentation
|
||||
- [ ] Animation specifications
|
||||
|
||||
### Documentation
|
||||
- [ ] Design rationale
|
||||
- [ ] User research summary
|
||||
- [ ] Usability test report
|
||||
- [ ] Developer handoff notes
|
||||
- [ ] Content guidelines
|
||||
|
||||
### Review Artifacts
|
||||
- [ ] Presentation deck
|
||||
- [ ] Design review recordings
|
||||
- [ ] Feedback synthesis
|
||||
|
||||
---
|
||||
|
||||
## Timeline & Milestones
|
||||
|
||||
### Phase 1: Discovery & Research
|
||||
**Duration:** [Timeframe]
|
||||
- [ ] User research
|
||||
- [ ] Competitive analysis
|
||||
- [ ] Design audit (if applicable)
|
||||
- **Milestone:** Research insights presented
|
||||
|
||||
### Phase 2: Concept & Exploration
|
||||
**Duration:** [Timeframe]
|
||||
- [ ] Initial concepts (3+ directions)
|
||||
- [ ] Stakeholder review
|
||||
- [ ] Concept refinement
|
||||
- **Milestone:** Design direction approved
|
||||
|
||||
### Phase 3: Detailed Design
|
||||
**Duration:** [Timeframe]
|
||||
- [ ] Wireframes
|
||||
- [ ] High-fidelity mockups
|
||||
- [ ] Design system components
|
||||
- **Milestone:** Design specs complete
|
||||
|
||||
### Phase 4: Prototype & Validation
|
||||
**Duration:** [Timeframe]
|
||||
- [ ] Interactive prototype
|
||||
- [ ] Usability testing
|
||||
- [ ] Iterate based on feedback
|
||||
- **Milestone:** Design validated
|
||||
|
||||
### Phase 5: Handoff & Support
|
||||
**Duration:** [Timeframe]
|
||||
- [ ] Developer handoff
|
||||
- [ ] Design QA
|
||||
- [ ] Launch support
|
||||
- **Milestone:** Design shipped
|
||||
|
||||
### Key Dates
|
||||
- **Project kickoff:** [Date]
|
||||
- **Design review 1:** [Date]
|
||||
- **Design review 2:** [Date]
|
||||
- **Final handoff:** [Date]
|
||||
- **Launch:** [Date]
|
||||
|
||||
---
|
||||
|
||||
## Stakeholders & Collaboration
|
||||
|
||||
### Core Team
|
||||
- **Design lead:** [Name] - [Role/responsibility]
|
||||
- **Product manager:** [Name]
|
||||
- **Engineering lead:** [Name]
|
||||
- **Researcher:** [Name]
|
||||
- **Content designer:** [Name]
|
||||
|
||||
### Reviewers & Approvers
|
||||
- [Name, Title] - [What they approve]
|
||||
- [Name, Title] - [What they approve]
|
||||
|
||||
### Communication Plan
|
||||
**Design reviews:**
|
||||
- Weekly sync: [Day/time]
|
||||
- Major milestones: [When]
|
||||
|
||||
**Feedback channels:**
|
||||
- [Slack channel]
|
||||
- [Figma comments]
|
||||
- [Email for formal approvals]
|
||||
|
||||
**Decision-making:**
|
||||
- Design decisions: [Who decides]
|
||||
- Scope changes: [Who approves]
|
||||
|
||||
---
|
||||
|
||||
## Design Tools & Resources
|
||||
|
||||
### Tools
|
||||
- **Design:** [Figma, Sketch, Adobe XD]
|
||||
- **Prototyping:** [Figma, Framer, ProtoPie]
|
||||
- **User testing:** [Lookback, UserTesting, Maze]
|
||||
- **Documentation:** [Notion, Confluence]
|
||||
|
||||
### Resources
|
||||
- **Design system:** [Link]
|
||||
- **Brand guidelines:** [Link]
|
||||
- **Component library:** [Link]
|
||||
- **Research repository:** [Link]
|
||||
|
||||
---
|
||||
|
||||
## Risks & Mitigation
|
||||
|
||||
### Potential Risks
|
||||
1. **Risk:** [Description of risk]
|
||||
- **Impact:** [High/Medium/Low]
|
||||
- **Mitigation:** [How to address]
|
||||
|
||||
2. **Risk:** [Description of risk]
|
||||
- **Impact:** [High/Medium/Low]
|
||||
- **Mitigation:** [How to address]
|
||||
|
||||
3. **Risk:** [Description of risk]
|
||||
- **Impact:** [High/Medium/Low]
|
||||
- **Mitigation:** [How to address]
|
||||
|
||||
### Dependencies
|
||||
- [Dependency on other team/project]
|
||||
- [Technical dependency]
|
||||
- [Resource dependency]
|
||||
|
||||
---
|
||||
|
||||
## Post-Launch
|
||||
|
||||
### Success Review
|
||||
- **When:** [Timeline for measuring success]
|
||||
- **Metrics to review:** [List metrics from success criteria]
|
||||
- **Learning goals:** [What do we want to learn?]
|
||||
|
||||
### Iteration Plan
|
||||
- [Planned improvements for v2]
|
||||
- [Features deferred to future phases]
|
||||
|
||||
### Documentation
|
||||
- [ ] Case study
|
||||
- [ ] Design learnings
|
||||
- [ ] Pattern documentation
|
||||
- [ ] Retrospective notes
|
||||
|
||||
---
|
||||
|
||||
## Appendix
|
||||
|
||||
### Research Links
|
||||
- [Link to research findings]
|
||||
- [Link to user interviews]
|
||||
- [Link to analytics dashboard]
|
||||
|
||||
### Design Files
|
||||
- [Link to Figma file]
|
||||
- [Link to prototype]
|
||||
- [Link to design specs]
|
||||
|
||||
### References
|
||||
- [Competitor analysis]
|
||||
- [Industry best practices]
|
||||
- [Related projects]
|
||||
|
||||
---
|
||||
|
||||
## Version History
|
||||
|
||||
| Version | Date | Author | Changes |
|
||||
|---------|------|--------|---------|
|
||||
| 0.1 | [Date] | [Name] | Initial draft |
|
||||
| 0.2 | [Date] | [Name] | [Changes] |
|
||||
| 1.0 | [Date] | [Name] | Final approved version |
|
||||
|
||||
---
|
||||
|
||||
## Approval
|
||||
|
||||
- [ ] Design lead approved
|
||||
- [ ] Product manager approved
|
||||
- [ ] Engineering lead approved
|
||||
- [ ] Stakeholder(s) approved
|
||||
|
||||
**Date approved:** ___________
|
||||
649
skills/design-brief-generator/references/design_principles.md
Normal file
649
skills/design-brief-generator/references/design_principles.md
Normal file
@@ -0,0 +1,649 @@
|
||||
# Design Principles
|
||||
|
||||
A comprehensive guide to establishing and applying design principles for your projects.
|
||||
|
||||
---
|
||||
|
||||
## What Are Design Principles?
|
||||
|
||||
Design principles are foundational guidelines that inform design decisions and help teams create consistent, purposeful user experiences. They serve as:
|
||||
|
||||
- **Decision-making tools** - When faced with trade-offs
|
||||
- **Alignment mechanisms** - Keep teams on the same page
|
||||
- **Communication shortcuts** - Express complex ideas quickly
|
||||
- **Quality filters** - Evaluate if designs meet standards
|
||||
|
||||
**Key characteristic:** Good principles are opinionated and help you say "no" to things that don't align.
|
||||
|
||||
---
|
||||
|
||||
## Characteristics of Effective Design Principles
|
||||
|
||||
### 1. Specific, Not Generic
|
||||
❌ **Bad:** "Keep it simple"
|
||||
✅ **Good:** "Show one primary action per screen"
|
||||
|
||||
### 2. Opinionated
|
||||
❌ **Bad:** "Design should be accessible"
|
||||
✅ **Good:** "Accessibility is non-negotiable - WCAG AA minimum"
|
||||
|
||||
### 3. Memorable
|
||||
- Short and punchy
|
||||
- Easy to remember
|
||||
- Ideally 3-7 principles total
|
||||
|
||||
### 4. Actionable
|
||||
- Clear enough to guide decisions
|
||||
- Can be applied in practice
|
||||
- Include examples of application
|
||||
|
||||
### 5. Authentic to Your Product
|
||||
- Reflect your unique approach
|
||||
- Not copied from others
|
||||
- Based on your users and context
|
||||
|
||||
---
|
||||
|
||||
## Types of Design Principles
|
||||
|
||||
### 1. Product-Level Principles
|
||||
**Scope:** Entire product or company
|
||||
**Duration:** Years
|
||||
**Examples:**
|
||||
- Google Material Design: "Motion provides meaning"
|
||||
- Apple HIG: "Depth creates hierarchy and focus"
|
||||
- Shopify Polaris: "Merchants first"
|
||||
|
||||
### 2. Project-Level Principles
|
||||
**Scope:** Specific feature or initiative
|
||||
**Duration:** Weeks to months
|
||||
**Examples:**
|
||||
- "Mobile-first for this redesign"
|
||||
- "Progressive disclosure over feature parity"
|
||||
- "Speed trumps beauty for this dashboard"
|
||||
|
||||
### 3. Brand Principles
|
||||
**Scope:** Visual and tonal identity
|
||||
**Duration:** Years
|
||||
**Examples:**
|
||||
- "Bold but not overwhelming"
|
||||
- "Playful but professional"
|
||||
- "Technical but approachable"
|
||||
|
||||
---
|
||||
|
||||
## Framework: Creating Design Principles
|
||||
|
||||
### Step 1: Understand Your Context
|
||||
|
||||
**Research questions:**
|
||||
- Who are our users?
|
||||
- What are their core needs?
|
||||
- What makes our product unique?
|
||||
- What do we want to be known for?
|
||||
- What trade-offs do we commonly face?
|
||||
|
||||
**Gather input from:**
|
||||
- User research findings
|
||||
- Stakeholder interviews
|
||||
- Competitive analysis
|
||||
- Brand strategy
|
||||
- Product vision
|
||||
|
||||
### Step 2: Identify Themes
|
||||
|
||||
**Look for patterns:**
|
||||
- Repeated design challenges
|
||||
- Common user feedback
|
||||
- Successful design decisions
|
||||
- Team values and culture
|
||||
- Competitive advantages
|
||||
|
||||
**Common themes:**
|
||||
- Simplicity vs. power
|
||||
- Speed vs. features
|
||||
- Guidance vs. flexibility
|
||||
- Innovation vs. familiarity
|
||||
- Delight vs. efficiency
|
||||
|
||||
### Step 3: Draft Principles
|
||||
|
||||
**Format options:**
|
||||
|
||||
**1. Statement + Explanation**
|
||||
```
|
||||
Principle: Progressive disclosure
|
||||
We show complexity only when needed, starting with
|
||||
the simplest path and revealing advanced features
|
||||
as users need them.
|
||||
```
|
||||
|
||||
**2. Principle + Sub-points**
|
||||
```
|
||||
Principle: Speed is a feature
|
||||
|
||||
- Optimize for p95 latency < 200ms
|
||||
- Perceived performance > actual performance
|
||||
- Never block user interactions
|
||||
```
|
||||
|
||||
**3. Opposites**
|
||||
```
|
||||
Clarity over cleverness
|
||||
We prefer obvious solutions over creative ones
|
||||
that require explanation.
|
||||
```
|
||||
|
||||
### Step 4: Test & Refine
|
||||
|
||||
**Validation questions:**
|
||||
- Can we apply this to real design decisions?
|
||||
- Does it help us choose between options?
|
||||
- Is it specific to our product?
|
||||
- Can we explain it in 30 seconds?
|
||||
- Does the team agree?
|
||||
|
||||
**Test with scenarios:**
|
||||
- Take recent design decisions
|
||||
- Apply principles retroactively
|
||||
- Do they guide toward the right choice?
|
||||
- Refine based on results
|
||||
|
||||
### Step 5: Document & Evangelize
|
||||
|
||||
**Documentation should include:**
|
||||
- Principle statement
|
||||
- Explanation (1-2 paragraphs)
|
||||
- Real examples (with images)
|
||||
- Anti-examples (what to avoid)
|
||||
- When to apply/not apply
|
||||
|
||||
---
|
||||
|
||||
## Example Design Principles
|
||||
|
||||
### Product: Slack
|
||||
|
||||
**1. Work hard at being easy**
|
||||
Surface the rich capabilities of Slack with progressive disclosure—make the basics easy to understand and the advanced features easy to find.
|
||||
|
||||
**2. Empowering, not clever**
|
||||
Clarity and usefulness, rather than cleverness, should be our guiding light. We should delight people with ease of use, not tricks.
|
||||
|
||||
**3. Courtesy and respect**
|
||||
We're mindful of the language and tone in both the product and our communication. We strive for a friendly, supportive voice.
|
||||
|
||||
---
|
||||
|
||||
### Product: Airbnb
|
||||
|
||||
**1. Unified**
|
||||
Every part of Airbnb is part of a greater whole. Design cohesively across platforms, features, and touch-points.
|
||||
|
||||
**2. Universal**
|
||||
Airbnb is used by millions around the world. Make sure your designs scale across cultures and contexts.
|
||||
|
||||
**3. Iconic**
|
||||
Our interfaces should be instantly recognizable. Leverage consistency and focus to create memorable moments.
|
||||
|
||||
**4. Conversational**
|
||||
Our voice is friendly and straightforward. Guide users with clarity and warmth.
|
||||
|
||||
---
|
||||
|
||||
### Product: GOV.UK
|
||||
|
||||
**1. Start with user needs**
|
||||
Service design starts with identifying user needs. If you don't know what the user needs are, you won't build the right thing.
|
||||
|
||||
**2. Do less**
|
||||
Government should only do what only government can do. If someone else is doing it, we should point to them.
|
||||
|
||||
**3. Design with data**
|
||||
In most cases, we can learn from real-world behavior by looking at how existing services are used. Let data drive decision-making.
|
||||
|
||||
**4. Do the hard work to make it simple**
|
||||
Making something look simple is easy. Making something simple to use is much harder.
|
||||
|
||||
**5. Iterate. Then iterate again**
|
||||
The best way to build good services is to start small and iterate wildly.
|
||||
|
||||
---
|
||||
|
||||
## Common Design Principle Patterns
|
||||
|
||||
### Simplicity & Clarity
|
||||
|
||||
**Patterns:**
|
||||
- "Simple over clever"
|
||||
- "Clarity is paramount"
|
||||
- "Progressive disclosure"
|
||||
- "One primary action per screen"
|
||||
- "Remove, then simplify"
|
||||
|
||||
**When to use:**
|
||||
- Complex enterprise software
|
||||
- Products with steep learning curves
|
||||
- Designing for novice users
|
||||
|
||||
**Example application:**
|
||||
- Dashboard shows 3 key metrics, not 20
|
||||
- Single CTA per page
|
||||
- Hide advanced settings in preferences
|
||||
|
||||
---
|
||||
|
||||
### Speed & Performance
|
||||
|
||||
**Patterns:**
|
||||
- "Speed is a feature"
|
||||
- "Instant feedback"
|
||||
- "Optimistic UI updates"
|
||||
- "Perceived performance matters"
|
||||
|
||||
**When to use:**
|
||||
- Real-time applications
|
||||
- Mobile-first products
|
||||
- High-frequency user actions
|
||||
|
||||
**Example application:**
|
||||
- Show loading states immediately
|
||||
- Update UI before server confirms
|
||||
- Preload likely next steps
|
||||
|
||||
---
|
||||
|
||||
### User Empowerment
|
||||
|
||||
**Patterns:**
|
||||
- "Users in control"
|
||||
- "Provide escape hatches"
|
||||
- "No dead ends"
|
||||
- "Make destructive actions reversible"
|
||||
|
||||
**When to use:**
|
||||
- Professional tools
|
||||
- Content creation apps
|
||||
- Complex workflows
|
||||
|
||||
**Example application:**
|
||||
- Undo for all actions
|
||||
- Multiple ways to accomplish tasks
|
||||
- Clear exit paths from flows
|
||||
|
||||
---
|
||||
|
||||
### Consistency & Predictability
|
||||
|
||||
**Patterns:**
|
||||
- "Familiar over novel"
|
||||
- "Consistency creates trust"
|
||||
- "Follow platform conventions"
|
||||
- "Don't reinvent the wheel"
|
||||
|
||||
**When to use:**
|
||||
- Enterprise software
|
||||
- Products spanning platforms
|
||||
- Established design systems
|
||||
|
||||
**Example application:**
|
||||
- Use platform-native components
|
||||
- Maintain interaction patterns
|
||||
- Consistent terminology
|
||||
|
||||
---
|
||||
|
||||
### Delight & Personality
|
||||
|
||||
**Patterns:**
|
||||
- "Personality without distraction"
|
||||
- "Delight in details"
|
||||
- "Human, not robotic"
|
||||
- "Make it fun"
|
||||
|
||||
**When to use:**
|
||||
- Consumer products
|
||||
- Creative tools
|
||||
- Brand-driven experiences
|
||||
|
||||
**Example application:**
|
||||
- Microinteractions
|
||||
- Playful empty states
|
||||
- Friendly error messages
|
||||
- Celebratory animations
|
||||
|
||||
---
|
||||
|
||||
## Applying Principles to Decisions
|
||||
|
||||
### Decision Framework
|
||||
|
||||
When facing a design choice:
|
||||
|
||||
1. **Identify the trade-off**
|
||||
- What are the options?
|
||||
- What does each optimize for?
|
||||
|
||||
2. **Consult principles**
|
||||
- Which principles apply?
|
||||
- What do they suggest?
|
||||
|
||||
3. **Make the call**
|
||||
- Principle-aligned decision
|
||||
- Document reasoning
|
||||
|
||||
4. **Validate**
|
||||
- Does it feel right?
|
||||
- Can you defend it?
|
||||
|
||||
### Example Decision Process
|
||||
|
||||
**Scenario:** Should we add a feature request form in-app or direct users to a forum?
|
||||
|
||||
**Options:**
|
||||
- A: In-app form (more convenient)
|
||||
- B: Public forum (builds community)
|
||||
|
||||
**Principles:**
|
||||
- "Community-driven development"
|
||||
- "Transparent by default"
|
||||
|
||||
**Decision:** Option B (forum) aligns better with principles of community and transparency.
|
||||
|
||||
---
|
||||
|
||||
## Principle Templates
|
||||
|
||||
### Template 1: Statement + Rationale
|
||||
```markdown
|
||||
## [Principle Name]
|
||||
|
||||
[One sentence principle statement]
|
||||
|
||||
**Why this matters:**
|
||||
[1-2 paragraphs explaining the reasoning]
|
||||
|
||||
**In practice:**
|
||||
- [Example 1]
|
||||
- [Example 2]
|
||||
- [Example 3]
|
||||
|
||||
**Not this:**
|
||||
[Anti-example with explanation]
|
||||
```
|
||||
|
||||
### Template 2: Principle Pairs
|
||||
```markdown
|
||||
## [This] over [That]
|
||||
|
||||
We prioritize [this] over [that] because [reasoning].
|
||||
|
||||
**Example:**
|
||||
When [scenario], we choose to [action] rather than
|
||||
[alternative action] because it better serves [user need].
|
||||
```
|
||||
|
||||
### Template 3: Question Format
|
||||
```markdown
|
||||
## [Question as principle]
|
||||
|
||||
[Answer and explanation]
|
||||
|
||||
**How to apply:**
|
||||
Ask yourself: [guiding question]
|
||||
If yes: [recommendation]
|
||||
If no: [alternative recommendation]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Project-Specific Principles: Examples
|
||||
|
||||
### E-commerce Redesign
|
||||
|
||||
1. **Speed drives conversion**
|
||||
- p95 load time < 2 seconds
|
||||
- Optimize images aggressively
|
||||
- Progressive enhancement
|
||||
|
||||
2. **Trust before transaction**
|
||||
- Show reviews prominently
|
||||
- Clear pricing (no surprises)
|
||||
- Visible security signals
|
||||
|
||||
3. **Mobile-first, always**
|
||||
- Design for small screens
|
||||
- Touch targets 44px+
|
||||
- One-handed navigation
|
||||
|
||||
---
|
||||
|
||||
### Enterprise Dashboard
|
||||
|
||||
1. **Data density with clarity**
|
||||
- Show relevant data, hide noise
|
||||
- Progressive disclosure for details
|
||||
- Scannable at a glance
|
||||
|
||||
2. **Customization without complexity**
|
||||
- Smart defaults for 80% of users
|
||||
- Power features for the 20%
|
||||
- Save personal preferences
|
||||
|
||||
3. **Actionable insights**
|
||||
- Every chart suggests an action
|
||||
- Highlight anomalies
|
||||
- Clear next steps
|
||||
|
||||
---
|
||||
|
||||
### Developer Tool
|
||||
|
||||
1. **Documentation first**
|
||||
- Inline code examples
|
||||
- Self-documenting APIs
|
||||
- Error messages that teach
|
||||
|
||||
2. **Powerful defaults, maximum flexibility**
|
||||
- Work out-of-box
|
||||
- Expose all config options
|
||||
- Follow principle of least surprise
|
||||
|
||||
3. **Speed matters**
|
||||
- Fast by default
|
||||
- Show performance metrics
|
||||
- Optimize for developer velocity
|
||||
|
||||
---
|
||||
|
||||
## Anti-Patterns to Avoid
|
||||
|
||||
### ❌ Too Generic
|
||||
"Make it user-friendly"
|
||||
- Applies to everything
|
||||
- Doesn't guide decisions
|
||||
- Basically useless
|
||||
|
||||
### ❌ Too Prescriptive
|
||||
"Always use blue buttons"
|
||||
- Too specific
|
||||
- Becomes a rule, not a principle
|
||||
- Limits creativity
|
||||
|
||||
### ❌ Too Many Principles
|
||||
Having 15+ principles
|
||||
- Can't remember them
|
||||
- Dilutes focus
|
||||
- Slows decisions
|
||||
|
||||
### ❌ Contradictory Principles
|
||||
"Move fast" + "Pixel-perfect polish"
|
||||
- Confuses priorities
|
||||
- Can't both be true
|
||||
- Leads to inconsistency
|
||||
|
||||
### ❌ Aspirational but Not Authentic
|
||||
Copying Apple's principles for your B2B SaaS
|
||||
- Doesn't fit your context
|
||||
- Team won't believe it
|
||||
- Won't guide real decisions
|
||||
|
||||
---
|
||||
|
||||
## Maintaining Design Principles
|
||||
|
||||
### Regular Review
|
||||
|
||||
**Quarterly check:**
|
||||
- Are we following them?
|
||||
- Do they still apply?
|
||||
- Should we refine them?
|
||||
|
||||
**Annual revision:**
|
||||
- Major product changes
|
||||
- New company direction
|
||||
- Market shifts
|
||||
|
||||
### Evangelization
|
||||
|
||||
**Onboarding:**
|
||||
- Introduce principles to new team members
|
||||
- Explain with real examples
|
||||
- Show how they're applied
|
||||
|
||||
**Design reviews:**
|
||||
- Reference principles explicitly
|
||||
- Call out misalignments
|
||||
- Celebrate when followed well
|
||||
|
||||
**Documentation:**
|
||||
- Include in design system
|
||||
- Show in component examples
|
||||
- Link from design files
|
||||
|
||||
---
|
||||
|
||||
## Principle Checklist for Design Briefs
|
||||
|
||||
When creating project-specific principles:
|
||||
|
||||
- [ ] **Based on research** - Grounded in user needs
|
||||
- [ ] **Specific to project** - Not generic platitudes
|
||||
- [ ] **Actionable** - Can guide real decisions
|
||||
- [ ] **Memorable** - Team can recall without looking
|
||||
- [ ] **3-5 principles** - Not too many
|
||||
- [ ] **Not contradictory** - Work together
|
||||
- [ ] **Include examples** - Show how to apply
|
||||
- [ ] **Team alignment** - Everyone agrees
|
||||
- [ ] **Documented** - Written in brief
|
||||
- [ ] **Referenced** - Used in reviews
|
||||
|
||||
---
|
||||
|
||||
## Resources
|
||||
|
||||
### Books
|
||||
- "Designing with Principles" - Ben Brignell
|
||||
- "The Design of Everyday Things" - Don Norman
|
||||
- "Don't Make Me Think" - Steve Krug
|
||||
|
||||
### Articles
|
||||
- [Design Principles FTW](https://www.designprinciplesftw.com/) - Collection of principles
|
||||
- [Creating Design Principles](https://alistapart.com/article/design-principles/) - A List Apart
|
||||
- [Bad Design Principles](https://www.smashingmagazine.com/2010/04/bad-design-principles/) - Smashing Magazine
|
||||
|
||||
### Examples
|
||||
- [Material Design Principles](https://material.io/design/introduction)
|
||||
- [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/)
|
||||
- [Salesforce Lightning Principles](https://www.lightningdesignsystem.com/)
|
||||
- [Atlassian Design Principles](https://atlassian.design/foundations/design-principles)
|
||||
|
||||
---
|
||||
|
||||
## Template: Document Your Principles
|
||||
|
||||
```markdown
|
||||
# [Project Name] Design Principles
|
||||
|
||||
## Overview
|
||||
These principles guide design decisions for [project].
|
||||
When faced with trade-offs, these help us choose the right path.
|
||||
|
||||
---
|
||||
|
||||
## 1. [Principle Name]
|
||||
|
||||
**Statement:**
|
||||
[One clear sentence]
|
||||
|
||||
**Why this matters:**
|
||||
[Explanation of rationale - 2-3 sentences]
|
||||
|
||||
**In practice:**
|
||||
✅ **Do this:**
|
||||
- [Specific example]
|
||||
- [Specific example]
|
||||
|
||||
❌ **Not this:**
|
||||
- [Anti-example]
|
||||
- [Anti-example]
|
||||
|
||||
**Example:**
|
||||
[Real example from the project, ideally with image]
|
||||
|
||||
---
|
||||
|
||||
## 2. [Principle Name]
|
||||
|
||||
[Repeat structure]
|
||||
|
||||
---
|
||||
|
||||
## When to Apply These Principles
|
||||
|
||||
These principles apply to:
|
||||
- [Context 1]
|
||||
- [Context 2]
|
||||
|
||||
These principles may not apply when:
|
||||
- [Exception 1]
|
||||
- [Exception 2]
|
||||
|
||||
---
|
||||
|
||||
## Decision Framework
|
||||
|
||||
When facing a design choice:
|
||||
1. Identify the trade-off
|
||||
2. Consult relevant principles
|
||||
3. Make principle-aligned decision
|
||||
4. Document reasoning
|
||||
|
||||
---
|
||||
|
||||
## Examples of Principles in Action
|
||||
|
||||
### Decision 1: [Description]
|
||||
**Options:** A or B
|
||||
**Principle:** [Which principle applies]
|
||||
**Decision:** [What we chose and why]
|
||||
|
||||
### Decision 2: [Description]
|
||||
[Repeat structure]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quick Tips
|
||||
|
||||
1. **Start broad, refine narrow** - Draft many, pick few
|
||||
2. **Test with real scenarios** - Do they actually help?
|
||||
3. **Get team buy-in** - Collaborative > dictated
|
||||
4. **Show, don't just tell** - Use examples
|
||||
5. **Evolve over time** - Principles aren't permanent
|
||||
6. **Make them visible** - Post in design files, Slack, etc.
|
||||
7. **Use in reviews** - "Does this align with principle X?"
|
||||
|
||||
---
|
||||
|
||||
**Remember:** Design principles should make decisions easier, not harder. If a principle doesn't help you choose, refine or remove it.
|
||||
@@ -0,0 +1,919 @@
|
||||
# User Research Methods
|
||||
|
||||
Comprehensive guide to user research methods for design projects.
|
||||
|
||||
---
|
||||
|
||||
## Why User Research Matters
|
||||
|
||||
**Reduces risk:** Validate assumptions before building
|
||||
**Saves time:** Fix issues before development
|
||||
**Builds empathy:** Understand users deeply
|
||||
**Drives decisions:** Data-informed design choices
|
||||
**Increases success:** Solutions that actually work
|
||||
|
||||
**Rule:** The cost of fixing a problem increases 10x at each stage (design → development → post-launch)
|
||||
|
||||
---
|
||||
|
||||
## When to Use Which Method
|
||||
|
||||
### Discovery Phase (Understanding)
|
||||
**Goal:** Learn about users, their context, and needs
|
||||
|
||||
**Methods:**
|
||||
- User interviews
|
||||
- Contextual inquiry
|
||||
- Diary studies
|
||||
- Surveys
|
||||
- Analytics review
|
||||
|
||||
**Questions answered:**
|
||||
- Who are our users?
|
||||
- What are their goals?
|
||||
- What problems do they face?
|
||||
- How do they currently solve this?
|
||||
|
||||
---
|
||||
|
||||
### Exploration Phase (Ideation)
|
||||
**Goal:** Generate and evaluate design directions
|
||||
|
||||
**Methods:**
|
||||
- Co-design workshops
|
||||
- Card sorting
|
||||
- Concept testing
|
||||
- Competitive analysis
|
||||
- Design critiques
|
||||
|
||||
**Questions answered:**
|
||||
- What solutions might work?
|
||||
- How should we organize information?
|
||||
- What do users expect?
|
||||
- What works elsewhere?
|
||||
|
||||
---
|
||||
|
||||
### Validation Phase (Testing)
|
||||
**Goal:** Evaluate specific designs before development
|
||||
|
||||
**Methods:**
|
||||
- Usability testing
|
||||
- Prototype testing
|
||||
- A/B testing
|
||||
- First-click tests
|
||||
- Tree testing
|
||||
|
||||
**Questions answered:**
|
||||
- Can users complete tasks?
|
||||
- Where do they struggle?
|
||||
- What works well?
|
||||
- Which version performs better?
|
||||
|
||||
---
|
||||
|
||||
### Measurement Phase (Optimization)
|
||||
**Goal:** Understand performance and iterate
|
||||
|
||||
**Methods:**
|
||||
- Analytics analysis
|
||||
- Heatmaps
|
||||
- Session recordings
|
||||
- Surveys (post-use)
|
||||
- A/B testing
|
||||
|
||||
**Questions answered:**
|
||||
- How are users actually using it?
|
||||
- Where do they drop off?
|
||||
- What's working vs. not?
|
||||
- How can we improve?
|
||||
|
||||
---
|
||||
|
||||
## Research Methods Guide
|
||||
|
||||
### 1. User Interviews
|
||||
|
||||
**What:** One-on-one conversations with users
|
||||
|
||||
**When to use:**
|
||||
- Discovery phase
|
||||
- Understanding motivations
|
||||
- Complex topics needing depth
|
||||
- Building empathy
|
||||
|
||||
**Duration:** 30-60 minutes per interview
|
||||
|
||||
**Participants:** 5-8 users per user segment
|
||||
|
||||
**Format:**
|
||||
- Semi-structured (planned questions with flexibility)
|
||||
- Open-ended questions
|
||||
- Follow-up probes
|
||||
|
||||
**Sample questions:**
|
||||
- "Tell me about a time when..."
|
||||
- "What were you trying to accomplish?"
|
||||
- "How did that make you feel?"
|
||||
- "What would make this better?"
|
||||
|
||||
**Best practices:**
|
||||
- Start broad, get specific
|
||||
- Ask "why" 5 times
|
||||
- Listen more than talk
|
||||
- Avoid leading questions
|
||||
- Record (with permission)
|
||||
|
||||
**Deliverables:**
|
||||
- Interview transcripts
|
||||
- Key findings summary
|
||||
- Quotes and themes
|
||||
- User journey maps
|
||||
|
||||
---
|
||||
|
||||
### 2. Contextual Inquiry
|
||||
|
||||
**What:** Observing users in their environment
|
||||
|
||||
**When to use:**
|
||||
- Understanding workflows
|
||||
- Physical context matters
|
||||
- Complex processes
|
||||
- B2B/enterprise products
|
||||
|
||||
**Duration:** 1-3 hours per session
|
||||
|
||||
**Participants:** 3-6 users
|
||||
|
||||
**Format:**
|
||||
- Observe users in natural environment
|
||||
- Ask questions as they work
|
||||
- Minimal interruption
|
||||
- Take photos/notes
|
||||
|
||||
**Four principles:**
|
||||
1. **Context:** Go to the user's environment
|
||||
2. **Partnership:** User and researcher collaborate
|
||||
3. **Interpretation:** Develop shared understanding
|
||||
4. **Focus:** Guide based on research questions
|
||||
|
||||
**Best practices:**
|
||||
- Master-apprentice model
|
||||
- Think-aloud protocol
|
||||
- Photograph artifacts
|
||||
- Note workarounds
|
||||
- Ask about exceptions
|
||||
|
||||
**Deliverables:**
|
||||
- Observation notes
|
||||
- Photos of workspace/tools
|
||||
- Workflow diagrams
|
||||
- Pain points and opportunities
|
||||
|
||||
---
|
||||
|
||||
### 3. Surveys
|
||||
|
||||
**What:** Quantitative data from many users
|
||||
|
||||
**When to use:**
|
||||
- Large sample sizes needed
|
||||
- Measuring satisfaction
|
||||
- Prioritizing features
|
||||
- Demographic data
|
||||
|
||||
**Duration:** 5-10 minutes (completion time)
|
||||
|
||||
**Participants:** 100+ for statistical significance
|
||||
|
||||
**Types of questions:**
|
||||
- Multiple choice
|
||||
- Likert scales (1-5 rating)
|
||||
- Ranking
|
||||
- Open-ended (limit to 1-2)
|
||||
|
||||
**Best practices:**
|
||||
- Keep it short (< 10 questions)
|
||||
- One question per page
|
||||
- Avoid bias in wording
|
||||
- Test before sending
|
||||
- Incentivize completion
|
||||
|
||||
**Common formats:**
|
||||
- NPS (Net Promoter Score)
|
||||
- CSAT (Customer Satisfaction)
|
||||
- SUS (System Usability Scale)
|
||||
- Custom satisfaction surveys
|
||||
|
||||
**Deliverables:**
|
||||
- Response data
|
||||
- Statistical analysis
|
||||
- Charts and visualizations
|
||||
- Key findings report
|
||||
|
||||
---
|
||||
|
||||
### 4. Usability Testing
|
||||
|
||||
**What:** Users attempt tasks with your design
|
||||
|
||||
**When to use:**
|
||||
- Validating designs
|
||||
- Finding usability issues
|
||||
- Comparing design options
|
||||
- Pre-launch validation
|
||||
|
||||
**Duration:** 45-60 minutes per session
|
||||
|
||||
**Participants:** 5 users per user type
|
||||
- Nielsen Norman: 5 users find 85% of issues
|
||||
|
||||
**Format:**
|
||||
1. Introduction
|
||||
2. Background questions
|
||||
3. Task scenarios (3-5 tasks)
|
||||
4. Post-task questions
|
||||
5. Debrief
|
||||
|
||||
**Task example:**
|
||||
"You need to update your credit card information. Show me how you would do that."
|
||||
|
||||
**Best practices:**
|
||||
- Test with prototype or real product
|
||||
- Think-aloud protocol
|
||||
- Don't help or lead
|
||||
- Note time to completion
|
||||
- Record screen + audio
|
||||
- Use realistic scenarios
|
||||
|
||||
**Metrics to track:**
|
||||
- Task success rate
|
||||
- Time on task
|
||||
- Errors made
|
||||
- Satisfaction rating
|
||||
|
||||
**Deliverables:**
|
||||
- Usability issues (with severity)
|
||||
- Task success rates
|
||||
- Video highlights
|
||||
- Recommendations
|
||||
|
||||
---
|
||||
|
||||
### 5. A/B Testing
|
||||
|
||||
**What:** Compare two versions with real users
|
||||
|
||||
**When to use:**
|
||||
- Optimizing designs
|
||||
- Data-driven decisions
|
||||
- High-traffic pages
|
||||
- Incremental improvements
|
||||
|
||||
**Duration:** 1-4 weeks (until statistical significance)
|
||||
|
||||
**Participants:** Varies (need large enough sample)
|
||||
|
||||
**Format:**
|
||||
- Version A (control)
|
||||
- Version B (variant)
|
||||
- Randomly assign users
|
||||
- Measure conversion
|
||||
|
||||
**Statistical requirements:**
|
||||
- Sample size calculator
|
||||
- 95% confidence level
|
||||
- 80% statistical power
|
||||
- Account for baseline conversion
|
||||
|
||||
**Best practices:**
|
||||
- Test one variable at a time
|
||||
- Run until statistically significant
|
||||
- Consider external factors (holidays, etc.)
|
||||
- Don't stop test early
|
||||
- Account for novelty effect
|
||||
|
||||
**Tools:**
|
||||
- Optimizely
|
||||
- Google Optimize
|
||||
- VWO
|
||||
- Custom implementation
|
||||
|
||||
**Deliverables:**
|
||||
- Winning variant
|
||||
- Conversion lift
|
||||
- Statistical confidence
|
||||
- Implementation recommendation
|
||||
|
||||
---
|
||||
|
||||
### 6. Card Sorting
|
||||
|
||||
**What:** Users organize content into categories
|
||||
|
||||
**When to use:**
|
||||
- Information architecture
|
||||
- Navigation design
|
||||
- Taxonomy creation
|
||||
- Menu structure
|
||||
|
||||
**Duration:** 20-30 minutes per session
|
||||
|
||||
**Participants:** 15-30 for reliable patterns
|
||||
|
||||
**Types:**
|
||||
|
||||
**Open card sort:**
|
||||
- Users create their own categories
|
||||
- Discovers mental models
|
||||
- Use early in design
|
||||
|
||||
**Closed card sort:**
|
||||
- Users sort into predefined categories
|
||||
- Validates existing structure
|
||||
- Use later in design
|
||||
|
||||
**Format:**
|
||||
1. Give users cards with content items
|
||||
2. Ask them to group related items
|
||||
3. Ask them to name groups
|
||||
4. Analyze patterns
|
||||
|
||||
**Tools:**
|
||||
- Optimal Workshop
|
||||
- UserZoom
|
||||
- Miro (remote)
|
||||
- Physical cards (in-person)
|
||||
|
||||
**Deliverables:**
|
||||
- Dendrogram (similarity matrix)
|
||||
- Common groupings
|
||||
- Category names
|
||||
- IA recommendations
|
||||
|
||||
---
|
||||
|
||||
### 7. Tree Testing
|
||||
|
||||
**What:** Users find content in text-only hierarchy
|
||||
|
||||
**When to use:**
|
||||
- Testing information architecture
|
||||
- Before visual design
|
||||
- Validating navigation
|
||||
- After card sorting
|
||||
|
||||
**Duration:** 10-15 minutes
|
||||
|
||||
**Participants:** 50+ for statistical significance
|
||||
|
||||
**Format:**
|
||||
1. Present text-only site structure
|
||||
2. Give user a task
|
||||
3. User clicks through structure
|
||||
4. Measure success and path
|
||||
|
||||
**Metrics:**
|
||||
- Success rate
|
||||
- Directness (optimal path?)
|
||||
- Time taken
|
||||
- First click
|
||||
|
||||
**Best practices:**
|
||||
- Test before visual design
|
||||
- 5-10 tasks
|
||||
- Realistic task scenarios
|
||||
- Don't test too deep (3-4 levels)
|
||||
|
||||
**Tools:**
|
||||
- Optimal Workshop
|
||||
- Treejack
|
||||
- UserZoom
|
||||
|
||||
**Deliverables:**
|
||||
- Success rates per task
|
||||
- Problem areas
|
||||
- Recommended structure changes
|
||||
- Piecharts showing paths taken
|
||||
|
||||
---
|
||||
|
||||
### 8. Diary Studies
|
||||
|
||||
**What:** Users log experiences over time
|
||||
|
||||
**When to use:**
|
||||
- Long-term behavior
|
||||
- Infrequent events
|
||||
- Context switching
|
||||
- Habitual use
|
||||
|
||||
**Duration:** 3-14 days
|
||||
|
||||
**Participants:** 10-20 users
|
||||
|
||||
**Format:**
|
||||
- Users log entries daily
|
||||
- Photo + text entries
|
||||
- Structured prompts
|
||||
- Follow-up interview
|
||||
|
||||
**Prompts example:**
|
||||
- "When did you use [product] today?"
|
||||
- "What were you trying to do?"
|
||||
- "Photo of where you were"
|
||||
- "What worked/didn't work?"
|
||||
|
||||
**Best practices:**
|
||||
- Keep it lightweight
|
||||
- Daily reminders
|
||||
- Incentivize completion
|
||||
- Follow up with interview
|
||||
|
||||
**Tools:**
|
||||
- dscout
|
||||
- Indeemo
|
||||
- Custom forms
|
||||
- Mobile apps
|
||||
|
||||
**Deliverables:**
|
||||
- Usage patterns over time
|
||||
- Context of use
|
||||
- Pain points
|
||||
- Opportunity areas
|
||||
|
||||
---
|
||||
|
||||
### 9. Competitive Analysis
|
||||
|
||||
**What:** Evaluate competitor products
|
||||
|
||||
**When to use:**
|
||||
- Understanding landscape
|
||||
- Identifying opportunities
|
||||
- Benchmarking
|
||||
- Inspiration
|
||||
|
||||
**Duration:** 1-2 weeks
|
||||
|
||||
**Competitors to analyze:** 3-5 direct + 2-3 indirect
|
||||
|
||||
**Framework:**
|
||||
1. Identify competitors
|
||||
2. Define criteria
|
||||
3. Evaluate each
|
||||
4. Synthesize findings
|
||||
|
||||
**Criteria examples:**
|
||||
- Features offered
|
||||
- User experience quality
|
||||
- Pricing/model
|
||||
- Visual design
|
||||
- Performance
|
||||
- User reviews
|
||||
|
||||
**Best practices:**
|
||||
- Sign up and use products
|
||||
- Complete key tasks
|
||||
- Read user reviews
|
||||
- Screenshot key flows
|
||||
- Note strengths/weaknesses
|
||||
|
||||
**Deliverables:**
|
||||
- Competitive matrix
|
||||
- Feature comparison
|
||||
- UX evaluation
|
||||
- Screenshots
|
||||
- Opportunities
|
||||
|
||||
---
|
||||
|
||||
### 10. Analytics Review
|
||||
|
||||
**What:** Analyze quantitative usage data
|
||||
|
||||
**When to use:**
|
||||
- Understanding current behavior
|
||||
- Identifying issues
|
||||
- Measuring impact
|
||||
- Continuous improvement
|
||||
|
||||
**Data sources:**
|
||||
- Google Analytics
|
||||
- Product analytics (Mixpanel, Amplitude)
|
||||
- Heatmaps (Hotjar, Crazy Egg)
|
||||
- Session recordings
|
||||
- Error logs
|
||||
|
||||
**Key metrics:**
|
||||
- Page views
|
||||
- Bounce rate
|
||||
- Time on page
|
||||
- Conversion rate
|
||||
- Drop-off points
|
||||
- Feature adoption
|
||||
|
||||
**Best practices:**
|
||||
- Define questions first
|
||||
- Look for anomalies
|
||||
- Segment users
|
||||
- Combine with qualitative
|
||||
- Track over time
|
||||
|
||||
**Deliverables:**
|
||||
- Usage dashboard
|
||||
- Key metrics report
|
||||
- Problem areas identified
|
||||
- Hypotheses for testing
|
||||
|
||||
---
|
||||
|
||||
## Research Planning
|
||||
|
||||
### Research Questions
|
||||
|
||||
**Bad questions:**
|
||||
- "Do users like this design?"
|
||||
- "Is this easy to use?"
|
||||
|
||||
**Good questions:**
|
||||
- "Can users find the checkout button within 10 seconds?"
|
||||
- "What prevents users from completing signup?"
|
||||
- "How do users currently manage their projects?"
|
||||
|
||||
### Research Plan Template
|
||||
|
||||
```markdown
|
||||
## Research Plan: [Project Name]
|
||||
|
||||
### Background
|
||||
[Why we're doing this research]
|
||||
|
||||
### Goals
|
||||
- [Goal 1]
|
||||
- [Goal 2]
|
||||
|
||||
### Research Questions
|
||||
1. [Question 1]
|
||||
2. [Question 2]
|
||||
3. [Question 3]
|
||||
|
||||
### Method
|
||||
[Which research method(s)]
|
||||
|
||||
### Participants
|
||||
- **Who:** [User segment]
|
||||
- **Number:** [How many]
|
||||
- **Recruiting:** [Where/how]
|
||||
- **Compensation:** [Incentive]
|
||||
|
||||
### Timeline
|
||||
- Planning: [Dates]
|
||||
- Recruiting: [Dates]
|
||||
- Sessions: [Dates]
|
||||
- Analysis: [Dates]
|
||||
- Reporting: [Dates]
|
||||
|
||||
### Deliverables
|
||||
- [Deliverable 1]
|
||||
- [Deliverable 2]
|
||||
|
||||
### Team
|
||||
- Researcher: [Name]
|
||||
- Designer: [Name]
|
||||
- Note-taker: [Name]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Recruiting Participants
|
||||
|
||||
### Screening Criteria
|
||||
|
||||
**Example screener questions:**
|
||||
|
||||
```markdown
|
||||
1. How often do you [relevant behavior]?
|
||||
- Daily (CONTINUE)
|
||||
- Weekly (CONTINUE)
|
||||
- Monthly (TERMINATE)
|
||||
- Never (TERMINATE)
|
||||
|
||||
2. What tools do you currently use for [task]?
|
||||
- [Competitor A] (CONTINUE)
|
||||
- [Competitor B] (CONTINUE)
|
||||
- Other: _____ (CONTINUE)
|
||||
- None (TERMINATE)
|
||||
|
||||
3. What is your role?
|
||||
- [Target role] (CONTINUE)
|
||||
- Other (TERMINATE)
|
||||
```
|
||||
|
||||
### Recruiting Sources
|
||||
|
||||
**Internal:**
|
||||
- Customer database
|
||||
- Email campaigns
|
||||
- In-app recruitment
|
||||
- Support ticket users
|
||||
|
||||
**External:**
|
||||
- User Interviews (platform)
|
||||
- Respondent.io
|
||||
- Ethnio
|
||||
- Craigslist (with screening)
|
||||
- Social media
|
||||
|
||||
### Incentives
|
||||
|
||||
**Typical rates:**
|
||||
- 30 min interview: $50-75
|
||||
- 60 min interview: $75-125
|
||||
- 90 min session: $100-200
|
||||
- B2B participants: $150-300
|
||||
- Executives: $300-500
|
||||
|
||||
---
|
||||
|
||||
## Conducting Research
|
||||
|
||||
### Interview Guide Template
|
||||
|
||||
```markdown
|
||||
## [Project] Interview Guide
|
||||
|
||||
**Duration:** 60 minutes
|
||||
|
||||
### Introduction (5 min)
|
||||
- Thank you for joining
|
||||
- Recording with permission
|
||||
- No right/wrong answers
|
||||
- Can stop anytime
|
||||
- Questions before we start?
|
||||
|
||||
### Warm-up (5 min)
|
||||
- Tell me about your role
|
||||
- Typical day at work
|
||||
- [Relevant context questions]
|
||||
|
||||
### Main Questions (40 min)
|
||||
|
||||
**Section 1: Current Behavior**
|
||||
- Walk me through how you [task]
|
||||
- What tools do you use?
|
||||
- What works well?
|
||||
- What's frustrating?
|
||||
|
||||
**Section 2: [Topic]**
|
||||
- [Questions]
|
||||
|
||||
**Section 3: [Topic]**
|
||||
- [Questions]
|
||||
|
||||
### Concept Test (if applicable) (10 min)
|
||||
- Show prototype/mockup
|
||||
- What do you see here?
|
||||
- What would you do first?
|
||||
- What questions do you have?
|
||||
|
||||
### Wrap-up (5 min)
|
||||
- Anything we didn't cover?
|
||||
- Final thoughts?
|
||||
- Thank you + compensation
|
||||
```
|
||||
|
||||
### Facilitation Best Practices
|
||||
|
||||
**DO:**
|
||||
- ✅ Build rapport first
|
||||
- ✅ Ask open-ended questions
|
||||
- ✅ Probe deeper ("Tell me more...")
|
||||
- ✅ Embrace silence
|
||||
- ✅ Stay neutral
|
||||
- ✅ Take notes (or have note-taker)
|
||||
|
||||
**DON'T:**
|
||||
- ❌ Lead the witness
|
||||
- ❌ Explain your design
|
||||
- ❌ Defend your choices
|
||||
- ❌ Ask yes/no questions
|
||||
- ❌ Put words in their mouth
|
||||
- ❌ Multi-part questions
|
||||
|
||||
---
|
||||
|
||||
## Analyzing Research
|
||||
|
||||
### Affinity Mapping
|
||||
|
||||
**Process:**
|
||||
1. Write observations on sticky notes
|
||||
2. Group related notes
|
||||
3. Name themes
|
||||
4. Identify patterns
|
||||
5. Prioritize insights
|
||||
|
||||
**Tools:**
|
||||
- Miro
|
||||
- Mural
|
||||
- FigJam
|
||||
- Physical wall + stickies
|
||||
|
||||
### Finding Themes
|
||||
|
||||
**Look for:**
|
||||
- Repeated phrases
|
||||
- Common pain points
|
||||
- Similar behaviors
|
||||
- Workarounds
|
||||
- Strong emotions
|
||||
|
||||
**Quotes to capture:**
|
||||
- Memorable phrases
|
||||
- Representative of theme
|
||||
- Emotionally resonant
|
||||
- Actionable insights
|
||||
|
||||
### Prioritizing Insights
|
||||
|
||||
**Framework:**
|
||||
- **Frequency:** How many users mentioned it?
|
||||
- **Severity:** How big a problem is it?
|
||||
- **Impact:** How much would solving it help?
|
||||
|
||||
**Priority Matrix:**
|
||||
```
|
||||
High Impact, High Frequency → P0 (Must fix)
|
||||
High Impact, Low Frequency → P1 (Should fix)
|
||||
Low Impact, High Frequency → P2 (Nice to fix)
|
||||
Low Impact, Low Frequency → P3 (Maybe later)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Research Deliverables
|
||||
|
||||
### 1. Research Report
|
||||
|
||||
**Structure:**
|
||||
```markdown
|
||||
# [Project] Research Report
|
||||
|
||||
## Executive Summary
|
||||
- Key findings (3-5 bullets)
|
||||
- Recommendations (3-5 bullets)
|
||||
|
||||
## Background
|
||||
- Research questions
|
||||
- Methods
|
||||
- Participants
|
||||
|
||||
## Findings
|
||||
### Theme 1: [Name]
|
||||
- Finding
|
||||
- Evidence (quotes, data)
|
||||
- Implications
|
||||
|
||||
### Theme 2: [Name]
|
||||
[Repeat]
|
||||
|
||||
## Recommendations
|
||||
1. [Action item with priority]
|
||||
2. [Action item with priority]
|
||||
|
||||
## Next Steps
|
||||
- [What comes next]
|
||||
|
||||
## Appendix
|
||||
- Full transcripts
|
||||
- Detailed data
|
||||
```
|
||||
|
||||
### 2. User Personas
|
||||
|
||||
**Components:**
|
||||
- Name and photo
|
||||
- Demographics
|
||||
- Goals
|
||||
- Frustrations
|
||||
- Behaviors
|
||||
- Quote
|
||||
- Scenario
|
||||
|
||||
**Keep it:**
|
||||
- Based on research
|
||||
- Focused on behaviors
|
||||
- Referenced in decisions
|
||||
- Updated regularly
|
||||
|
||||
### 3. Journey Maps
|
||||
|
||||
**Components:**
|
||||
- Stages of experience
|
||||
- User actions
|
||||
- Thoughts and feelings
|
||||
- Pain points
|
||||
- Opportunities
|
||||
|
||||
**Format:**
|
||||
- Timeline across top
|
||||
- Emotional curve
|
||||
- Touchpoints
|
||||
- Behind-the-scenes actions
|
||||
|
||||
---
|
||||
|
||||
## Research Ethics
|
||||
|
||||
### Informed Consent
|
||||
|
||||
**Must include:**
|
||||
- Purpose of research
|
||||
- What you'll do with data
|
||||
- Recording disclosure
|
||||
- Right to stop anytime
|
||||
- How data will be stored
|
||||
- Contact information
|
||||
|
||||
### Privacy & Data
|
||||
|
||||
**Best practices:**
|
||||
- De-identify data
|
||||
- Secure storage
|
||||
- Limited access
|
||||
- Retention policy
|
||||
- GDPR/privacy compliance
|
||||
- Don't share recordings externally
|
||||
|
||||
### Participant Wellbeing
|
||||
|
||||
**Considerations:**
|
||||
- Don't cause distress
|
||||
- Allow breaks
|
||||
- Respect "I don't know"
|
||||
- Compensate fairly
|
||||
- Follow through on promises
|
||||
|
||||
---
|
||||
|
||||
## Research Checklist for Design Briefs
|
||||
|
||||
- [ ] **Research questions** defined
|
||||
- [ ] **Methods** selected and justified
|
||||
- [ ] **Participants** criteria specified
|
||||
- [ ] **Sample size** determined
|
||||
- [ ] **Timeline** planned
|
||||
- [ ] **Recruiting** strategy defined
|
||||
- [ ] **Incentives** budgeted
|
||||
- [ ] **Interview guide** created
|
||||
- [ ] **Consent form** prepared
|
||||
- [ ] **Analysis plan** defined
|
||||
- [ ] **Deliverables** specified
|
||||
- [ ] **Stakeholder** review scheduled
|
||||
|
||||
---
|
||||
|
||||
## Resources
|
||||
|
||||
### Books
|
||||
- "Just Enough Research" - Erika Hall
|
||||
- "The User Experience Team of One" - Leah Buley
|
||||
- "Interviewing Users" - Steve Portigal
|
||||
- "Observing the User Experience" - Goodman, Kuniavsky, Moed
|
||||
|
||||
### Tools
|
||||
- **Recruiting:** User Interviews, Respondent
|
||||
- **Remote testing:** UserTesting, Lookback, Maze
|
||||
- **Surveys:** Typeform, Google Forms, Qualtrics
|
||||
- **Analysis:** Dovetail, Airtable, Notion
|
||||
- **Card sorting:** Optimal Workshop, UserZoom
|
||||
|
||||
### Templates
|
||||
- [Research Plan Template](https://www.nngroup.com/articles/ux-research-cheat-sheet/)
|
||||
- [Interview Guide Template](https://userinterviews.com/blog/interview-guide-template)
|
||||
- [Usability Test Plan](https://www.usability.gov/how-to-and-tools/resources/templates.html)
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference
|
||||
|
||||
### Research Method Selection
|
||||
|
||||
| Need | Method | Participants | Duration |
|
||||
|------|--------|--------------|----------|
|
||||
| Understand users | Interviews | 5-8 | 30-60 min |
|
||||
| Observe context | Contextual inquiry | 3-6 | 1-3 hours |
|
||||
| Large sample | Survey | 100+ | 5-10 min |
|
||||
| Test usability | Usability test | 5 | 45-60 min |
|
||||
| Compare options | A/B test | 1000+ | 1-4 weeks |
|
||||
| Organize content | Card sorting | 15-30 | 20-30 min |
|
||||
| Test IA | Tree testing | 50+ | 10-15 min |
|
||||
| Long-term use | Diary study | 10-20 | 3-14 days |
|
||||
| Competitor insight | Competitive analysis | N/A | 1-2 weeks |
|
||||
| Usage patterns | Analytics | N/A | Ongoing |
|
||||
|
||||
---
|
||||
|
||||
**Remember:** Research is not a phase, it's a practice. Build it into every project.
|
||||
Reference in New Issue
Block a user