Quantitative surveys and in-depth interviews answer different types of questions. Choosing between them begins with the decision the research must support, then considers the evidence, people and time available.
Use surveys for structured comparison
Quantitative surveys work well when teams need consistent measures across a defined sample. They support estimates, segment comparisons and tracking when questions and answer options can be specified in advance.
Use interviews for explanation and discovery
In-depth interviews allow a moderator to explore language, context, motivations and unexpected themes. They are useful when the team needs to understand how participants interpret an experience or make a decision.
Match recruitment to the method
Surveys may require larger samples and carefully managed quotas. Interviews usually involve fewer participants but demand stronger scheduling, moderator preparation and depth of screening.
Combine methods intentionally
A survey can show how common a pattern is, while interviews can explain why it occurs. Sequence the methods around a clear learning need and avoid adding a second method unless it changes the decision or strengthens confidence.
Related Capacity guide: see Screening Surveys: How to Find the Right Participants to connect this step with the next part of the research workflow.
Define the outcome before configuring the work
Begin with the decision the study must support and the evidence required to make it. For quantitative surveys vs in-depth interviews, that means describing what success looks like for matching the research method to the decision and evidence required. Write the outcome in language that research leads, stakeholders, moderators and analysts can all understand. Then identify what must be true at launch, what may be adjusted during fieldwork and what must remain fixed for the results to be interpretable. This step prevents a technical configuration from becoming the de facto research plan. It also gives reviewers a practical test: every rule, field or checkpoint should protect the participant experience, the intended sample or the analysis. If nobody can explain the purpose of an element, simplify or remove it before it creates work downstream.
Turn principles into acceptance criteria
General intentions become useful when they are expressed as observable criteria. Agree how the team will judge whether structured comparison, contextual depth or a deliberate combination is needed. Write examples of expected behavior, edge cases and unacceptable outcomes. Include the evidence that will be reviewed and the person responsible for the final call. The criteria should be specific enough for a colleague who did not design the study to test them consistently. They should also leave room for professional judgment when the research context changes. A short acceptance checklist improves collaboration because it separates a genuine defect from a preference. It also reduces late debate, when pressure to launch can make teams accept workarounds they would not have approved during planning.
| Stage | Team question | Evidence to keep |
|---|---|---|
| Plan | What decision must this work support? | Brief, criteria and named owners |
| Configure | How will the rule work in real journeys? | Versioned setup and review notes |
| Pilot | Which ordinary and edge cases must pass? | Test paths, expected results and fixes |
| Monitor | Which signal would justify action? | Threshold, interpretation and decision log |
Design a workflow with named owners
Map the work from initial setup to final export, and assign an owner at each point where information changes. For this topic, the working group usually includes research leads, stakeholders, moderators and analysts. State who prepares the configuration, who reviews it, who approves launch and who responds when monitoring reveals a problem. Ownership does not require a complicated governance process. A compact table containing the task, owner, status, evidence and approval date is often sufficient. What matters is that decisions are visible and recoverable. When ownership is unclear, small changes happen in messages or spreadsheets and never reach the system of record. A named workflow keeps the research intent connected to the operational details.
Methodology reference: GOV.UK Service Manual guidance on user research provides useful independent context for this stage. Read the source ↗
Pilot realistic journeys, not isolated screens
A useful pilot follows complete participant and team journeys. Create ordinary cases, boundary cases and deliberately difficult cases. Include at least one scenario that could expose choosing a familiar method that cannot produce the evidence the decision requires. Test on the devices, languages, traffic sources and account roles that will be used in production. Ask testers to record the path they followed, the result they expected and the result they observed. Avoid fixing an issue and checking only the affected screen; repeat the complete journey to confirm that the change did not alter a later condition. A pilot is also an opportunity to review participant-facing language, support instructions and export fields. Those details are easy to miss when testing concentrates only on whether a button works.
Monitor a small set of decision-ready signals
Dashboards become distracting when every available measure receives equal attention. Select signals that connect directly to a possible action. Relevant measures here include clarity of the research question, sample needs, available time and analysis plan. Define a normal range, an investigation threshold and the owner of the response. Review trends and segment differences rather than reacting to a single reading. When a signal moves, check whether the change is explained by timing, source mix, quota availability or a planned configuration update. Record the interpretation beside the number. This practice turns monitoring into a repeatable decision process and prevents a team from treating normal variation as a crisis. It also creates useful evidence for improving the next study.
Handle exceptions without losing comparability
No fieldwork plan anticipates every situation. A supplier may change, an audience may be harder to reach or a wording issue may emerge after launch. Define how exceptions will be assessed before one occurs. Preserve the original rule, describe the proposed change, estimate the effect on participants and analysis, and obtain the appropriate approval. Apply changes from a recorded time or version so affected responses can be identified. Avoid silent corrections that make early and late data look equivalent when the experience was different. A controlled exception process allows the team to adapt while protecting comparability. It also gives analysts the context needed to decide whether results should be combined, segmented or qualified.
Interpret evidence with context
Operational data describes behavior, but it does not automatically explain cause. Combine the available signals with study design, source information and qualitative feedback. If a pattern appears in one segment, ask whether the difference reflects eligibility, device experience, invitation timing or the underlying population. If several indicators point in the same direction, document the reasoning before taking action. This is especially important when the apparent problem could be choosing a familiar method that cannot produce the evidence the decision requires. Avoid creating universal cutoffs from one project without validation. The purpose of review is to protect the research question, not to maximize a convenient metric. Contextual interpretation produces decisions that can be defended and repeated across studies.
Document the final state for analysis and learning
At close, capture more than the final number of completes. Store the approved configuration, meaningful changes, source definitions, monitoring notes, exception decisions and the logic behind any excluded records. Include stable identifiers so analysts can connect the export to the fieldwork history. Write a short closeout note that explains what happened, what differed from plan and what the team would change next time. This record supports transparent analysis and makes future setup faster. It also prevents institutional knowledge from remaining with one project manager. A useful closeout is concise, factual and written soon after fieldwork, while the reasons behind decisions are still available.
A practical thirty-day improvement plan
During the first week, review a recent project and identify where matching the research method to the decision and evidence required became unclear or required manual correction. In week two, agree the acceptance criteria, owners and monitoring signals that would have prevented the issue. In week three, apply the revised workflow to a small live or internal pilot and collect feedback from both researchers and operational users. In week four, compare the pilot with the previous process using time, rework, participant outcomes and data usability. Keep the changes that improve the evidence or reduce avoidable effort. Place the checklist and examples where the team works, and schedule a brief review after the next full study. Improvement becomes durable when it is attached to ordinary delivery rather than a one-time training session.