Reachability
Reachability is whether the user, in the state they're actually in, can take the next step toward what they're trying to do. It depends on whatever that step happens to need: energy, attention, decisiveness, skills, the right assets, motivation, and so on. Each step has to be reachable from where the prior step actually left them, not from where the team imagines users start out.
Definition
The user's capacity, at a moment in their timeline, to initiate the next step of their pursuit.
Reachability is user-side capacity
Reachability lives on the user's side. It's about whether the user, in the state they're in right now, has what they need to take the next step. The offering's presence, the affordances available in the environment, the absence of obstacles — those are separate conditions that compose with reachability but don't constitute it.
The same user encountering the same step at two different moments can have reachability in one and not the other. After a clean prior step, they might have momentum, the right context loaded, and the decisiveness to act. An hour later, having context-switched, they may have none of these — and the step isn't reachable even though nothing about the offering changed.
One condition, many factor-types
Whether the user can initiate the next step depends on whether the necessary factors are present at that moment. Those factors include energy, attention, trajectory, decisiveness, assets, skills, companions, absence of obstacles, and signal-continuity from prior affordances, among others. None of these gets categorical privilege; each is a precondition that can fail.
The framework groups them for working convenience — material-shaped factors (assets, information, skills, context) tend to be time-invariant within the user's current state; motivation-shaped factors tend to be time-variant and signal-dependent — but the grouping is didactic, not structural.
Each step is a reachability check
Each sub-transition on the critical route must be reachable from the state produced by the prior sub-transition. The question to ask at every step-to-step transition: can a user in the state produced by step N initiate step N+1 using what step N gave them, plus what they already had, at the moment all relevant factors are present? If the answer is no, the path stalls there — even if subsequent steps are correctly specified.
Reachability is what makes a big change possible by making each local change achievable. The paperclip-to-house upgrade illustrates: the end state is far from the start state, and a single transition between them isn't reachable. The actual transition required many intermediate states, each close enough to the prior state that the next trade was viable.
Distinct from reachable affordances
Reachable affordances are the affordance-side complement: the slice of the affordance landscape currently engageable from the user's now-state. The user with reachability picks among reachable affordances; the two compose at hopscotch but are each independent preconditions. A user with reachability might or might not engage any reachable affordances — their step might use only internal capacity. A user without reachability can't engage reachable affordances regardless of what's available.
Failure eliminates everything downstream
Reachability failure at a transition isn't a local stall. The user evaluating affordances at step N who finds the transition to N+1 unsupported doesn't continue to N+1 anyway to see what's there. The whole downstream sequence is eliminated from that user's experience.
This makes reachability gaps disproportionately costly. A single broken transition wipes out all the work the offering has done to support steps beyond it.
Example
A signup cohort member just past email verification is prompted to "invite your team." The assets the step requires — teammates' email addresses — aren't on hand in the state the user just landed in. They could leave the flow to dig them up, but doing so breaks the session; most don't return.
The step isn't reachable from where the user is, even though the prompt is in front of them and the underlying action is straightforward. The failure is in the assets factor-type: the prior step didn't deliver, and the user didn't bring, what this step requires to be initiable.