wiki › Paths

Following the tracks

Following the tracks is the discipline of shaping the product around what users actually do, not around what the team thinks they should do. The team watches real trajectories: what users picked up and used, what they skipped past in favor of their own workarounds, where they got stuck, where they bypassed the product entirely. Those observations drive the next round of design work.

Definition

A discipline that produces route-familiarity through observation of how users actually traverse a transition, with path-shaping decisions following from that familiarity rather than from internal planning.

Two preconditions

The discipline only operates when two conditions hold simultaneously:

  1. Framework-internal rigor on what observed trajectories get sequenced against — the critical route, the next-hopscotch selection criteria, the path's theorized best-route-knowledge. Without that rigor, the team observes user behavior and reads it through whatever frame they happen to have (most often offering-as-object), producing interpretations the framework's apparatus would have read differently.

  2. Actual timeline observation of user trajectories — analytics, qualitative interviews, session replays, behavioral data over time. Without observation, the tracks are invisible regardless of framework rigor, and the team falls back on internal planning because there are no tracks to follow.

Both are required. A team with rigor but no observation has apparatus with no data to apply it to. A team with observation but no rigor has uninterpretable data.

What the tracks reveal

Tracks register both the trajectory itself and which affordances along it the user found route-efficacious. Two patterns carry particularly direct diagnostic weight:

  1. Hopscotch-past behavior — users observably routing around a provider-supplied affordance at a step in favor of their own defaults. Direct evidence that the affordance isn't route-efficacious at that step: either it isn't outperforming the alternative the user has access to, or it isn't present-and-recognizable at the moment of need, or both. The provider doesn't have to ask users why; the trajectory is the diagnostic.

  2. Drop-off concentrated at a specific transition — evidence about that transition's inadequacy, plus silence about every step downstream of it. Users eliminated at transition X teach the provider nothing about steps beyond X. The asymmetry is per-transition rather than per-step-range, which makes the diagnostic actionable: concentration points are typically a small set, and finding them is high-leverage even when the surrounding steps are well-built.

Descriptive fidelity at the design level

Provider intuition about what users should incorporate is the prescriptive default. Following the tracks is the descriptive correction. The user's actual trajectory across the affordance landscape is the data, and the design work is shaping the landscape so future users find better-fit affordances at the moments the data has flagged.

The temporal frame belongs to the user, not to the trail. The provider observes traversals across calendar time, but at each moment what the provider sees is one user's present-tense step. Aggregate trail-shape emerges from many users' present-tense steps, and the discipline operates on those steps rather than on the trail's own historical durability.

Example

A SaaS team ships an in-app tutorial to teach new users how the product works. Session replays show most users dismiss the tutorial within a few seconds and then head to the public docs site or search YouTube for a walkthrough. The hopscotch-past pattern is the diagnostic: the tutorial isn't outperforming the user's own default at the "figure out what this does" step. Useful redesign options follow from that diagnosis — integrate the docs more visibly inside the app, accept that a video walkthrough is the route-efficacious affordance and link to one, or remove the tutorial layer entirely.

See also