Research operations workshop / 5 MIN READ
Keep the prototype’s simulated promise visible
Plan how prototype simulation is explained, operated and reported without creating false reliance.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-06
A prototype may use prewritten responses, manual actions or fictional records to explore an experience before the underlying service exists. Participants and decision-makers need an honest boundary around what is simulated so useful feedback does not become a claim about real capability.
What you will leave with: A prototype simulation map with participant disclosure and evidence limitations.
Use this when
- A research prototype includes behavior that is not implemented in the real product.
- A team manually produces responses during a concept session.
This is not authorization for deceptive research, a production-readiness assessment or permission to expose people to consequential decisions based on simulated output.
Map the real and simulated parts
GOV.UK recommends prototypes to explore designs before committing to a build. Document what the current prototype actually does and which parts are represented by a simulation.
Identify prewritten responses, manual operator actions, fictional data and non-working links. Explain which research question each simulated element helps explore. Avoid adding impressive behavior solely to make the concept attractive. If the idea depends on an unavailable capability, record that feasibility remains unresolved. A smooth research interaction does not show that the organization can deliver the same service reliably in production.
Agree an honest participant explanation
Tell participants they are using a prototype and explain the material boundaries relevant to consent and safe participation. Have the research ethics, privacy or other appropriate owner review any proposed concealment or incomplete disclosure before the study proceeds. Do not improvise deception to preserve realism.
Make clear when actions will not create real bookings, orders or service decisions. If a person may reasonably rely on an output, stop and clarify the limitation. Use fictional or approved sample information and keep the activity away from consequential medical, financial or other personal decisions. The participant should not leave believing the session has delivered a real service that does not exist.
Operate the simulation consistently enough to interpret
Prepare an operator guide describing permitted responses and the points where the researcher may intervene. Keep departures from the guide visible. A hidden operator’s improvisation can make the concept seem more capable or responsive than the planned design.
Record the actual prototype version and relevant operator actions alongside the participant’s response. Do not silently repair every confusing moment and then claim the design was easy to use. If the simulation breaks, explain what is happening appropriately and decide whether continuing will still answer the question. Preserve the difference between the designed behavior and the team’s live rescue.
Report the experience without implying technical proof
Describe what participants encountered and which reactions depend on simulated behavior. Separate interest in the proposed experience from evidence that its technical, operational or commercial delivery is feasible. Include relevant caveats next to the finding, not only in an appendix.
At the close, clarify outstanding misunderstandings about what was real and what remains proposed. Follow the approved research process for any concern raised by the simulation. Give the product or service owner the specific unanswered feasibility questions. The useful outcome is a grounded understanding of the concept’s experience, with the unbuilt parts still honestly identified.
Make the reasoning concrete.
A fictional research prototype appears to recommend a custom event plan immediately. In reality, a researcher selects a prepared response after seeing the participant’s choices.
Present the session as a working product demonstration
Opening: Let observers infer that automated planning already exists.
Hypothesis: The concept looks ready to sell.
Risk: Participant enthusiasm may be misused as proof of an unbuilt capability.
Document the simulation boundary
Opening: Explain the prototype appropriately and mark manual response selection in the research record.
Hypothesis: The team can learn about the proposed experience.
Risk: Automation quality and operating feasibility remain separate unanswered questions.
The research report describes reactions to the proposed planning interaction and discloses the manual behavior. The product owner receives feasibility questions rather than a claim that the service is ready for customers.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Simulation
Which behaviors are manual, fictional or not implemented?
Purpose
What question does each simulation help explore?
Disclosure
What must participants and observers understand?
Operation
How will operator interventions and deviations be recorded?
Claim
What conclusions would exceed the experience actually tested?
Watch for the wrong conclusion.
- Treating participant enthusiasm as proof of technical feasibility.
- Letting a participant rely on fictional service output.
- Hiding operator rescue from the research record.
Your next action
Map one prototype’s simulated behaviors and add a clear disclosure and reporting boundary for each consequential assumption.
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: Making prototypes →Primary government design guidance · Supports: Prototypes support exploration before committing to a build; the simulation disclosure and reliance safeguards are original editorial analysis.