January 30, 2006

Activity-Centred Design vs. Human-Centred Design – Theory vs. Practice? (Part 1)

In a recent discussion thread a reference was made to Don Norman’s essay about Activity-Centred Design and the Dangers of Human-Centred Design. (To which Norman later posted a clarification.) This essay has inspired a considerable amount of discussion, which is understandable, because Norman challenges established principles of HCD (or seems to do so). Basically, he says that the design focus of HCD is too limited to capture the characteristics of users’ activities and therefore brings the danger of ending up with suboptimal designs.

Going through Norman’s essays I kept asking myself the same questions: Is this whole discussion relevant for practical usability engineering? Does anyone really work in the fashion as criticised by Norman? Which points he makes are related to issues encountered during the everyday work of a usability engineer or user interface designer? Here are some of my thoughts.

Since my postings tend to become rather long, I’m going to split this one for easier consumption.


Norman criticises the “Know your user” principle of HCD, because there are designs that work well for everyone and HCD focuses on the user instead of the activity and the tools. After all “Tools Define the Activity: People Really Do Adapt to Technology”. He mentions everyday objects such as garden tools and kitchen utensils as examples for things that work well for everyone and “have been designed without the benefit of user studies and the methods of Human-Centered Design”.
I wonder why Norman does not mention ERP systems and things like that. Well, maybe those are slightly more complex than garden tools, and much more “artificial” in the sense that there’s not much physical activity involved and “cognitive objects” are manipulated instead.
With simple tools, it is rather clear whether they are usable or not (there aren’t many design errors to make when producing a shovel). With complex computer systems, you might not have a clue exactly how usable the thing is. So what to do? First, it helps when you are aware of humans’ cognitive limitations. I assume that Norman does not negate that. But beyond that, a lot of the tools a usability engineer encounters are NOT designed to work for everyone. (Why should your average desperate housewife bother with a customer relationship management system?) Regarding the aspect of artificiality, Norman states that people adapt to even highly artificial systems like handwriting and typing, which can take people months and years to learn. The thing is, in today’s world you usually don’t have the time for a system to “evolve” (as the automobile did, according to Norman) but need to deploy it usually in a shorter period than the next 10 years before someone comes up with a better alternative. So doing some user research is usually a good idea. Hoping that users will adapt to your tool might cause some problems – first for the users, but ultimately for yourself. Knowing what characterises the users / the user group in terms of education, work experience etc. is highly relevant for the design of a system, because you can tailor the system to the specific needs of the users (which may be considerably different from the “average user”, which does not exist, anyway…)
To react to certain comments in advance: I’m not stating the other extreme of what Norman seems to say; I don’t think that one can hope to create an interactive system that will make all users equally happy – not even with HCD, user research or whatever you want to call it. Yes, (some) users must adapt to (some) aspects of interactive systems and can do so. But: I do not start working with the assumption that the user adapting to the system is the best way to handle things! The examples that Norman states for people adapting to tools only illustrate that it’s possible in certain cases. This doesn’t mean that it’s good or can’t be done better.

(Continued on February 20, 2006)