Dani Weidner Open to Staff roles

Feature / Interaction design

A/B testing for people who run experiments for a living

The platform needed built-in A/B testing, and the people using it run experiments for a living. Customers were faking holdouts with invisible variants, which caused bugs and support tickets. I designed the flow against 17 acceptance criteria and caught a metrics issue in a live session before release.

In one minute

SituationExperimentation UI is unforgiving: traffic has to sum correctly, control has to be unambiguous, and the interface has to work with one variant or twenty.
What I didSpecced every edge case with engineering before handoff, replaced the invisible-variant workaround with a real holdout, and reviewed the flow live with customers who test daily.
OutcomeA setting applied at the wrong level, which would have corrupted the metrics, was caught in session and went to engineering before release.

Prototype. Set up variants, split traffic, add a hold-out, choose the dismissal level, and review blocking issues before launch. Fictional brand and data. Open full screen ↗

Scope17Acceptance criteria written with engineering before handoff
Decision1–20Variants, with the interface adapting at each count
Decision2 of 3Customers preferred campaign-level settings, which set the default

Decisions

Decision 01 / 04

Spec every edge case before engineering starts

I wrote the edge cases into the acceptance criteria: entry states for one versus many variants, traffic that doesn’t sum to 100 percent, the rule that the last variant can’t be deleted, and exactly what control means.

Why: so engineering could build without coming back with questions.

Decision 02 / 04

Replace a workaround with a real holdout

Customers needed a slice of traffic that sees nothing, and with no real feature they were faking one with invisible variants, causing scroll-lock bugs, CSS conflicts, and support tickets. I turned that workaround into requirements for a dedicated holdout that renders no creative at all, which keeps measurement clean.

Decision 03 / 04

Review it live with people who test for a living

Sessions with three enterprise customers who run experiments daily confirmed the core interactions and caught one subtle issue: a setting applied at the wrong level that would have corrupted the metrics. It went to engineering as a spike before it could ship.

One variable at a time: creative or settings, never both.Customer experimentation practice, validated in session
CONFIRMED CAUGHT + FIXED DESIGNED TO CRITERIA A FULL SET OF ACCEPTANCE CRITERIA, WRITTEN FIRST THE A/B TEST FLOW TRAFFIC LOGIC, LOCKING, AN UNAMBIGUOUS CONTROL INLINE TRAFFIC EDITING LOCK BEHAVIOR SPLIT TRAFFIC EQUALLY REVIEWED LIVE, BEFORE RELEASE WITH CUSTOMERS WHO RUN TESTS FOR A LIVING LIVE CUSTOMER REVIEW CORE INTERACTIONS CONFIRMED IN SESSION ONE SUBTLE ISSUE CAUGHT, FIXED PRE-RELEASE SHIPPED
Fig. Designed to acceptance criteria, reviewed live, one issue caught before release
Decision 04 / 04

Let the split decide the default

Customers split on whether dismissal settings belong at the campaign or variant level. Instead of imposing one opinion, it became a configurable setting, with campaign level as the default because 2 of 3 customers preferred it.

Next / Case 04
Setting the conventions a whole product runs on