Plan a round of simulations
A prediction of how a modelled audience behaves in a specific situation. A user research simulation asks them a set of questions. A user journey simulation puts them through an interface and records what they do.
-
Describe what you want to explore. No brief or question list needed. The opening message here was:
How do UK SMEs think about their customers' experience of POS? Let's do some discovery.
-
Review the plan before anything runs. The agent planned two simulations rather than one, because the question has more than one consequence worth predicting: what merchants believe their customers feel at checkout, and which improvements they would rank and pay for. It selected the audience and asked before running.
-
Ask for anything it missed.Optional A whole simulation is added by asking:
Could we add another simulation focused on loyalty features? Maybe some identity feature questions too.
The questions inside a planned simulation work the same way. Ask the agent to reword question 12, change its answer options, add five more, or drop the ones you do not need.
-
Or edit it yourself.Optional Open a planned simulation to see the survey, question by question, with its answer options, and change any of it by hand.
flowchart LR Q["`**Question** How do UK SMEs think about their customers' experience of POS?`"]:::question Q --> S1["`**Simulation** · Understand your audience What merchants believe customers feel at checkout`"]:::simulation Q --> S2["`**Simulation** · Prioritise features Which improvements they would pay for`"]:::simulation Q -.->|"added on request"| S3["`**Simulation** · Understand your audience Loyalty and identity at the counter`"]:::simulation
One question produced two simulations. The third was added by asking for it.
Read one synthesis across all of them
One report across every simulation in the round: a summary, recommendations citing the predictions behind them, and the questions the round did not answer. It also records where simulations disagree.
-
Run them. They run in parallel and take a few minutes.
-
Read the synthesis first, not the individual results. Three simulations produce three sets of results. The synthesis reads across all of them:
UK SMEs overwhelmingly see in-person customer recognition as revenue-critical (97.9% agree), but the path to capturing it is blocked by two compounding friction points: 70% say asking for details at checkout feels awkward and slows queues, and 75.4% strongly agree customers would feel uncomfortable knowing card taps build a visit profile. The clearest commercial signal is that 85.9% would very likely enable a loyalty feature requiring no extra hardware or checkout steps, and 87.5% prefer it built directly into Stripe Terminal over a third-party tool.
Demand was not the problem. Both obvious ways to capture it, asking at the counter or profiling silently, are ruled out by something the merchants said.
-
Open the recommendations.Optional Each one cites the predictions behind it.
-
Read the open questions.Optional Six of them: what the round could not settle. This is the backlog for the next round, and three of these become round two's simulations.
-
Export the synthesis. For whoever, or whatever, works on it next.
Apply the findings to the work
-
Copy or download it. Copy the markdown straight to your clipboard, or download it as a markdown file or a PDF.
-
Hand it to whoever writes the next version. That can be a person. Here it is Claude, given the exported findings and a PRD written before any of this:
I will paste a bunch of findings from some discovery I did around Stripe Terminal. I'm working on an idea for a loyalty feature. Apply the findings to the PRD to update it and improve it.
-
Review what changed. The findings mostly confirmed the existing design. The document grew from 135 lines to 158:
- The background now opens with the demand stats, and a new subsection states the limits of the evidence: a UK sample against a US-first launch, merchant-side rather than shopper-side, and simulated.
- A fifth goal, prove ROI in-product, because the sceptical segment makes dashboard analytics a retention requirement rather than reporting.
- A new P0 requirement for shopper-facing consent messaging on screen and receipt, with copy variants as a Phase 1 A/B test. The consent language and its opt-in rate is the biggest remaining unknown, and now a structured experiment rather than a guess.
- Offline behaviour added to the core flow, because recognition cannot be part of the payment path.
- Two sequencing changes: wallet-token handling stopped being an optimisation and became a hard gate for UK launch, and the EU DPIA moved from phase three into phase one.
Run the next round
A set of simulations and the synthesis across them. Rounds map to stages of the work: versions of a spec, iterations of a design. Starting a new round leaves the previous one in place, with its own simulations and its own synthesis.
-
Upload v2. Add the improved version of the PRD to the project:
let's do further simulations to explore additional unknowns and validate this plan
-
A new round is created. Round one stays where it is, with its own simulations and its own synthesis to go back to.
-
Check what it planned from the document. Four simulations: which consent wording wins, whether shoppers are comfortable with card-tap recognition, how pricing affects adoption, and whether Stripe is trusted with customer identity against loyalty specialists.
Two of those run against a consumer audience rather than the merchants. That is the PRD's own caveat being acted on: it recorded that the 75.4% discomfort figure was merchants predicting shopper feelings, so round two asks the shoppers directly.
flowchart LR S1["`**Simulation** · Understand your audience What merchants believe customers feel at checkout`"]:::simulation --> SY S2["`**Simulation** · Prioritise features Which improvements they would pay for`"]:::simulation --> SY S3["`**Simulation** · Understand your audience Loyalty and identity at the counter`"]:::simulation --> SY SY["`**Synthesis** · round one 15 recommendations · 6 open questions`"]:::synthesis SY --> PRD["`**PRD version 2** demand evidence · P0 consent requirement · ROI goal · evidence limits stated`"]:::document PRD --> N1["`**Simulation** · Test messaging Consent wording on the reader screen`"]:::simulation PRD --> N2["`**Simulation** · Validate a concept Shopper comfort with card-tap recognition`"]:::simulation PRD --> N3["`**Simulation** · Assess risk of a change Per-transaction fee vs bundled pricing`"]:::simulation PRD --> N4["`**Simulation** · Compare positioning Trust in Stripe vs loyalty specialists`"]:::simulation
Round one's three simulations produced one synthesis, the synthesis produced version two of the PRD, and version two produced round two's four simulations.
Nobody planned that sequence in advance. Each step set the subject of the next, and each question was more specific than the one before it.
Repeating the loop
Rounds can continue indefinitely: version three, version four, each with its own simulations and synthesis. Once there is something to click, a round can run user journey simulations instead, pointed at a Figma prototype, a preview URL or staging, so the build you are about to ship is tested before you ship it.