Skip to content

Guided Multi-Path Onboarding Flow

Workflow — instantiates Outcome-Attractor Pathway Design

Routes users or participants from different initial conditions through different supports toward the same activation or readiness state.

A Guided Multi-Path Onboarding Flow is the live, operational workflow that reads where a new participant is starting from and steers them down a route fitted to that start — different supports, different sequence, different defaults — all converging on the same activation or readiness state. Its defining move is entry-time routing plus in-flight support: unlike a document that lists which routes exist, this is the running machinery that actually assigns a person to a route and carries them along it. It reads the starting-state signal, applies a choice rule to pick the fitting path, and then supplies the affordances and nudges that keep that path pulling toward the goal. It is where the archetype stops being a design and becomes something a real user moves through.

Example

A project-management SaaS knows its new accounts arrive in very different states: a solo founder with an empty workspace, an ops lead migrating a spreadsheet full of existing projects, and an admin rolling the tool out to a forty-person team. A single linear tutorial serves none of them well — the founder is overwhelmed, the migrator is bored past the one thing they need, the admin can't find provisioning.

The Guided Multi-Path Onboarding Flow branches at entry. It asks two quick signal questions, routes the founder into a template-seeded quick-start, the migrator into an import wizard with field-mapping help, and the admin into a team-setup track with bulk invites. Each route offers its own progressive-disclosure supports[n1] — contextual tips, sensible defaults, a checklist that only shows the next relevant step — and all three funnel toward the identical "activated" state: a workspace with at least one real project, one teammate or client, and one completed task. The migrator reaches it by importing; the founder by building from a template; the admin by provisioning — same endpoint, three basins shaped to three starts.

How it works

  • Signal, then route. A short entry probe classifies the starting state; a choice rule maps that class to a route rather than making the user guess which onboarding they want.
  • Fit the supports to the route, not the average. Each route carries its own defaults, tips, and step sequence — the basin conditions that make this start's progress easy — instead of one generic set.
  • Converge on one activation definition. Every route is engineered to deliver the same readiness state, so branching never means branching the goal.
  • Nudge, don't force. Supports pull toward the endpoint (defaults, prompts, just-in-time help); the participant retains agency, which is what keeps a fitted route from becoming a rail.

Tuning parameters

  • Branch count — how many distinct routes the flow offers. More branches fit starts more precisely but multiply the flows to build, test, and maintain.
  • Routing signal cost — how much you ask up front to classify the start. Richer signals route better but add entry friction that can lose users before they begin.
  • Support intensity per route — how heavily each path scaffolds. Heavy support rescues struggling starts but can slow confident users and breed dependence.
  • Activation-state strictness — how demanding the shared readiness bar is. A high bar means real activation but a longer flow; a low bar activates fast but nominally.
  • Reroute openness — how freely a participant can switch routes mid-flow. Generous switching recovers mis-routes but can leave users churning between paths.

When it helps, and when it misleads

Its strength is reach without lockout: participants who would stall against a one-size path — the atypical start the tutorial never imagined — get a route built for them, so more of them cross into the activated state. Fitting the basin to the start is exactly how a destination "does the work" for a diverse population.

Its failure mode is mis-routing and the illusion of progress. A weak entry signal can drop a user onto the wrong route, where fitted supports actively push them away from where they needed to go, and a flow tuned to feel like progress can march users to a nominal "activated" flag they don't actually understand — motion mistaken for readiness. The classic misuse is letting one branch become the maintained "real" onboarding while the others rot into neglected dead ends, quietly recreating the single path the flow was meant to escape. The guarding discipline is to route on an honest signal, keep an easy mid-flow reroute, and define activation by a state the user can actually use rather than a step they merely reached.

How it implements the components

  • starting_state_diversity_map — the entry probe operationalizes the diversity map: the flow reads which start it is dealing with before doing anything else.
  • basin_condition_design — each route's defaults, tips, and sequencing are basin conditions, shaped per start to pull that trajectory toward activation.
  • pathway_choice_rule — the routing logic that maps a classified start to its fitting route is the choice rule in running form.

It does not enumerate and govern the full set of allowed routes as an authoritative register (admissible_pathway_set) — that is Admissible Pathway Catalog — nor verify that the activated state actually meets the standard (endpoint_equivalence_test), which is Endpoint Equivalence Test Suite's.

Editorial Notes

Form Classification

Form family: Protocol, Workflow & Routine

Rationale: Guided Multi-Path Onboarding Flow operates as a repeatable ordered procedure or handoff sequence that coordinates action because it routes users or participants from different initial conditions through different supports toward the same activation or readiness state.

Independent corroboration: The frozen evidence defines Guided Multi-Path Onboarding Flow as 'Routes users or participants from different initial conditions through different supports toward the same activation or readiness state', so its operative form is Protocol, Workflow & Routine.

Nearest alternative: Control, Automation & Runtime — Entry classification and route mapping may execute automatically, but differentiated supports and convergence form an onboarding workflow.

Review outcome: Independent reviewer agreement; medium confidence.

Origin Attribution

Primary origin: Human-Computer Interaction

Origin pattern: Cross-disciplinary synthesis

Present-day reach: Multi-domain

Rationale: UX onboarding and progressive disclosure developed branching support by initial user state.

Related originating lineages:

Review resolution: Both reviewers agree that human_computer_interaction is primary: UX onboarding and progressive disclosure developed branching support by initial user state. I retain education_pedagogy, organizational_management only as formative lineage, not as a list of later applications. I resolve origin_mode as cross_disciplinary_synthesis because the artifact joins distinct disciplinary contributions. I resolve domain_reach as multi_domain because it transfers across several fields but is not a domain-free primitive. Encyclopedia synthesis is true because the exact generalized packaging is an encyclopedia-authored combination or refinement.

Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.

Review outcome: Reconciled after independent review; high confidence.

Notes

[n1] Progressive disclosure is the UX practice of revealing options and complexity only as a user needs them. In a multi-path flow it is a basin condition: it shapes the immediate environment so the next step toward activation is the easy, obvious one for that route's starting state.