experimental-design

name

experimental-design

description

Apply experimental-design whenever the user needs to test a hypothesis, validate an assumption, or determine whether something actually works. Triggers on phrases like "how do we test this?", "design an experiment", "what would prove this?", "set up an A/B test", "how do we validate this hypothesis?", "what's the right control?", "is this result significant?", "what sample size do we need?". Use proactively when decisions rest on untested assumptions — designing the test before collecting data prevents post-hoc rationalization.

Experimental Design

Core principle: Define what counts as evidence before you collect it. A well-designed experiment eliminates alternative explanations so only one conclusion survives. Pre-registration is the firewall between discovery and self-deception.

---

When to Use This Skill

• A decision hinges on a factual claim no one has tested
• Someone proposes an A/B test but hasn't defined success criteria
• epistemic-mapping flagged a dangerous assumption needing validation
• A team is about to invest resources based on an unvalidated hypothesis
• Prior experiment results were inconclusive and need a better design

---

Core Methodology

Step 1: Convert the Question into a Testable Hypothesis

Take the vague question ("Does feature X improve retention?") and produce a precise, falsifiable hypothesis pair.

• H₀ (null): The default — no effect. "Feature X has no effect on 30-day retention."
• H₁ (alternative): The claim. "Feature X increases 30-day retention by ≥ 2 percentage points."

State the direction. One-tailed when you only care about improvement; two-tailed when you also need to detect harm. Default two-tailed unless strong prior reason to expect one direction.

If a hypothesis isn't falsifiable — if no observable outcome could disprove it — rewrite it.

Step 2: Identify Variables

• Independent variable (IV): What you manipulate. One per experiment unless factorial design with sufficient power.
• Dependent variable (DV): What you measure. The metric closest to the outcome you care about. Proxies introduce noise.
• Controlled variables: Held constant across conditions.
• Potential confounders: Could vary between groups and affect DV independently. List them all, then design controls (randomization, stratification, matching, statistical control).

Step 3: Select the Experimental Design

Randomized Controlled Trial (RCT / A/B test) — Gold standard. Random assignment eliminates confounding. Use when you can randomize and have sample size.

Quasi-experimental — When randomization is impossible:

• Difference-in-differences: Treated vs. untreated, before vs. after. Requires parallel trends.
• Regression discontinuity: Exploit a threshold (users above/below a score cutoff). Strong validity near cutoff.
• Interrupted time series: Track outcome over time, look for level/slope change at intervention.

Within- vs. between-subjects — Within-subjects eliminates individual differences but introduces order effects (counterbalance or use washout periods).

Factorial — Multiple IVs to detect interactions. Multiplicatively more sample. Only when interactions are the research question.

State what design you picked and why alternatives were rejected.

Step 4: Determine Sample Size

Run a power analysis before data collection:

• Minimum detectable effect (MDE): Smallest practically meaningful effect — not statistically significant, practically significant.
• Significance level (α): False positive rate. Standard 0.05; lower for high-stakes.
• Power (1-β): Probability of detecting a real effect. Standard 0.80; use 0.90 for critical experiments.
• Baseline rate: Current DV value (e.g., retention = 40%).
• Variance estimate: From historical data or pilot.

If required n exceeds feasible: accept larger MDE, run longer, or redesign for a more sensitive metric. Do not run underpowered and hope.

Step 5: Pre-Register Success Criteria

Before any data collection, commit in writing to:

• Primary metric: The one metric that determines success.
• Secondary metrics: Should move if hypothesis is correct (and shouldn't if effect is spurious).
• Success threshold: Effect size and significance required.
• Guardrail metrics: Must not degrade (error rate, latency, revenue).
• Decision rules: "If primary improves by ≥ MDE at p < α, ship. If guardrail degrades by > X%, halt."
• Stopping rules: Early stop conditions (sequential testing with adjusted thresholds) and extension criteria.

Pre-registration prevents the garden of forking paths — redefining success after seeing results.

Step 6: Mitigate Threats to Validity

Internal validity (did X actually cause Y?):

• Selection bias → randomization or matching
• Attrition → intent-to-treat analysis
• Maturation → control group captures natural change
• History → concurrent control experiences same external events
• Instrumentation → consistent measurement across conditions

External validity (does it generalize?):

• Sample representativeness → stratified sampling
• Temporal validity → run through full business cycles
• Setting validity → test in production, not staging

Construct validity (are we measuring what we think?):

• Metric validity → does the DV capture the construct?
• Treatment fidelity → did participants actually experience the treatment?

For each threat, state mitigated / partially mitigated / unmitigated and what that means for interpretation.

Step 7: Specify the Analysis Plan

Define the exact analytical approach before data arrives:

• Statistical test: t-test, chi-squared, regression, Bayesian — matched to data type and design.
• Multiple comparison correction: Bonferroni, Holm, or FDR if testing multiple hypotheses.
• Segmentation plan: Pre-specified subgroups (new vs. returning users). Exploratory segments labeled as such.
• Sensitivity analysis: Re-run under different assumptions (excluding outliers, different attribution windows).
• Effect size reporting: Practical effect size (Cohen's d, relative lift, absolute difference) alongside p-values. Statistical without practical significance is noise.

Step 8: Define Timeline and Resources

• Ramp-up plan: Traffic allocation schedule (5% → 20% → 50%).
• Minimum run duration: From sample size and business cycles.
• Maximum run duration: When to call it.
• Resource requirements: Engineering, data pipeline, stakeholder reviews.
• Go/no-go checkpoints: Dates to review interim data for safety (not for peeking at results).

---

Output Format

🎯 Research Question

• Plain language: [What are we trying to find out?]
• H₀: [Null — no effect]
• H₁: [Alternative — specific, falsifiable, directional]

📋 Variables

Role	Variable	Measurement
Independent (IV)	[What we manipulate]	[How treatment is defined]
Dependent (DV)	[What we measure]	[Metric definition and source]
Controlled	[Held constant]	[How controlled]
Confounder	[Potential threat]	[Mitigation approach]

🔬 Design

• Type: [RCT / quasi-experimental / observational — with variant]
• Justification: [Why, and what alternatives were rejected]
• Assignment: [Random / stratified / threshold — mechanism]

📊 Sample Size

• MDE: [Minimum detectable effect]
• Power: [Target]
• α: [Significance level]
• Required n: [Per group and total]
• Feasibility: [Can we reach this? If not, what changes?]

✅ Pre-Registered Criteria

• Primary metric: [name] — success if [condition]
• Secondary metrics: [List with expected direction]
• Guardrail metrics: [List with degradation thresholds]
• Decision rule: [If...then ship / halt / extend]
• Stopping rule: [Early stop conditions]

⚠️ Threats to Validity

Threat	Category	Severity	Mitigation	Residual Risk
[Threat]	Internal	[H/M/L]	[Approach]	[What remains]
[Threat]	External	[H/M/L]	[Approach]	[What remains]
[Threat]	Construct	[H/M/L]	[Approach]	[What remains]

📊 Analysis Plan

• Test: [Statistical test with justification]
• Correction: [Multiple comparison method, if applicable]
• Segments: [Pre-specified subgroups]
• Sensitivity: [Alternative analyses]

📋 Timeline and Resources

• Duration: [Min — max]
• Ramp plan: [Traffic allocation schedule]
• Checkpoints: [Go/no-go review dates]
• Resources: [What's needed]

---

Thinking Triggers

• "What would we need to observe to abandon this hypothesis?"
• "If we saw this result, could we explain it without the hypothesis being true?"
• "Are we testing what we think we're testing, or a proxy?"
• "What's the smallest effect that would actually change our decision?"
• "If we can't randomize, what's the best natural experiment available?"
• "What would a skeptic say is wrong with this design?"

---

Common Traps

• Post-hoc hypothesis: Formulating after seeing data. If you discover something unexpected, label it exploratory and design a new experiment to confirm.
• Underpowered experiments: Running too small to detect realistic effects, then concluding "no effect." Absence of evidence is not evidence of absence — especially with n=47.
• Peeking: Checking daily and stopping when results look good. Inflates false positives dramatically. Use sequential testing with adjusted thresholds for interim looks.
• Surrogate metrics: Measuring clicks when you care about retention. The surrogate must have a validated causal link to what matters.
• Multiple testing without correction: Testing 20 metrics and celebrating the one significant at p=0.05 is finding noise.
• Ignoring practical significance: A statistically significant 0.01% improvement at p=0.03 isn't worth shipping if engineering cost exceeds value.

---

Example Applications

Trigger	Application
"Does this new onboarding flow improve activation?"	A/B test, randomized assignment, activation rate as primary DV, power analysis for minimum lift, pre-registered 14-day window
"We think the bottleneck is the database"	Observational study: latency with and without DB load, control for concurrent traffic, pre-register the latency threshold that confirms
"Should we invest in this training program?"	Difference-in-differences: trained vs. untrained teams' productivity before and after, controlling for team composition and project difficulty
epistemic-mapping flagged "We assume users prefer simplicity"	Within-subjects preference test: simple and complex versions (counterbalanced), measure task completion + stated preference, pre-register which signal wins on conflict