Don Norman: Designing For People

Nielsen Norman Group

Activity-Centered Design & Scenarios

In your article Human-Centered Design Considered Harmful you say that "activities are not the same as tasks," but are scenarios the same as tasks?

In my line of work (web application design & development) our personas are 80% scenario descriptions (one likely scenario per activity) — which we then break down into user needs, tasks and system features.

From these we then build task-flow diagrams to describe an "activity" (e.g. registration), followed by prototyping.

Your article is making me rethink this process, but I am keen to know where scenarios fit into the picture!

Scenarios are usually specified at too high a level to be of much value in the design of specific interface elements. Task-flow diagrams are important.

Tasks are situations with a single, well-specified goal, such as "respond to this email." Activities are larger groupings, comprised of multiple tasks that fit together, such as "get caught up on the day's correspondence" which means reading email, responding, looking up information, sometimes to copy and paste into emails, checking calendars, and other associated, related tasks. Thus, to me, "registration," from your example above, sounds more like a task than an activity.

To me, error analysis is the sweet spot for improvement. Usually, designers do think of the order in which activities will be done. But they seldom think properly about what should be done when the person encounters problems, or when the situation is novel.

It doesn't matter whether the analysis is called task analysis, task-flow diagram, scenario, activity analysis, or activity-flow diagram. What does matter is that it be a detailed analysis of the steps a person might follow when things go wrong. What should you tell the person? What choices should you offer?

What would the person wish to do in each of the situations?

It is relatively easy to design for the perfect cases, when everything goes right, or when all the information required is available in proper format. Good design, however, will handle the unexpected situation, when there are special cases, when the information is entered incorrectly or incompletely, or correctly. but in the wrong location or wrong sequence.

This is where the difference arises between a pleasant experience and a frustrating one.

One way to do this is to look at all the error messages, determine why they might arise, and redesign so that they either never appear, or if they might, that they are transformed into assistance. Not "help" which tells the person what should have been done, but "assistance" which offers the proper action and makes it so easy to proceed that the person might deliberately type incomplete information to get the guidance.

Remember: the "perfect" behavior seldom arises. Almost ever situation is a special case of one sort or another. So design for the special cases, design to eliminate error messages.