Initial commit
This commit is contained in:
Zhongwei Li
12
.claude-plugin/plugin.json
Normal file
12
.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,12 @@
|
||||
{
|
||||
"name": "design-brief-generator",
|
||||
"description": "Generate comprehensive design briefs for design projects. Use this skill when designers ask to 'create a design brief', 'structure a design project', 'define design requirements', or need help planning design work.",
|
||||
"version": "0.0.0-2025.11.28",
|
||||
"author": {
|
||||
"name": "James Rochabrun",
|
||||
"email": "jamesrochabrun@gmail.com"
|
||||
},
|
||||
"skills": [
|
||||
"./skills/design-brief-generator"
|
||||
]
|
||||
}
|
||||
3
README.md
Normal file
3
README.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# design-brief-generator
|
||||
|
||||
Generate comprehensive design briefs for design projects. Use this skill when designers ask to 'create a design brief', 'structure a design project', 'define design requirements', or need help planning design work.
|
||||
68
plugin.lock.json
Normal file
68
plugin.lock.json
Normal file
@@ -0,0 +1,68 @@
|
||||
{
|
||||
"$schema": "internal://schemas/plugin.lock.v1.json",
|
||||
"pluginId": "gh:jamesrochabrun/skills:design-brief-generator",
|
||||
"normalized": {
|
||||
"repo": null,
|
||||
"ref": "refs/tags/v20251128.0",
|
||||
"commit": "a224b33fc1775ce70956788fc6c59dd050b31d04",
|
||||
"treeHash": "43cd6ae805dca8f27fa8344545de456325d8d99ed3302af78fde0b85ae812818",
|
||||
"generatedAt": "2025-11-28T10:17:46.610475Z",
|
||||
"toolVersion": "publish_plugins.py@0.2.0"
|
||||
},
|
||||
"origin": {
|
||||
"remote": "git@github.com:zhongweili/42plugin-data.git",
|
||||
"branch": "master",
|
||||
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
|
||||
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
|
||||
},
|
||||
"manifest": {
|
||||
"name": "design-brief-generator",
|
||||
"description": "Generate comprehensive design briefs for design projects. Use this skill when designers ask to 'create a design brief', 'structure a design project', 'define design requirements', or need help planning design work."
|
||||
},
|
||||
"content": {
|
||||
"files": [
|
||||
{
|
||||
"path": "README.md",
|
||||
"sha256": "964733951db1717bcb74d698ef7c763816e4b96ed06708cb67a5da64e14f1bc9"
|
||||
},
|
||||
{
|
||||
"path": ".claude-plugin/plugin.json",
|
||||
"sha256": "8699b91ae72df0338d42de964cf953bf23a3dd647102aff33704206ea7eda8fe"
|
||||
},
|
||||
{
|
||||
"path": "skills/design-brief-generator/SKILL.md",
|
||||
"sha256": "419cf77b8118e72b41ce73049ec674880c094c03019197f1217be74b4f0076ca"
|
||||
},
|
||||
{
|
||||
"path": "skills/design-brief-generator/references/design_principles.md",
|
||||
"sha256": "8fbc90552af392d49b4d1afe31a11aaeb5a60d8f38f2a6d6f0c3da0085a70ec8"
|
||||
},
|
||||
{
|
||||
"path": "skills/design-brief-generator/references/design_brief_template.md",
|
||||
"sha256": "2c6b9382c71bb6cad7087c180aaa9da828a796ed9562b9ae3f70aa7201a844e0"
|
||||
},
|
||||
{
|
||||
"path": "skills/design-brief-generator/references/user_research_methods.md",
|
||||
"sha256": "bb3665fc2fd9572c00049c1630933154882a49e2ff62211f625a81e39b074711"
|
||||
},
|
||||
{
|
||||
"path": "skills/design-brief-generator/references/accessibility_guidelines.md",
|
||||
"sha256": "cad4d6539a46163e7bc794378b2463284e9ad37841894b796b16096f5ecd8569"
|
||||
},
|
||||
{
|
||||
"path": "skills/design-brief-generator/scripts/generate_brief.sh",
|
||||
"sha256": "8b3225488d4b161e1597466c015a2732eba3a33cbccdf759aa7ff303219657a6"
|
||||
},
|
||||
{
|
||||
"path": "skills/design-brief-generator/scripts/validate_brief.sh",
|
||||
"sha256": "b80b9c5fe1dd363dd01861d0c9bab1ce20fa82a754b88ff368b5e03c7f0de6d6"
|
||||
}
|
||||
],
|
||||
"dirSha256": "43cd6ae805dca8f27fa8344545de456325d8d99ed3302af78fde0b85ae812818"
|
||||
},
|
||||
"security": {
|
||||
"scannedAt": null,
|
||||
"scannerVersion": null,
|
||||
"flags": []
|
||||
}
|
||||
}
|
||||
631
skills/design-brief-generator/SKILL.md
Normal file
631
skills/design-brief-generator/SKILL.md
Normal file
@@ -0,0 +1,631 @@
|
||||
---
|
||||
name: design-brief-generator
|
||||
description: Generate comprehensive design briefs for design projects. Use this skill when designers ask to "create a design brief", "structure a design project", "define design requirements", or need help planning design work.
|
||||
---
|
||||
|
||||
# Design Brief Generator
|
||||
|
||||
## Overview
|
||||
|
||||
Generate comprehensive, well-structured design briefs that align stakeholders and guide design projects. This skill helps designers create clear project briefs that define scope, goals, constraints, and success criteria.
|
||||
|
||||
**Built for:**
|
||||
- UX/UI designers
|
||||
- Product designers
|
||||
- Design leads
|
||||
- Design systems teams
|
||||
- Brand designers
|
||||
|
||||
---
|
||||
|
||||
## Quick Start
|
||||
|
||||
### 1. Generate Design Brief
|
||||
|
||||
Run the interactive script:
|
||||
|
||||
```bash
|
||||
scripts/generate_brief.sh
|
||||
```
|
||||
|
||||
This will guide you through creating a comprehensive design brief covering:
|
||||
- Project goals and objectives
|
||||
- Target users and personas
|
||||
- Design constraints
|
||||
- Success criteria
|
||||
- Timeline and deliverables
|
||||
|
||||
### 2. Validate Brief
|
||||
|
||||
Check brief completeness:
|
||||
|
||||
```bash
|
||||
scripts/validate_brief.sh <brief_file.md>
|
||||
```
|
||||
|
||||
Ensures all critical sections are included.
|
||||
|
||||
---
|
||||
|
||||
## Core Workflow
|
||||
|
||||
### When to Create a Design Brief
|
||||
|
||||
**Use a design brief for:**
|
||||
- New product/feature design projects
|
||||
- Design system initiatives
|
||||
- Redesign projects
|
||||
- Brand identity projects
|
||||
- UX research initiatives
|
||||
|
||||
**Skip for:**
|
||||
- Minor UI tweaks
|
||||
- Bug fixes
|
||||
- Small iterations on existing designs
|
||||
|
||||
---
|
||||
|
||||
## Design Brief Components
|
||||
|
||||
### 1. Project Overview
|
||||
|
||||
**What it includes:**
|
||||
- Project name and description
|
||||
- Background and context
|
||||
- Why this project matters now
|
||||
- Business objectives
|
||||
- User problems being solved
|
||||
|
||||
**Example:**
|
||||
```markdown
|
||||
## Project Overview
|
||||
|
||||
**Project:** Mobile app redesign
|
||||
**Background:** Current app has 2.8 star rating with users citing confusing navigation
|
||||
**Business Goal:** Increase app retention from 15% to 40% (Day 30)
|
||||
**User Problem:** Users can't find key features, leading to frustration and abandonment
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2. Design Goals & Objectives
|
||||
|
||||
**Define what success looks like:**
|
||||
- Primary design goal
|
||||
- Secondary goals
|
||||
- Success metrics
|
||||
- Must-haves vs. nice-to-haves
|
||||
|
||||
**Example:**
|
||||
```markdown
|
||||
## Design Goals
|
||||
|
||||
**Primary Goal:** Create intuitive navigation that helps users complete core tasks in < 3 taps
|
||||
|
||||
**Secondary Goals:**
|
||||
- Reduce visual clutter by 40%
|
||||
- Improve accessibility (WCAG AA compliance)
|
||||
- Establish reusable component library
|
||||
|
||||
**Success Metrics:**
|
||||
- Task success rate: 90%+
|
||||
- Time on task: -50%
|
||||
- SUS score: 75+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3. Target Users & Personas
|
||||
|
||||
**Who are we designing for:**
|
||||
- Primary user personas
|
||||
- User needs and pain points
|
||||
- User goals and motivations
|
||||
- Technical proficiency
|
||||
- Context of use
|
||||
|
||||
**Example:**
|
||||
```markdown
|
||||
## Target Users
|
||||
|
||||
**Primary Persona:** Sarah, Marketing Manager
|
||||
- **Age:** 32-45
|
||||
- **Tech Savvy:** Medium
|
||||
- **Goals:** Create campaigns quickly, track performance
|
||||
- **Pain Points:** Current tool too complex, takes too long
|
||||
- **Context:** Uses on desktop during work hours, sometimes mobile
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4. Design Principles & Direction
|
||||
|
||||
**Guiding principles for the project:**
|
||||
- Core design principles
|
||||
- Visual direction
|
||||
- Interaction patterns
|
||||
- Content strategy
|
||||
- Accessibility requirements
|
||||
|
||||
**Example:**
|
||||
```markdown
|
||||
## Design Principles
|
||||
|
||||
1. **Clarity over cleverness** - Users should never wonder what to do next
|
||||
2. **Progressive disclosure** - Show what's needed, hide complexity
|
||||
3. **Consistent patterns** - Use established design system components
|
||||
4. **Accessible by default** - WCAG AA minimum, aim for AAA
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5. Scope & Constraints
|
||||
|
||||
**What's in and out of scope:**
|
||||
|
||||
**In Scope:**
|
||||
- Screens/flows included
|
||||
- Platforms (web, mobile, tablet)
|
||||
- Devices and browsers
|
||||
- Accessibility requirements
|
||||
|
||||
**Out of Scope:**
|
||||
- What we're NOT designing
|
||||
- Future considerations
|
||||
|
||||
**Constraints:**
|
||||
- Technical limitations
|
||||
- Timeline constraints
|
||||
- Resource constraints
|
||||
- Brand guidelines to follow
|
||||
|
||||
**Example:**
|
||||
```markdown
|
||||
## Scope
|
||||
|
||||
**In Scope:**
|
||||
- Dashboard redesign (5 screens)
|
||||
- Mobile responsive (iOS, Android)
|
||||
- Dark mode support
|
||||
- WCAG AA compliance
|
||||
|
||||
**Out of Scope:**
|
||||
- Admin panel (separate project)
|
||||
- Native mobile apps (web only)
|
||||
- Marketing website
|
||||
|
||||
**Constraints:**
|
||||
- Must use existing design system
|
||||
- Launch deadline: 8 weeks
|
||||
- Development team: 2 engineers
|
||||
- No custom illustrations budget
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 6. User Flows & Journeys
|
||||
|
||||
**Key user paths to design:**
|
||||
- Primary user flows
|
||||
- Entry points
|
||||
- Decision points
|
||||
- Success states
|
||||
- Error states
|
||||
|
||||
**Example:**
|
||||
```markdown
|
||||
## Key User Flows
|
||||
|
||||
**Flow 1: Create Campaign**
|
||||
1. Land on dashboard
|
||||
2. Click "New Campaign"
|
||||
3. Choose template
|
||||
4. Customize content
|
||||
5. Preview
|
||||
6. Publish
|
||||
7. Success confirmation
|
||||
|
||||
**Flow 2: View Analytics**
|
||||
[Define the flow]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 7. Deliverables & Timeline
|
||||
|
||||
**What will be delivered:**
|
||||
|
||||
**Design Deliverables:**
|
||||
- User research (if needed)
|
||||
- Wireframes
|
||||
- High-fidelity mockups
|
||||
- Interactive prototype
|
||||
- Design specifications
|
||||
- Component documentation
|
||||
- Accessibility annotations
|
||||
|
||||
**Timeline:**
|
||||
- Week 1-2: Research & wireframes
|
||||
- Week 3-4: High-fidelity designs
|
||||
- Week 5-6: Prototype & testing
|
||||
- Week 7-8: Refinement & handoff
|
||||
|
||||
---
|
||||
|
||||
### 8. Success Criteria
|
||||
|
||||
**How we'll measure success:**
|
||||
|
||||
**Qualitative:**
|
||||
- User testing feedback
|
||||
- Stakeholder approval
|
||||
- Designer review
|
||||
- Accessibility audit pass
|
||||
|
||||
**Quantitative:**
|
||||
- Task success rate
|
||||
- Time on task
|
||||
- Error rate
|
||||
- SUS score
|
||||
- NPS
|
||||
|
||||
**Example:**
|
||||
```markdown
|
||||
## Success Criteria
|
||||
|
||||
**Usability Testing:**
|
||||
- 8/10 users complete primary task without help
|
||||
- Average SUS score: 75+
|
||||
- Zero critical accessibility issues
|
||||
|
||||
**Business Metrics (post-launch):**
|
||||
- 40% Day 30 retention (up from 15%)
|
||||
- 90% task completion rate
|
||||
- < 5% error rate
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Design Project Types
|
||||
|
||||
### 1. New Feature Design
|
||||
|
||||
**Focus areas:**
|
||||
- User needs validation
|
||||
- Integration with existing product
|
||||
- Interaction patterns
|
||||
- Edge cases
|
||||
|
||||
**Brief template:** Standard brief with emphasis on user flows
|
||||
|
||||
---
|
||||
|
||||
### 2. Redesign Project
|
||||
|
||||
**Focus areas:**
|
||||
- Current state analysis
|
||||
- What's working/not working
|
||||
- Migration considerations
|
||||
- Before/after comparisons
|
||||
|
||||
**Additional sections:**
|
||||
- Current pain points
|
||||
- Competitive analysis
|
||||
- Design audit findings
|
||||
|
||||
---
|
||||
|
||||
### 3. Design System
|
||||
|
||||
**Focus areas:**
|
||||
- Component inventory
|
||||
- Design principles
|
||||
- Usage guidelines
|
||||
- Governance
|
||||
|
||||
**Additional sections:**
|
||||
- Adoption strategy
|
||||
- Documentation plan
|
||||
- Maintenance plan
|
||||
|
||||
---
|
||||
|
||||
### 4. Brand/Visual Design
|
||||
|
||||
**Focus areas:**
|
||||
- Brand attributes
|
||||
- Visual language
|
||||
- Mood boards
|
||||
- Design explorations
|
||||
|
||||
**Additional sections:**
|
||||
- Brand guidelines
|
||||
- Application examples
|
||||
- Asset deliverables
|
||||
|
||||
---
|
||||
|
||||
## Stakeholder Alignment
|
||||
|
||||
### Discovery Questions
|
||||
|
||||
**Ask before starting:**
|
||||
1. What problem are we solving?
|
||||
2. Who are the users?
|
||||
3. What are the business goals?
|
||||
4. What's the timeline?
|
||||
5. What are the constraints?
|
||||
6. How will we measure success?
|
||||
7. Who needs to approve?
|
||||
|
||||
### Stakeholder Review Process
|
||||
|
||||
**Brief review checklist:**
|
||||
- [ ] Product Manager reviewed
|
||||
- [ ] Engineering lead reviewed (feasibility)
|
||||
- [ ] Design lead approved
|
||||
- [ ] Key stakeholders aligned
|
||||
- [ ] Success metrics agreed upon
|
||||
- [ ] Timeline confirmed
|
||||
- [ ] Resources allocated
|
||||
|
||||
---
|
||||
|
||||
## Design Brief Best Practices
|
||||
|
||||
### DO:
|
||||
- ✅ **Start with "why"** - Clearly state the problem
|
||||
- ✅ **Define success** - Specific, measurable criteria
|
||||
- ✅ **Include constraints** - Technical, time, resource
|
||||
- ✅ **Show examples** - Inspiration, references
|
||||
- ✅ **Get buy-in early** - Review draft with stakeholders
|
||||
- ✅ **Keep it concise** - 2-3 pages maximum
|
||||
- ✅ **Make it visual** - Include diagrams, mockups, references
|
||||
|
||||
### DON'T:
|
||||
- ❌ **Jump to solutions** - Focus on problem first
|
||||
- ❌ **Be vague** - "Make it better" isn't helpful
|
||||
- ❌ **Ignore constraints** - They shape the solution
|
||||
- ❌ **Work in isolation** - Involve PM, Engineering early
|
||||
- ❌ **Skip research** - Base decisions on data
|
||||
- ❌ **Forget accessibility** - Consider from the start
|
||||
|
||||
---
|
||||
|
||||
## Accessibility in Design Briefs
|
||||
|
||||
### Minimum Requirements
|
||||
|
||||
**Every design brief should include:**
|
||||
|
||||
**WCAG Compliance:**
|
||||
- [ ] Target level (A, AA, AAA)
|
||||
- [ ] Color contrast requirements (4.5:1 for text)
|
||||
- [ ] Keyboard navigation support
|
||||
- [ ] Screen reader compatibility
|
||||
- [ ] Touch target sizes (44x44px minimum)
|
||||
|
||||
**Testing Plan:**
|
||||
- [ ] Screen reader testing (NVDA, JAWS, VoiceOver)
|
||||
- [ ] Keyboard-only navigation
|
||||
- [ ] Color contrast validation
|
||||
- [ ] Automated testing (axe, Lighthouse)
|
||||
|
||||
See `references/accessibility_guidelines.md` for complete checklist.
|
||||
|
||||
---
|
||||
|
||||
## Cross-Functional Collaboration
|
||||
|
||||
### Working with Product
|
||||
|
||||
**PM provides:**
|
||||
- Business requirements
|
||||
- User research
|
||||
- Success metrics
|
||||
- Timeline constraints
|
||||
|
||||
**Designer provides:**
|
||||
- Design expertise
|
||||
- User experience recommendations
|
||||
- Feasibility feedback
|
||||
- Design timeline
|
||||
|
||||
### Working with Engineering
|
||||
|
||||
**Engineering needs from brief:**
|
||||
- Technical constraints acknowledged
|
||||
- Interaction patterns defined
|
||||
- Edge cases documented
|
||||
- Component reuse identified
|
||||
|
||||
**Design provides to Engineering:**
|
||||
- Design specifications
|
||||
- Component documentation
|
||||
- Interaction details
|
||||
- Responsive breakpoints
|
||||
|
||||
---
|
||||
|
||||
## Design Tools & Templates
|
||||
|
||||
### Recommended Tools
|
||||
|
||||
**Design Briefs:**
|
||||
- Notion (collaborative docs)
|
||||
- Confluence
|
||||
- Google Docs
|
||||
- Figma FigJam (visual briefs)
|
||||
|
||||
**User Flows:**
|
||||
- Figma
|
||||
- Miro
|
||||
- Whimsical
|
||||
- FigJam
|
||||
|
||||
**Prototyping:**
|
||||
- Figma
|
||||
- Framer
|
||||
- ProtoPie
|
||||
- Principle
|
||||
|
||||
---
|
||||
|
||||
## Example Design Briefs
|
||||
|
||||
### Example 1: Mobile App Feature
|
||||
|
||||
```markdown
|
||||
# Design Brief: In-App Messaging
|
||||
|
||||
## Project Overview
|
||||
Add direct messaging between users within our fitness app.
|
||||
|
||||
**Business Goal:** Increase engagement, reduce churn
|
||||
**User Problem:** Users want to connect with workout partners
|
||||
|
||||
## Design Goals
|
||||
- Enable 1:1 messaging
|
||||
- Keep it simple and focused
|
||||
- Integrate with existing notifications
|
||||
|
||||
## Target Users
|
||||
Primary: Sarah, fitness enthusiast, 28-45, uses app 4x/week
|
||||
|
||||
## Scope
|
||||
**In:** 1:1 text messaging, read receipts, notifications
|
||||
**Out:** Group chat, media sharing (future phase)
|
||||
|
||||
## Success Criteria
|
||||
- 40% of users try messaging in first 30 days
|
||||
- 20% become weekly active messagers
|
||||
- No increase in support tickets
|
||||
|
||||
## Timeline
|
||||
6 weeks: Research (1w), Design (3w), Prototype & Test (2w)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Example 2: Dashboard Redesign
|
||||
|
||||
```markdown
|
||||
# Design Brief: Analytics Dashboard Redesign
|
||||
|
||||
## Project Overview
|
||||
Redesign analytics dashboard to improve data comprehension.
|
||||
|
||||
**Current Issues:**
|
||||
- Users overwhelmed by data
|
||||
- Key metrics buried
|
||||
- Poor mobile experience
|
||||
|
||||
## Design Goals
|
||||
1. Surface most important metrics first
|
||||
2. Enable drill-down for details
|
||||
3. Make it mobile-friendly
|
||||
|
||||
## Target Users
|
||||
- Marketing managers (primary)
|
||||
- Executives (secondary)
|
||||
- Data analysts (tertiary)
|
||||
|
||||
## Success Criteria
|
||||
- Users find key metric in < 10 seconds
|
||||
- Mobile traffic increases 30%+
|
||||
- SUS score: 75+
|
||||
|
||||
## Timeline
|
||||
8 weeks (Research: 2w, Design: 4w, Testing: 2w)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Resources
|
||||
|
||||
### Scripts
|
||||
|
||||
- **generate_brief.sh** - Interactive brief generation
|
||||
- **validate_brief.sh** - Check brief completeness
|
||||
|
||||
### References
|
||||
|
||||
- **design_brief_template.md** - Comprehensive template
|
||||
- **accessibility_guidelines.md** - WCAG checklist
|
||||
- **design_principles.md** - Common design principles
|
||||
- **user_research_methods.md** - Research guidance
|
||||
|
||||
---
|
||||
|
||||
## Tips for Designers
|
||||
|
||||
### Before Creating the Brief
|
||||
|
||||
1. **Talk to stakeholders** - Understand the real problem
|
||||
2. **Review existing research** - Don't start from scratch
|
||||
3. **Check technical constraints** - Talk to engineering
|
||||
4. **Understand the timeline** - Be realistic
|
||||
|
||||
### During Brief Creation
|
||||
|
||||
1. **Start with template** - Don't reinvent the wheel
|
||||
2. **Be specific** - Vague briefs lead to vague designs
|
||||
3. **Include visuals** - Mood boards, references, examples
|
||||
4. **Define success** - How will you know it worked?
|
||||
|
||||
### After Brief Creation
|
||||
|
||||
1. **Review with PM** - Align on goals and scope
|
||||
2. **Review with Engineering** - Validate feasibility
|
||||
3. **Get stakeholder sign-off** - Explicit approval
|
||||
4. **Treat it as living doc** - Update as you learn
|
||||
|
||||
---
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
### Pitfall 1: Too Broad
|
||||
|
||||
**Problem:** "Redesign the entire app"
|
||||
**Solution:** Break into phases, prioritize
|
||||
|
||||
### Pitfall 2: Solution-First
|
||||
|
||||
**Problem:** "Make it look like Apple"
|
||||
**Solution:** Start with user problems, not aesthetics
|
||||
|
||||
### Pitfall 3: No Constraints
|
||||
|
||||
**Problem:** Ignoring technical/time limits
|
||||
**Solution:** Document and respect constraints
|
||||
|
||||
### Pitfall 4: Skipping Research
|
||||
|
||||
**Problem:** Designing based on assumptions
|
||||
**Solution:** At minimum, review existing data
|
||||
|
||||
### Pitfall 5: Vague Success Criteria
|
||||
|
||||
**Problem:** "Make it better" isn't measurable
|
||||
**Solution:** Define specific, testable criteria
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
A great design brief:
|
||||
|
||||
1. **Defines the problem** clearly
|
||||
2. **Sets goals** and success criteria
|
||||
3. **Identifies users** and their needs
|
||||
4. **Documents constraints** (time, tech, budget)
|
||||
5. **Aligns stakeholders** early
|
||||
6. **Guides the work** without being prescriptive
|
||||
7. **Evolves** as you learn
|
||||
|
||||
**Get started:**
|
||||
```bash
|
||||
scripts/generate_brief.sh
|
||||
```
|
||||
|
||||
This creates a solid foundation for successful design projects.
|
||||
@@ -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.
|
||||
486
skills/design-brief-generator/scripts/generate_brief.sh
Executable file
486
skills/design-brief-generator/scripts/generate_brief.sh
Executable file
@@ -0,0 +1,486 @@
|
||||
#!/bin/bash
|
||||
|
||||
# Design Brief Generator
|
||||
# Interactive workflow for creating design project briefs
|
||||
|
||||
set -e
|
||||
|
||||
# Colors
|
||||
GREEN='\033[0;32m'
|
||||
BLUE='\033[0;34m'
|
||||
YELLOW='\033[1;33m'
|
||||
RED='\033[0;31m'
|
||||
CYAN='\033[0;36m'
|
||||
NC='\033[0m' # No Color
|
||||
|
||||
echo -e "${BLUE}╔════════════════════════════════════════════════╗${NC}"
|
||||
echo -e "${BLUE}║ Design Brief Generator ║${NC}"
|
||||
echo -e "${BLUE}╚════════════════════════════════════════════════╝${NC}"
|
||||
echo ""
|
||||
|
||||
# Function to prompt for input
|
||||
prompt_input() {
|
||||
local prompt="$1"
|
||||
local var_name="$2"
|
||||
local required="$3"
|
||||
|
||||
while true; do
|
||||
echo -e "${YELLOW}${prompt}${NC}"
|
||||
read -r input
|
||||
|
||||
if [ -n "$input" ]; then
|
||||
eval "$var_name='$input'"
|
||||
break
|
||||
elif [ "$required" != "true" ]; then
|
||||
eval "$var_name=''"
|
||||
break
|
||||
else
|
||||
echo -e "${RED}This field is required. Please provide a value.${NC}"
|
||||
fi
|
||||
done
|
||||
}
|
||||
|
||||
# Gather basic information
|
||||
echo -e "${GREEN}Step 1: Project Basics${NC}"
|
||||
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
|
||||
echo ""
|
||||
|
||||
prompt_input "Project Name:" PROJECT_NAME true
|
||||
prompt_input "One-line Description:" DESCRIPTION true
|
||||
prompt_input "Output Filename (default: ${PROJECT_NAME// /_}_brief.md):" OUTPUT_FILE false
|
||||
|
||||
# Set default output file if not provided
|
||||
if [ -z "$OUTPUT_FILE" ]; then
|
||||
OUTPUT_FILE="${PROJECT_NAME// /_}_brief.md"
|
||||
OUTPUT_FILE=$(echo "$OUTPUT_FILE" | tr '[:upper:]' '[:lower:]')
|
||||
fi
|
||||
|
||||
echo ""
|
||||
echo -e "${GREEN}Step 2: Project Context${NC}"
|
||||
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
|
||||
echo ""
|
||||
|
||||
prompt_input "What problem are you solving?" PROBLEM true
|
||||
prompt_input "Who are the primary users?" PRIMARY_USERS true
|
||||
prompt_input "What are the business goals?" BUSINESS_GOALS true
|
||||
|
||||
echo ""
|
||||
echo -e "${GREEN}Step 3: Design Goals${NC}"
|
||||
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
|
||||
echo ""
|
||||
|
||||
prompt_input "Primary design goal:" DESIGN_GOAL true
|
||||
prompt_input "How will you measure success?" SUCCESS_METRICS true
|
||||
|
||||
echo ""
|
||||
echo -e "${GREEN}Step 4: Scope & Constraints${NC}"
|
||||
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
|
||||
echo ""
|
||||
|
||||
prompt_input "What's in scope (platforms, screens, features)?" IN_SCOPE true
|
||||
prompt_input "What's explicitly out of scope?" OUT_OF_SCOPE false
|
||||
prompt_input "Key constraints (timeline, tech, budget)?" CONSTRAINTS false
|
||||
|
||||
echo ""
|
||||
echo -e "${GREEN}Step 5: Project Type${NC}"
|
||||
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
|
||||
echo ""
|
||||
echo "Select project type:"
|
||||
echo " 1) New feature design"
|
||||
echo " 2) Redesign"
|
||||
echo " 3) Design system"
|
||||
echo " 4) Brand/Visual design"
|
||||
echo ""
|
||||
|
||||
while true; do
|
||||
read -p "Enter choice (1-4): " project_type
|
||||
case $project_type in
|
||||
1) PROJECT_TYPE="New Feature Design"; break;;
|
||||
2) PROJECT_TYPE="Redesign"; break;;
|
||||
3) PROJECT_TYPE="Design System"; break;;
|
||||
4) PROJECT_TYPE="Brand/Visual Design"; break;;
|
||||
*) echo -e "${RED}Invalid choice. Please enter 1, 2, 3, or 4.${NC}";;
|
||||
esac
|
||||
done
|
||||
|
||||
# Generate brief
|
||||
echo ""
|
||||
echo -e "${BLUE}Generating design brief...${NC}"
|
||||
echo ""
|
||||
|
||||
# Create brief from template
|
||||
cat > "$OUTPUT_FILE" << EOF
|
||||
# Design Brief: $PROJECT_NAME
|
||||
|
||||
**Project Type:** $PROJECT_TYPE
|
||||
**Designer:** $(whoami)
|
||||
**Date:** $(date +%Y-%m-%d)
|
||||
**Last Updated:** $(date +%Y-%m-%d)
|
||||
**Status:** Draft
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
$DESCRIPTION
|
||||
|
||||
This design brief outlines the approach for $PROJECT_NAME, addressing the need to $PROBLEM for $PRIMARY_USERS.
|
||||
|
||||
---
|
||||
|
||||
## Project Overview
|
||||
|
||||
### Background
|
||||
|
||||
$PROBLEM
|
||||
|
||||
### Business Objectives
|
||||
|
||||
$BUSINESS_GOALS
|
||||
|
||||
### Why Now?
|
||||
|
||||
[Add context about timing and strategic importance]
|
||||
|
||||
---
|
||||
|
||||
## Design Goals & Objectives
|
||||
|
||||
### Primary Goal
|
||||
|
||||
$DESIGN_GOAL
|
||||
|
||||
### Secondary Goals
|
||||
|
||||
- [Goal 2]
|
||||
- [Goal 3]
|
||||
|
||||
### Success Criteria
|
||||
|
||||
$SUCCESS_METRICS
|
||||
|
||||
**Specific Metrics:**
|
||||
- [Metric 1]: [Target]
|
||||
- [Metric 2]: [Target]
|
||||
- [Metric 3]: [Target]
|
||||
|
||||
---
|
||||
|
||||
## Target Users
|
||||
|
||||
### Primary User: $PRIMARY_USERS
|
||||
|
||||
**Demographics:**
|
||||
- Age range: [Range]
|
||||
- Role/Context: [Description]
|
||||
- Tech proficiency: [Low/Medium/High]
|
||||
|
||||
**User Needs:**
|
||||
- [Need 1]
|
||||
- [Need 2]
|
||||
- [Need 3]
|
||||
|
||||
**Pain Points:**
|
||||
- [Current frustration 1]
|
||||
- [Current frustration 2]
|
||||
- [Current frustration 3]
|
||||
|
||||
**User Quote:**
|
||||
_"[Include actual user feedback if available]"_
|
||||
|
||||
### Secondary Users
|
||||
|
||||
[Add if applicable]
|
||||
|
||||
---
|
||||
|
||||
## Design Principles
|
||||
|
||||
Core principles guiding this project:
|
||||
|
||||
1. **[Principle 1]** - [Description]
|
||||
2. **[Principle 2]** - [Description]
|
||||
3. **[Principle 3]** - [Description]
|
||||
4. **[Principle 4]** - [Description]
|
||||
|
||||
---
|
||||
|
||||
## Scope
|
||||
|
||||
### In Scope
|
||||
|
||||
$IN_SCOPE
|
||||
|
||||
- [Additional scope item]
|
||||
- [Additional scope item]
|
||||
|
||||
### Out of Scope
|
||||
|
||||
$OUT_OF_SCOPE
|
||||
|
||||
- [Additional exclusion]
|
||||
- [Future consideration]
|
||||
|
||||
### Constraints
|
||||
|
||||
$CONSTRAINTS
|
||||
|
||||
**Technical Constraints:**
|
||||
- [Technical limitation]
|
||||
|
||||
**Timeline Constraints:**
|
||||
- [Deadline or milestone]
|
||||
|
||||
**Resource Constraints:**
|
||||
- [Budget, team size, etc.]
|
||||
|
||||
---
|
||||
|
||||
## Key User Flows
|
||||
|
||||
### Flow 1: [Primary User Flow]
|
||||
|
||||
1. [Entry point]
|
||||
2. [Step 1]
|
||||
3. [Step 2]
|
||||
4. [Decision point]
|
||||
5. [Success state]
|
||||
|
||||
**Alternative Paths:**
|
||||
- [Error state]
|
||||
- [Alternative completion]
|
||||
|
||||
### Flow 2: [Secondary Flow]
|
||||
|
||||
[Define flow]
|
||||
|
||||
---
|
||||
|
||||
## Design Requirements
|
||||
|
||||
### Visual Design
|
||||
|
||||
- Style: [Minimalist/Bold/Playful/etc.]
|
||||
- Mood: [Professional/Friendly/Energetic/etc.]
|
||||
- Visual references: [Links to inspiration]
|
||||
|
||||
### Interaction Design
|
||||
|
||||
- Primary interaction patterns: [Tap/Swipe/Hover/etc.]
|
||||
- Animations: [Yes/No, what kind]
|
||||
- Feedback mechanisms: [How system responds]
|
||||
|
||||
### Accessibility
|
||||
|
||||
- **WCAG Level:** [A/AA/AAA]
|
||||
- **Required:**
|
||||
- [ ] Keyboard navigation
|
||||
- [ ] Screen reader support
|
||||
- [ ] Color contrast (4.5:1 minimum)
|
||||
- [ ] Touch targets (44x44px)
|
||||
- [ ] Focus indicators
|
||||
- [ ] Alternative text for images
|
||||
|
||||
### Responsive Design
|
||||
|
||||
- **Platforms:** [Web/iOS/Android]
|
||||
- **Breakpoints:**
|
||||
- Mobile: 320px - 767px
|
||||
- Tablet: 768px - 1023px
|
||||
- Desktop: 1024px+
|
||||
|
||||
---
|
||||
|
||||
## Deliverables & Timeline
|
||||
|
||||
### Design Deliverables
|
||||
|
||||
**Research Phase:**
|
||||
- [ ] Competitive analysis
|
||||
- [ ] User research findings (if applicable)
|
||||
- [ ] Current state analysis (if redesign)
|
||||
|
||||
**Design Phase:**
|
||||
- [ ] User flows
|
||||
- [ ] Wireframes (low-fi)
|
||||
- [ ] High-fidelity mockups
|
||||
- [ ] Interactive prototype
|
||||
- [ ] Design specifications
|
||||
- [ ] Component documentation
|
||||
- [ ] Accessibility annotations
|
||||
|
||||
**Handoff Phase:**
|
||||
- [ ] Developer handoff session
|
||||
- [ ] Asset export
|
||||
- [ ] Design QA checklist
|
||||
|
||||
### Timeline
|
||||
|
||||
| Phase | Duration | Deliverables | Due Date |
|
||||
|-------|----------|-------------|----------|
|
||||
| Discovery & Research | [X weeks] | Research, flows | [Date] |
|
||||
| Wireframes | [X weeks] | Low-fi designs | [Date] |
|
||||
| High-Fidelity | [X weeks] | Mockups, prototype | [Date] |
|
||||
| Testing & Iteration | [X weeks] | Refined designs | [Date] |
|
||||
| Handoff | [X weeks] | Specs, assets | [Date] |
|
||||
|
||||
**Key Milestones:**
|
||||
- [Date]: Design review #1 (wireframes)
|
||||
- [Date]: Design review #2 (high-fi)
|
||||
- [Date]: Usability testing
|
||||
- [Date]: Final design sign-off
|
||||
- [Date]: Developer handoff
|
||||
|
||||
---
|
||||
|
||||
## Design Direction
|
||||
|
||||
### Visual References
|
||||
|
||||
**Inspiration:**
|
||||
- [Link to mood board]
|
||||
- [Link to similar products]
|
||||
- [Link to design explorations]
|
||||
|
||||
**What We Like:**
|
||||
- [Specific element from reference 1]
|
||||
- [Specific element from reference 2]
|
||||
|
||||
**What to Avoid:**
|
||||
- [Anti-pattern 1]
|
||||
- [Anti-pattern 2]
|
||||
|
||||
---
|
||||
|
||||
## Technical Considerations
|
||||
|
||||
### Design System
|
||||
|
||||
- **Using existing:** [Yes/No, which system]
|
||||
- **New components needed:** [List]
|
||||
- **Design tokens:** [Colors, typography, spacing]
|
||||
|
||||
### Implementation Notes
|
||||
|
||||
- [Technical constraint to consider]
|
||||
- [Platform-specific considerations]
|
||||
- [Performance considerations]
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
### Usability Testing
|
||||
|
||||
**Pre-Launch:**
|
||||
- [ ] Task success rate: 90%+
|
||||
- [ ] Time on task: [Target time]
|
||||
- [ ] SUS score: 75+
|
||||
- [ ] Accessibility: Zero critical issues
|
||||
|
||||
**Test Scenarios:**
|
||||
1. [Scenario 1]
|
||||
2. [Scenario 2]
|
||||
3. [Scenario 3]
|
||||
|
||||
### Post-Launch Metrics
|
||||
|
||||
**Within 30 days:**
|
||||
- [Metric 1]: [Target]
|
||||
- [Metric 2]: [Target]
|
||||
- [Metric 3]: [Target]
|
||||
|
||||
**Within 90 days:**
|
||||
- [Longer-term metric 1]
|
||||
- [Longer-term metric 2]
|
||||
|
||||
---
|
||||
|
||||
## Stakeholders & Roles
|
||||
|
||||
| Role | Name | Responsibility | Status |
|
||||
|------|------|---------------|--------|
|
||||
| Designer | [Name] | Design execution | Active |
|
||||
| Design Lead | [Name] | Design approval | Review |
|
||||
| Product Manager | [Name] | Requirements, priorities | Review |
|
||||
| Engineering Lead | [Name] | Feasibility, timeline | Review |
|
||||
| User Researcher | [Name] | Research insights | Support |
|
||||
|
||||
**Sign-Off Required:**
|
||||
- [ ] Design Lead
|
||||
- [ ] Product Manager
|
||||
- [ ] Engineering Lead
|
||||
|
||||
---
|
||||
|
||||
## Risks & Dependencies
|
||||
|
||||
### Risks
|
||||
|
||||
| Risk | Impact | Mitigation |
|
||||
|------|--------|-----------|
|
||||
| [Risk 1] | High/Med/Low | [How to address] |
|
||||
| [Risk 2] | High/Med/Low | [How to address] |
|
||||
|
||||
### Dependencies
|
||||
|
||||
- [ ] [Dependency 1: e.g., API availability]
|
||||
- [ ] [Dependency 2: e.g., Design system update]
|
||||
- [ ] [Dependency 3]
|
||||
|
||||
---
|
||||
|
||||
## Open Questions
|
||||
|
||||
- [ ] [Question 1]
|
||||
- [ ] [Question 2]
|
||||
- [ ] [Question 3]
|
||||
|
||||
**Decisions Needed:**
|
||||
- [ ] [Decision 1] - Owner: [Name], By: [Date]
|
||||
- [ ] [Decision 2] - Owner: [Name], By: [Date]
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
**Research:**
|
||||
- [Link to user research]
|
||||
- [Link to analytics data]
|
||||
|
||||
**Design:**
|
||||
- [Link to Figma file]
|
||||
- [Link to design system]
|
||||
|
||||
**Context:**
|
||||
- [Link to PRD]
|
||||
- [Link to technical spec]
|
||||
|
||||
---
|
||||
|
||||
## Appendix
|
||||
|
||||
### Change Log
|
||||
|
||||
| Date | Change | Author |
|
||||
|------|--------|--------|
|
||||
| $(date +%Y-%m-%d) | Initial draft | $(whoami) |
|
||||
|
||||
### Notes
|
||||
|
||||
[Additional context, decisions, or important information]
|
||||
|
||||
EOF
|
||||
|
||||
echo -e "${GREEN}✓ Design brief generated successfully!${NC}"
|
||||
echo ""
|
||||
echo -e "Output file: ${BLUE}$OUTPUT_FILE${NC}"
|
||||
echo ""
|
||||
echo -e "${YELLOW}Next steps:${NC}"
|
||||
echo " 1. Review and fill in placeholder sections"
|
||||
echo " 2. Add user flows and design requirements"
|
||||
echo " 3. Attach visual references or mood boards"
|
||||
echo " 4. Share with stakeholders for review"
|
||||
echo " 5. Run validation: scripts/validate_brief.sh $OUTPUT_FILE"
|
||||
echo ""
|
||||
echo -e "${GREEN}✓ Done!${NC}"
|
||||
243
skills/design-brief-generator/scripts/validate_brief.sh
Normal file
243
skills/design-brief-generator/scripts/validate_brief.sh
Normal file
@@ -0,0 +1,243 @@
|
||||
#!/bin/bash
|
||||
|
||||
# Design Brief Validation Script
|
||||
# Checks design brief completeness and quality
|
||||
|
||||
set -e
|
||||
|
||||
# Colors
|
||||
GREEN='\033[0;32m'
|
||||
BLUE='\033[0;34m'
|
||||
YELLOW='\033[1;33m'
|
||||
RED='\033[0;31m'
|
||||
NC='\033[0m'
|
||||
|
||||
# Check if file provided
|
||||
if [ $# -lt 1 ]; then
|
||||
echo "Usage: $0 <brief_file.md>"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
BRIEF_FILE="$1"
|
||||
|
||||
# Check if file exists
|
||||
if [ ! -f "$BRIEF_FILE" ]; then
|
||||
echo -e "${RED}✗ Error: File not found: $BRIEF_FILE${NC}"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo -e "${BLUE}╔════════════════════════════════════════════════╗${NC}"
|
||||
echo -e "${BLUE}║ Design Brief Validation Report ║${NC}"
|
||||
echo -e "${BLUE}╚════════════════════════════════════════════════╝${NC}"
|
||||
echo ""
|
||||
echo -e "File: ${BLUE}$BRIEF_FILE${NC}"
|
||||
echo ""
|
||||
|
||||
# Counters
|
||||
ISSUES_FOUND=0
|
||||
WARNINGS=0
|
||||
CHECKS_PASSED=0
|
||||
|
||||
# Function to check section exists
|
||||
check_section() {
|
||||
local section_name="$1"
|
||||
local section_pattern="$2"
|
||||
local required="$3"
|
||||
|
||||
if grep -q "$section_pattern" "$BRIEF_FILE"; then
|
||||
echo -e "${GREEN}✓${NC} $section_name section found"
|
||||
((CHECKS_PASSED++))
|
||||
return 0
|
||||
else
|
||||
if [ "$required" = "true" ]; then
|
||||
echo -e "${RED}✗${NC} $section_name section missing (REQUIRED)"
|
||||
((ISSUES_FOUND++))
|
||||
else
|
||||
echo -e "${YELLOW}⚠${NC} $section_name section missing (recommended)"
|
||||
((WARNINGS++))
|
||||
fi
|
||||
return 1
|
||||
fi
|
||||
}
|
||||
|
||||
echo -e "${BLUE}━━━ Required Sections ━━━${NC}"
|
||||
echo ""
|
||||
|
||||
# Check required sections
|
||||
check_section "Project Overview" "##.*Project Overview\|##.*Overview" true
|
||||
check_section "Design Goals" "##.*Design Goals\|##.*Goals.*Objectives" true
|
||||
check_section "Target Users" "##.*Target Users\|##.*Users" true
|
||||
check_section "Scope" "##.*Scope" true
|
||||
check_section "Success Criteria/Metrics" "##.*Success\|##.*Metrics" true
|
||||
|
||||
echo ""
|
||||
echo -e "${BLUE}━━━ Recommended Sections ━━━${NC}"
|
||||
echo ""
|
||||
|
||||
# Check recommended sections
|
||||
check_section "Design Principles" "##.*Design Principles\|##.*Principles" false
|
||||
check_section "User Flows" "##.*User Flows\|##.*Flows" false
|
||||
check_section "Deliverables" "##.*Deliverables" false
|
||||
check_section "Timeline" "##.*Timeline" false
|
||||
check_section "Accessibility" "##.*Accessibility\|##.*a11y\|##.*WCAG" false
|
||||
|
||||
echo ""
|
||||
echo -e "${BLUE}━━━ Content Quality Checks ━━━${NC}"
|
||||
echo ""
|
||||
|
||||
# Check for placeholder text
|
||||
if grep -q "\[.*\]" "$BRIEF_FILE"; then
|
||||
echo -e "${YELLOW}⚠${NC} Contains placeholder brackets - fill in all placeholders"
|
||||
((WARNINGS++))
|
||||
else
|
||||
echo -e "${GREEN}✓${NC} No placeholders remaining"
|
||||
((CHECKS_PASSED++))
|
||||
fi
|
||||
|
||||
# Check for TBD/TODO
|
||||
if grep -qi "TBD\|TODO\|FIXME" "$BRIEF_FILE"; then
|
||||
echo -e "${YELLOW}⚠${NC} Contains TBD/TODO markers - resolve open items"
|
||||
((WARNINGS++))
|
||||
else
|
||||
echo -e "${GREEN}✓${NC} No TBD markers"
|
||||
((CHECKS_PASSED++))
|
||||
fi
|
||||
|
||||
# Check for empty sections
|
||||
if grep -q "^##.*\n\n##" "$BRIEF_FILE"; then
|
||||
echo -e "${YELLOW}⚠${NC} Empty sections detected"
|
||||
((WARNINGS++))
|
||||
else
|
||||
echo -e "${GREEN}✓${NC} No empty sections"
|
||||
((CHECKS_PASSED++))
|
||||
fi
|
||||
|
||||
# Check for specific design content
|
||||
echo ""
|
||||
echo -e "${BLUE}━━━ Design-Specific Checks ━━━${NC}"
|
||||
echo ""
|
||||
|
||||
# Check for user mentions
|
||||
if grep -qi "user\|persona" "$BRIEF_FILE"; then
|
||||
echo -e "${GREEN}✓${NC} Users/personas mentioned"
|
||||
((CHECKS_PASSED++))
|
||||
else
|
||||
echo -e "${RED}✗${NC} No users or personas defined"
|
||||
((ISSUES_FOUND++))
|
||||
fi
|
||||
|
||||
# Check for success metrics
|
||||
if grep -qi "metric\|measure\|KPI\|success" "$BRIEF_FILE"; then
|
||||
echo -e "${GREEN}✓${NC} Success metrics mentioned"
|
||||
((CHECKS_PASSED++))
|
||||
else
|
||||
echo -e "${RED}✗${NC} Success metrics not clearly defined"
|
||||
((ISSUES_FOUND++))
|
||||
fi
|
||||
|
||||
# Check for accessibility
|
||||
if grep -qi "accessibility\|a11y\|WCAG" "$BRIEF_FILE"; then
|
||||
echo -e "${GREEN}✓${NC} Accessibility considerations included"
|
||||
((CHECKS_PASSED++))
|
||||
else
|
||||
echo -e "${YELLOW}⚠${NC} No accessibility requirements mentioned"
|
||||
((WARNINGS++))
|
||||
fi
|
||||
|
||||
# Check for scope definition
|
||||
IN_SCOPE=false
|
||||
OUT_SCOPE=false
|
||||
|
||||
if grep -qi "in scope\|in-scope" "$BRIEF_FILE"; then
|
||||
echo -e "${GREEN}✓${NC} In-scope defined"
|
||||
IN_SCOPE=true
|
||||
((CHECKS_PASSED++))
|
||||
else
|
||||
echo -e "${YELLOW}⚠${NC} In-scope not clearly defined"
|
||||
((WARNINGS++))
|
||||
fi
|
||||
|
||||
if grep -qi "out of scope\|out-of-scope" "$BRIEF_FILE"; then
|
||||
echo -e "${GREEN}✓${NC} Out-of-scope defined"
|
||||
OUT_SCOPE=true
|
||||
((CHECKS_PASSED++))
|
||||
else
|
||||
echo -e "${YELLOW}⚠${NC} Out-of-scope not defined (prevents scope creep)"
|
||||
((WARNINGS++))
|
||||
fi
|
||||
|
||||
# Check for design principles
|
||||
if grep -qi "principle\|guideline" "$BRIEF_FILE"; then
|
||||
echo -e "${GREEN}✓${NC} Design principles mentioned"
|
||||
((CHECKS_PASSED++))
|
||||
else
|
||||
echo -e "${YELLOW}⚠${NC} Consider adding guiding design principles"
|
||||
((WARNINGS++))
|
||||
fi
|
||||
|
||||
# Document quality
|
||||
echo ""
|
||||
echo -e "${BLUE}━━━ Document Quality ━━━${NC}"
|
||||
echo ""
|
||||
|
||||
# Check word count
|
||||
WORD_COUNT=$(wc -w < "$BRIEF_FILE")
|
||||
echo -e "Word count: $WORD_COUNT"
|
||||
|
||||
if [ "$WORD_COUNT" -lt 400 ]; then
|
||||
echo -e "${YELLOW}⚠${NC} Brief seems short (< 400 words)"
|
||||
((WARNINGS++))
|
||||
elif [ "$WORD_COUNT" -gt 3000 ]; then
|
||||
echo -e "${YELLOW}⚠${NC} Brief is very long (> 3000 words) - consider condensing"
|
||||
((WARNINGS++))
|
||||
else
|
||||
echo -e "${GREEN}✓${NC} Brief length appropriate"
|
||||
((CHECKS_PASSED++))
|
||||
fi
|
||||
|
||||
# Check for proper heading structure
|
||||
if grep -q "^#\s" "$BRIEF_FILE"; then
|
||||
echo -e "${GREEN}✓${NC} Proper heading structure"
|
||||
((CHECKS_PASSED++))
|
||||
else
|
||||
echo -e "${YELLOW}⚠${NC} Check heading hierarchy (should start with # not ##)"
|
||||
((WARNINGS++))
|
||||
fi
|
||||
|
||||
# Final Summary
|
||||
echo ""
|
||||
echo -e "${BLUE}╔════════════════════════════════════════════════╗${NC}"
|
||||
echo -e "${BLUE}║ Validation Summary ║${NC}"
|
||||
echo -e "${BLUE}╚════════════════════════════════════════════════╝${NC}"
|
||||
echo ""
|
||||
echo -e "Checks passed: ${GREEN}$CHECKS_PASSED${NC}"
|
||||
echo -e "Warnings: ${YELLOW}$WARNINGS${NC}"
|
||||
echo -e "Issues found: ${RED}$ISSUES_FOUND${NC}"
|
||||
echo ""
|
||||
|
||||
# Recommendations
|
||||
echo -e "${BLUE}━━━ Recommendations ━━━${NC}"
|
||||
echo ""
|
||||
echo "1. Ensure all required sections are complete"
|
||||
echo "2. Fill in all placeholder text marked with [brackets]"
|
||||
echo "3. Define clear, measurable success criteria"
|
||||
echo "4. Include accessibility requirements (WCAG level)"
|
||||
echo "5. Clearly define what's in and out of scope"
|
||||
echo "6. Add user flows for key interactions"
|
||||
echo "7. Review with stakeholders before starting design work"
|
||||
echo ""
|
||||
|
||||
# Exit code
|
||||
if [ "$ISSUES_FOUND" -gt 0 ]; then
|
||||
echo -e "${RED}❌ Design brief validation failed${NC}"
|
||||
echo -e " Address $ISSUES_FOUND critical issue(s) before proceeding"
|
||||
exit 1
|
||||
elif [ "$WARNINGS" -gt 0 ]; then
|
||||
echo -e "${YELLOW}⚠ Design brief validation passed with warnings${NC}"
|
||||
echo -e " Consider addressing $WARNINGS warning(s) to improve quality"
|
||||
exit 0
|
||||
else
|
||||
echo -e "${GREEN}✅ Design brief validation passed!${NC}"
|
||||
echo -e " Brief looks ready for stakeholder review"
|
||||
exit 0
|
||||
fi
|
||||
Reference in New Issue
Block a user