A sequence of screens and interactions a user follows to complete a specific task or goal.
A user flow is the sequence of screens and decisionsDecisionStrategyA recorded decision with context, rationale, and consequencesView reference → a person moves through to get something done, drawn with its branches and dead ends visible. It maps the path, not the pixels, which is what makes it useful: you can see where a journey forks, where it can fail, and where a user might fall out, before a single screen is finished.
The flow inherits two older lineages. One is the engineering flowchart, standardised in the mid twentieth century to diagram a process as connected steps and decision diamonds. The other is the taskTaskProduct SpecificationA unit of work within a story or epicView reference → analysis of early human-computer interaction, which decomposed a goal into the ordered operations a user performs to reach it. Screen design absorbed both: a flow is a flowchart whose nodes are interface states and whose branches are user choices.
As the discipline settled, practitioners drew a sharp line between two artefacts that look alike. A task flow shows the single, linear path that every user takes through one task, useful when the task is done the same way by everyone. A user flow is broader: it admits branches, multiple entry points, and the different routes real people take, including the ones that end in failure. Confusing the two produces flows that are either uselessly idealised or impossibly tangled.
The other persistent distinction is from information architecture. Information architecture organises what exists, the hierarchy, navigation, and labelling of content. A user flow runs on top of that structure and traces how a person moves through it over time. One is the map of the territory; the other is the route taken across it.
A SaaS team has a 40 percent drop-off during signup and no agreement on why. A designer maps the actual user flow: trigger is "clicked Start free trial", and the steps run email, verification, workspace setup, invite teammates, first project. Drawing it exposes the failure state nobody had named, a verification email that takes ninety seconds to arrive while the screen offers no way forward. The flow makes the gap obvious and gives the team a place to put the fix, a holding state with a resend option. The success state ("created first project") and the failure state ("abandoned at verification") are now explicit properties of the flow, so the analytics team knows exactly which two events to instrument.
user_flow_maps_user_journeyuser_flow_routes_through_screenIn the Unified Product Graph, user_flowuser_flow_routes_through_screenuser_flow_targets_personauser_flow_requires_featureuser_flow_validated_by_observationtrigger, success_state, and failure_state properties make the flow testable, not just illustrative.
Type-specific fields on BaseNode
triggerstringInitiating event
stepsstring[]Ordered steps
success_statestringSuccessful completion
failure_statestringFailed completion
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
4 phases — initial: draft · template: PUBLISHING
13 edge types connected to this entity.
product_navigated_via_user_flowservice_blueprint_contains_user_flowdesign_system_encompasses_user_flowuser_flow_routes_through_screenuser_flow_contains_customer_journey_stageuser_flow_targets_personauser_flow_requires_featureproduct_onboards_via_user_flowuser_flow_maps_user_journeywalkthrough_maps_user_flowproduct_enables_flow_user_flowuser_flow_validated_by_observationdesign_concept_realised_as_user_flow