Users Don't Think in Tasks

The Wrong Unit

You have been designing flows. Task flows, user flows, onboarding flows. You have mapped every step, labeled every screen, measured every completion rate. You probably have a spreadsheet somewhere with time-on-task numbers and drop-off percentages by step. You have done the work of someone who believes the fundamental unit of design is the task.

It isn’t. Users don’t open your product to complete tasks. They open it because something in their life needs to change. They want to feel less anxious about money, or stay connected to people they love, or get something done so they can stop thinking about it. The task is just the toll road. The destination is something else entirely, and if your product doesn’t take them there, it doesn’t matter how smooth the road was. This is not a philosophical distinction. It determines what you build, what you cut, and why half of your well-designed features get ignored.

Goals Run the Show

In 2002, Edwin Locke and Gary Latham published a summary of 35 years of research on how goals drive behavior. Their conclusion was stark: conscious goals are the immediate motivational cause of most human action. Not habits, not instincts. Goals. As they defined it, “a goal is the object or aim of an action, for example, to attain a specific standard of proficiency, usually within a specified time limit.” The research showed that when people have clear, specific goals, their behavior organizes around reaching them. When they don’t, behavior drifts. Ryan and Deci’s self-determination theory adds the deeper layer. People aren’t just goal-directed. They’re 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 task-level needs. No one has ever felt a deep sense of competence from completing a dropdown menu. These needs operate at the goal level, at the level of what someone’s life looks like after using your product for six months. The problem is that design, as a profession, defaults to the task level. Task analysis breaks user behavior into discrete, observable actions. That is useful. It becomes a trap when task completion gets treated as the definition of success rather than a step toward it.

What the Milkshake Knew

In the 1990s, a fast-food chain hired Clayton Christensen’s research team to help them 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 had nothing to do with milkshakes. 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. The users weren’t buying a drink. They were solving a problem their morning had. The product team had spent years asking the wrong question. They had been optimizing for the task (buying a milkshake) when the goal was something else entirely: surviving a boring, solitary commute without stopping for breakfast. Those are completely different design problems. A thicker milkshake addresses the first. A more entertaining drive-through experience, or something that lasts longer, addresses the second. This is documented in Christensen’s Competing Against Luck and has since become one of the most cited cases in product strategy for one reason: it happens everywhere, all the time, and most teams never catch it because they are not looking at the goal level.

The Gap Between Completion and Value

Here is what makes this expensive. You can build a product where users complete every task and still churn at 60%. The tasks work. The goal isn’t being met. Users leave not because your onboarding is broken, but because what they wanted at the end of that onboarding, the change in their life, never arrived. This gap shows up in fitness apps where workout logging is smooth but people stop exercising. It shows up in budgeting tools where transaction categorization is fast but users still feel out of control of their finances. It shows up in project management software where every ticket can be assigned and every deadline can be set, but teams still feel disorganized. The tasks work. The goals don’t. 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 is not the same as 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 task is just the mechanism. When you design at the task level without anchoring to the goal level, you optimize the mechanism and leave the actual job undone. Users feel it even when they can’t articulate it. The product is fine. It just isn’t for them.

Goal Before Flow

The fix is not to stop mapping flows. Flows are useful. The fix is to 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. Make it concrete. Then look at your flow and ask a blunt question: does every step in this flow move the user closer to that sentence, or does it serve the product’s needs instead? Call this the Goal Before Flow check. Run it before any major design decision. Before you add a feature, ask whether it serves the goal. Before you remove one, ask whether users were depending on it to get there. Before you congratulate yourself on a 90% task completion rate, ask whether users got what they came for. The check works because it forces a perspective shift. It moves the design conversation from “how do users do the thing” to “why are they here at all.” Those are different conversations that produce different products.

What They Came For

Designers who work at the task level 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. The ones that failed: you guessed.