Map the Task Before the Screen

Why does an app built to help students study so often start by asking them what to study? Why do so many screens ask for things people don’t know? (Your prescription number. Your routing number. The model number printed somewhere on the back of the fridge.)

Usually the screen isn’t the problem. The task was never mapped.

Mapping it is called task analysis: a close look at what people do to reach a goal, step by step, from their side of the screen. It’s an old idea, and an often skipped one. Back in 2014, Larry Marine wrote that “pretty much everyone skips the critical step that guarantees success: task analysis.”[1] Now that AI can build a screen in an afternoon, I’d bet it gets skipped even more.

I co-founded Phloe, a biology study app for iOS, and I design it, so I’ll use it for the examples. Here are seven steps to do a task analysis well.

1. Define the problem before the product.

Most teams are sure they already know the user’s problem. It’s their job to, after all.

But what a team knows best is how its product works. That’s a different map from how people get the job done, and it’s easy to confuse the two.

So start with the task itself: how people reach their goal today, and what it takes. Look for two things as you go: where they need support, and which steps could disappear.

And map the task, not your app. Trace how people use your current screens and you’ll end up polishing the detour.

You can’t remove a step you never wrote down.

2. Watch people before you analyze them.

Task analysis sits on top of user research. Personas tell you who you’re designing for, scenarios tell you when and why they show up, and storyboards show the moment in context. (I wrote about personas that last in my last piece.)

The tempting shortcut is a whiteboard session: gather the team and map the task from memory. It feels efficient. But you know your product too well, and you’ll draw its path instead of the user’s.

So watch a few people do the task. A few is enough; this isn’t a census.

Better yet, watch people who don’t use your product at all. For Phloe, that means students studying with no app: flashcards, a highlighter, a group chat the night before the exam. (The screener survey I’m running for Phloe right now is about exactly that: how students prep for exams.)

Study the task, not your app.

3. Write down five things.

For each task you watch, write down five things[2]:

• Trigger: what gets people to start.
• Desired outcome: how they know they’re done.
• Base knowledge: what they’re expected to know when they start.
• Required knowledge: what they actually need to know to finish.
• Artifacts: the tools and information they use along the way.

Imagine Maya, a first-year student in intro biology, getting ready for her first exam. (She’s invented; the app isn’t.) Her five things might read like this:

Look at the gap between base knowledge and required knowledge. Maya knows when the exam is. Knowing what to review, and when, is a skill of its own, and it’s one students are still building.

That gap is the design problem, and the product should close it. Don Norman calls this putting knowledge in the world, so it doesn’t have to live in people’s heads.

Every fact the product knows is one Maya doesn’t have to.

4. Break the goal into four to eight subtasks.

Pick one persona and one scenario. What’s their goal, and what’s driving it? Maya wants to do well on Friday, because a bad first exam is hard to climb out of.

Write the goal at the top, then break it down. That’s the “hierarchical” in hierarchical task analysis: a goal, the subtasks under it, and the steps under those. The method “originated in human factors,” as Peter Hornsby notes[3]: John Annett and Keith Duncan described it in 1967[4] as a way to design training for complex jobs. It has been breaking big jobs into smaller ones ever since.

The Interaction Design Foundation suggests four to eight subtasks[2]. With fewer, you’re probably hiding steps. With more, you’ve probably mixed levels. Here’s Maya:

Then take each subtask a level down, but only as far as it helps.

Start at the goal. Stop when the steps stop teaching you anything.

5. Mark who does what.

Now draw it, one subtask at a time, as a flow: what the system shows, what the person does, what the person decides.

Then mark every step as one of four kinds, a color each if you’re using sticky notes:

• What the person has to do.
• What the product could do instead.
• The tools and information the person needs.
• Open questions about the task.

Give the decisions the most attention. They’re where the task demands knowledge, and where people often don’t have it.

Walk the flow as your persona and flag every point where the task needs something they’re unlikely to know. On Maya’s map, one tool note says “syllabus,” and a question sits at “Plan the days”: how would she know how to space it out?

A map full of user steps is a product full of homework.

6. Work backward from the outcome.

A first map shows how people get the job done today. The point is to change it: remove steps, or hand them to the product, so people reach the outcome with fewer steps and less to know.

Start at the desired outcome and walk backward, asking of each step: does the person have to do this, or could the product?

If Phloe asks for the exam date once and knows which units the course covers, it can plan the days itself. It knows which questions Maya missed, so it can pick what she reviews and bring it back before she forgets. Walk it back far enough and the whole task shrinks to one question, the one on Phloe’s home screen: Ready for today’s lesson?

Choices count as steps, too. Where you can, make them for people, with sensible defaults and suggestions. Sheena Iyengar and Mark Lepper’s well-known studies[5] found people drawn to bigger assortments but more satisfied with what they chose from smaller ones.

So Maya shouldn’t have to pick from every unit and every study mode. Give her the next lesson, with a way to pick another.

Every step you hand to the product is one nobody has to take.

7. Write the story, then check it.

A diagram shows what happens. It can’t show why.

So write the story beside it: a short narrative of the task that focuses on the whys. Maya studies late, after her shift, because it’s the only quiet time she has, which is why the app should never assume she has an hour. That sentence explains more about the task than any sticky note.

Then check your work with someone who wasn’t part of the breakdown but knows the task well: an instructor, a tutor, the stakeholder who owns the flow. They’ll catch the step you skipped because you’ve done it too many times to notice.

A map nobody questions is a map nobody checked.

Subtract before you add.

Task analysis sounds like documentation. It’s closer to subtraction.

The goal was never a bigger diagram. It’s a shorter task: fewer steps, fewer decisions, less for people to know.

So watch the task before you design the screen. Watch people who don’t use your app at all. Write down what they know and what the task needs them to know. Then take steps away until only the ones that matter are left.

Adding a feature is easy.

Taking away a step takes a map.