Interaction design as an area of specialization is still relatively young, and continually evolving and re-defining itself. Often this is healthy; but in some cases, trends seem to have taken the discipline off the rails. One of these is a move to almost clerical roles and methods of user interface design that have arisen in some projects and companies with which I’ve been familiar, at least in the area of Web design.
Growing professions, particularly multidisciplinary ones without standardized certifications and qualifications, may be more likely to attract a people who are semi-qualified—and maybe only tangentially interested. This is perhaps especially true of “soft skill” roles such as interaction design and usability. But it seems to have happened very quickly in this field, and I am surprised at the number of people who claim to be qualified and have, for example, never heard of SIGCHI or its equivalents (or, at best, have never bothered to join); are not at all familiar with HCI history or classic papers and concepts (particularly true, it seems, of those who have never worked outside of the Web); and are often neither “active users” of technology (e.g. early adopters) nor particularly adept with or interested in computers in general.
Because these people practice neither user-centred design nor computer science, but rather focus on documentation (often using a very narrow range of specific applications), I call them “user interface clerks.” The design method they follow seems to be:
- Read uses cases written by business analysts;
- Produce static drawings of Web pages to reflect the use cases;
- (Optionally) perform usability tests using the drawings and make superficial changes as a result;
- Hand over the diagrams to Web developers and software engineers.
Notice that there is virtually no user input, research, knowledge, or involvement. The use cases do not introduce it, and they are the first significant problem. Most use cases are essentially disorganized short stories that describe how a user accomplishes a task or tasks using an imagined user interface. (Use cases are written by “business analysts,” a profession that seems to me to be devoid of any particular skill set or qualification. Perhaps the subject of a future post.) The user interface is not specified in detail, but critical aspects of it, such as widgets and Web pages, are assumed and written in. Much of the work of the interaction designer is heavily influenced, if not largely predetermined, by whomever writes the use cases. Ideally, of course, use cases should be implementation-independent, technology-free descriptions of a system, detailing basic user intentions and system responses, but not presuming any specific way of instantiating these in a particular user interface design. See for instance Constantine and Lockwood’s Structure and Style in Use Cases for User Interface Design (PDF).
Another problem is the drawings, or “wire frames” as they are usually called. These are typically produced in Microsoft Visio (or OmniGraffle on the Mac). They are very time consuming to produce and maintain, so the UI clerks end up spending the vast majority of their effort producing and editing them, as a result ending up virtually uninvolved in other aspects of analysis and design. “Wire frame” is a term that comes from computer graphics and is a display mode in which a three-dimensional object is rendered in a manner showing only object edges and joins, not surfaces. This is done in order to provide quick visualization of the models. There are two important differences between these wire frames and the diagrams drawn by the user interface clerk. The first is that, in computer graphic wire frames, the missing detail already exists and can be rendered at any time. The wire frames are an optional display mode: defining surface textures and fills is part of the work process. If the UI design equivalent of 3D object surface details was detailed graphic design, these UI “wire frames” might be justifiable, although I think it is preferable to design the entire user experience at least somewhat co-operatively with a visual designer.
However, the second difference between 3D wire frames and these user interface diagrams is that the non-rendered component of UI drawings is not just “surface details,” but the central component of the design: the behaviour of the user interface, or the interaction design itself. The diagrams are static and only specify content and, usually, rudimentary layout. So this design method is not only incomplete, but the behavioural details end up being defined by developers and engineers. This might work out in some cases, but often it does not. This is not only because the engineers do not have training or experience in interaction design, or do not have the time to consider it in enough detail. It is because good interaction design must be “built in” to a system, and cannot be tacked on at the end. This is particularly problematic for complex interactions, which are much more prevalent than in the earlier days of the Web.
I state that superficial changes are made if and when usability testing is performed: this is an important point and perhaps the crux of the problem. The “clerical” method of designing and defining a user interface is not only time-consuming, but is also part of a lockstep waterfall procedure, and as such is adhered to in order to reduce risk. That is, risk from the project perspective, not in terms of usability. It is considered far more important to deliver something—anything—on schedule than it is to succeed in improving a software system. And with that, we arrive back at the place that, as interaction designers, we have been arguing against for decades now. Partly as a result, the actual work of designing innovative and usable user interfaces is being taken over by visual designers and others who seem to be far more willing than the “clerks” to get their hands dirty with the details of interactivity.
It’s time for the user interface clerks to put aside Visio and learn about user and task analysis, interaction design beyond simple hypertext, and how to design and prototype interaction.
What is the difference between someone begging for money, and another shoving towards us a “