HCD harmful? A Clarification

Many have had difficulty with my article in Interactions magazine Human-Centered Design Considered Harmful.

(Hah, that's an understatement! There must be 500 comments and blogs posted about it.)

In particular, I failed to make clear what I meant by "Activity-Centered Design," (ACD) and how it differs from "Human-Centered Design" (HCD).

Some people seem to think I have completely renounced everything I have said in the past. Others simply think I have gone quite loony. And others have rushed in to explain what I must have meant.

I do not think this to be any change in what I have advocated. Rather, I see all my work as part of a coherent pattern, moving toward products and services that truly fit human needs.

The problem, however, is that HCD has developed as a limited view of design. Instead of looking at a person's entire activity, it has primarily focused upon page-by-page analysis, screen-by-screen. As a result, sequences, interruptions, ill-defined goals — all the aspects of real activities, have been ignored. And error messages — there should not be any error messages. All messages should contain explanations and offer alternative ways of proceeding from the message itself.

These changes are only possible if one takes a larger view — an activity-centered view.

None of this is present in today's HCD. It should be, but it isn't.

By focusing upon the tasks to be done and on the activities that are actually carried out, I hope to broaden people's views of what should be considered.

Now, there has been one change, more in emphasis than substance. There has been far too much emphasis on individual people, trying to model them, trying to build fascinating scenarios and "personas." I think much of this work misplaced, irrelevant, and potentially harmful if it diverts the limited time and resources of the design team away from matters that can actually help.

Are Scenarios and Personas worthless? No, scenarios are great for marketing. Personas are great for communication: see my essay "Ad-Hoc Personas & Empathetic Focus". But for great design, design for the activity.

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.

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.

I believe that we should increase our focus upon the tasks and activities to be accomplished and reduce the focus on these cute but design-empty scenarios and personas. If I truly understand the task, if I truly understand the mixture of tasks that together comprise an activity, and if I truly understand the interruptions, ill-defined nature of most people's approach to their activities, then I can provide far better support than if I focus upon the training, age, or personality of the individual people who might use it.

Design for the activity and the rest will take care of itself, better than the reverse — design for the person, without proper support for the activity.

Some day I hope to be able to expand upon this analysis.

Does this help?