wiki › Affordances

Single-elimination stakes

Single-elimination stakes describe the do-or-die nature of every transition a user makes through a product: one inadequate handoff between steps ends the user's experience of everything after it. The user doesn't push through to see what's on the other side; they route around, give up, or substitute. A product with strong screens 1-5 and 7-30 but a weak handoff from 5 to 7 effectively has no screens 7-30 for most users, because those screens never got reached.

Definition

The property by which user progression through a route is binary at every transition — one inadequate transition eliminates every downstream step from the user's experience, regardless of how well-built those steps are.

Why progression is binary

Users don't keep going past an inadequate transition to see what's available later. A user at step N who finds nothing adequate to support the transition to step N+1 doesn't continue to step N+1 anyway and check what's there — they route around, give up, or substitute. The provider's path-shaping at step N+1 and beyond is never encountered, much less evaluated.

This is the forward consequence of hopscotch: if the user actively selects which affordance to incorporate at each step, then any step where no adequate affordance is available ends the user's engagement with the route. Investment in step N+k is conditional on transitional adequacy at every prior step. Spend on later steps pays off only when each earlier transition has been survived.

Well-built destinations, under-supported transitions

Single-elimination most often produces well-built destinations separated by under-supported transitions, not under-coverage of long stretches of route. A team that has invested in steps 1–5 and 6–30 but not in the transition from 5 to 6 has, from most users' lived experience, no steps 6–30 — not because they weren't built, but because they were never reached. The build effort exists on the team's side; from the user's side it sits behind an elimination point that wasn't passed.

Reachability is the local condition

Reachability names what makes a specific transition work or fail for a specific user at a specific moment — whether they have the energy, attention, skills, and other capacity to initiate the step. Single-elimination names what that local failure does to every step downstream. Reachability is the per-transition condition; single-elimination is the across-route consequence. Improving reachability at one transition isn't a local improvement; it's an unlock for whatever lies beyond it that affected users currently never see.

Example

A SaaS company's product has a polished first-invoice flow, a clean recurring-billing dashboard, and a sophisticated reporting suite. But the email verification step in the signup cohort's first session sends verification links that get stripped by a sizable slice of corporate email systems. Users who can't verify don't reach the invoice flow, the dashboard, or the reports. From the team's vantage, the product has four major surfaces. From those users' lived experience, the product is a verification screen that doesn't work.

See also