<!-- last-reviewed: 2026-06-01 · owner: Design Research (Design Research Director) -->
SOP-048 — Research plan
SOP · owner: Design Research (Design Research Director). Layer: SOP/Runbook (
docs/canon.md). Method definitions and the spine’s role live indocs/methodology.mdand the JD — not restated here. State note (2026-06-01): the repo holds zero research evidence and no participant seam; until a live seam exists, plans resolve to simulated studies at a stated confidence penalty. This procedure is executable today (the plan is produced; the study it plans may be simulated).
Interface Contract
- Inputs: phase / gate context ← from CPTO · trigger:
de-risk commissioned - Inputs: concept to de-risk ← from Innovation Director · trigger:
de-risk commissioned - Inputs: framework / spec for Director review ← from <Instructional Designer / UX Designer> · trigger:
review requested - Outputs: research plan + brief → to UX Research Associate · trigger:
research brief issued - Outputs: research activities (status) → to all agents · trigger:
briefing posted - Outputs: recruitment request (personal data) → to Personal Assistant · trigger:
personal-data scoped - Outputs: research plan → to Archivist · trigger:
artifact approved - Handoff trigger (in): a phase gate approaches and gate evidence is needed, or Innovation hands a concept to de-risk
- Handoff trigger (out): the plan is approved and the brief is issued to the UXR (or the study is run/simulated by the Director)
- Definition of Done before handoff:
- [ ] The gate question is named and traced to a
docs/methodology.mdexit criterion - [ ] The leanest method that answers it is chosen (and justified — no method for its own sake)
- [ ] Instruments specified (screener 3–5 criteria; open-ended, task-framed guide; debrief template separating quote / behavior / interpretation)
- [ ] Confidence ceiling stated (simulated vs. live) before any study runs
- [ ] Recruitment touching personal data routed through the PA (never direct)
- [ ] Learnings captured to
docs/knowledge/if the planning surfaced one - [ ] Plan handed to the Archivist (0 drift)
- [ ] The gate question is named and traced to a
Registered triggers (
gate evidence ready,research brief issued) — added todocs/handoff-triggers.md(Wave-2 block, Operations-approved 2026-06-01).briefing posted,personal-data scoped, andartifact approvedalready existed. The recruitment-request edge is absorbed by the PA’spersonal-data scopedfan-in sink (SOP-040, §3.1 R1); the CPTO / Innovation / UX-Research / PMO edges reconcile aspending(those roles are not Interface-Contract identities here — §3.1.1 R3).
Purpose
Establish, at each phase boundary, what evidence the gate needs, by what method, on what timeline — so the venture advances on evidence, not assumption, and runs the leanest study that produces a real signal.
When to use
Whenever a phase gate (Ideate / Plan / Build / Grow / Operate) approaches and gate evidence is owed, or when the Innovation Director hands a concept that needs de-risking, or when in-market/telemetry signals call for a structured read.
Flow
flowchart LR
A["Identify the<br/>gate question"] --> B["Choose the<br/>leanest method"]
B --> C["Draft the<br/>instruments"]
C --> D{"Live participants<br/>available?"}
D -->|yes| E["Brief UXR<br/>(SOP-051)"]
D -->|no| F["Plan as simulated<br/>(state confidence penalty)"]
E --> G["Sequence with PMO;<br/>route recruitment via PA"]
F --> G
classDef s fill:#1d4ed8,color:#fff,stroke:#1e3a8a
classDef d fill:#0f766e,color:#fff,stroke:#134e4a
class A,B,C,E,F,G s
class D d
Text fallback: name the gate question (traced to a docs/methodology.md exit
criterion) → choose the leanest method (JTBD interview, concept test, usability
walkthrough, telemetry synthesis, short survey) → draft the instruments → are live
participants available? (yes → brief the UXR via SOP-051; no → plan as a simulated
study and state the confidence penalty) → sequence the activities with the PMO and
route any personal-data recruitment through the PA.
Steps
- Identify the question. Work from
docs/methodology.mdphase deliverables and exit criteria. State the one question the evidence must answer for the gate. - Choose the method. Select the leanest method that produces a real signal. Justify it; reject method-for-its-own-sake and over-long studies (a one-week question gets a one-week study).
- Draft the instruments. Screener (3–5 criteria); interview/usability guide (open-ended, task-framed, no leading questions); debrief template that captures verbatim quotes, observed behaviors, and interpretations separately.
- Set the confidence ceiling. If no live participant seam exists, the study is simulated — state this and the confidence penalty up front, in the plan.
- Sequence and route. Hand the research activities to the PMO for delivery
sequencing; route any recruitment that needs personal contact/calendar data
through the PA (
personal-data scoped). - Brief execution. For evaluative/telemetry work, issue the brief to the UXR
(SOP-051,
research brief issued); for generative work, run or simulate it yourself. - Hand off the plan to the Archivist; capture any learning.
Roles / approvers
Run by the Design Research Director. The Director owns method selection and exit criteria; the UXR executes within the plan but never modifies it. The CPTO + Principal are the downstream consumers of the evidence the plan produces (via SOP-049).
Guardrails
- Lean research — the smallest study that answers the question; no method for its own sake.
- Simulation is labeled — no live seam means a simulated study with a stated confidence penalty; never present a simulated plan as a live one.
- No leading instruments — open-ended, task-framed; a leading question is a research defect.
- Personal data is PA-only — recruitment routes through the PA; never accessed directly, never archived.
- Stay in your lane — the plan produces evidence, not concepts (Innovation), market sizing (Growth), or builds (Engineering).
- Do not restate
docs/methodology.mdmethod definitions — link to it.
See also: SOP-049 (gate evidence) · SOP-051 (usability protocol) ·
docs/units/design-research/charter.md · docs/handoff-triggers.md.