Actualized route
An actualized route is the step-by-step record of what one user actually did to get from start to finish on a particular try, not the journey in the abstract or some minimum version of it. The full trace: which buttons they clicked, what they skipped, where they Googled the answer instead of reading the docs, where they bypassed the product entirely and used something else.
Definition
The specific instance of a route that unfolded — the cumulative trace of steps a user actually made and executed during a particular traversal.
How the trace accumulates
Each step the user executes appends to the actualized route. The trace grows as the user advances: each step lands them in a new now-state, they select again, act again, and the trace lengthens. Steps of both kinds — internal-capacity moves and hopscotches onto external affordances — appear in the trace. The actualized route is the empirical record of every step the user took.
Different users from the same starting state produce different actualized routes, because selection at each step depends on what's reachable, what the user reads in available signals, and their runtime conditions. The same user across attempts can produce different actualized routes too, as the affordance landscape and their own now-state shift between attempts.
Relation to route and critical route
Route is the structural primitive — the shape of a trajectory through state-space. Critical route is one specialization: the minimum-dependency-structure between selected endpoints, defined causally. Actualized route is the other specialization: a specific traversal as it occurred, defined empirically.
Critical route is what's necessary in principle. Actualized route is what happened in fact. The two typically don't match. An actualized route routinely includes steps not on the critical route (auxiliary moves, lookups, detours, social checks) and may skip steps the critical route requires (where the user found a workaround or eliminated mid-traversal). The gap between them is diagnostic.
What aggregate actualized routes reveal
A single actualized route is one user's trace. Patterns across many users' actualized routes are the data that Following the tracks reads against the path's theorized commitments. Where users converge on a step the team didn't predict, where they hopscotch past an affordance the team featured, where drop-off concentrates at a specific transition, where users route outside the offering entirely — these are all properties of actualized routes in aggregate.
Provider intuition about what users should do is the prescriptive default; actualized-route data is the descriptive correction. The patterns reveal which moments matter and which affordances fit each moment — the input that path-shaping decisions are supposed to follow from.
Example
A user signs up for a project management tool. Their actualized route: signup form, email verification, landing on the empty workspace, closing the onboarding modal without engaging it, opening the help docs in a new tab, returning to the workspace, creating a project, creating three tasks using keyboard shortcuts learned from the docs, switching to a separate browser tab to copy a teammate's email, returning to invite the teammate, closing the tab.
That exact sequence is one actualized route. A second user from the same starting state might engage the onboarding modal, never open the docs, create tasks via UI buttons, and invite a teammate by importing from a connected calendar. Same offering, same starting state, two different actualized routes. The team's design work depends on observing many such traces and reading what they reveal — that the modal is being closed (so it isn't route-efficacious at that step), that opening docs in a new tab is a real step a meaningful share of users take (so path-shaping should account for it), that the keyboard-shortcut route runs faster than the UI-button route among users who find it.