Design Research Plan

---
name: design-research-plan
description: Use when starting any user research study — to define the research question, select methods, write a participant screener, and set a timeline before recruiting begins.
source: NNG "UX Research Cheat Sheet" (Nielsen, 2017); IDEO Human-Centered Design Toolkit (IDEO.org, 2015); Google Ventures Research Sprint guide
tags: [user-research, research-planning, ux, screener, methods, study-design]
---

# Design Research Plan

Write a one-page research plan that aligns the team on what questions the study will answer, which method fits those questions, and who to recruit — before a single participant is contacted.

## Why This Is Best Practice

**Adopted by:** Google Ventures mandates a written research plan before every sprint research day; IDEO's HCD Toolkit requires a "learning goals" document as the first step in all field research; Nielsen Norman Group's UX research training treats the research plan as the non-negotiable foundation of any credible study
**Impact:** NNG research shows that teams without a written plan collect data that answers the wrong question in the majority of studies — the most expensive research mistake because it is only discovered after sessions are complete and cannot be fixed retrospectively; a plan reviewed by stakeholders before recruiting eliminates post-study scope disputes and prevents "we should have asked about X" regret
**Why best:** Ad-hoc research — starting with recruiting before aligning on questions — produces data that is hard to act on; different team members leave sessions with different interpretations of what was learned; a written plan is the contract between the research team and stakeholders that prevents both under-scoping (missing key questions) and over-scoping (trying to answer everything in one study)

Sources: NNG "UX Research Cheat Sheet" (Nielsen Norman Group, 2017); IDEO "The Field Guide to Human-Centered Design" (IDEO.org, 2015); Goodman, Kuniavsky & Moed "Observing the User Experience" (Morgan Kaufmann, 2012) Ch. 3

## Steps

### 1. Write the research question

One sentence. Not a business question ("should we build this?") and not a solution ("how do we improve checkout?") — a behavioral or attitudinal question about users:

```
What are the primary reasons users abandon the checkout flow before entering payment information?
```

Gates:
- Cannot be answered with existing analytics alone → user research is needed
- Specific enough that you will know when it is answered
- Does not presuppose the answer ("why do users dislike X?" presupposes they dislike it)

If the team cannot agree on one research question, run a 20-minute alignment session to prioritize — multiple competing questions signal a scope problem, not a research plan problem.

### 2. Select the method

| Question type | Method |
|---------------|--------|
| Why do users behave a certain way? | User interviews |
| Can users complete tasks on the interface? | Usability testing |
| What do users do in their natural environment? | Contextual inquiry / diary study |
| How do users mentally organize a topic? | Card sorting |
| What are users' attitudes at scale? | Survey |
| Which of two designs performs better? | A/B test |

One method per study. If multiple question types are present, split into multiple studies or prioritize the highest-risk unknown.

### 3. Define participant criteria

Write a screener with three sections:

**Qualifying criteria** — must-haves that define the target user:
- Role, behavior, or context (not just demographics)
- Example: "Has made an online purchase in the last 30 days"

**Disqualifying criteria** — exclude anyone who would skew results:
- Competitors, researchers, UX practitioners (familiarity bias)
- People who work at your company

**Desired mix** — diversity factors relevant to your question:
- Experience level (novice vs. power user)
- Device type (mobile vs. desktop) if relevant
- Frequency of the behavior being studied

### 4. Set participant count

| Method | Recommended count |
|--------|-----------------|
| Interviews | 5–8 per distinct user segment |
| Usability testing (formative) | 5 per segment |
| Usability testing (summative) | 20+ for statistical validity |
| Card sorting | 15–20 |
| Survey | 100+ for quantitative analysis |
| Contextual inquiry | 5–8 |

More participants are not always better for qualitative methods — the 5-user rule (Nielsen, 1993) applies to formative usability testing; diminishing returns set in quickly for interviews.

### 5. Build the timeline

```
Week 1: Finalize plan + screener → stakeholder review
Week 2: Recruit participants (allow 5–7 business days minimum)
Week 3: Run sessions (1–2 per day max to preserve researcher quality)
Week 4: Synthesize findings → readout
```

Buffer for: no-shows (recruit 20% more than needed), scheduling conflicts, pilot session rescheduling.

### 6. Address consent and legal requirements

- Prepare consent form covering: recording permission, data usage, anonymization
- Check if incentive requires legal/finance approval (typically ≥$50 USD)
- For healthcare, financial, or children's products: flag for compliance review before recruiting
- Store session recordings in accordance with your data retention policy

### 7. Get stakeholder sign-off

Share the one-page plan with PM, design lead, and any stakeholder who will act on findings. Require explicit sign-off before recruiting begins. The questions they add or remove at this stage cost nothing; the questions they add after sessions end cost another full round of research.

## Rules

- One research question per study — if stakeholders push for more, negotiate which is highest priority or plan sequential studies
- Write the screener before recruiting; never recruit first and write criteria after
- Never recruit from your internal user panel exclusively — familiarity with your product biases results
- Pilot every study (one session with a colleague) before running real participants
- Do not start recruiting before the discussion guide or task scenarios exist — schedule conflicts will force you to run unprepared

## Common Mistakes

- **Research question is a business question**: "Should we redesign the nav?" is a decision, not a research question. Reframe: "What tasks do users attempt in the nav that they fail to complete?"
- **Screener is too permissive**: "Anyone who uses apps" recruits the wrong people; be specific about the behavior you're studying
- **No buffer for no-shows**: participants cancel; always recruit 20–30% more than the target count
- **Skipping stakeholder alignment**: stakeholders who don't see the plan until the readout will question the findings or ask for follow-up research on questions the plan could have included

## When NOT to Use

- When the research question can be answered with existing analytics, support tickets, or NPS data — run a desk research pass first; quantitative data may already answer the question
- When the team is mid-sprint and needs a decision in 24 hours — use a 2-hour guerrilla testing session instead of a full planned study
- When no change budget exists to act on findings — research without action is waste; confirm the team can act before investing in a study