Research Plan

Origin & evolution

User research inherited its planning vocabulary from the social sciences, where a study protocol fixes questions, sampling, and analysis ahead of data collection. The translation into product practice owes a lot to Erika Hall's Just Enough Research (2013), which framed research as a set of methods a team picks deliberately rather than a ritual, and separated the kinds of study a plan might serve: generative work to define a problem, descriptive work to understand one, evaluative work to test a solution🔧SolutionDiscoveryA proposed approach to address an opportunityView reference →, and causal work to explain behaviour.

Hall also put recruitment at the centre of plan quality. Locating, screening, and acquiring the right participants🙋ParticipantUser ResearchA person participating in researchView reference → determines whether findings mean anything, because a study run against the wrong people produces confident answers to the wrong question. A research plan that omits its recruitment criteria has skipped the part most likely to break it.

The field has since converged on the plan as the contract between a researcher and the team commissioning the work. It states what will be learned and what will be left out, so that a study stays scoped and its results stay defensible.

Torres offers a third position. In Continuous Discovery Habits (2021), she argues that discovery should be structured as a weekly cadence — at least one customer conversation per week — rather than a series of discrete formal studies. By that reading, a research plan is less a one-off protocol and more a standing operating procedure: the questions, the recruitment pipeline, and the analysis rhythm are set up once and then run continuously. This shifts the plan's centre of gravity from scoping a bounded study to maintaining the infrastructure that keeps the team in contact with users. The tension between Torres's cadence model and the one-study contract model is worth noting when deciding how much formality a given plan needs🫀NeedUserA user need, pain, desire, or constraintView reference →.

How it works in practice

A team keeps losing trial users somewhere in the first session, and nobody knows where. The research plan reads as follows. Research questions❓Research QuestionUser ResearchA question guiding a research studyView reference →: where do first-time users stall, and what are they expecting when they stall. Method: eight moderated usability sessions with think-aloud, plus a review of session recordings for the stall point. Recruitment: solo operators who signed up in the last fortnight and abandoned before creating a second project, screened out if they have used a competing tool. Analysis: affinity mapping of stall moments across the eight transcripts.

The study runs over two weeks. Six of eight participants stall at the same empty-state screen, expecting a template and finding a blank canvas. The plan's tight recruitment is what makes that finding trustworthy: these are the exact users who churn, not a convenient panel.

Research plan vs. its neighbours

• Test plan📝Test PlanQuality AssuranceA structured plan for testing a hypothesisView reference → validates a stated hypothesis🧪HypothesisValidationA testable belief about a solutionView reference → against a pre-set success threshold. A research plan investigates open questions whose answers are not yet known and often cannot be reduced to a single metric🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference →. One confirms or kills a belief; the other builds understanding.
• Research brief is the short upstream statement of need: the business question, the deadline, the stakeholders🧑‍💼StakeholderTeam & OrganisationA person with influence over the productView reference →. The research plan is the fuller design that answers the brief with a method, a sample, and an analysis approach.
• Research study🧑‍🔬Research StudyUser ResearchA planned research activityView reference → is the work itself, the sessions conducted and data gathered. The plan is the design the study follows, written before any participant is booked.

In the graph

In the Unified Product Graph, research_plan🗺️Research PlanValidationA plan for gathering evidence to validate a draft entity anchors the design layer of the validation region. A hypothesis🧪HypothesisValidationA testable belief about a solutionView reference → reaches it through hypothesis_investigated_via_research_planHypothesisinvestigated viaResearch Planhierarchy, marking the plan as the route from an uncertain belief to evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference → about it. The plan then connects outward through research_plan_recruits_participantResearch PlanrecruitsParticipantcausal, a causal edge that records the people a study draws in. That second edge carries real weight: it makes recruitment a first-class part of the graph rather than an implementation detail, so a plan whose participants do not match its target segment is visibly suspect, and the chain from hypothesis🧪HypothesisValidationA testable belief about a solutionView reference → through research_plan🗺️Research PlanValidationA plan for gathering evidence to validate a draft entity to participant🙋ParticipantUser ResearchA person participating in researchView reference → stays traceable.