A Tale of Two Tutorials: A Cognitive Approach to Interactive System Design and Interaction Design Meets Agility

I usually only make it to one conference a year, but in 2004 I had the unusual pleasure (or duty, depending on your point of view) of attending both CHI in Vienna and OOPSLA in Vancouver. (Next year I will do the W’s— Warsaw and Walla Walla). I presented my own material on user-centered design and had the opportunity to attend tutorials on two very different approaches to improving the usability of interactive systems.

A Cognitive Approach to Interactive System Design

Mike Atwood and Tom Hewett’s A Cognitive Approach to Interactive System Design at the CHI conference was a full-day tutorial, based primarily on Cognitive Task Analysis in the form of Goal-Oriented Modeling with a supporting role for Cognitive Walkthroughs. We spent the morning session looking at the basics of these techniques and reviewing the case for improved usability through bad-design examples found in the book Set Phasers on Stun (a collection of technological disasters such as the Therac 25 tragedy where patients were given fatal doses of radiation through a programming error). The afternoon consisted of a workshop during which our impromptu teams designed, prototyped, and walked-through a futuristic vending machine (à la the CHI 2000 design competition).

The center of attention was Goal-Oriented Models (GOMs, not to be confused with Card, Moran and Newell’s GOMS, ending in capital “S”—Goals, Operators, Methods and Selectors). These are a form of Hierarchical Task Analysis with a goal at the top, followed by sub-goals, unit tasks and artifacts, as shown in Figure 1. Sub-goals may be further sub-divided as required, always ending with a unit task: in an interactive system, some operation that users can perform such as clicking or dragging.

Figure 1: Goal-Oriented Model for Making a Cup of Tea

Although these models can seem trivial at first glance, I believe they are important in focusing attention on how users attain their goals. And of course it is still possible for designers to create models with unrealistic expectations of users—but that is where cognitive walkthroughs come in. In their tutorial, Mike and Tom use a slightly abbreviated version of Wharton, et al.’s questions:

However, I find when I am trying to teach this, that it is easier to return to Wharton’s four questions and to tie them up with the classic interaction cycle. So my version looks like this:

Now this may come as something of a surprise if you are primarily involved in HCI, but these questions are profound to software and web site developers since most will never have considered user interaction in this way. It is especially helpful if combined with good examples of how not to design with users’ goals in mind.

Interaction Design Meets Agility

OOPSLA is the premier software development conference for object oriented methods. It is possibly one of the longest-running in any IT field since it is going to have its 20 th anniversary in 2005. There were over 50 (mostly half-day) tutorials available at OOPSLA, but only Jeff Patton’s and my own had very much to do with user-centered design—a situation worthy of a separate article in its own right (see, for example, www.usabilitynews.com/news/article2005.asp).

Jeff’s half-day tutorial (also presented at UPA 2004 in Minneapolis) is a marriage between Constantine and Lockwood’s usage-centered design and Agile processes such as eXtreme Programming. Because Agile processes in general are moderately lightweight on design and heavyweight on collaboration, the tutorial makes use of a number of group activities with cards and Post-It ® notes.

We worked through several collaborative sessions, establishing user roles and tasks on moveable notes or cards and prioritizing them. These we grouped together on flip-chart sheets, performing a cluster analysis of sorts. The overall approach was certainly very supportive of collaboration and the techniques used helped a lot in visualizing the system requirements. However, although Jeff did talk about user observation, it is not clear how this might feed into the collaborative process. And while the collaboration teams are supposed to include end users, I am personally very skeptical whether user involvement in this kind of process produces usable systems.

My biggest concern is taking tasks out of context. We produced a very effective overview of the system using a kind of scattergram that displayed time across the horizontal axis and business criticality along the vertical. This “span plan” is shown in Figure 2. The horizontal slices are the phases in which task implementation may be considered. In theory it would be possible to link tasks performed by the same user role with another set of lines, but what is missing altogether is the original context from which these tasks were plucked. This is exactly what the goal-oriented models provided us. Let’s return to the tea-making model for a moment. While we might decide that adding lemon to tea is not sufficiently critical to the business to appear in the first release of our process, we can see where it belongs in context and know that its omission is not going to make life too impossible for our users (unless they really, really have to have lemon). The same can certainly not be said about boiling the kettle, though, since we have provided no alternative means for doing this. Also, when it does come to implementing the “add lemon” functionality, we know where it goes and could even have made provision for it in the user interface.

Figure 2, Span Plan showing tasks by time and criticality (photo courtesy of Jeff Patton)

So while I am very impressed with the Usage-Centered Design/Agile models when it comes to collaboration, I think we need further techniques, including goal-oriented modeling, to achieve true user-centered design. I do address issues like this in my own tutorial, but there is still a lot of work to be done.

References

Wharton, C., Rieman, J., Lewis, C., & Polson, P. (1994). The cognitive walkthrough method: A practitioner's guide. In J. Nielsen & R. L. Mack (eds.). Usability inspection methods. New York, NY: John Wiley. [Amazon.com]   [Amazon.co.uk]

Casey, S. (1998). Set Phasers on Stun: And Other True Tales of Design, Technology, and Human Error. Santa Barbara, CA: Aegean. [Amazon.com]   [Amazon.co.uk]

The Author

William Hudson is principal consultant for Syntagm Ltd, based near Oxford in the UK. His experience ranges from firmware to desktop applications, but he started by writing interactive software in the early 1970's. For the past ten years his focus has been user interface design, object-oriented design and HCI.

Other free articles on user-centred design: www.syntagm.co.uk/design/articles.htm

© 2001-2005 ACM. This is the author's version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in interactions, {Volume 12, Issue 1, January + February 2005} http://doi.acm.org/10.1145/1041280.1041297