User Interface Clerks

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:

  1. Read uses cases written by business analysts;
  2. Produce static drawings of Web pages to reflect the use cases;
  3. (Optionally) perform usability tests using the drawings and make superficial changes as a result;
  4. 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.

One Response to “User Interface Clerks”

  1. James Says:

    I agree with what you’re saying, but I think there’s a cause and effect issue at play. Not so much in an agency setting or where there are multidisciplinary teams with well-defined roles like PM, visual designer, interface developer, programmer, etc. However, I think the structure some people are forced to work within, doesn’t often allow specialization.

    So, the business analyst who just happens to have watched user testing at some point, and is asked out of the blue to conduct one, muddles through and produces poor results. However, in the interest of padding their resume, they add it as a skill.

    It’s like coming into a new work situation (as I’ve done twice in the last couple years) and finding out, not only are things really not how they’re presented to you, but the fight you have on your hands to drive understanding of the web development process is almost certain to be a losing one. So you get asked or expected to do all things web, while knowing you need more resources or budget, but having to live without it.

    I’m not sure about people passing themselves off as interaction designers with no real HCI education/experience, but I know all too well what the term ‘web consultant’ has come to mean in my career. A bit of usability analyst, a bit of PM, a bit of visual designer, a bit of UI developer and often not doing the things you’re most skilled at nearly enough. Meanwhile doing lots of things you’d rather bring a skilled contractor in for, but which you can’t consider.

Leave a Reply