Users Don't Think in Tasks

TL;DR: Goal-setting theory shows that people organize their behavior around outcomes, not interface tasks. Users do not care about completing your flow unless it gets them closer to the change they actually want.

You have been designing flows: task flows, user flows, onboarding flows. You have mapped every step, labeled every screen, measured every completion rate. Once you spend enough time looking at steps, screens, and drop-off points, it gets very easy to start thinking the step is the real unit of design. It usually is not.

Users do not open your product because they care about completing tasks. They open it because something in their life needs to change. They want to feel less anxious about money, stay connected to people they love, or get something done so they can stop thinking about it. Sometimes they just want to send the invoice, pay the bill, book the trip, and get back to their day. Your flow only helps with one small part of that bigger goal. The task is just the mechanism. What they care about is what changes for them once it is done.

Goals matter more than tasks

In 2002, Edwin Locke and Gary Latham published a summary of 35 years of research on how goals drive behavior. Their conclusion was clear: conscious goals are the immediate motivational cause of most human action. When people have clear, specific goals, their behavior organizes around reaching them. When they do not, behavior drifts.

Richard Ryan and Edward Deci ’s self-determination theory adds the deeper layer. People are not just goal-directed. They are organized around three fundamental psychological needs: autonomy (I am in control of my actions), competence (I am getting better at something that matters), and relatedness (I am connected to other people). These are not screen-level needs. Completing a dropdown menu is not the kind of thing people experience as meaningful progress in itself. These needs sit above the task level.

Design defaults to the task level. Task analysis breaks user behavior into discrete, observable actions. That is useful. It becomes a trap when completion gets treated as success rather than as one step toward something bigger.

The milkshake study showed this

In the 1990s, Clayton Christensen’s research team was hired to help a fast-food chain sell more milkshakes. The standard approach would have been to ask customers what they wanted in a milkshake: flavor, thickness, price. The team did something different. They spent a day in the restaurant watching when milkshakes were purchased and by whom.

What they found pointed past the milkshake itself. Nearly half of all milkshakes sold left the building before 9am, purchased by people driving alone. The researchers followed up. What job, they asked, were these people hiring the milkshake to do? The answer was the commute: a long drive, one free hand, something to occupy the time that was also filling enough to last until lunch. The milkshake was slow, it lived in the cupholder, and it demanded almost no attention. People were not just buying a drink. They were solving a morning problem.

The team had been asking about the drink. The users were trying to solve a commute problem.

Completion is not the same as value

You can build a product where users complete every step and still leave. The mechanics work, but the goal is not being met. Users leave not because your onboarding is broken, but because the change they wanted in their life never arrived.

This gap shows up in fitness apps where workout logging is smooth but people stop exercising. It also shows up in budgeting tools where transaction categorization is fast but users still feel out of control of their finances. You see it in project management software too, where every ticket can be assigned and every deadline can be set, but people still feel disorganized. The product works at the task level. The outcome people came for still does not show up.

Nielsen Norman Group ’s task analysis framework is explicit about this distinction: a task is an observable activity with a start and an end point, and it differs from a goal. Filling in a form is a task. Getting approved for a loan is a goal. The goal is what the user hired the product to do. The form is just the mechanism.

Start with the goal

Do not stop mapping flows. Flows are useful. Just name the goal before you draw the first box.

Not the user’s task goal. Not “complete checkout” or “create an account.” Their life goal. What is different about their life if your product works? What specific thing are they trying to change, avoid, or achieve? Write it down in one sentence and make it concrete. Then look at your flow and ask a blunt question: does every step move the user closer to that sentence, or does it mostly serve the product’s needs?

Run that check before any major design decision. Ask whether each feature serves the goal, not just the flow. Then ask whether your 90% completion rate means users actually got what they came for. That question gets skipped more often than it should.

Designers who stay at the task level can build products that work and still fail. The features are there. The flows complete. The users leave anyway, and nobody in the post-mortem can explain why because every metric looked fine.

Every flow you have ever designed was built on top of a goal you either understood or guessed at. When the work failed, there is a good chance the guess was the weak point. That is not unusual. It is normal.