Path
A path is what a team deliberately builds for users showing up with one particular goal: the screens, prompts, help, walkthroughs, emails, and anything else shaped to support that pursuit.
Definition
A path is the provider's deliberate route-efficacious affordances for a specific intent.
Four distinct things: landscape, offering, path, route
The path sits inside a four-way structural distinction the framework relies on for evaluating provider work against user trajectory.
- Affordance landscape: the totality of intent-aligned affordances currently in existence — provider-built, third-party, user-external, substitute. Most of it is outside the provider's control.
- Offering: the provider's complete affordance output. The app, the materials, the integrations the provider supplies into the landscape.
- Path: a narrower slice within the offering — the affordances the provider has deliberately shaped to support a specific intent.
- Route: the user's actual trajectory through the landscape. Where the user hopscotched, what they incorporated, what they bypassed.
Providers shape paths. Users take routes. The path doesn't determine the route; it shapes the landscape the user navigates. Different users with the same intent produce different actualized routes, and the same user across attempts will too, as conditions and affordance availability change. This is what makes path design strategic rather than prescriptive.
How the user encounters a path
The path's whole-object existence is provider-side. From the user's vantage, the path shows up only at the moments of route-step traversal — what's reachable, recognizable, and initiable at the moment they're at this step. This is encounter-moment adequacy: the path is evaluated locally, step by step, not as a comprehensive object.
A path that's comprehensively shaped but has an affordance gap at encounter-moment X fails at X. A path that's improvisationally assembled but has the right affordance available at every encounter-moment succeeds. Building more affordances doesn't constitute path investment unless those affordances land at the moments users actually need them.
Paths are intent-specific
A path is shaped for a specific intent. Two users showing up with different intents ought, structurally, to encounter different paths — different starter content, different next-step nudges, different surfaced affordances. The framework's structural commitment is per-intent paths as primary work; implementation reality typically deploys OSFA-primary-with-paths-augmenting — a default path carrying the bulk of the experience, with intent-specific augmentations layered on.
Example
A project-management SaaS shapes a path for the signup cohort arriving with intent to set up a first project: starter templates surfaced in the empty state, an in-app checklist of opening actions, sample data pre-loaded to edit, an email sequence nudging the user to invite a teammate. That's the path — the provider's deliberate affordances for that intent.
The route is what a particular user actually did: opened the empty state, dismissed the template picker, pasted in tasks from their existing spreadsheet, switched to a YouTube tutorial to figure out keyboard shortcuts, came back, set up the project with a different sequence than the path anticipated. The path shaped the landscape; the route is what the user navigated through it.