Synthetic User Research: A Protocol for Traceable Claims

Synthetic user research is a structured use of generated profiles and responses to explore research questions. It can produce hypotheses and expose assumptions, but simulated responses are not evidence of real behavior. A defensible protocol keeps that distinction visible from question to report.

Start by stating what the exercise can inspect, what it cannot establish, and how conclusions will be traced to inputs. The deliverable should help someone decide what to investigate next, not imply customer discovery has happened.

Frame a question with a bounded claim

Write the decision, uncertainty, and intended claim before configuring profiles. “Will customers trust us?” asks simulation to verify a human response. “Which visible claims lack explanation or support?” gives it something concrete to examine.

Define the unit of analysis: a page statement, interpretation of a billing term, or point in a journey. Do not shift silently between units. An unexplained statement is not automatically a trust problem; a generated concern is not a reason for abandonment.

Nielsen Norman Group recommends synthetic output for hypothesis-generating support, not replacement of research. Its discussion of unrealistic behavior explains why the protocol must constrain claims as well as tasks.

For definitions, see the synthetic users guide. Here, the focus is study governance rather than tool selection or biographies.

Specify the protocol before the run

Include the question, decision owner, materials, profile assumptions, task instructions, permitted exploration, stopping rules, analysis method, and follow-up plan. Record these before viewing output so success cannot quietly be redefined around a pleasing answer.

Identify what is supplied and what may be inferred. An idea has no observed page behavior. With a URL, record the relevant version or review date and available material. Do not imply exhaustive coverage of changing content.

In Cairo, exercises can begin with a URL or idea, use demographic, socioeconomic, and psychometric profiles, and inspect bounded website journeys. Views and reports organize output, but do not eliminate the researcher's protocol. Rosetta provides model context.

For the underlying system, use the existing technical evaluation framework. Do not duplicate its role inside every study.

Preserve the chain from material to claim

Separate four layers: source material, generated output, researcher interpretation, and follow-up. A page quotation belongs to the first. A profile's explanation belongs to the second. A proposed cause of confusion belongs to the third. An interview question belongs to the fourth.

Assign local identifiers so reviewers can work backward from statements to materials and tasks. These can be ordinary notes; do not assume a product automatically creates a complete audit trail. Retain surrounding context rather than isolating a convenient sentence.

Use evidence-matched verbs. “The page states” refers to content. “The simulation interpreted” refers to generated output. “We hypothesize” marks inference. “Customers believe” requires customer evidence and should not be a synthetic exercise's conclusion alone.

Keep contradictions. If one profile assumes inclusion while another cannot determine it, the disagreement may identify an unresolved question. Do not average competing interpretations into fictional consensus.

Hypothetical example: review a service guarantee

Hypothetical example, not a reported result: A home-maintenance marketplace reviews its guarantee page. The question is whether it explains eligibility, exclusions, and support steps, not whether homeowners trust the marketplace.

The protocol limits exploration to the page and relevant explanatory links. Profiles vary in assumed category familiarity. The task ends before requesting support or sharing personal information.

The researcher labels source S1: a sentence about covered work. Generated output O1 interprets it as covering all services. The researcher checks actual exclusions before making an inference.

If coverage remains unspecified, claim C1 says: “The reviewed material leaves this eligibility question unresolved.” It does not say homeowners misunderstand the guarantee. Follow-up F1 asks prospective customers to explain coverage during a moderated session.

If exclusions are clearly available within scope, record that too. The generated response may inspire a navigation question but cannot support missing-content claims. Traceability has prevented an attractive hypothesis from becoming an unsupported finding.

The study record should also include rejected interpretations. That provides a useful account of what the team examined and why a claim did not survive review, instead of presenting only plausible concerns that favor a redesign.

Review the report before sharing

• Identify evidence type for substantive statements.
• Make each input and task locatable.
• Keep assumptions distinct from customer facts.
• Preserve contradictions and unavailable information.
• Label generated quotations as simulated.
• Reserve market claims for appropriate evidence.
• Assign an owner and next step to consequential hypotheses.

For task construction, use the synthetic user testing guide. A consistent protocol still distinguishes generated contrasts from observed outcomes.

State limitations where decisions are made

Put limitations beside recommendations, not only in appendices. Explain generated output, assumed profiles, bounded environment, and absence of real transactions. If variants were compared, state this was not statistical A/B testing.

Traceability does not guarantee accuracy: a documented chain can contain mistaken interpretation. Shared model assumptions can generate repeated themes, and clean documentation cannot create independent human experience.

Recommendations should remain proportional: clarify a claim, prepare a task, investigate a contradiction, or gather evidence before deciding. A strong synthetic study makes the next research step inspectable without hiding the need for real people.

Next step: Explore your public page or product idea in Cairo, define one question and an audience, and use the simulated report to plan what to investigate next.