289 lines
7.0 KiB
Markdown
289 lines
7.0 KiB
Markdown
# User Persona Template
|
|
|
|
Use this template when creating user personas to guide design decisions.
|
|
|
|
## Persona Structure
|
|
|
|
### Basic Information
|
|
|
|
**Name:** [Give a realistic name]
|
|
**Age:** [Age or age range]
|
|
**Occupation:** [Job title/role]
|
|
**Location:** [City, state/country]
|
|
**Photo:** [Description of representative person]
|
|
|
|
### Demographics
|
|
|
|
**Education:** [Highest level completed]
|
|
**Income Level:** [Range if relevant]
|
|
**Tech Savviness:** [Low / Medium / High]
|
|
**Preferred Devices:** [Desktop, mobile, tablet preferences]
|
|
|
|
### Psychographics
|
|
|
|
**Goals:**
|
|
- Primary goal related to product/service
|
|
- Secondary goals
|
|
- Long-term aspirations
|
|
|
|
**Pain Points:**
|
|
- Frustrations with current solutions
|
|
- Obstacles to achieving goals
|
|
- Areas of friction in user journey
|
|
|
|
**Motivations:**
|
|
- What drives their behavior
|
|
- What success looks like to them
|
|
- Triggers for taking action
|
|
|
|
**Behaviors:**
|
|
- How they currently solve problems
|
|
- Daily routines and habits
|
|
- Decision-making process
|
|
- Information-seeking patterns
|
|
|
|
### Context
|
|
|
|
**Typical Day:**
|
|
Brief narrative of how they would interact with your product/service in their daily life.
|
|
|
|
**Quote:**
|
|
> "A quote that captures their mindset or primary frustration"
|
|
|
|
### Design Implications
|
|
|
|
**Priorities for this persona:**
|
|
1. Most important feature/capability
|
|
2. Second priority
|
|
3. Third priority
|
|
|
|
**Design Considerations:**
|
|
- UI complexity they can handle
|
|
- Information density preferences
|
|
- Visual style they'd resonate with
|
|
- Language/tone that appeals to them
|
|
|
|
---
|
|
|
|
## Example Personas
|
|
|
|
### Example 1: B2B SaaS Product
|
|
|
|
**Name:** Sarah Chen
|
|
**Age:** 34
|
|
**Occupation:** Marketing Manager at mid-size tech company
|
|
**Location:** San Francisco, CA
|
|
**Tech Savviness:** High
|
|
|
|
**Goals:**
|
|
- Track campaign performance across multiple channels
|
|
- Generate reports for stakeholders quickly
|
|
- Prove ROI of marketing initiatives
|
|
- Streamline team collaboration
|
|
|
|
**Pain Points:**
|
|
- Current tools require too many manual exports
|
|
- Data lives in siloed systems
|
|
- Difficult to visualize trends
|
|
- Stakeholder reports take hours to compile
|
|
|
|
**Motivations:**
|
|
- Career advancement through data-driven decisions
|
|
- Making team more efficient
|
|
- Proving marketing's business impact
|
|
- Reducing time on administrative tasks
|
|
|
|
**Behaviors:**
|
|
- Checks dashboards first thing each morning
|
|
- Makes decisions based on data, not gut feel
|
|
- Shares insights with team in Slack
|
|
- Prefers visual data over spreadsheets
|
|
|
|
**Quote:**
|
|
> "I spend more time making reports than actually analyzing the data."
|
|
|
|
**Design Implications:**
|
|
- Dashboard should load fast with real-time data
|
|
- Export/share functionality needs to be prominent
|
|
- Visual data representation crucial
|
|
- Mobile view important for on-the-go checks
|
|
- Clean, professional aesthetic
|
|
|
|
---
|
|
|
|
### Example 2: Consumer Mobile App
|
|
|
|
**Name:** Marcus Johnson
|
|
**Age:** 28
|
|
**Occupation:** Personal Trainer
|
|
**Location:** Austin, TX
|
|
**Tech Savviness:** Medium
|
|
|
|
**Goals:**
|
|
- Track client progress efficiently
|
|
- Schedule and manage appointments
|
|
- Share workout plans easily
|
|
- Build professional online presence
|
|
|
|
**Pain Points:**
|
|
- Juggling multiple apps is confusing
|
|
- Clients forget scheduled sessions
|
|
- Difficult to show progress over time
|
|
- Paper-based tracking isn't professional
|
|
|
|
**Motivations:**
|
|
- Growing client base
|
|
- Looking professional to prospects
|
|
- Saving time on administrative work
|
|
- Providing better client experience
|
|
|
|
**Behaviors:**
|
|
- Checks phone between client sessions
|
|
- Prefers quick mobile interactions
|
|
- Learns by doing, not reading manuals
|
|
- Values visual progress tracking
|
|
|
|
**Quote:**
|
|
> "I need something simple that makes me look professional to my clients."
|
|
|
|
**Design Implications:**
|
|
- Mobile-first design is critical
|
|
- Large touch targets for ease of use
|
|
- Quick actions without deep menus
|
|
- Visual progress charts for sharing
|
|
- Clean but energetic visual style
|
|
- Minimal text, maximum visual feedback
|
|
|
|
---
|
|
|
|
### Example 3: Enterprise Software
|
|
|
|
**Name:** David Patel
|
|
**Age:** 51
|
|
**Occupation:** IT Director at Fortune 500 company
|
|
**Location:** Chicago, IL
|
|
**Tech Savviness:** High (but values efficiency over novelty)
|
|
|
|
**Goals:**
|
|
- Ensure system security and compliance
|
|
- Manage budget and vendor relationships
|
|
- Minimize downtime and incidents
|
|
- Support 5,000+ employees efficiently
|
|
|
|
**Pain Points:**
|
|
- Too many disparate systems to monitor
|
|
- Difficulty demonstrating security posture
|
|
- Vendor management is time-consuming
|
|
- Hard to get visibility across entire infrastructure
|
|
|
|
**Motivations:**
|
|
- Protecting company and employee data
|
|
- Proving value to executive team
|
|
- Career reputation on system reliability
|
|
- Simplifying complex environments
|
|
|
|
**Behaviors:**
|
|
- Prefers desktop for serious work
|
|
- Values comprehensive documentation
|
|
- Makes decisions based on security first
|
|
- Needs to justify purchases with data
|
|
- Expects professional support
|
|
|
|
**Quote:**
|
|
> "I need complete visibility and control, but I don't have time to babysit systems."
|
|
|
|
**Design Implications:**
|
|
- Information-dense interfaces acceptable
|
|
- Security features prominently featured
|
|
- Comprehensive reporting capabilities
|
|
- Professional, trustworthy visual design
|
|
- Clear documentation and support access
|
|
- Desktop-optimized, with mobile monitoring
|
|
|
|
---
|
|
|
|
## Creating Personas from Research
|
|
|
|
### Data Sources
|
|
|
|
**Quantitative:**
|
|
- Analytics data (demographics, behavior patterns)
|
|
- Survey responses
|
|
- Usage statistics
|
|
- A/B test results
|
|
|
|
**Qualitative:**
|
|
- User interviews
|
|
- Customer support tickets
|
|
- Sales team feedback
|
|
- Social media comments
|
|
- Competitor reviews
|
|
|
|
### Synthesis Process
|
|
|
|
1. **Identify patterns** in research data
|
|
2. **Group similar users** into segments
|
|
3. **Create 2-4 distinct personas** (not more)
|
|
4. **Name and humanize** each persona
|
|
5. **Validate** with real users if possible
|
|
6. **Update** as you learn more
|
|
|
|
### Using Personas
|
|
|
|
**Design decisions:**
|
|
- "Would Sarah find this feature intuitive?"
|
|
- "Does this match Marcus's mobile-first behavior?"
|
|
- "Is this comprehensive enough for David's needs?"
|
|
|
|
**Prioritization:**
|
|
- Which features serve primary persona?
|
|
- What can be deprioritized for secondary personas?
|
|
- Are we excluding any important user segments?
|
|
|
|
**Communication:**
|
|
- Share personas with entire team
|
|
- Reference in design reviews
|
|
- Use in user story writing
|
|
- Test designs against persona needs
|
|
|
|
---
|
|
|
|
## Red Flags
|
|
|
|
**Personas to avoid:**
|
|
|
|
**Too generic:**
|
|
- "Tech-savvy millennial"
|
|
- Could describe anyone
|
|
- No specific goals or pain points
|
|
|
|
**Too specific:**
|
|
- Based on one person only
|
|
- Includes irrelevant details
|
|
- Not representative of segment
|
|
|
|
**Too many:**
|
|
- More than 4-5 personas
|
|
- Dilutes focus
|
|
- Makes design decisions harder
|
|
|
|
**Aspirational rather than realistic:**
|
|
- Who you WANT users to be
|
|
- Not who they actually are
|
|
- Leads to mismatch with real users
|
|
|
|
---
|
|
|
|
## Persona Checklist
|
|
|
|
- [ ] Based on research, not assumptions
|
|
- [ ] Includes demographics AND psychographics
|
|
- [ ] Clear goals and pain points
|
|
- [ ] Specific behaviors described
|
|
- [ ] Design implications outlined
|
|
- [ ] Relatable and memorable
|
|
- [ ] Validated with real users
|
|
- [ ] Shared with entire team
|
|
- [ ] Referenced in decision-making
|
|
- [ ] Updated as you learn more
|