A plan for gathering evidence to validate or refine a draft entity, the question, method, participants, and what would change the team's mind.
A research plan is the design document for a study: the questions it sets out to answer, the method that will answer them, who gets recruited, and how the findings will be analysed. It is the artefact that keeps a study honest, because writing the questions down before fieldwork begins is what stops a team from going looking for the answer it already wanted.
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 solutionSolutionDiscoveryA 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 participantsParticipantUser 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.
A team keeps losing trial users somewhere in the first session, and nobody knows where. The research plan reads as follows. Research questionsResearch 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.
In the Unified Product Graph, Research PlanValidationA plan for gathering evidence to validate a draft entity anchors the design layer of the validation region. A research_planHypothesisValidationA testable belief about a solutionView reference → reaches it through hypothesisHypothesisinvestigated viaResearch Planhierarchy, marking the plan as the route from an uncertain belief to evidenceEvidenceValidationData supporting or refuting a hypothesisView reference → about it. The plan then connects outward through hypothesis_investigated_via_research_planResearch 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 research_plan_recruits_participantHypothesisValidationA testable belief about a solutionView reference → through hypothesisResearch PlanValidationA plan for gathering evidence to validate a draft entity to research_planParticipantUser ResearchA person participating in researchView reference → stays traceable.participant
Type-specific fields on BaseNode
research_questionstringPrimary research question
suggested_methodsstring[]Suggested methods
evidence_thresholdstringMinimum evidence bar
deadlinestringSuggested completion deadline. @example "2026-06-30"
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
4 phases — initial: draft
2 edge types connected to this entity.
hypothesis_investigated_via_research_planresearch_plan_recruits_participant