Empathy-First Experiments

What it is

Empathy-First Experiments is a lightweight framework for improving experiment quality before a test is designed.

It helps teams identify assumptions, upstream expectations, user risks, evidence sources, metrics, guardrails and decision rules before they write a hypothesis.

The problem it solves

Too many experiments start with a proposed interface change and work backwards into a justification.

The result is usually a tidy test ticket with a weak spine: unclear user risk, vague evidence, a shaky metric and a hypothesis that says little more than "we think this will increase conversion".

Empathy-First Experiments slows the team down before the test is built, so the work starts with belief, risk and evidence instead of theatre.

The framework steps

1. Name the experiment

   Define the moment, page, feature, audience and intended outcome.

2. Run an assumption audit

   List the assumptions being treated as fact and define what would prove them wrong.

3. Scan upstream signals

   Look at what users were told before arrival: ads, snippets, reviews, social, email, marketplace copy or AI summaries.

4. Check human evidence

   Use support tickets, feedback, sales notes, session replays, survey verbatims or short user conversations.

5. Write the hypothesis in belief language

   Frame the test around perceived risk, moment of doubt, behaviour and evidence.

6. Sanity-check the metric

   Clarify what the metric represents: belief, clarity, confidence, friction or something else.

7. Define the decision rule

   Decide what counts as a win, what counts as inconclusive, and when to stop or reverse.

Use the 10-minute preflight

Before writing the hypothesis, the framework asks teams to slow down and answer the questions that usually get skipped.

1. What assumptions are we treating as fact?

2. What would prove those assumptions wrong?

3. What upstream messages shaped user belief?

4. What human evidence do we have?

5. What risk is the user trying to avoid?

6. What do they need to believe to continue?

7. What metric are we using, and what does it actually represent?

8. What guardrails stop this becoming a dirty little conversion trick?

9. What will we call a win?

10. What will make us stop or reverse?

The preflight is designed to expose weak reasoning before it becomes a neat-looking test ticket.

Hypothesis format

The framework uses belief language so hypotheses are not just interface guesses with a metric stapled on.

If we reduce [perceived risk] at [moment of doubt] by [change], then [behaviour] will improve because [reason grounded in evidence].

A better hypothesis explains what the user is worried about, where the doubt appears, what will change, what behaviour should move and why the team believes that mechanism is plausible.

Hypothesis upgrade

Not every experiment is testing the same kind of problem. The framework gives teams three stronger hypothesis patterns depending on what needs to be learned.

Worked example: checkout drop

Lazy diagnosis: Users abandon because checkout is too hard.

Empathy-first diagnosis: Users arrive expecting fast delivery and easy returns, but checkout introduces uncertainty, surprise costs and vague conditions.

User risk: Surprise delivery cost, returns hassle and regret.

Moment of doubt: Cart to checkout entry.

Better hypothesis:

If we reduce perceived risk around delivery and returns at checkout entry by showing clear delivery dates, costs and a plain-English returns summary, then checkout completion will improve because uncertainty and surprise-cost anxiety will drop.

Guardrails:

• Refunds
• Returns
• Cancellations
• Support contacts

Decision rule: Win if checkout completion improves without guardrail harm. Stop or reverse if returns, cancellations or support contacts spike.

The point is not to decorate checkout with trust badges. The point is to test whether uncertainty, not interface effort, is what is damaging confidence.

What this prevents

A stronger experiment starts before anyone opens the testing platform.

• Experiments based on stakeholder preference
• Hypotheses that merely describe an interface change
• Metrics that do not map to the real user risk
• Post-rationalised wins
• Trust-damaging uplifts
• Conversion theatre disguised as evidence

Who it is for

• Experimentation teams
• UX researchers
• CRO specialists
• Product teams
• Content and journey teams
• Anyone tired of "we think this will increase conversion" masquerading as strategy

Why it matters

Good experimentation is not just about changing a page and watching a metric move. It is about making the reasoning visible before the test starts.

This framework helps teams avoid post-rationalised experiments, weak hypotheses, proxy metrics and conversion theatre dressed up as evidence.

How this connects to C.O.R.P.S.E

C.O.R.P.S.E Triage identifies where trust, clarity or coherence is breaking. Empathy-First Experiments turns that diagnosis into a testable hypothesis with evidence, guardrails and decision rules.

1. Diagnose

   Find the trust failure with C.O.R.P.S.E.

2. Translate

   Turn the finding into belief, risk or contradiction.

3. Test

   Design a focused experiment with metrics and guardrails.

4. Learn

   Interpret the result without pretending every uplift is truth.

C.O.R.P.S.E finds the rot. Empathy-First stops the next test becoming decorative theatre.