User flow vs user journey: what each means, with goals, tasks and features

Five words, side by side #

The two words travel with three others: feature, task and goal. Teams mix them up because each one describes “what the user does” at a different size.

The definitions of feature and task come from the literature. A feature is “a prominent or distinctive user-visible aspect, quality, or characteristic of a software system” (Kang et al., SEI, 1990 · technical report). A task is “any activity that is usually observable and has a start and an end point” (Rosala, NN/g, 2020 · UX research firm). The names in the BookStack column are from featkpr’s records of that app; the flow is drawn below.

How a flow differs from a journey #

The Nielsen Norman Group puts the difference in the level of detail: “User journeys describe a user’s holistic, high-level experience across channels and over time. User flows zoom in to describe a set of specific, discrete interactions that make up a common user pathway through a product.” (Kaplan, NN/g, 2023 · UX research firm)

So the two answer different questions. A journey map asks why a person arrives, where they stall and why they leave, including the parts no screen of yours can see: the search that brought them, the colleague who recommended you, the email they ignored. A flow asks whether the product gets a person through one task, step by step, and what breaks on the way when the code changes.

That is why a journey rarely lives in a codebase and a flow always does. Every step of a flow is a screen or a request that exists in the app’s code, and you can walk it on a running copy.

Goals and tasks are not the same thing #

Filling in a form is a task. Registering for a service is the goal the task serves (Rosala, NN/g, 2020 · UX research firm). The distinction matters more than it looks, because tasks change every time the screens change and goals mostly don’t. A redesign that moves a button rewrites the task. The goal, delete the token so the old script loses access, stays the same.

A useful test: if you can say it as a click (“press Save”), it is a step. If it has a start and an end on the screen (“fill in the new-book form”), it is a task. If you would still want it done after a redesign (“publish the page”), it is a goal.

featkpr keys its goals on what changes in the app, not on the clicks. Each goal record names an object and the change made to it: the record “Delete the api token” is the object api_token with the change deleted, and a redesign that moves the delete button changes neither.

How featkpr uses the words: goals, features, flows #

featkpr maps a web app in three layers, smallest first:

• a goal is one thing a person gets done, keyed on what changes: an object and the change made to it;
• a feature is a named part of the app, read from its code, and it groups the goals kept on its routes;
• a module groups features by the part of the code they come from.

A goal sits inside a feature, and a feature inside a module. A flow is not a fourth layer: it is how a person moves through the app, screen by screen, and it ends on a goal. On BookStack featkpr holds 298 features in 13 modules, and its Flows board holds 149 flows ending at 89 features (20 Oct 2026).

featkpr says “flow” and never “journey” for a path inside an app, because a path through real screens is what it can read and show. Its flows are close to the Nielsen Norman Group’s user flows, with two differences. They are drafted from a crawl of a running copy of the app, not drawn by a designer, so each step is a screen that exists. And each one waits for a person to keep it or drop it before it counts.

Here is one real goal from BookStack, inside its feature and module, with a drafted flow that ends on it:

The same idea in featkpr’s app: a drafted goal and the real screens a person walks to reach it, left to right.

Every flow featkpr drafted for BookStack is in the library of flows, grouped by the goal it reaches. The goals are in the library of goals and the features in the library of features.

Which one should you draw? #

• A journey map when the question is why people arrive, stall or leave, including what happens outside the product. It belongs to research, marketing and service design.
• A flow when the question is whether the product gets a person through a task, and what a change to the code breaks on the way. It belongs to product, design and engineering together.
• A goal list when the team first has to agree what counts as done, before anyone argues about screens.
• A feature list when you need to know what exists at all. The feature inventory guide shows what to put on one, with a template.

Most teams need all four at different times. The mistake is using one word for all of them.

Mix-ups worth avoiding #

Calling every flow a journey. A diagram of six screens inside one product is a flow. Calling it a journey hides the part a journey map is for: what happens outside.

Writing tasks as goals. “Fill in the form” is a task. When a list of goals reads like a list of clicks, it will need rewriting at the next redesign.

One flow per feature. A goal often rests on several features. On BookStack, the goal “Update the permissions” rests on routes for books, chapters, pages, shelves and the API. A flow can pass through several goals on its way, too.

Treating a user story as a flow. A user story (“as an editor, I want to delete a token so that the old script loses access”) states a goal and its reason. It names no screens. The flow is how the product answers it.

Where featkpr fits #

featkpr drafts the flows and goals of a web app from its code and its real screens, and a person keeps or drops each one. The user flows service is that work for your app; the library is that work on BookStack, in the open.

How this guide was written and checked, and where its numbers come from: how we write and check. Found an error? Report a correction.