Research operations workshop / 5 MIN READ
Rehearse the session before asking for someone’s time
Run a practical readiness check across people, materials and technology.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-06
A session can fail even when the interview guide is thoughtful. A rehearsal catches broken access, confusing task materials and unclear responsibilities before a participant has to work around them.
What you will leave with: A session readiness record with a fallback for each essential dependency.
Use this when
- A study uses a new prototype or remote meeting setup.
- Several people or tools must work together during sessions.
A colleague’s rehearsal does not replace research with relevant participants or establish product usability.
Walk through the actual route
GOV.UK session-planning guidance includes preparation, recording arrangements and a practice session. Rehearse the precise participant route rather than checking only the facilitator’s view.
Start with the invitation and follow the joining instructions on an appropriate device. Check whether a participant needs an account, download, permission or code that the invitation does not mention. Open the correct prototype version using the same access level they will receive. Avoid making the rehearsal effortless through administrator privileges that participants will not have. Mark any support the participant would unexpectedly need before the intended research task starts.
Exercise each person’s responsibility
Have the facilitator, note-taker and technical support person perform their real roles. Practice admitting a participant, explaining recording, starting a task, taking a break and closing. If one person covers several roles, look for moments when responsibilities collide rather than assuming they can manage everything simultaneously.
Confirm where questions from observers arrive and who handles scheduling messages during a live session. The facilitator should not have to abandon a participant to search for a replacement link. Use fictional data in all materials, and remove internal comments or account details that do not belong in a participant-facing view.
Prepare an honest fallback
For each essential component, write what happens if it fails. If the prototype is unavailable, can the question still be explored with printed scenarios, or would that become a different study? If recording fails, decide whether approved note-taking is sufficient. Do not quietly change methods and later combine the sessions as if nothing differed.
Prepare a simple message for pausing or rescheduling. Preserve the participant’s agreed compensation and explain their options without making them troubleshoot your system. A fallback is useful only when it preserves the research purpose and respects the participant, not merely when it keeps the calendar full.
Freeze a ready version and log deviations
Record the versions of the guide, prototype and information sheet approved for the round. Keep late edits visible so the team can understand which sessions used which material. A necessary repair should not be hidden just because the study has started.
After rehearsal, assign each issue an owner and a resolution needed before the first session. Separate genuine blockers from minor conveniences. At the end of each live session, record operational deviations briefly and review whether they affect interpretation. This makes the study’s actual conditions inspectable without turning the research notes into a technical incident log.
Make the reasoning concrete.
A fictional facilities platform plans remote sessions on a prototype. In rehearsal, the participant link requests a company-only login and the observer chat appears in the shared window.
Fix issues during live sessions
Opening: Keep the scheduled start and ask each participant to work around the problems.
Hypothesis: The team avoids rescheduling preparation time.
Risk: Access problems consume participant effort and expose internal discussion.
Repair and rerun the route
Opening: Create the approved participant access path and move observer messages to a private view.
Hypothesis: A second rehearsal verifies the practical fixes.
Risk: The team must protect enough preparation time to complete the check.
The first session remains blocked until participant access and screen sharing are verified. The team prepares a rescheduling message rather than treating a broken setup as useful customer evidence.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Route
Can someone follow the invitation with participant-level access?
Roles
Who facilitates, records, supports and handles scheduling?
Fallback
Which failures allow a valid alternate method, and which require stopping?
Version
Which guide and prototype are approved for this round?
Deviation
Where will actual differences from the plan be recorded?
Watch for the wrong conclusion.
- Testing only from an administrator account.
- Using real customer data to make a prototype look realistic.
- Combining changed methods without recording the difference.
Your next action
Run the complete joining and first-task route with a colleague who has never seen your setup. Fix the first blocker before recruiting further sessions.
Sources & scope
The workflow, worksheets and hypothetical examples are original editorial analysis. Sources support only the identified principles. No measured business results or named human reviewer are claimed.
- GOV.UK Service Manual: Plan a round of user research →Primary government research guidance · Supports: Practice sessions and recording arrangements; the operational workflow is original editorial analysis.