Data Nexus

Product and interface

User flow

The ordered path a person takes through a product to complete one goal, including what happens when it goes wrong.

Also called Пользовательский сценарий

01/What it means

A user flow is written per goal, not per screen: “return an item”, “add a second driver”, “pay an invoice”. It names the entry points, the decision at each step, the data the system needs at that point, and the exits — success, abandonment, and every error state.

The error states are the part usually missing and the part that decides the experience. A flow that documents only the path where everything works has described the demo, not the product; most of the support load and most of the abandonment lives in the branches nobody drew.

It is also the cheapest artefact in a build. Disagreements that would cost weeks in code are resolved in an afternoon on a flow, because a flow makes the missing decision visible: who is allowed to do this, what happens if they are half way through, what does the system already know.

02/What people get wrong

A flow made of screens multiplies as edge cases appear, because each new condition needs a new screen. A flow made of the states the system can occupy stays the same size and covers the cases nobody thought of yet. Model the states; the screens fall out of them.

Who does this

A definition is free. Being answerable for the figure it produces is the part that is bought, and this term is a working part of the engagements below.

UX, UI and user flows
Model states, don’t multiply screens.
Next

The definitions are the easy part. Whether the figure on your dashboard was computed this way is a different question, and usually the more expensive one.