Top Tasks and Top Outcomes: the two lists to write before you start designing
Most design work goes wrong long before anyone draws a screen. It goes wrong in the gap between “here are the requirements” and “let’s start designing”, where a long list of features quietly stands in for an understanding of what users are actually trying to do. Two short lists close that gap. Write them first, agree them with your team, and almost every later decision gets easier. I call them Top Tasks and Top Outcomes.
List one: Top Tasks
A Top Tasks list is the small number of things people overwhelmingly come to your product to do, ranked. The method isn’t mine; it comes from Gerry McGovern’s Top Tasks work. The underlying truth is one every designer should tattoo somewhere visible: a handful of tasks dominate, and the long tail barely registers.
When you gather every possible thing a user might want to do and then ask real users to vote on what matters, the results are lopsided every time. A few tasks soak up the overwhelming majority of the attention; dozens of others get almost none. That pattern is gold, because it tells you where to spend your design effort and, just as usefully, where not to.
To build the list:
- Gather a comprehensive set of candidate tasks from research, support tickets, analytics, and stakeholders. Phrase them as things users do, not features you have.
- Strip out duplicates and internal jargon until each item is a clear, comparable task.
- Get a representative group of real users to rank or vote. Don’t let the loudest person in the building stand in for the market.
- Read off the top few. Those are your top tasks. Everything else is the long tail.
The discipline is in what you do next: you design for the top of that list with everything you have, and you refuse to let the tail dictate the core experience.
List two: Top Outcomes
Tasks describe what users do. Outcomes describe why: what has to be true afterwards for the task to count as a success. It’s an easy distinction to skate over and an expensive one to miss, because you can help someone complete a task and still leave them worse off.
“Upload a file” is a task. “The right data is in the system, the user trusts it’s there, and they didn’t have to do it fifty times by hand” is an outcome. Design only to the task and you’ll produce an upload button that technically works. Design to the outcome and you’ll ask about the fifty files a day, the formats, the error states, and the confidence the user needs that it worked. That is a completely different, and far better, design.
A Top Outcomes list pairs your top tasks with the results that matter, for both sides:
- The user’s outcome: the real-world job that’s now done, and how they know it’s done.
- The business outcome: what the organisation needs to be true (adoption, fewer support calls, a completed transaction) without which the work won’t be funded twice.
Hold the two in tension. An interface that serves the business while quietly failing the user is the express route into design debt.
Why both, and why first
These two lists do something a requirements document can’t: they give you a fixed point to design against, and a shield when delivery pressure arrives.
This is the same instinct behind test driven design: agree what success looks like before you build, so success isn’t quietly redefined as “whatever we shipped”. When a manager wants to cut the one feature that actually serves a top task, a shared, agreed list is your evidence. When you write usability test tasks later, your top tasks are the tasks you test. The lists keep paying out across the whole project.
It’s tempting to skip them. Lists feel slight next to a roadmap, and there’s always pressure to be seen drawing screens. But a beautiful design of the wrong thing is still the wrong thing, and you’ll have spent your most expensive hours making it. Two short lists, agreed before you start, are the cheapest insurance in product design.