That Technology Magazine

(This post continues the entry from January 30, 2006)

Norman also says that the concentration on “tasks” may be harmful and that one should rather focus on “activities”. For Norman, activities are higher in the hierarchy, comprising several tasks (which are themselves a set of actions that consist of operations). Activities should be the unit of exploration because focusing on tasks can lead to a fragmented design of individual screens that do not “support the sequential requirements of the underlying tasks and activities”. I agree that you cannot solve every user interface design problem by providing a step-by-step wizard. But then: anyone who thinks that this would be a reasonable approach is in for some trouble. There are tasks, activities or whatever that can be “brought on screen” as a sequence of distinct steps, then there are distinct steps that vary in their order and then there are the things Norman is talking about – probably the majority of activities – that are more complex and that cannot easily be broken down into individual building blocks without destroying coherence. But HCD does not negate that. Quite a portion of work goes into finding out exactly how that “overall workflow” looks like and conceiving of ways to support it without artificially breaking it up. Apart from that, if I tried to break up any workflow I encountered during my work into segments of individual screens I could cancel this blog because I would do nothing else besides designing screens matched to individual tasks of workflows. The point is: I don’t think that the problem that Norman describes is even an option in serious usability engineering / user interface design; at least not if you want to do good work.

And then there’s the good old “listening to users” thing. Norman states that “listening to customers is always wise, but acceding to their requests can lead to overly complex designs”. I absolutely agree. But I think the whole argument should be better directed towards clients than towards usability engineers or user interface designers. I suppose Norman knows of Nielsen’s “The User Is Always Right” and “The User Is Not Always Right” slogans in his book on Usability Engineering, so I guess he knows that the argument does not come as a surprise for practitioners.
In Norman’s opinion what the design process needs is an authoritative leader (or “dictator”) who is in control of the overall design and the conceptual model. I couldn’t agree more. Here he is talking about the reality of HCD projects, where all too often a usability engineer is seen as someone who collects all user input (in early stages) and user feedback (in later stages) and is then supposed to find ways to put each and every piece of information into the final system. Which can produce some nasty results. As an example for misguided design processes Norman mentions the use of Personas that put the focus on individuals but are more or less useless for designing a system that will adequately support the activity in question.
I think those are really two issues: firstly, the “listening to users” problem isn’t inherent in HCD but more in the way it is put into practice (or how some clients want to put it into practice). Sometimes it takes some work on the side of the usability engineer to remind the client of why he was hired in the first place: because the usability engineer is the expert not only on collecting user and activity data but also an expert on how to put this data to good use – and this includes disregarding some of it. Secondly, the use of personas is not necessarily aimed at being the foundation on which to base a system on, but they can become valuable communication tools. Creating personas and giving them names can be extremely helpful when talking to stakeholder groups. In fact, they can be used to achieve something that Norman demands: taking the focus off individual functions and to activities people conduct with a system. Sometimes you have to make stakeholders aware that there really is something like a “user” and that he has some goals he wants to achieve by using the system instead of simply admiring the cool buttons that marketing has requested. Point: Personas are communication tools, not something put into your “interface maker” which then produces some nice screens based on the information. (Norman explicitly acknowledges the communication value of Personas in his clarification.)

So, in my opinion the problems Norman describes are real. But I do also think that they are more relevant on a theoretical level and not for the practical work of a usability engineer. (Exception: the “listening to users problem”, which is very real but – in my opinion – not due to HCD limitations.) If you would try to put the restricted view that Norman seems to have of HCD into practice, you would probably not survive your very first project (or at least users would not tolerate the result).