Ux Research

UX Research

Plan, conduct, and analyze user research that produces actionable insights for product design. This skill provides frameworks, methods, and practical guidance for every stage of the research process — from defining the right question to presenting findings that drive decisions.

When to Use This Skill

Use this skill when:

• Planning a research study (choosing methods, defining scope, writing a plan)
• Writing interview scripts or discussion guides
• Creating usability test plans with tasks and success metrics
• Recruiting participants and writing screener surveys
• Analyzing qualitative data (affinity diagrams, thematic analysis)
• Synthesizing research into personas, journey maps, or opportunity maps
• Setting up continuous discovery practices (weekly interviews, OSTs)
• Presenting findings and recommendations to stakeholders

Core Principle

Research is a tool for reducing risk, not a deliverable. The goal is always to inform decisions — not to produce documents. Research is not asking people what they like, not a political tool, and not science. It's applied inquiry that helps you solve the right problem.

Research Types

Choose your research type based on what decisions are in play:

Generative / Exploratory

When: Before you know what you're building. You need to define the problem. Methods: Interviews, field observation, contextual inquiry, diary studies, literature review Output: Problem definition, opportunity areas, personas, mental models

Descriptive

When: You have a design problem and need to fully understand the context. Methods: Contextual inquiry, fly-on-the-wall observation, journey mapping, card sorting Output: Current-state maps, workflow diagrams, mental models

Evaluative

When: You have potential solutions and need to test them. Methods: Usability testing, heuristic evaluation, A/B testing, click testing, tree testing Output: Severity-ranked issues, task completion rates, recommendations

Causal

When: A solution is live and you need to understand actual usage patterns. Methods: Analytics review, A/B testing, funnel analysis, surveys Output: Conversion data, behavioral patterns, quantitative validation

The Research Process

1. Define the Problem

Start with a clear problem statement. Base it on a verb that indicates outcome:

• Good: "Identify the barriers preventing users from completing onboarding"
• Good: "Evaluate whether the new checkout flow reduces abandonment"
• Bad: "Understand the user experience" (too vague)
• Bad: "Explore the problem space" (no measurable outcome)

Write 3-5 research questions. More than 10 means your scope is too broad.

2. Select the Approach

See references/research-methods-catalog.md for detailed method descriptions.

3. Plan and Prepare

Every study needs a written plan, even if it's brief. Use templates/research-plan-template.md.

Essential plan elements:

• Problem statement and research questions
• Methodology and rationale
• Participant criteria and recruiting approach
• Number of participants (see benchmarks below)
• Timeline and logistics
• How data will be captured and stored
• Who will participate from the team

Participant benchmarks:

• Usability testing: 3-5 per round (catch ~85% of issues with 5 users)
• Generative interviews: 5-8 per persona segment
• Card sorting: 15-20 for statistical patterns
• Surveys: 100+ for quantitative significance
• Continuous discovery: 1 per week minimum

4. Recruit Participants

Recruiting is the hardest part. Embrace it — good recruiting puts the quality in your research.

A good participant:

• Shares the goals and concerns of target users
• Embodies key characteristics (age, role, tech familiarity)
• Can articulate their thoughts clearly
• Is familiar with relevant technology at the same level as target users

Write a screener survey (see templates/screener-template.md):

• Define specific behaviors you're looking for
• Determine required tool knowledge and access level
• Set topic knowledge requirements
• Don't make it obvious who you're looking for (people will game it)

Recruiting tips:

• The importance of recruiting perfectly representative users is overrated
• Testing early and often matters more than perfect representation
• Don't be embarrassed to ask friends and neighbors for initial rounds
• Offer reasonable incentives ($50-100/hour)
• Keep the invitation simple
• Don't discuss the product beforehand

5. Collect Data

Data management:

• Use consistent naming: Study-ParticipantName-YYYY-MM-DD
• Get files onto a shared drive immediately
• Use familiar tools — technical difficulties kill research sessions
• Keep a research kit ready to go at a moment's notice

Core collection methods:

Interviewing — The most effective way to see the world as users do. See references/interviewing-guide.md for the full technique guide.

Quick checklist:

• Prepare an interview guide with goals, demographics, icebreakers, and focus questions
• Ask open-ended questions; follow up with "Tell me more about that"
• Listen more than you speak — get comfortable with silence
• Note exact phrases and vocabulary participants use
• Pay attention after you stop recording — revelations often come then

Usability Testing — Observe representative users attempting tasks with your design. See references/usability-testing-guide.md for the complete process.

Quick checklist:

• Create tasks based on scenarios and personas
• The designer should NOT be the facilitator
• Have a separate observer taking notes
• Test early, test often — never right before lunch
• 3 users per round, debrief over lunch the same day

Contextual Inquiry — Interview and observe in the participant's actual environment.

Quick checklist:

• Plan for travel time
• Get situated without interrupting routines
• Ask people to do activities, not give you a tour
• Observe everything: environment, workarounds, tools, interruptions
• Use more than one researcher for multiple perspectives

6. Analyze Data

Analysis is where patterns become insights. Get everyone involved — include people who will benefit from participating.

Qualitative analysis process: 1. Review all notes and recordings closely 2. Extract observations: behaviors, emotions, actions, verbatim quotes 3. Write each observation on a sticky note (coded to the source participant) 4. Group notes into themes on a whiteboard 5. Watch patterns emerge; rearrange as you assess 6. Name each cluster with an insight statement 7. Derive actionable recommendations from insights

Analysis session structure:

• Summarize research goals and process (what did we want to find out?)
• Describe participants and circumstances
• Describe data gathering methods
• Pull out quotes and observations as a group
• Group into themes (e.g., "participants rely on pen and paper to aid memory")
• Summarize findings: patterns → insights → implications for design
• Document in a shareable format

See references/analysis-synthesis.md for detailed techniques including affinity diagrams, opportunity mapping, and persona creation.

7. Report Results

A quick sketch of a persona or a photo of sticky notes on a whiteboard is far superior to a lengthy written report that goes ignored.

Always include:

• Research goals and questions
• Methods and participant summary
• Key findings (patterns and insights)
• Severity-ranked recommendations
• Suggested next steps

Findings severity scale:

Findings frequency scale:

Issue triage (3 tiers):

• Tier 1: High severity + high frequency → immediate action, high risk to product success
• Tier 2: Moderate severity with low frequency, or low severity with moderate frequency
• Tier 3: Low severity + low frequency → low risk, add to backlog

Use templates/findings-report-template.md for the report structure.

Continuous Discovery

For teams practicing continuous discovery (recommended), research is not a phase — it's a weekly habit.

The continuous discovery cadence:

• Weekly touchpoints with customers by the team building the product
• Small research activities in pursuit of a desired outcome
• Infuse daily product decisions with continuous customer input

The product trio (product manager + designer + engineer) should:

• Conduct story-based interviews weekly (not opinion-based — ask about actual past behavior)
• Maintain an Opportunity Solution Tree mapping outcomes → opportunities → solutions → assumption tests
• Generate 15-20 solution ideas per opportunity (volume drives quality)
• Test 10-20 assumptions per week through small, rapid experiments
• Define success criteria before running tests

See references/continuous-discovery.md for the full framework.

Common Mistakes to Avoid

• Leading questions: "Don't you think this is easier?" → "How would you describe this experience?"
• Confirmation bias: Seeking evidence that supports your hypothesis instead of genuinely testing it
• Testing too late: Testing right before launch when there's no time to act on findings
• Asking opinions instead of observing behavior: People don't accurately predict their own behavior
• Over-documenting, under-acting: A 50-page report nobody reads vs. a whiteboard photo that drives change
• Skipping the screener: Recruiting anyone available instead of representative participants
• The facilitator is the designer: The person who built it can't objectively watch it fail
• Solving during analysis: Resist the urge to jump to solutions before the patterns are clear
• Adding features based on user requests: "I'd like it if it could do X" — probe deeper; they often already have a source for X

Quick Reference

Problem statement formula: [Verb: identify/evaluate/determine] + [what] + [for whom] + [context] Interview question format: Open-ended, behavior-focused, past-tense ("Tell me about the last time you...") Usability task format: Scenario-based, goal-oriented ("You want to [goal]. Show me how you'd do that.") Screener format: Behavioral questions that filter without revealing criteria Analysis output: Pattern → Insight → Recommendation → Severity

Resources

This skill includes:

• references/research-methods-catalog.md: Detailed guide to 20+ research methods organized by type
• references/interviewing-guide.md: Complete interviewing technique from preparation to debrief
• references/usability-testing-guide.md: Full testing process with scoring rubrics, triage, SUS (full 10-question scale with scoring formula, grade/percentile interpretation, subscales), and alternative questionnaires (UMUX-Lite, SEQ, NASA-TLX)
• references/analysis-synthesis.md: Affinity diagrams, thematic analysis, persona creation, opportunity mapping
• references/continuous-discovery.md: Weekly cadence, Opportunity Solution Trees, assumption testing
• references/workshop-methods.md: Team facilitation techniques — problem framing (HMW, Problem Tree, Abstraction Laddering, Rose/Thorn/Bud), ideation (Thumbnail Sketching, Creative Matrix, Round Robin, Alternative Worlds), prioritization (Importance/Difficulty Matrix, Bull's-Eye, Dot Voting, What's on Your Radar), and modeling (Storyboarding, Concept Poster, Cover Story Mock-Up). Includes half-day workshop template and facilitation anti-patterns.
• templates/research-plan-template.md: Fillable research plan
• templates/interview-guide-template.md: Interview script template
• templates/usability-test-plan-template.md: Test plan with tasks and metrics
• templates/screener-template.md: Participant screener survey
• templates/findings-report-template.md: Research findings report
• examples/method-selection-scenarios.md: "Given X situation, use Y method" decision guide
• examples/interview-to-insights.md: Walkthrough from raw interview data to actionable insights

From Interviews to Insights: A Walkthrough

This example walks through the complete process of turning raw interview data into actionable design insights, using a fictional project: improving the onboarding experience for a project management tool called "TaskFlow."

---

Context

Study: Generative research for TaskFlow onboarding redesign Method: Semi-structured interviews (story-based) Participants: 6 new users who signed up in the past 30 days Goal: Identify why 55% of new users don't complete onboarding

---

Step 1: Raw Interview Data

Here are excerpts from three of the six interviews:

P1 — Sarah, Marketing Manager, 2 weeks in

"I signed up because my boss told me to. I landed on this screen with like five options and I didn't know which one to pick. I think I clicked 'Create a project' but then it asked me all these questions about methodology — Kanban, Scrum, Waterfall — and I was like, I just want to make a to-do list."

"I ended up closing the tab and going back to my spreadsheet. I came back a few days later when I had more time."

"The thing is, I still don't really know what half the features do. I basically just use it as a list."

P2 — Dev Lead, 3 weeks in

"The setup was fine for me, I've used Jira and Asana before, so I knew what I was looking for. But when I tried to invite my team, I couldn't figure out where the invite function was. I went to Settings, then Project Settings, then back to the main page... turned out it was under the People icon in the sidebar."

"My team members had an even harder time. Two of them asked me how to see their tasks. They couldn't find the board view."

P3 — Freelance Designer, 1 week in

"I almost didn't finish signing up because it asked for a company name and I don't have one. I just typed my name but it felt weird. The whole flow seemed designed for teams, not individuals."

"I wanted to just track my client projects. I don't need sprints or retrospectives. I need deadlines and a way to share progress with clients."

---

Step 2: Extract Observations

Write one observation per sticky note. Code each to its source participant.

---

Step 3: Group into Themes

After placing all sticky notes on the wall (from all 6 interviews), clusters emerge:

Cluster A: "The onboarding assumes too much expertise"

• Observation 2: Didn't understand methodology options
• Observation 5: Doesn't understand features after 2 weeks
• [P4]: "I picked Kanban because it sounded familiar but I don't know what it means"
• [P5]: "The tutorial was about sprints and I don't use sprints"

Cluster B: "Key features are hidden"

• Observation 7: Couldn't find invite function
• Observation 8: Team members couldn't find board view
• [P4]: "I didn't know there was a calendar view until my coworker showed me"
• [P6]: "Where do I add a deadline? I still haven't figured that out"

Cluster C: "The product assumes you're a team, not an individual"

• Observation 9: "Company name" field wrong for solo users
• Observation 10: Flow designed for teams
• Observation 11: Needs deadlines and client sharing, not sprints
• [P5]: "I work alone, the collaboration features are just noise for me"

Cluster D: "Users satisfice rather than explore"

• Observation 3: Closed tab, returned days later
• Observation 4: Uses as simple to-do list
• Observation 6: Experienced user had no trouble (prior mental model)
• [P6]: "I just picked the first option that seemed okay"

---

Step 4: Write Insight Statements

Each cluster becomes an insight with three parts: observation, interpretation, and implication.

Insight 1: Jargon-heavy onboarding creates a knowledge barrier

Observation: 4 of 6 participants didn't understand project methodology options (Kanban, Scrum, Waterfall) and couldn't distinguish between them. Two picked randomly; one abandoned.

Interpretation: The onboarding assumes domain knowledge that most non-technical users don't have. It forces a consequential decision (project methodology) at the moment of lowest understanding. This violates the principle that systems should match the user's language and mental model (Jakob's Law, Recognition over Recall).

Implication: Onboarding should defer methodology decisions or make them invisible. Ask users about their goals ("track tasks," "manage a team project," "share progress with clients") and map those to appropriate configurations behind the scenes.

Severity: High — directly causes abandonment Frequency: High — 4 of 6 participants

---

Insight 2: Core features lack discoverability

Observation: 5 of 6 participants couldn't find at least one key feature (inviting team members, board view, calendar view, deadlines). Users looked in logical places (Settings, Project Settings) but the features were elsewhere.

Interpretation: The information architecture doesn't match users' mental models for where features should live. The "People" icon in the sidebar is not a strong enough signifier for team management. Users default to Settings for anything configuration-related.

Implication: Add contextual discovery prompts within workflows (e.g., after creating a project, prompt "Want to invite team members?"). Consider restructuring Settings to include People and View options, or add clear labels to sidebar icons.

Severity: High — prevents core feature adoption Frequency: High — 5 of 6 participants

---

Insight 3: Solo users feel the product isn't for them

Observation: 2 of 6 participants were individual users. Both reported the onboarding felt designed for teams. The "Company name" field, collaboration-focused copy, and team methodology options created friction.

Interpretation: The product has a one-size-fits-all onboarding that optimizes for the team use case. Solo users represent a meaningful segment but are effectively alienated during first contact. This is a peak-end rule issue — the first impression shapes their entire relationship with the product.

Implication: Add a branching question early in onboarding: "Are you working solo or with a team?" Tailor subsequent screens, terminology, and default settings to match. For solo users: hide team features, use "your projects" instead of "workspace," and skip the company name field.

Severity: Moderate — doesn't cause abandonment but reduces engagement Frequency: Moderate — 2 of 6 participants (but may represent a larger unseen segment)

---

Insight 4: Users adopt the minimum viable workflow and stop exploring

Observation: 4 of 6 participants use only basic features (task lists) despite the product offering boards, timelines, calendars, and automations. They chose the first approach that worked and stuck with it.

Interpretation: This is classic satisficing behavior. Users don't explore because their immediate need is met. The product offers no progressive disclosure or contextual hints to guide users toward more powerful features once they're comfortable.

Implication: Implement progressive feature introduction — after users have been active for 1 week, surface contextual suggestions: "You have 15 tasks. Try Board View to see them visually." Avoid tooltip tours on day 1; time guidance to when it's relevant.

Severity: Moderate — doesn't prevent task completion but limits product value and retention Frequency: High — 4 of 6 participants

---

Step 5: Prioritize and Recommend

---

Step 6: Build the Opportunity Solution Tree

Desired Outcome: Increase onboarding completion from 45% to 75%
├── Users don't understand initial setup choices
│   ├── Replace methodology picker with goal questions
│   └── Offer guided templates based on role
├── Users can't find key features
│   ├── Add contextual discovery prompts
│   └── Restructure sidebar with labels
├── Solo users feel product isn't for them
│   └── Add solo/team path branching
└── Users adopt minimum workflow and stop
    ├── Progressive feature hints at day 7
    └── Usage-based suggestions ("You have 15 tasks...")

---

What Made This Analysis Effective

1. Started with stories, not opinions — Interview questions asked about actual past behavior 2. One observation per note — Kept things atomic for flexible grouping 3. Coded to participants — Could trace every insight back to specific people 4. Named clusters as insights, not topics — "Jargon-heavy onboarding creates a knowledge barrier" vs. "Onboarding" 5. Three-part insight format — Observation → Interpretation → Implication provides clear logic chain 6. Severity + frequency scoring — Enables objective prioritization 7. Connected to UX principles — Referenced Jakob's Law, satisficing, peak-end rule to strengthen recommendations 8. Ended with an OST — Mapped insights directly to an actionable framework for the team

Method Selection Scenarios

Real-world scenarios showing how to choose the right research method. For each situation, we explain the decision rationale and the expected output.

---

Scenario 1: "We're building a new product and don't know where to start"

Context: The team has a vague idea about the problem space but hasn't talked to users yet. Stakeholders have opinions about what to build, but no evidence.

Research type: Generative / Exploratory

Recommended methods: 1. Stakeholder interviews (first) — Understand business goals, constraints, and internal assumptions 2. User interviews (5-8 per segment) — Discover real needs, goals, and pain points 3. Contextual inquiry (3-5 sessions) — Observe actual behavior in context

Why not usability testing? There's nothing to test yet. You need to understand the problem before designing solutions.

Expected output: Personas, opportunity map, problem statement, design principles

Timeline: 3-4 weeks

---

Scenario 2: "We redesigned the navigation and need to know if it works"

Context: The IA team restructured the site navigation based on card sort results. They have a prototype and want to validate before development.

Research type: Evaluative

Recommended methods: 1. Tree testing (20-30 participants) — Validate findability in the new structure without visual design influence 2. Usability testing (5 users) — Test the prototype with realistic task scenarios

Why tree testing before usability testing? Tree testing isolates the IA from visual design. If items are unfindable in the tree, no amount of visual polish will fix it.

Expected output: Findability scores per task, completion rates, identified problem areas in the hierarchy

Timeline: 1-2 weeks

---

Scenario 3: "Users are dropping off during onboarding but we don't know why"

Context: Analytics show 60% of new users abandon during onboarding. The team has hypotheses but no direct user data.

Research type: Evaluative + Generative (combined)

Recommended methods: 1. Analytics review (first) — Identify exactly where users drop off (which step, which screen) 2. Usability testing (5 users) — Watch new users go through onboarding; identify confusion points 3. Post-abandonment interviews (5-8 users who dropped off) — Understand why they left in their own words

Why not just A/B testing? A/B testing tells you which version performs better, but not why users are struggling. You need to understand the problem before testing solutions.

Expected output: Step-by-step drop-off analysis, severity-ranked issues, recommendations for each onboarding step

Timeline: 2-3 weeks

---

Scenario 4: "The team is arguing about which feature to build next"

Context: Product and engineering have different opinions about priorities. There's no user data to settle the debate.

Research type: Generative

Recommended methods: 1. User interviews (5-8) focused on current workflows and pain points 2. Buy a Feature exercise with 4-8 users — Force trade-off decisions to reveal true priorities 3. Opportunity Solution Tree — Map interview findings to a structured framework for prioritization

Why not a survey? Surveys tell you what people say they want. Interviews + Buy a Feature reveal what they actually need and what they'll trade off.

Expected output: Prioritized opportunity map, evidence-based feature recommendations

Timeline: 2 weeks

---

Scenario 5: "We need quick feedback on two design directions"

Context: The team has two competing design concepts for a key flow. They need to decide which direction to pursue before investing in a full prototype.

Research type: Evaluative

Recommended methods: 1. Comparative usability testing (5 users) — Show both concepts to the same users in alternating order; ask them to complete the same tasks on each 2. Preference testing (after tasks) — Ask which they preferred and why

Why not A/B testing? The designs aren't built yet. Comparative usability testing is faster and cheaper at this stage, and you get qualitative data about why one works better.

Expected output: Task completion comparison, qualitative preference data, clear recommendation for which direction to pursue

Timeline: 3-5 days

---

Scenario 6: "We launched 3 months ago and want to know how it's going"

Context: The product is live with real users. The team wants to understand adoption patterns, satisfaction, and areas for improvement.

Research type: Causal + Evaluative

Recommended methods: 1. Analytics review — Understand actual usage patterns, feature adoption, retention 2. Survey (100+ users) — Measure satisfaction (SUS, NPS), identify top pain points at scale 3. Follow-up interviews (5-8 from survey respondents) — Deep dive into the "why" behind survey patterns

Why not just analytics? Analytics tell you what users do, not why. The survey adds breadth; interviews add depth.

Expected output: Usage report, satisfaction benchmarks, prioritized improvement roadmap

Timeline: 3-4 weeks

---

Scenario 7: "We need to understand how our product fits into users' daily workflow"

Context: The team knows users interact with their product alongside many other tools, but doesn't understand the full workflow context.

Research type: Descriptive

Recommended methods: 1. Contextual inquiry (5-8 sessions) — Visit users in their environment; watch them work 2. Diary study (10-15 users, 1-2 weeks) — Capture daily tool usage and context over time 3. Journey mapping (synthesis) — Visualize the full workflow with touchpoints, emotions, and pain points

Why contextual inquiry instead of interviews? People can't accurately describe their workflow from memory. You need to observe it happening.

Expected output: Current-state journey map, workflow diagram, integration opportunities

Timeline: 3-5 weeks

---

Scenario 8: "We're setting up continuous discovery for the first time"

Context: The team wants to move from ad-hoc research to weekly customer touchpoints.

Recommended setup: 1. Automate recruiting — Add in-product prompts for research participation 2. Weekly story-based interviews (1 per week minimum) — Focus on actual past behavior 3. Maintain an OST — Update weekly with new opportunities from interviews 4. Run assumption tests — 2-3 small experiments per week 5. Monthly synthesis — Step back and look for patterns across the month's interviews

Start small: Even one interview per week is infinitely better than quarterly research. Build the habit first, then scale.

Timeline: Ongoing — expect 4-6 weeks to establish the rhythm

---

Quick Decision Matrix

Analysis & Synthesis

Techniques for turning raw research data into actionable insights, models, and recommendations. Covers affinity diagramming, thematic analysis, persona creation, opportunity mapping, and mental model construction.

The Goal of Analysis

Turn individual observations into patterns. Turn patterns into insights. Turn insights into recommendations. The output is not a document — it's shared understanding that drives design decisions.

Affinity Diagramming

The most fundamental synthesis technique. It externalizes observations and lets patterns emerge through spatial grouping.

Process

Materials needed:

• Large room with whiteboard wall space
• Sticky notes (multiple colors help)
• Markers
• Camera to photograph the board

Steps:

1. Extract observations from notes, recordings, and transcripts

• Write one observation per sticky note
• Use the participant's words when possible (direct quotes)
• Code each note to its source participant (e.g., "P3" in the corner)
• Types of observations: goals, priorities, tasks, motivators, barriers, habits, relationships, tools, environment

2. Place all notes on the wall without organizing

3. Group silently — team members move notes into clusters without talking

• Move notes that seem related together
• It's okay to move notes others have placed
• Don't create categories first — let them emerge
• Aim for 5-15 groups (fewer = too abstract, more = too granular)

4. Name each cluster with an insight statement

• Bad: "Navigation" (too generic, just a label)
• Good: "Users rely on search because they don't trust the navigation categories"
• The name should be a finding, not a topic

5. Identify relationships between clusters

• Which clusters reinforce each other?
• Which are in tension?
• Are there cause-and-effect relationships?

6. Prioritize based on:

• Frequency: How many participants reflected this theme?
• Impact: How much does this affect the user's ability to achieve their goal?
• Business alignment: Does addressing this serve business goals?

7. Derive recommendations from each prioritized insight

• What design action does this insight suggest?
• What should we do differently?
• What should we investigate further?

Analysis Session Format

Duration: 2-4 hours depending on data volume

Agenda: 1. Context setting (10 min): Summarize research goals, participants, methods 2. Individual review (20 min): Each team member reviews their notes silently 3. Note creation (30 min): Everyone writes observations on sticky notes 4. Silent grouping (20 min): Place and cluster notes without talking 5. Group discussion (30 min): Walk through clusters, debate groupings, name themes 6. Insight generation (30 min): Write insight statements for each cluster 7. Prioritization (20 min): Vote on most impactful insights 8. Action planning (20 min): Identify recommendations and next steps

Thematic Analysis

A more structured alternative to affinity diagramming, useful for larger data sets.

Process

1. Familiarize — Read through all data twice 2. Code — Tag relevant segments with descriptive codes 3. Search for themes — Group codes into broader themes 4. Review themes — Check that themes accurately represent the data 5. Define themes — Write a clear description of what each theme captures 6. Report — Select compelling extracts that illustrate each theme

Coding Framework

When coding observations, tag them with:

• Behavior codes: What users do (actions, workarounds, habits)
• Attitude codes: What users think and feel (beliefs, frustrations, desires)
• Context codes: Environmental factors (tools, constraints, relationships)
• Process codes: Sequences and workflows (steps, triggers, decision points)

Persona Creation

A persona is a fictional user archetype — a composite model from research data that represents a group of needs and behaviors. Good personas might be the most useful and durable outcome of user research.

How Many Personas?

As few as possible while representing all relevant behavior patterns. Typically 3-5 for a product.

Persona Elements

1. Photo: A real, relatable photo — not stock photography 2. Name: Something that fits the demographic naturally 3. Demographics: Realistic without stereotyping 4. Role: Closely matching one of your research participants 5. Quote: An actual verbatim quote from interviews that embodies a core belief or attitude 6. Goals: 3-4 key goals the product will serve or relate to 7. Behaviors and habits: Specific, habitual behaviors that define this persona's pattern 8. Skills: Level of technical expertise and domain experience 9. Environment: Physical, social, and technological context affecting their product use 10. Relationships: People who influence their decisions or are affected by them 11. Frustrations: Current pain points and barriers 12. Motivations: What drives their behavior

Creating Personas from Research Data

1. Review all interview data and look for behavioral patterns 2. Identify behavioral variables (e.g., frequency of use, tech comfort, decision-making style) 3. Map participants along these variables 4. Identify clusters of similar participants 5. Create one persona per cluster 6. Flesh out with real data from participants in that cluster 7. Validate with the team — do these feel real?

Scenarios

If personas are your characters, scenarios are your plots. Each scenario tells how a persona interacts with your system to meet their goals.

Use scenarios to:

• Flesh out requirements
• Explore potential solutions
• Validate proposed solutions
• Create usability test scripts

Format: "When [persona] is [context/trigger], they want to [goal] so they [action sequence]. They feel [emotion] when [outcome]."

Opportunity Mapping

Opportunity Solution Tree

A visual framework for mapping the path from business outcomes to customer opportunities to solutions.

Structure:

Desired Outcome (business metric the team can influence)
├── Opportunity 1 (customer need/pain point/desire)
│   ├── Solution A
│   │   ├── Assumption test 1
│   │   └── Assumption test 2
│   └── Solution B
│       └── Assumption test 3
├── Opportunity 2
│   ├── Solution C
│   └── Solution D
└── Opportunity 3
    └── Solution E

Rules:

• The desired outcome is a product metric, not a business metric (the team must be able to directly influence it)
• Opportunities come from research — they are customer needs, pain points, and desires
• Break large opportunities into smaller sub-opportunities until they're actionable
• Generate 15-20 solutions per opportunity before evaluating (volume drives quality)
• Choose a target opportunity that is a "leaf node" (no children) before ideating solutions
• Test assumptions, not whole ideas — what must be true for this solution to work?

Prioritizing Opportunities

Consider:

• Opportunity size: How many users are affected?
• Market factors: Is this a growing need? Are competitors addressing it?
• Company factors: Do we have the capability? Does it align with strategy?
• Customer factors: How painful is this? How frequently encountered?

Mental Model Construction

A mental model diagram represents the user's cognitive space — how they think about a domain, organized into tasks, beliefs, and feelings.

Process

1. Conduct user research (interviews, contextual inquiry) 2. Create an affinity diagram from the data 3. Place affinity clusters into stacks representing the user's cognitive space 4. Group stacks around the tasks or goals they relate to 5. Map your product's features underneath, aligned to the user's model 6. Gaps between the user's model and your features = opportunities

Using Mental Models

• "Intuitive" design = design that matches the user's mental model
• Where your product aligns with the mental model → reinforce
• Where your product diverges from the mental model → either adapt the design or plan for learning
• Where the mental model has no coverage → opportunity for new features

Behavioral Audience Segments

Behavioral segments group people by how they think about a domain — not by demographics. Two people with the same job title, age, and industry may reason completely differently about the same activity. Behavioral segments surface these differences and give design teams a foundation for supporting distinct intents.

How They Differ from Personas

Building Behavioral Segments

1. Develop empathy first — Conduct deep listening sessions with 10-30 people. Focus on their reasoning, emotional reactions, and guiding principles about a purpose broader than your product 2. Pick out concepts — From each session, extract reasoning, reactions, and guiding principles. Write summaries starting with a verb 3. Look for patterns across people — Group similar reasoning patterns. Let segments emerge bottom-up from the data, not from predefined categories 4. Name each segment by intent — The name should describe how this group thinks, not who they are. "Cautious evaluators who need proof before committing" not "Enterprise buyers" 5. Validate boundaries — Each segment should have distinct guiding principles. If two segments reason the same way, merge them

Using Behavioral Segments

• Inspire direction — Segments reveal which types of reasoning your product supports well and which it ignores. This shapes strategy, not just features
• Expand angles — Instead of jumping to the obvious solution, segments help you see the problem from multiple reasoning styles
• Customize support — Different segments may need different flows, messaging, or onboarding paths — not because of who they are, but because of how they think
• Complement personas — Use behavioral segments for strategic direction; use personas for tactical design decisions. They work together

Segments vs. Personas: When to Use Which

---

Journey Map Synthesis

When to Create Journey Maps

After you have:

• Interview data from 5+ participants about the same experience
• A clear understanding of the stages of the experience
• Observations about emotions, pain points, and touchpoints at each stage

Journey Map Structure

Header:

• Customer name/persona
• Scenario description
• Goals and expectations

For each stage:

Empathy Map

A quicker synthesis tool for articulating what you know about a user type.

Four quadrants: 1. Says — Direct quotes and statements from research 2. Does — Actions and behaviors observed 3. Thinks — Thoughts, beliefs, concerns (may not be explicitly stated) 4. Feels — Emotional state throughout the experience

Center: The user's goals and needs

Reporting Insights

Insight Statement Format

A good insight statement has three parts: 1. Observation: What we saw (the pattern) 2. Interpretation: What it means (the why) 3. Implication: What we should do about it (the design direction)

Example:

• Observation: 4 of 5 participants ignored the sidebar navigation and used search instead
• Interpretation: The navigation categories don't match users' mental models for finding content
• Implication: We should restructure navigation using terminology from card sort results, and make search more prominent as a primary navigation strategy

Recommendation Format

Each recommendation should include:

• Finding: The insight it addresses
• Severity: Critical / High / Moderate / Low
• Recommendation: Specific action to take
• Effort estimate: Small / Medium / Large
• Evidence: Which participants, how many, supporting quotes

Continuous Discovery

A framework for integrating research into weekly product development practice, based on established continuous discovery and Lean UX principles.

Why Continuous Discovery?

Digital products are never finished. Customer needs and market conditions change continuously. Research cannot be a phase — it must be a habit. The goal: weekly touchpoints with customers by the team building the product, conducting small research activities in pursuit of a desired outcome.

The Product Trio

Continuous discovery is driven by a product trio: product manager + designer + engineer. All three participate in:

• Customer interviews
• Opportunity mapping
• Solution ideation
• Assumption testing

This isn't optional. Cross-functional participation ensures solutions are desirable, viable, and feasible from the start.

Six Prerequisite Mindsets

1. Outcome-oriented: Define success by impact on customers and business, not by features shipped 2. Customer-centric: Place the customer at the center; prioritize their needs alongside business needs 3. Collaborative: Reject siloed work; leverage collective expertise 4. Visual: Use drawings, maps, and diagrams to externalize thinking 5. Experimental: Adopt a scientific approach — identify assumptions and test them 6. Continuous: Move away from project mindset; integrate discovery throughout development

The Weekly Cadence

Minimum Viable Discovery

Automating Recruiting

The biggest barrier to weekly interviews is recruiting. Automate it:

• In-product prompts: "Help us improve — chat with our team for 15 min"
• Post-interaction surveys with opt-in for follow-up
• Customer success team referrals
• Maintain a participant panel with a simple sign-up form
• Incentivize participation with gift cards, early access, or product credits

The Opportunity Solution Tree (OST)

The central visual framework for continuous discovery. It maps the path from a desired outcome to testable assumptions.

Structure

Desired Outcome
├── Opportunity A (customer need/pain/desire)
│   ├── Sub-opportunity A1
│   │   ├── Solution 1
│   │   │   ├── Assumption test
│   │   │   └── Assumption test
│   │   └── Solution 2
│   └── Sub-opportunity A2
│       └── Solution 3
├── Opportunity B
│   ├── Solution 4
│   └── Solution 5
└── Opportunity C
    └── Solution 6

Building the OST

Step 1 — Set the desired outcome:

• Must be a product outcome (metric the team can directly influence)
• Not a business outcome (lagging indicator like revenue)
• Example: "Increase weekly active users who complete onboarding from 40% to 65%"

Step 2 — Map the opportunity space:

• Opportunities come from customer interviews — they are needs, pain points, and desires
• Structure opportunities hierarchically (big problems → sub-problems)
• Break down until opportunities are specific enough to address with a single solution
• Target "leaf nodes" — opportunities with no children

Step 3 — Ideate solutions:

• Generate 15-20 ideas per target opportunity (volume drives quality)
• Use group evaluation (dot-voting) to select ~3 diverse solutions for further exploration
• Don't converge too early — diversity of solutions is important

Step 4 — Identify assumptions:

• For each solution, enumerate what must be true for it to work
• Categories: desirability, viability, feasibility, usability, ethical
• Use story mapping and pre-mortems to surface hidden assumptions

Step 5 — Test assumptions:

• Prioritize "leap of faith" assumptions (riskiest ones)
• Use assumption mapping: plot assumptions on importance vs. certainty
• Test the riskiest, most important assumptions first

Story-Based Interviewing

The backbone of continuous discovery. Collect stories about actual past behavior, not opinions about hypothetical futures.

Why Stories?

• People don't accurately predict their own future behavior
• Stories reveal actual behavior, context, emotions, and workarounds
• Stories surface opportunities you wouldn't think to ask about
• Stories are harder to fabricate than opinions

Interview Structure for Continuous Discovery

Opening (5 min):

"Tell me about the last time you [did relevant activity]."

Story collection (20-30 min):

• Follow the story chronologically: "What happened next?"
• Dig into key moments: "Tell me more about that."
• Capture emotions: "How did that make you feel?"
• Understand motivation: "Why was that important to you?"
• Explore alternatives: "What did you try before that?"

Closing (5 min):

• "Is there anything else about this experience you'd like to share?"
• Thank them and explain how their input will be used

Interview Snapshot

After each interview, create a quick-reference summary:

• Participant: Name/ID, role, key demographics
• Date: Date of interview
• Stories collected: 1-2 sentence summary of each story shared
• Opportunities identified: Needs, pain points, desires surfaced
• Memorable quotes: 2-3 verbatim quotes
• Surprises: Anything unexpected or that challenged assumptions

Synthesizing Across Interviews

After every 3-5 interviews: 1. Review all interview snapshots 2. Look for patterns across stories 3. Add new opportunities to the OST 4. Refine or restructure existing opportunities 5. Identify which opportunities are growing in evidence

Assumption Testing

Types of Assumptions

Assumption Mapping

Plot assumptions on a 2x2:

         Important
            │
    Test     │    Test
    these    │    these
    SECOND   │    FIRST
            │
  ──────────┼──────────
            │
    Don't    │    Test
    test     │    these
    these    │    THIRD
            │
         Unimportant

   Known ◄──┼──► Unknown

Designing Tests

Principles:

• Test assumptions, not whole ideas
• Define success criteria BEFORE running the test
• Design the smallest possible experiment
• Simulate an experience to evaluate actual behavior (not stated preference)
• Aim for 10-20 iterations per week

Test types (from fastest to most rigorous):

Integrating with Agile

Dual-Track Agile

• Discovery track: Testing hypotheses, talking to users, mapping opportunities
• Delivery track: Building the ideas that survive discovery
• Some team members participate in both tracks
• Discovery feeds the delivery backlog with validated ideas

Sprint Integration

1. Start of sprint: Review OST, select target opportunity 2. During sprint: Run 1-2 interviews + 2-3 assumption tests 3. End of sprint: Update OST with new evidence, share findings at retro 4. Continuous: Discovery data informs delivery priorities

Communicating with Stakeholders

• Show the OST: It makes your decision logic visible
• Share interview snapshots: Quick, digestible evidence
• Present assumption test results: "We tested X, here's what we learned"
• Frame everything in outcomes: "This will move [metric] because [evidence]"

Common Pitfalls

• Interviewing without a desired outcome: You'll collect interesting but unfocused data
• Jumping to solutions before mapping opportunities: You'll solve the wrong problem
• Testing whole ideas instead of assumptions: Too slow, too expensive
• Skipping the weekly cadence: Discovery debt accumulates like technical debt
• Only the PM does interviews: The whole trio needs direct customer contact
• Treating the OST as static: It should evolve weekly as you learn

Interviewing Guide

A complete guide to conducting effective user interviews — from preparation through debrief. Combines established interviewing techniques and methodologies.

Why Interviewing?

A simple interview remains the most effective way to get inside another person's head and see the world as they do. It's a core research technique with many applications. Being a good interviewer requires basic social skills, some practice, and a modicum of self-awareness.

Preparation

Write an Interview Guide

Your guide should contain:

1. Brief description and goal of study (1-2 sentences) 2. Basic factual/demographic questions (role, experience, tools used) 3. Icebreaker questions (2-3 easy warmup questions) 4. Focus questions (the primary topics of the interview, 5-10 questions) 5. Closing questions ("Is there anything else you'd like to share?")

Question Design Principles

Ask about behavior, not opinions:

• Bad: "Would you use a feature that does X?"
• Good: "Tell me about the last time you tried to do X."

Ask open-ended questions:

• Bad: "Was that easy or hard?"
• Good: "How would you describe that experience?"

Ask about specifics, not generalizations:

• Bad: "What do you usually do when...?"
• Good: "Walk me through what happened the last time..."

Focus on past behavior (story-based interviewing):

• Bad: "What would you do if...?"
• Good: "Tell me about a time when..."
• People don't accurately predict their future behavior. Past behavior is the best predictor.

Story-Based Interview Questions

The most reliable interview data comes from stories about actual past behavior. Structure your interview around collecting specific stories:

Story prompts:

• "Tell me about the last time you [did relevant activity]."
• "Walk me through what happened from the beginning."
• "What happened next?"
• "Can you think of a specific example?"

Deepening prompts:

• "Tell me more about that."
• "What do you mean by [their word]?"
• "Why was that important to you?"
• "How did that make you feel?"
• "What were you hoping would happen?"
• "What did you try before that?"

Avoid these question types:

• Leading: "Don't you think..." / "Wouldn't it be better if..."
• Hypothetical: "What would you do if..."
• Binary: "Did you like it?" (yes/no)
• Double-barreled: "How did you find and purchase the product?" (two questions in one)

Session Structure

Introduction (5 minutes)

• Introduce yourself and your role
• Describe the purpose of the conversation
• Explain how information will be used and shared
• Get permission to record (audio/video)
• Ask if they have any questions before starting
• Brief small talk to build rapport

Example opening:

"Thanks for taking the time to talk with me today. I'm [name], a [role] working on [project]. I'm here to learn about your experience with [topic]. There are no right or wrong answers — I'm genuinely interested in how you see things. Everything you share will be used to improve our product, and your name won't be attached to specific quotes unless you give permission. Do you mind if I record this so I can focus on our conversation instead of taking notes? Do you have any questions before we start?"

Warmup (5 minutes)

• Ask easy, factual questions about their role and context
• Build comfort and establish conversational tone
• Example: "Tell me a bit about your role and what a typical day looks like."

Core Interview (30-40 minutes)

• Follow your guide but be willing to deviate when interesting threads emerge
• Ask open-ended questions that encourage stories
• Use the "Tell me more about that" technique liberally
• Allow pauses — get comfortable with 5-10 seconds of silence
• Listen for:
• Goals: What are they trying to achieve?
• Priorities: What matters most to them?
• Tasks: What steps do they take?
• Motivators: What drives their behavior?
• Barriers: What gets in their way?
• Habits: What do they do repeatedly?
• Relationships: Who else is involved?
• Tools: What do they use?
• Environment: What surrounds them?

Conclusion (5 minutes)

• "Is there anything I didn't ask about that you think is important?"
• "Is there anything you'd like to ask me?"
• Thank them sincerely
• Explain next steps if applicable

During the Interview

Active Listening Techniques

• Mirror: Repeat the last few words they said as a question ("...and then it crashed?" → encourages them to continue)
• Summarize: "So if I understand correctly, you..." → validates understanding and invites correction
• Acknowledge emotions: "That sounds frustrating" → builds trust without leading
• Comfortable silence: After they finish speaking, wait 3-5 seconds. They'll often elaborate with the most valuable information.

What to Capture

• Direct quotes (mark them clearly — these are gold)
• Specific behaviors described
• Workarounds and hacks
• Emotional reactions (frustration, delight, confusion)
• Exact vocabulary and terminology they use
• Things they DON'T mention that you expected them to
• Environmental factors

Common Pitfalls

Deep Listening for Empathy Development

Beyond standard interviewing, deep listening is a complementary technique for developing cognitive empathy — understanding another person's reasoning, reactions, and guiding principles. This approach, grounded in Indi Young's work, focuses on the problem space rather than the solution space.

How Deep Listening Differs from Standard Interviewing

What to Listen For

Focus on three components during a deep listening session:

1. Inner thinking — The reasoning behind decisions and actions. Not what they did, but why they decided to do it. The whys and wherefores, decision-making and indecision, causation 2. Emotional reactions — Feelings that arise in response to events. These are signals, not data points — use them to dig deeper into reasoning 3. Guiding principles — Deeply held philosophies that steer behavior over time. These are the most valuable and hardest to surface. They explain patterns across many decisions

Deep Listening Techniques

Follow the peaks and valleys. Pay attention to emotional high and low points. These reveal where the deepest reasoning and strongest reactions live.

Neutralize your own reactions. When something triggers agreement, disagreement, surprise, or an idea in you — notice it and let it pass. Your reactions pull attention away from the speaker. Practice recognizing and dissipating these distractions.

Harness emotional empathy as a signal. When you feel the same emotion as the speaker, use it as a cue to dig deeper into their reasoning — not as an invitation to share your own similar experience.

Set aside your agenda. Don't redirect toward your product, your features, or your hypotheses. Let the person lead. If they go somewhere unexpected, that's where insight lives.

Exhibit understanding, not competence. Shift from demonstrating your expertise to genuinely understanding their perspective. Curiosity about people is the key ingredient.

After a Deep Listening Session

Spend at least 10 minutes per person reviewing what they said. You are guaranteed to misconstrue meanings if you don't. This is still developing empathy — not yet analyzing. Stay focused on one person at a time.

For each concept that contributes to empathy (reasoning, reaction, or guiding principle): 1. Start with the verb — what is the person trying to accomplish or work through? 2. Write the rest — capture the reasoning, the emotional reaction, or the guiding principle 3. Edit until clean — make it clear and concise, using the person's own words where possible

When to Use Deep Listening vs. Standard Interviews

• Standard interviews → When you need actionable data about behavior, workflows, and pain points for a specific product
• Deep listening → When you need to understand the problem space before defining solutions, when building behavioral audience segments, or when your team is making assumptions about why users behave the way they do

Both techniques produce valuable research. Deep listening feeds the slower, person-focused cycle that balances the faster solution-focused cycle.

---

After the Interview

Immediate Debrief (within 1 hour)

• Write down your top 3-5 observations while they're fresh
• Note anything surprising or that challenged your assumptions
• Flag quotes you want to reference later
• Rate the quality of the session (was the participant a good fit? Were questions effective?)

Interview Snapshot

Create a quick-reference summary for each interview:

Format:

• Participant: [Name/ID, role, key demographics]
• Date: [Date]
• Key stories collected: [1-2 sentence summary of each story]
• Opportunities identified: [Needs, pain points, desires surfaced]
• Memorable quotes: [2-3 verbatim quotes]
• Surprises: [Anything unexpected]

Synthesis

After completing all interviews in a round:

1. Gather all interview snapshots 2. Extract individual observations onto sticky notes (one per note, coded to participant) 3. Group observations into themes using affinity diagramming 4. Name each cluster with an insight statement 5. Map insights to the Opportunity Solution Tree (if using continuous discovery) 6. Identify patterns that suggest design opportunities

See references/analysis-synthesis.md for the full synthesis process.

Interview Logistics

Remote Interviews

• Test your video/audio setup before the session
• Have a backup plan (phone call) if technology fails
• Ask participant to share their screen if observing tool usage
• Record the session (with permission) using your video conferencing tool
• Mute notifications on both sides

In-Person Interviews

• Arrive early to set up
• Minimize environmental distractions
• Position yourself at an angle (not directly facing — less confrontational)
• Bring backup recording equipment
• Have water available for participant

Recruiting for Interviews

• See templates/screener-template.md for writing a participant screener
• Maintain an ongoing database of potential participants
• For continuous discovery: automate recruiting through in-product prompts
• Incentivize fairly ($50-100/hour for consumer, $150-300/hour for B2B/enterprise)

Research Methods Catalog

Detailed guide to UX research methods organized by type. Each method includes when to use it, what it reveals, practical steps, and tips.

Looking Methods

Methods for observing human experience

Interviewing

Gathering information through direct dialogue

Best for: Generative research, understanding goals, motivations, mental models Participants: 5-8 per segment Time: 45-60 minutes per session

Benefits:

• Gain information directly from users
• Challenge your preconceptions
• Deepen empathy
• Build credibility with stakeholders

Process: 1. Identify a topic for investigation 2. Prepare your questions and recording equipment 3. Determine criteria for selecting interviewees 4. Identify and recruit participants 5. Set a time and place to meet 6. Introduce yourself and the purpose; obtain consent 7. Start with easy questions, then draw out specifics 8. Listen carefully and take good notes 9. Thank each participant

Tips:

• Choose a location with minimal distractions
• Don't put words into the interviewee's mouth
• Resist the urge to analyze during the session
• Note exact vocabulary participants use

See references/interviewing-guide.md for the complete technique.

---

Fly-on-the-Wall Observation

Observing people in an unobtrusive manner

Best for: Understanding natural behavior, identifying workarounds, discovering unarticulated needs Participants: Observe 5-10 people/sessions Time: 2-4 hours per observation session

Benefits:

• Diminishes your presence as a researcher
• Reveals behavior people don't report in interviews
• Challenges assumptions about how people work
• Informs subsequent research activities

Process: 1. Identify a subject area to study 2. Develop a plan to guide your investigation 3. Consider which people and activities to watch 4. Choose a location to visit 5. Obtain necessary access and permissions 6. Prepare materials for capturing what you see 7. Go out and observe 8. Record findings in videos, photos, and notes

Tips:

• Make every effort to blend into the background
• Take on the role of an objective bystander
• Look at the situation from several vantage points
• Don't interact unless necessary

---

Contextual Inquiry

Interviewing and observing people in their own environment

Best for: Understanding real workflows, environment factors, workarounds, tool usage Participants: 4-8 participants Time: 1-2 hours per session (plus travel)

Benefits:

• Reveals what people actually do vs. what they say they do
• Captures environmental factors that affect product use
• Surfaces workarounds and pain points invisible in lab settings
• Produces accurate scenarios for design

Process: 1. Identify a location and people to be involved 2. Prepare questions and recording equipment 3. Go to the site 4. Introduce yourself and the purpose; obtain consent 5. Ask participants to do tasks in their normal way 6. Observe their actions unobtrusively 7. Interject questions at opportune moments 8. Record findings in videos, photos, and notes 9. Thank each participant

Things to keep in mind:

• Plan for travel time
• Get situated without interrupting routines
• Establish trust, don't be disruptive
• Note everything in as much detail as possible
• Summarize immediately after

Tips:

• Ask people to do activities, not just give you a tour
• Use more than one researcher for multiple perspectives
• Stay focused on your goals, yet open to discovery

---

Walk-a-Mile Immersion

Building empathy through firsthand experience

Best for: Deeply understanding user frustrations, physical and emotional experiences Participants: The researcher themselves Time: Varies (hours to days)

Process: 1. Identify whose experience you want to replicate 2. Choose the tasks and activities to perform 3. Assemble what's needed for a realistic simulation 4. Determine the best location 5. Obtain necessary access and permissions 6. Conduct the targeted tasks as realistically as possible 7. Note findings along the way

Tips:

• Commit fully — don't give up early
• Ask another observer to help capture findings
• Consider accessibility simulation tools to understand impaired experiences

---

Participatory Methods

Learning from people through cooperative design activities

What's on Your Radar?

People plot items according to personal significance

Best for: Understanding priorities, revealing what people care about most Participants: 5-10 stakeholders or users Time: 30-45 minutes

Process: 1. Identify a topic for consideration 2. Make a large poster that looks like a radar screen (3 concentric circles, 4-6 segments) 3. Label circles: Primary, Secondary, Tertiary 4. Label segments as subcategories of the topic 5. Give each person a poster, pen, and sticky notes 6. Instruct them to plot their personal considerations 7. Ask participants to describe their rankings

Tips:

• Limit plotting time to 15 minutes
• Allow participants to write in some segment labels
• Listen closely when people describe their choices

---

Buy a Feature

A game using artificial money to express trade-off decisions

Best for: Understanding feature priorities, revealing what users truly value Participants: 4-8 stakeholders or users Time: 45-60 minutes

Process: 1. Identify a product or service to focus on 2. Generate a list of potential features 3. Make playing cards for each feature with a price tag 4. Give each player a limited amount of artificial money 5. Ask them to purchase features within their budget 6. Encourage them to articulate their deliberations

Tips:

• Pricing can be based on actual cost of execution
• Listen for evidence of motivations and priorities
• Have participants make buying decisions in pairs for richer discussion

---

Card Sorting

Understanding how users categorize and organize information

Best for: Information architecture, navigation structure, labeling Time: 30-45 minutes per session

Types:

Important: A closed sort tests classification, not findability. If users can sort "Account settings" into "Profile," it doesn't mean they'll navigate there. Use tree testing or task-based testing to validate findability.

Participants:

• Exploratory analysis (patterns and themes): 8-10 participants is often sufficient
• Statistical analysis (dendrograms, clusters): 15-30+ for meaningful statistical patterns
• Team sorts (collaborative, generative): 3-5 groups of 2-3 people — good for hearing reasoning, not for statistics

Choosing Content

Poorly chosen content is the most common reason card sorts fail.

Content sources:

• New product → wish list of content types and features
• Existing product → content inventory or audit (sample representative items, don't include everything)
• Application → tasks, functions, and menu items

Running the Sort

Facilitation tips:

• Do a test run first — catches duplicate content, confusing titles, and bad instructions
• Let participants work at their own pace
• Anticipate questions: "Can I put a card in two groups?" (usually yes for physical; depends on tool for digital)
• For team sorts: listen to the discussion, not just the final grouping — reasoning is as valuable as results
• For open sorts: ask participants to name their groups after sorting, not before (naming first biases the grouping)
• Take notes on body language, hesitation, and verbal reasoning

Physical vs. digital:

• Physical cards (3"×5" index cards) — Better for face-to-face sorts, richer observation, team discussions
• Online tools (OptimalSort, UserZoom, etc.) — Better for remote participants, larger samples, automatic data capture

Analysis: Two Approaches

Always do exploratory analysis first. Statistical analysis is optional and requires 15+ participants.

Exploratory analysis (do this every time):

1. Look at each participant's results individually — What classification schemes did they use? (Topic, task, audience, format?) 2. Create a spreadsheet — Cards as rows, participant groups as columns. Look for where cards consistently land together 3. Identify strong pairs — Which cards always go together across participants? These are natural siblings 4. Identify scattered cards — Which cards end up in different groups for different people? These are ambiguous items that may need their own category or clearer labeling 5. Examine group labels — What words did participants use? These are candidates for your navigation labels 6. Note outlier reasoning — Sometimes one participant's unusual grouping reveals an insight everyone else missed

Statistical analysis (for 15+ participants):

Cautions with statistics:

• Don't rely on statistics alone — they can suggest a tidy answer that doesn't reflect the messiness of real data
• Always combine with exploratory analysis to understand why patterns exist
• Statistical methods work poorly with fewer than 15 participants

Applying Results to Information Architecture

Card sort results are one input, not a dictation. Combine with business requirements, content strategy, and technical constraints.

After the card sort: Validate the resulting IA with a tree test — give users tasks and ask them to navigate the category structure to find the right answer. Card sorting tells you how to organize; tree testing tells you if people can find things.

---

Build Your Own

People express ideal solutions using symbolic elements

Best for: Uncovering latent needs, discovering what users actually want Participants: 4-8 in pairs Time: 30-60 minutes

Process: 1. Identify a product or service to focus on 2. Make a kit of representational building blocks (shapes, symbols) 3. Divide group into teams of two 4. Give each team a construction kit 5. Ask them to build an expression of an ideal solution 6. Encourage "thinking aloud" as they construct 7. Ask each team to present their final model

---

Journaling / Diary Studies

People record personal experiences over time

Best for: Understanding experiences over time, capturing in-the-moment reactions, remote research Participants: 8-15 participants Time: 1-4 weeks

Process: 1. Define the experience or behavior to track 2. Create a structured journal template (digital or physical) 3. Brief participants on what to record and when 4. Send regular reminders (but don't over-prompt) 5. Collect journals at the end of the study period 6. Analyze entries for patterns across participants and time

---

Evaluative Methods

Testing designs and solutions

Usability Testing

Observing representative users attempting tasks with a design

Best for: Identifying interaction problems, validating design decisions Participants: 3-5 per round Time: 30-60 minutes per session

See references/usability-testing-guide.md for the complete process, scoring rubrics, and triage framework.

What usability testing CAN do:

• Uncover problems with labeling, structure, mental model, and flow
• Reveal whether interface language works for your audience
• Show how users think about the problems you're solving
• Demonstrate to stakeholders whether the approach meets goals

What usability testing CANNOT do:

• Provide a story, vision, or breakthrough design
• Tell you whether the product will succeed in the market
• Tell you which user tasks are more important than others
• Substitute for QA testing

Usability has 5 quality components:

• Learnability: How easy for first-time users to accomplish basic tasks?
• Efficiency: Once learned, how quickly can users perform tasks?
• Memorability: After time away, how easily can users reestablish proficiency?
• Errors: How many, how severe, and how easily recovered?
• Satisfaction: How pleasant to use?

---

Heuristic Evaluation

Expert review against established usability principles

Best for: Quick identification of obvious usability issues before user testing Evaluators: 2-3 minimum (each finds different issues) Time: 1-2 hours per evaluator

Nielsen's 10 Heuristics: 1. System status visibility: Appropriate feedback within 400ms 2. Match with real world: Language and conventions familiar to users 3. User control and freedom: Emergency exits, undo, redo 4. Consistency and standards: Same things behave the same way 5. Error prevention: Help users avoid errors, not just recover 6. Recognition over recall: Options visible, instructions findable 7. Flexibility and efficiency: Shortcuts for expert users 8. Aesthetic and minimalist design: No irrelevant information 9. Help users recover from errors: Error messages that help 10. Help and documentation: Task-oriented, easy to find

Severity Rating Scale (0-4):

• 0 — Not a problem: Cosmetic only
• 1 — Cosmetic: Fix if time permits
• 2 — Minor: Low priority
• 3 — Major: High priority, causes significant difficulty
• 4 — Catastrophic: Must fix before release

Pros: Quick, cheap, catches basic issues early Cons: Simplistic, won't catch all issues — not a substitute for usability testing

---

Tree Testing

Evaluating findability within a site's hierarchy

Best for: Validating information architecture without visual design influence Participants: 20-50 for quantitative results Time: 15-20 minutes per participant

Process: 1. Create a text-only representation of your site hierarchy 2. Write task scenarios ("Where would you find X?") 3. Participants navigate the tree to find where they'd expect each item 4. Measure success rate, directness (first click accuracy), and time to complete

---

A/B Testing

Comparing two versions to determine which performs better

Best for: Validating specific design decisions with statistical confidence Participants: Depends on traffic (need 95% confidence level) Time: Run until statistical significance is reached

Process: 1. Select your goal metric 2. Create variations (change one thing at a time) 3. Choose an appropriate start date 4. Run until 95% confidence level 5. Review the data 6. Decide: stick with control, switch to variation, or run more tests

Caution: A/B testing can be seductive because it promises mathematical certitude. But human decision-making is still necessary. The best response to a UI question is not always a test.

---

Synthesis Methods

Turning data into insights and models

Affinity Diagramming

Grouping observations into themes

See references/analysis-synthesis.md for the complete process.

Empathy Mapping

Articulating what you know about a user type

Four quadrants: 1. What the user says — Direct quotes and statements 2. What the user does — Actions and behaviors observed 3. What the user thinks — Thoughts, beliefs, concerns (may not be explicit) 4. What the user feels — Emotional state throughout the experience

Journey Mapping

Visualizing the user flow from a high-level perspective

For each step, document:

• Goal — What is the user trying to accomplish?
• Actions — What does the user do?
• Touchpoint — What parts of the product are involved?
• Thinking — What is the user thinking?
• Feeling — What is the user feeling?
• Opportunities — How can we improve this step?
• Ownership — Who on the team is responsible?

Persona Creation

Composite user archetypes from research data

See references/analysis-synthesis.md for the complete persona creation process.

Usability Testing Guide

A complete guide to planning, conducting, and analyzing usability tests. Combines established usability testing frameworks and methodologies.

When to Use Usability Testing

Test early. Test often. Never right before lunch.

• Before designing: test comparable or competitor sites
• During design: test wireframes and prototypes
• Before launch: test the near-final product
• After launch: test to identify improvement opportunities

Two kinds of testing:

• "Get it" testing: Show users the site/product. Do they understand the purpose, value proposition, organization, and how it works?
• Key task testing: Ask users to complete specific tasks. Watch how well they do.

Planning a Test

Decide What to Test

Good test candidates:

• Core user flows (onboarding, checkout, search)
• New features or redesigned areas
• Areas where analytics show drop-off or confusion
• Competitor products (for benchmarking)
• Multiple design concepts (comparative testing)

Write a Test Plan

Use templates/usability-test-plan-template.md for the full template.

Essential elements:

• Objectives (what questions will this test answer?)
• Subject of the test (prototype, live product, competitor)
• Methodology (moderated/unmoderated, remote/in-person)
• Participants (number, criteria, recruiting method)
• Task scenarios (4-6 per session)
• Usability goals (completion rate, error-free rate, time on task)
• Success metrics (what constitutes "pass" for each task?)

Write Task Scenarios

Tasks should be:

• Scenario-based: Give context, not just instructions
• Goal-oriented: Focus on what the user wants to achieve, not the steps
• Realistic: Based on actual use cases from personas or analytics
• Neutral: Don't use the same words that appear in the interface

Example — Bad:

"Click on the Account Settings menu and change your email address."

Example — Good:

"You recently changed your email address. Show me how you'd update it in this app."

Example — Bad:

"Use the search filter to find running shoes under $100."

Example — Good:

"You're looking for a pair of running shoes and your budget is under $100. Find a pair you'd consider buying."

How Many Users?

Per round: 3-5 users

• 3 users catches the most obvious problems and allows same-day debrief
• 5 users catches approximately 85% of usability issues
• More users in a single round has diminishing returns
• Better to do 3 rounds of 3 than 1 round of 9

Why small and frequent beats large and rare:

• Faster feedback loops
• Less pressure to "get it right" in one test
• Each round can test fixes from the previous round
• Lower cost per round = more rounds = better product

How Many Tasks?

• 30-minute session: 3-4 tasks
• 60-minute session: 5-7 tasks
• Order tasks from easy to difficult
• Include at least one "Get It" task at the beginning
• Save the most important task for when the participant is warmed up (task 2 or 3)

Recruiting

Key principle: The importance of recruiting perfectly representative users is overrated. Testing early and often with imperfect participants is far better than waiting for perfect ones.

Good enough participants:

• Share key goals with target users
• Have similar tech proficiency
• Are NOT employees or close friends of the team (for formal rounds)
• Can articulate their thoughts while working

Recruiting tips:

• Offer reasonable incentives ($50-100/hour consumer, more for B2B)
• Keep the invitation simple
• Don't discuss the product beforehand
• For early/informal rounds: friends, neighbors, and hallway testing are fine
• Maintain an ongoing database of potential participants

Use templates/screener-template.md to write a screening survey.

Running the Test

Roles

• Facilitator: Guides the participant through tasks. Should NOT be the designer or developer — they can't sit idly while their creation fails.
• Observer/Notetaker: Takes structured notes while watching. Records task outcomes, timestamps, and quotes.
• Team observers: Watch from a separate room or screen. Everyone on the team should be encouraged to attend.

Setup

In-person:

• Quiet room with two chairs, computer, and recording equipment
• Video cable to a TV in another room for team observation
• Screen recording software (with audio)
• Water for the participant

Remote:

• Video conferencing with screen sharing
• Ask participant to share their screen and think aloud
• Record the session (with permission)
• Have a backup plan if tech fails

Facilitation Script

Opening (5 min):

"Thanks for coming. I'm going to ask you to try some things on [product] and tell me what you think as you go. This isn't a test of you — we're testing the product. There are no wrong answers. If you get stuck, that's valuable information for us. I may not be able to help you during the tasks because I want to see what a real user would experience. Please think out loud — tell me what you're looking at, what you're trying to do, and what you're thinking."

Before each task:

"I'm going to read you a scenario. Take a moment to read it on this card, then show me how you'd approach it."

During tasks:

• Stay quiet unless the participant is completely stuck or silent
• If silent: "What are you thinking right now?"
• If stuck for 2+ minutes: "What would you do if I weren't here?"
• If completely blocked: note the failure and move to the next task
• Never say "click there" or "try the menu" — let them struggle

Probing questions (after each task):

• "What did you expect to happen when you clicked that?"
• "Was anything confusing or unexpected?"
• "On a scale of 1-5, how easy was that? Why?"
• "What would you have done if you were at home?"

Closing (5 min):

"That's all the tasks. Before we finish — what was the hardest part? Is there anything else you noticed that you'd like to share?"

What the Observer Should Capture

For each task, record:

• Task outcome: Success / Failure / Partial success
• Time to complete (if measuring)
• Path taken: What did they click/tap?
• Errors: Wrong turns, misclicks, confusion points
• Verbal reactions: Direct quotes, especially frustration or confusion
• Body language: Sighing, leaning in, squinting (in-person)
• Assist needed: Did the facilitator have to intervene?

Analyzing Results

Same-Day Debrief (Critical)

After testing 3-4 users, debrief immediately — over lunch is ideal.

Debrief structure: 1. Each observer shares their top 3 observations 2. Identify issues that multiple users encountered 3. Rate each issue on severity and frequency 4. Identify quick wins (obvious fixes, low effort) 5. Decide what to fix before the next round

Severity Scale

Frequency Scale

Issue Triage (3 Tiers)

Typical Problem Categories

Users are unclear on the concept: They don't get it. They either don't know what to make of the page, or they think they do but they're wrong. → Revisit the value proposition, labeling, and overall page purpose.

The words they're looking for aren't there: Either (a) your categories don't match their mental model, or (b) categories are right but labels are wrong. → Consider card sorting to realign navigation and labeling.

There's too much going on: What they need is on the page, but they can't see it. Visual noise is hiding it. → Reduce noise, improve visual hierarchy, make key elements "pop."

Triage Guidelines

• Ignore "kayak" problems: Users go astray briefly but recover immediately without help. These are normal navigation behavior, not bugs.
• Resist the impulse to add things: When users don't get something, the instinct is to add explanations. Often the fix is to remove something that's obscuring the meaning.
• Be skeptical of feature requests: "I'd like it if it could do X" — probe deeper. They often have a fine source for X already.
• Grab the low-hanging fruit: Focus on "head slappers" (obvious to everyone once seen) and "cheap hits" (minimal effort, high visibility).

Presenting Findings

Use templates/findings-report-template.md for the full report template.

Key sections: 1. Executive summary (3-5 bullet points) 2. Methodology (who, what, how) 3. Task results table (task, success rate, average time, key issues) 4. Prioritized findings with severity ratings 5. Recommendations with effort estimates 6. Video clips or screenshots of key moments (most persuasive artifact)

Persuasion tip: A 2-minute video clip of a user struggling with a task is worth more than a 20-page report. Always capture highlight clips.

Benchmarks and Metrics

Task-Level Metrics

• Completion rate: % of users who successfully completed the task
• Error-free rate: % of users who completed without any errors
• Time on task: Average time to complete (compare across rounds)
• Single Ease Question (SEQ): "How easy was this task?" (1-7 scale, asked after each task)
• Average SEQ across studies: 5.5
• Below 5.0 indicates a usability problem worth investigating

Study-Level Metrics

• System Usability Scale (SUS): See detailed section below
• Net Promoter Score (NPS): "How likely are you to recommend?" (0-10)
• Promoters (9-10), Passives (7-8), Detractors (0-6)
• NPS = % Promoters − % Detractors
• UMUX-Lite: 2-question alternative to SUS (see below)

Industry Benchmarks

• Average task completion rate: 78%
• Average SUS score: 68
• Average SEQ score: 5.5
• Target for good usability: 80%+ completion, 75+ SUS, 5.5+ SEQ

---

System Usability Scale (SUS)

The most widely used standardized usability questionnaire. Developed in 1986, validated across thousands of studies. Takes 1-2 minutes to administer. Requires only 12-14 users for reliable results, but can be used with as few as 5.

When to Administer

• After the participant completes all tasks in a usability test
• Before the debrief/interview (capture immediate impression, not post-discussion rationalization)
• Can also be used for periodic benchmarking of a live product (survey existing users)

The 10 Questions

Participants rate each statement on a 5-point scale: Strongly Disagree (1) to Strongly Agree (5).

Important: Present all 10 questions together on one page. Don't skip questions or change the wording — the scale is validated as a complete set. The alternating positive/negative tone is intentional (prevents response bias).

Scoring Formula

SUS scoring is not intuitive — don't just average the raw responses.

Step 1: Calculate item scores

• For odd-numbered items (positive statements): item score = raw score − 1
• For even-numbered items (negative statements): item score = 5 − raw score

This converts all items to a 0-4 scale where higher = better.

Step 2: Sum and multiply

• Add all 10 item scores (range: 0-40)
• Multiply by 2.5 to get the SUS score (range: 0-100)

Example calculation:

SUS Score = 35 × 2.5 = 87.5

Interpreting SUS Scores

SUS produces a single number from 0-100, but it's not a percentage. Use these interpretation scales:

Grade Scale

Adjective Scale

Acceptability Ranges

Key Benchmarks

• Average SUS score across all products: 68 (this is a C grade, not "good")
• Target for "good" usability: 75+ (B grade, 70th percentile)
• Target for "excellent" usability: 85+ (A+ grade)
• A score of 68 is average, not passing — many teams mistake this for "good enough"

SUS Subscales

SUS can be split into two factors (though the overall score is most reliable):

If the learnability subscale is significantly lower than general usability, the product is usable once learned but has an onboarding problem. If general usability is low but learnability is fine, the product is easy to pick up but frustrating to use.

Common Mistakes with SUS

Tracking SUS Over Time

SUS is most valuable as a comparative measure:

A change of 3+ points is generally considered meaningful. A change of 10+ points represents a major shift in perceived usability.

---

Alternative Usability Questionnaires

SUS isn't always the right tool. Choose based on your constraints:

UMUX-Lite (2 questions)

Use when you need a very quick satisfaction measure — in-app surveys, post-task popups, or when respondent time is extremely limited.

Questions (7-point scale, Strongly Disagree to Strongly Agree): 1. "[System name]'s capabilities meet my requirements." 2. "[System name] is easy to use."

Scoring: Average the two scores. Can be converted to a SUS-equivalent: (mean − 1) × (100/6).

Tradeoff: Much shorter, but less diagnostic. Tells you "there's a problem" but not where.

Single Ease Question (SEQ)

Use after each individual task (not at study level) to measure perceived task difficulty.

Question: "Overall, how easy or difficult was this task?" (1 = Very Difficult, 7 = Very Easy)

Benchmark: Average across studies is 5.5. Below 5.0 signals a task-level usability issue.

Best paired with: Task completion rate. A task with high completion but low SEQ means users succeeded but found it frustrating.

NASA-TLX (Task Load Index)

Use when you need to measure cognitive workload — common in complex/professional tools, safety-critical systems, or comparing two interface approaches for the same task.

6 subscales: Mental demand, Physical demand, Temporal demand, Performance, Effort, Frustration (each rated 0-100).

When to use over SUS: When "how usable" matters less than "how much effort does this take?" — e.g., comparing a wizard vs. a single-page form for a complex task.

Choosing the Right Questionnaire

Workshop Methods

Facilitation techniques for team workshops — framing problems, generating ideas, prioritizing decisions, and building alignment. These are collaborative activities, not solo research methods. Most work best with 4-10 participants and a dedicated facilitator.

---

Problem Framing

Methods for defining and reframing the problem before jumping to solutions.

Statement Starters (How Might We)

Reframe problems as opportunities using open-ended prompts.

Best for: Transitioning from research findings to ideation; reframing negative findings as design challenges Participants: 3-8 Time: 15-30 minutes

Process: 1. Start with a set of research findings, pain points, or problem statements 2. Rewrite each as an open-ended prompt using a starter phrase:

• "How might we ___?"
• "In what ways might we ___?"
• "How to ___?"

3. Pick the best starter for each problem — the one that opens the most solution space without embedding a specific solution 4. Vote on the strongest HMW statements to carry into ideation

Tips:

• Don't embed solutions: "HMW add a search bar?" is too narrow. "HMW help users find what they need quickly?" opens more possibilities
• Too broad = useless ("HMW improve the experience?"). Too narrow = one solution. Aim for the middle
• Generate 3-5 HMW variations per insight, then pick the best

Example:

• Finding: "Users abandon checkout when they see unexpected shipping costs"
• Too broad: "HMW improve checkout?"
• Too narrow: "HMW show shipping costs on the product page?"
• Right level: "HMW eliminate surprises during checkout?"

---

Problem Tree Analysis

Explore causes and effects of a problem by mapping them as roots and branches.

Best for: Understanding root causes before solving; revealing that the stated problem may not be the real one Participants: 4-8 Time: 30-45 minutes

Process: 1. Write the focal problem statement in the center of a whiteboard 2. Ask the team to identify causes — write below the problem (roots) 3. For each cause, ask "Why does this happen?" to dig deeper (sub-roots) 4. Ask the team to identify effects — write above the problem (branches) 5. For each effect, ask "What does this lead to?" (sub-branches) 6. Discuss and decide which root cause or effect to focus on

Tips:

• Distinguish direct vs. indirect causes — direct causes are more actionable
• Some effects are frequent, some rare — note which ones matter most
• The original problem statement may turn out to be a symptom, not the root cause
• Use dot voting to decide which branch to tackle first

---

Abstraction Laddering

Broaden or narrow a problem statement by asking "Why?" (up) and "How?" (down).

Best for: When the problem feels too broad or too narrow; reframing to find the right level of abstraction Participants: 3-6 Time: 20-30 minutes

Process: 1. Write the initial problem statement on the middle rung of a ladder diagram 2. Move up by asking "Why is this important?" — produces broader, more strategic frames 3. Move down by asking "How might we solve this?" — produces narrower, more tactical frames 4. Generate 2-3 options at each level 5. Discuss and choose the level that opens the most useful solution space

Example:

• Start: "Users can't find the settings page"
• Up (Why?): "Users can't customize their experience" → "Users feel the product doesn't fit their needs"
• Down (How?): "Add settings to the navigation" → "Add a gear icon in the header"
• Best level depends on project scope — early discovery goes up, late iteration goes down

Tips:

• Going up reveals strategic opportunities you might have missed
• Going down reveals that you may already have a solution in mind (check if it's the right one)
• Sometimes the original statement turns out to be the best level after all

---

Rose, Thorn, Bud

Categorize observations as positive (rose), negative (thorn), or having potential (bud).

Best for: Quick team debrief after research sessions, sprint retrospectives, design reviews Participants: 3-10 Time: 15-25 minutes

Process: 1. Give each participant sticky notes in three colors:

• Pink/Red = Rose — things that are positive, working well
• Blue = Thorn — things that are negative, painful, broken
• Green = Bud — things that have potential, ideas worth exploring

2. Set a timer (5-8 minutes) for silent individual writing — one item per note 3. Each person places their notes on a shared board 4. Group similar items together 5. Discuss patterns and decide on next actions

Tips:

• Require multiple items per color to force balanced thinking
• Don't discuss solutions during the exercise — just capture observations
• Buds are the most valuable output — they're the bridge from findings to opportunities

---

Ideation

Methods for generating a large volume of ideas before narrowing down.

Thumbnail Sketching

Rapid small drawings to explore many visual possibilities quickly.

Best for: Early concept exploration; generating UI layout options; breaking out of the first idea Participants: 3-8 (individual work, then group share) Time: 20-40 minutes

Process: 1. Give each person a sheet divided into 6-8 small boxes 2. State the design challenge clearly 3. Set a timer: 2-3 minutes per sketch 4. Each person sketches a different approach in each box — quantity over quality 5. After individual sketching, each person presents their top 2-3 to the group 6. Group discusses patterns and selects concepts to develop further

Tips:

• Emphasize visual thinking, not drawing skill — stick figures are fine
• Short time limits prevent overthinking and self-editing
• Encourage truly different approaches in each box, not refinements of one idea
• First ideas are rarely the best — push past the obvious

---

Creative Matrix

Generate ideas at the intersections of two sets of categories.

Best for: Breaking out of habitual thinking; generating a high volume of diverse ideas Participants: 4-8 in teams of 2-3 Time: 20-30 minutes

Process: 1. Draw a grid (max 5×5) on a large poster or whiteboard 2. Label columns with people categories (user types, personas, contexts) 3. Label rows with enabling categories (technologies, channels, touchpoints, constraints) 4. Give each team sticky notes and pens 5. Set a timer: 15-20 minutes 6. Teams ideate at each intersection — one idea per sticky note, placed in the cell 7. Tally ideas per team — reward quantity 8. Review and discuss the most promising intersections

Example grid:

Tips:

• Choose categories that feel unrelated — the unusual intersections produce the freshest ideas
• Encourage drawing over writing
• Don't judge during generation — evaluation comes later

---

Round Robin

Ideas evolve as they pass from person to person.

Best for: Building on each other's ideas; ensuring all voices contribute equally; reducing dominance by loud voices Participants: 4-5 per group Time: 20-30 minutes

Process: 1. Give each person a worksheet folded into four sections 2. Section 1: Each person writes the challenge and an unconventional solution (3 min) 3. Pass worksheet to the left 4. Section 2: Write a reason why this proposal will fail (3 min) 5. Pass worksheet to the left 6. Section 3: Write a way to resolve the critique (3 min) 7. Pass worksheet to the left 8. Section 4: Refine or extend the solution (3 min) 9. Return to original owner; each person presents their evolved idea

Tips:

• Strict time limits keep energy high
• Encourage wild initial ideas — the critique/resolve cycle makes them practical
• The "why it will fail" step is the most valuable — it stress-tests ideas quickly

---

Alternative Worlds

Use analogous domains to generate fresh perspectives.

Best for: When the team is stuck; bringing outside inspiration; breaking industry-specific assumptions Participants: 4-8 Time: 30-45 minutes

Process: 1. State the design challenge 2. Brainstorm analogous organizations or domains (e.g., "How would a hotel solve this? A hospital? A video game?") 3. Select 2-3 alternative worlds that are very different from yours 4. For each world, discuss: "How would [company/domain] approach our challenge?" 5. Extract principles and ideas that could translate to your context

Example:

• Challenge: "How might we reduce onboarding time for our B2B software?"
• Alternative world: Video games → Progressive tutorials, learn-by-doing, achievement unlocks
• Alternative world: IKEA → Visual-only assembly instructions, numbered steps, everything in the box
• Translate: "What if onboarding was a playable tutorial instead of a documentation link?"

Tips:

• Resist the temptation to use direct competitors — the point is radical difference
• If possible, interview someone who works in the alternative world
• Extract the principle, not the literal solution

---

Prioritization

Methods for deciding what to do first.

Importance/Difficulty Matrix

Plot items on two axes to reveal quick wins and strategic investments.

Best for: Prioritizing features, backlog items, research findings, or design improvements Participants: 4-8 Time: 30-45 minutes

Process: 1. Draw a large quad chart on a whiteboard 2. Label horizontal axis: Importance (or Impact) — low to high 3. Label vertical axis: Difficulty (or Cost/Effort) — low to high 4. Write each item on a sticky note 5. As a group, place each item by debating its relative position on both axes 6. Discuss the resulting quadrants:

Tips:

• Give each item a unique position — don't stack items at the same point
• Listen carefully during debates — the reasoning is as valuable as the placement
• This is a planning tool, not a scientific cost-benefit analysis
• Revisit after each sprint/cycle as importance and difficulty shift

---

Bull's-Eye Diagramming

Rank items into concentric rings of priority.

Best for: Forcing hard choices about what's essential vs. nice-to-have; simpler than a full matrix when you just need priority tiers Participants: 4-8 Time: 20-30 minutes

Process: 1. Draw three concentric circles on a large poster 2. Label from center outward: Primary (must have), Secondary (should have), Tertiary (nice to have) 3. Write each item on a sticky note 4. As a group, debate and place each item in a ring 5. The center ring should be deliberately small — force tough choices

Tips:

• Size the center ring to fit only 3-5 items — this forces prioritization
• Enforce time limits on each debate (2-3 minutes per item)
• Tertiary doesn't mean irrelevant — it means "not now"

---

Visualize the Vote (Dot Voting)

Quick democratic poll to surface group preferences.

Best for: Narrowing down a large set of options quickly; making decisions after brainstorming; reducing the influence of the loudest voice Participants: 4-15 Time: 5-10 minutes

Process: 1. Display all options on a wall (ideas, concepts, features, HMW statements) 2. Give each person voting tokens:

• 1 large dot for overall favorite
• 2 small dots for interesting details or specific aspects

3. Announce the voting criteria clearly (e.g., "Vote for the idea most likely to reduce onboarding time") 4. Everyone votes simultaneously (prevents anchoring) 5. Tally votes 6. Discuss: why did top items get votes? Any surprises?

Tips:

• Use different colored dots for different voting criteria
• Place detail votes on specific parts of a concept, not just the title
• Dot voting is a signal, not a final decision — use it to narrow, then discuss the top 3-5

---

What's on Your Radar?

People map items to concentric rings by personal significance.

Best for: Understanding individual priorities before group discussion; revealing hidden disagreements about what matters Participants: 5-10 Time: 25-35 minutes

Process: 1. Draw a radar diagram: 3 concentric rings + 4-6 labeled segments (subcategories of the topic) 2. Label rings: Primary (center), Secondary, Tertiary 3. Give each person their own copy, a pen, and sticky notes 4. Individually: plot items according to personal significance (10-15 min) 5. Each person describes their radar to the group 6. Compare radars — look for consensus and divergence

Tips:

• Allow participants to add their own items and write in segment labels
• The most interesting output is where people disagree — those are the items worth discussing
• Follow up with dot voting or importance/difficulty matrix to converge

---

Modeling & Communication

Methods for making ideas tangible and shareable.

Storyboarding

A sequence of drawings showing a concept in use.

Best for: Communicating a user scenario; making an abstract concept concrete; building team alignment on a proposed experience Participants: 2-4 per storyboard Time: 30-60 minutes

Process: 1. Choose a concept and a specific user scenario 2. Use a template with 8-12 blank frames 3. Draft the main story arc: beginning (context/trigger), middle (interaction), end (outcome) 4. Determine the main character (use a persona) and setting 5. Sketch key moments — one per frame 6. Add a caption below each frame describing what's happening 7. Present to the broader team for feedback

Tips:

• Draw like a comic book — vary angles (wide shot for context, close-up for detail)
• Include the emotional arc, not just the functional steps
• Show the "before" state (pain) and "after" state (resolution)
• Stick figures are perfectly fine — clarity matters more than art

---

Concept Poster

A one-page pitch for a new idea.

Best for: Presenting a concept to stakeholders; rally team around a vision; comparing multiple concepts side-by-side Participants: 2-4 per poster Time: 30-45 minutes

Structure: 1. Name and tagline — memorable, captures the essence 2. Big picture illustration — what does it look like? 3. Summary — 2-3 sentences on the core idea 4. Key stakeholders — who benefits and how 5. Features and benefits — 3-5 bullet points 6. Timeline — rough phases for development

Tips:

• Make the first draft quickly — don't overthink
• Display posters prominently (war room, Slack) to rally enthusiasm
• Use these to compare 2-3 competing concepts before committing

---

Cover Story Mock-Up

A mock magazine article describing the successful future of an idea.

Best for: Vision alignment; getting stakeholders excited; thinking through what success looks like in concrete terms Participants: 3-6 Time: 45-60 minutes

Process: 1. Choose a relevant publication (real or fictional) 2. Date it 1-2 years in the future 3. Write a headline and subheading announcing your concept's success 4. Draw cover art 5. Write the first paragraph of the story — what happened, why it matters, who benefited 6. Add sidebar stories, callout quotes, and supporting details

Tips:

• Make it realistic — no fantasy outcomes, just ambitious plausible ones
• The exercise forces you to articulate what success actually looks like
• Great for kickoff meetings to align on vision before getting into details

---

Workshop Planning Quick Reference

Choosing the Right Activity

Half-Day Workshop Template

A typical 3-hour workshop combining multiple methods:

Facilitation Anti-Patterns

Research Findings Report

Study Overview

• Study: [Name]
• Date: [Date range]
• Researcher(s): [Names]
• Method: [e.g., Moderated usability testing]
• Participants: [Number and brief profile]

Executive Summary

3-5 bullet points that a stakeholder can read in 30 seconds and understand what happened and what to do.

• [Key finding 1 + recommended action]
• [Key finding 2 + recommended action]
• [Key finding 3 + recommended action]

Research Goals

What questions did this research answer?

1. [Question] → Answer: [Brief answer] 2. [Question] → Answer: [Brief answer] 3. [Question] → Answer: [Brief answer]

Methodology

• Method: [Description of approach]
• Participants: [Number], recruited via [method]
• Profile: [Key characteristics]
• Sessions: [Duration], [setting — remote/in-person]
• Data captured: [Recording type, notes, artifacts]

Participant Summary

Key Findings

Finding 1: [Insight statement]

Severity: Critical / High / Moderate / Low Frequency: [X of Y participants]

What we observed: [Description of the pattern — what happened, when, and how participants reacted]

Supporting evidence:

• P1: "[Direct quote]"
• P3: "[Direct quote]"
• [Behavior observed in X of Y sessions]

Why it matters: [Impact on user goals, business metrics, or product success]

Recommendation: [Specific, actionable recommendation]

Effort estimate: Small / Medium / Large

---

Finding 2: [Insight statement]

Severity: Critical / High / Moderate / Low Frequency: [X of Y participants]

What we observed: [Description]

Supporting evidence:

• [Quote or observation]
• [Quote or observation]

Why it matters: [Impact]

Recommendation: [Action]

Effort estimate: Small / Medium / Large

---

Finding 3: [Insight statement]

[Same structure as above]

---

Task Results (for usability testing)

Prioritized Recommendations

Tier definitions:

• Tier 1: Must address before release / in current cycle
• Tier 2: Plan for next cycle
• Tier 3: Add to backlog

What Worked Well

Don't only report problems — highlight what users responded positively to.

• [Positive finding 1]
• [Positive finding 2]

Suggested Next Steps

• [ ] [Immediate action — e.g., Fix Tier 1 issues]
• [ ] [Follow-up research — e.g., Card sort to validate new navigation]
• [ ] [Longer-term — e.g., Re-test after fixes are implemented]

Appendix

Raw Data Location

[Link to shared drive folder with recordings, notes, and transcripts]

Study Materials

• Research plan: [Link]
• Interview guide / test script: [Link]
• Screener: [Link]

Highlight Clips

2-minute video clips are the most persuasive artifact you can share.

• [Clip 1: Description — timestamp or link]
• [Clip 2: Description — timestamp or link]

Interview Guide

Study Info

• Study: [Name]
• Interviewer: [Name]
• Date: [Date]
• Participant: [ID/Name]

Study Goal

[One sentence describing what you want to learn]

---

Introduction (5 min)

Read this to the participant:

"Thanks for taking the time to talk with me today. I'm [name], a [role] working on [project]. I'm here to learn about your experience with [topic].

A few things before we start:

• There are no right or wrong answers — I'm genuinely interested in how you see things
• I may ask follow-up questions to understand better; it's not because you said something wrong
• Everything you share will be used to improve our product
• Your name won't be attached to specific quotes unless you give permission
• Do you mind if I record this so I can focus on our conversation instead of notes?

Do you have any questions before we start?"

---

Warmup Questions (5 min)

Easy factual questions to build rapport.

1. Tell me a bit about your role. What does a typical day look like? 2. [Context question relevant to the study topic]

---

Core Questions (30-40 min)

Story-based questions about actual past behavior. Use "Tell me more about that" liberally.

Topic 1: [Theme]

3. Tell me about the last time you [relevant activity].

• Walk me through what happened from the beginning.
• What happened next?
• How did that make you feel?

4. [Follow-up question about this topic]

Topic 2: [Theme]

5. Can you think of a specific time when [relevant situation]?

• What did you try first?
• What were you hoping would happen?
• What actually happened?

6. [Follow-up question about this topic]

Topic 3: [Theme]

7. Tell me about a time when [relevant challenge or pain point].

• What did you try before that?
• Why was that important to you?

8. [Follow-up question about this topic]

---

Probing Questions (use as needed)

Keep these ready to deepen any response:

• "Tell me more about that."
• "What do you mean by [their word]?"
• "Can you give me a specific example?"
• "Why was that important to you?"
• "What were you expecting to happen?"
• "What did you try before/after that?"
• "How did that make you feel?"
• "Who else was involved?"
• "What would have made that easier?"

---

Closing (5 min)

9. Is there anything about [topic] that I didn't ask about but you think is important? 10. Is there anything you'd like to ask me?

Thank them sincerely. Explain next steps if applicable. Provide incentive.

---

Post-Interview (complete within 1 hour)

Quick Debrief

• Top 3 observations:

1. [Observation] 2. [Observation] 3. [Observation]

• Surprising findings: [What challenged your assumptions?]

• Key quotes:

1. "[Quote]" 2. "[Quote]"

• Opportunities identified: [Needs, pain points, desires surfaced]

• Questions for next interview: [Anything to add or adjust?]