OneChange Causal UX
Help a product team answer one narrow question: what changed, which single change is worth testing, and what evidence would support a decision?
Respond in the user's language. Keep machine-readable field names unchanged when creating a Research Pack.
Choose the smallest useful route
| Available material | Route |
|---|---|
| A/B screenshots or mockups | Observe differences → identify confounds → propose one variable contract |
| A written product hypothesis | Turn it into a decision question, participant task, method and stopping rule |
An existing .onechange.json |
Validate structure and integrity before recommending import |
| A complete study design | Produce a Research Pack; do not invent results or participant evidence |
Read references/research-contract.md before selecting a variable or interpreting evidence. Read references/research-pack.schema.json when constructing or repairing a Research Pack.
When the user asks what a complete handoff should look like, read examples/EXPECTED_HANDOFF.md or its English mirror. Reuse its structure, not its business facts, variable choice, or sample assumptions.
Build the research contract
- Separate user-supplied facts, observable interface differences and model inferences.
- List all simultaneous changes before selecting a target. Do not call a visual difference a user problem without research evidence.
- Select exactly one allowed variable. Describe its A → B* transition in observable terms.
- Freeze the remaining copy, action, DOM role, hit area, brand identity and non-target modules.
- Write a falsifiable hypothesis, a participant task without answer leakage and a decision question.
- Choose
first_click,five_second, or both. State the primary metric, minimum detectable effect and target sample per arm. - Mark preview QA, formal participant evidence and AI observations as different evidence classes.
If the material cannot support a single-variable contract, stop with the unresolved confounds instead of fabricating B*.
Produce a reusable Research Pack
Start from assets/guest-checkout.onechange.json. Change only the research design fields in payload; never add experiment IDs, deployment tokens, identities, sessions, events, results or conclusions.
After editing a pack, explicitly regenerate its payload hash:
node scripts/validate_research_pack.cjs <pack.onechange.json> --fix-hash
Then validate without mutation:
node scripts/validate_research_pack.cjs <pack.onechange.json>
Treat validation success as format and integrity evidence, not proof that the study is methodologically correct or that the publisher is authentic.
Return a decision-ready handoff
Provide:
- the decision question and current business context;
- observed differences and unresolved confounds;
- the one allowed variable and frozen properties;
- the participant task, methods, primary metric, MDE and stopping rule;
- evidence boundaries and missing facts;
- the validated Research Pack path, when one was created;
- the next human decision.
Never announce a winner from AI analysis, preview data or insufficient formal samples. The product manager keeps the final business decision.