OSFA
OSFA is the single shared experience the offering serves when nothing more tailored has been built for what a particular user is trying to do. It's the common ground users fall back to when no better-fit version exists for their case.
Definition
OSFA (one-size-fits-all) is the shared, non-routed experience an offering serves when classification doesn't deliver a user to a built path.
The four functions OSFA serves
Under the framework's structural commitment, OSFA is retained for four specific functions:
- Fallback when no built path exists for the routed intent. Classification may produce a clean signal that maps to an intent category the team hasn't built a path for — either because per-path margin economics don't yet justify the investment, or because path-building hasn't reached that branch. The user lands in OSFA.
- Recovery when guessed intent is wrong. Intent detection is approximate. When the user's behavior reveals that the routed path doesn't match what they're actually trying to do, OSFA is the surface they fall back to while they reorient.
- Error and reset states. 404s, exits, "start over" actions, dead-ends. The shared landscape carries the user when the routed structure breaks.
- Common landscape vocabulary. The cross-path consistency layer — shared navigation, shared object model, shared visual language — that keeps paths cohering as a portfolio rather than fragmenting into disconnected experiences.
All four functions hold under ideal conditions, not only under implementation constraints. OSFA is structurally necessary even when team capacity and tooling aren't the binding factor.
Two ways OSFA gets deployed
The framework's structural commitment is OSFA-as-fallback: paths carry the bulk of the user experience and OSFA fills the four functions above. The implementation reality, when offering-as-object thinking dominates a team's commitments, is OSFA-as-default: OSFA carries the bulk of the user experience and paths get layered on as augmentation features.
The two differ on what role OSFA plays — tail or dog. Team-capacity and code-architecture constraints reinforce OSFA-as-default but aren't its root cause; teams committed to offering-as-paths prioritize routing and per-intent paths even with limited resources.
Example
A project management tool's sorting hat classifies arriving users into "freelancer billing clients," "agency tracking team capacity," and "internal team running sprints." Each classified intent routes to a path with intent-specific onboarding, sample data, and first-week prompts. A user whose answers don't classify cleanly — they checked options across multiple categories, or they skipped the questions — lands in OSFA: the generic blank workspace with the standard empty state and the default getting-started checklist. Same landscape every classified user sees in cross-path navigation, just without intent-specific augmentation on top.