Task Flow

Design work traveled screen by screen for a long time. A designer handed over twelve screens, and the engineer could tell what each one was without knowing what order they came in. Filenames like share_01 and share_02 imply a sequence, but whether 02 follows 01 or splits off from it lived only in the head of the person who drew them.

Handoff meetings kept circling the same question. Ask what comes after this screen, hear that it depends on the situation, then spend an hour trying to enumerate the situations. The engineer eventually picked an order based on their own judgment, and review caught the wrong order late enough that the work had to be redone. Two weeks of building, thrown out over a sequence nobody had written down anywhere.

Task flow solves that by switching the unit from screen to task. Pick one thing the user is actually trying to do and lay it out from start to finish in a single line. Branches get stripped out on purpose. The point is counting how many steps it takes, and a diagram with every exception drawn in is a diagram you can't count.

It starts with writing the task as a verb phrase. "Share a document with a teammate" describes something a user finishes. Write "the sharing feature" instead and nothing decides where one task ends.

Four steps follow.

1. Fix the start and end points. The start is a document already open; the end is the recipient holding a link. Without both, whether to draw the login comes up as an argument every time.
2. Cut the middle into user actions. Actions, not screens — that distinction does the work. If one screen is where you type a name, pick a permission, and hit send, that screen is three steps.
3. Write three things on each step: which screen, what the user does, and what the product answers with. Drop the third and nothing catches the stretch where a click produces no visible response until it reaches production.
4. Count the steps. Share button, pick a teammate, pick a permission, type a message, send — five steps, and that number becomes the material for the next conversation.

Finding what to cut follows a pattern. Look for steps where the user already knows the answer and steps where most people leave the default alone. If nine out of ten leave the permission at view-only, that step can fold into a default and open only for whoever wants to change it. That is how five steps become three. Neither move removes a capability — the teammate who needs a different permission still gets there, one tap further in.

The moment you need a branch, the task flow is the wrong container. Covering where the path splits on login status and where a missing payment method blocks progress means moving to a user flow. A task flow has to stay one line to keep working as a counting tool.

Four places account for most of the use.

The first is deciding the first task in onboarding, the process of getting a new user settled into the product. When the first task anyone meets is seven steps long, half of them leave partway through. You can only choose what to fold once the steps are counted, and the first task is the one place where a single extra step costs the most users.

The second is agreeing on order before drawing wireframes — the plain layout drawings that carry structure and nothing decorative. Draw the frames before settling the order and you finish six screens before learning that two of them aren't needed.

The third is scripting a usability test. The method hands a participant one sentence describing a job and watches where they stall, so the steps have to be split in advance for anyone to record which one stopped them.

The fourth is comparing against competitors. Count how many steps the same task takes in a rival product, set the two counts side by side, and the conversation runs on numbers instead of impressions. Nine steps against four is an argument that survives a room full of opinions.

"The sharing task flow is five steps right now. Can we get it to three?"

A proposal to cut the number of steps one task costs.

"This should be a user flow, not a task flow. There are three branches in it."

Pointing out that the scope no longer fits one line, so the tool has to change.

"The task flow doesn't say what the product responds with, so the loading state got left out."

Raising the problem that a step with no product response written on it comes out empty in the build.

At Pagedeck, Noa reached for this first when redesigning document sharing. Writing out the existing path produced six steps: share button, search for a teammate, select the teammate, pick a permission, type a message, send. With all six lined up, usage logs showed the message field was being used on 12 percent of shares.

Mia asked about the permission step. The logs said 87 percent left it at the default of view-only, so permission and message both folded away behind an expander for whoever wanted them, and six steps became three. Theo took those three lines and planned the build order from them without asking how many screens there would be.

The most common misreading is that fewer steps automatically means better design. It's a tool for counting steps, so driving the count down looks like the goal. But the easiest way to shorten the count is piling several decisions onto one screen, which turns three steps into three steps holding six decisions. People can only hold so much at once, and plenty of teams have watched the drop-off rate rise on the shorter version — the count went down and completions went down with it. Two numbers deserve counting: the steps, and the decisions inside each one.

Treating a finished diagram as finished design is the other mistake. A task flow has no exceptions in it, so the file that exceeds the size limit, the missing permission, and the dropped connection are all absent. Hand it over without filling those in and the engineer decides for themselves, which is how one product ends up with a different error message on every screen. The usual fix is a second pass over the same line, marking what can fail at each step.