Collect and Represent the Data
Ideally the first steps in the design process should occur before a design is ever considered. Unfortunately, in virtually every case I have encountered, a design for the user interface has already been in the works before the steps for collecting user and task related data have been performed.
Nevertheless, if you are one of the people performing the research, do as much as you can to push the design out of your mind and focus on objectively collecting and evaluating the data. And, in your data analysis, following the data and not your or the preconceived notions of someone else.
There are a variety of means for collecting data and representing it. The means for collecting the data will generally involve:
- Observation - collecting the step-by-step activities as a person under observation performs their tasks.
- Inquiry - collecting data about the a person's cognitive processes.
- Task models - summary process models (with variants and edge cases) of how users perform each task. This is different from workflow models in that in task models no references to specific tools or systems should be included in the task model. A task model should be abstracted and represented at a level without reference to actions taking place on a particular device or system.
- Workflows - summary process models (with variants and edge cases) similar to the task flows with reference to a particular device or system. For example, if the user interface consists of a particular web page, there should be a reference to that webpage and the action(s) that took place.
- Cognitive models - a representation of the cognitive activities and processes that take place as the person performs a task.
- Breadth analysis - I have noted that this is often overlooked. Breadth analysis organizes the tasks by frequency of use and if appropriate, order of execution. This is also the place to represent the tasks that users perform in their work environment but were not directly part of the data collection process.
I cannot hope to provide detailed instructions in this blog. However, I can provide a few pointers. There published works on how to collect, analyze and model the data by leaders in the field.
Here are three books that can recommend and several can be found in my library:
User and Task Analysis for Interface Design
by J. Hackos & J. Redish I highly recommend this book. I use it frequently. For those of us experienced in the profession and with task and user analysis, what they discuss will seem familiar - as well it should. However, what they do are provide clear paths and methods for collecting data from users. The book is well-structured and extremely useful for practitioners. I had been using task and user analysis for a decade before this book came out. I found that by owning this book, I could throw all my notes away related to task and user analysis, and use this book as my reference.
Motion and Time Study: Improving Work Methods and Management
by F. Meyer
Motion and Time Study for Lean Manufacturing (3rd Edition)
by F. Meyer & J. R. StewartTime and motion study is a core part of industrial engineering as the means to improve the manufacturing process. Historically, time and motion studies go back to Fredrick Taylor (http://en.wikipedia.org/wiki/Frederick_Winslow_Taylor) who pioneered this work in the later part of the 19th and in early part of the 20th Century. I have used time and motion studies as a means for uncovering problematic designs. Time and motion studies can be particularly useful when users are engaged in repetitive activities and as a means for improving efficiency and even as a means for reducing repeated stress injuries. The first book I have in my library however it is a bit old (but very inexpensive) so I include the second book by Meyers (and Stewart) that more recent. I can say that the methods of time and motion can be considered timeless, thus adding a book published in 1992 can still be valuable.
Time and motion studies can produce significant detail regarding the activities that those under observation perform. However, these studies are time-consuming and as such, expensive. Nevertheless, they can provide extremely valuable data that can uncover problems and improve efficiency.
Contextual Design: Defining Customer-Centered Systems (Interactive Technologies)
by H. Beyer & K. Holtzblatt & Rapid Contextual Design: A How-to Guide to Key Techniques for User-Centered Design (Interactive Technologies)
by K. Holtzblatt, J. B. Wendell & S. WoodThe first book I have in my library, but not the second. I have used many of the methods described in Contextual Design before the book was published. The contextual design process is one of the currently "hot" methods collecting user and task data, and as such, every practitioner should own a copy of this book - at least as a reference.
I believe what's particularly useful about this contextual inquiry is that it collects data about activities not directly observered. It's able but that affect the users and the tasks that they perform. For example, clinicians engaged in the remote monitoring of patients often have other duties, many of them patient related. Collecting data exclusively targeting remote monitoring activities (or the activities specific to a targeted device or company) can miss significant activities that impact remote monitoring and vice versa.
Additional Resources
As a graduate student, I had the privilege of having my education supported by Xerox's Palo Alto Research Center. I was able to work with luminaries of the profession, Tom Moran and Allen Newell on a couple of projects. In addition I was able to learn the GOMS model. I have found this model useful in that it nicely blends objectively observed activities with cognitive processes. However, the modeling process can be arduous, and as such, expensive.
Allen Newell and Herbert Simon are particularly well known for their research on chess masters and problem solving. They were well-known for their research method, protocol analysis. Protocol analysis is a method that has the person under observation verbally express their thoughts while engaged a particular activity. This enables the observer to collect data about the subject's thoughts, strategies and goals. This methodology has been adopted by the authors of contextual inquiry and one that I have often used in my research.
The problem with protocol analysis is that it cannot capture cognitive processes that occur beyond the level of consciousness, such as the perception. For example, subjects are unable to express how they perceive and identify words, or express how they are able to read sentences. These processes are largely automatic and thus not available to conscious processes. (I shall discuss methods that will enable one to collect data that involves automatic processes when I discuss usability testing in a later article.) However, protocol analysis can provide valuable data regarding a subject's thoughts particularly when that person reaches a point where confusion sets-in or where the person attempts to correct an error condition.
Here's a link from Wikipedia: http://en.wikipedia.org/wiki/GOMS.
Another book that I have in my library by a former Bell Labs human factors researcher, Thomas K. (TK) Landauer, is The Trouble with Computers: Usefulness, Usability, and Productivity
.This is fun book. I think it's much more instructive to the professional than Don Norman's book, The Psychology Of Everyday Things
. (Nevertheless, I place the link to Amazon just the same. This is a good book for professional in the field to give to family members who ask "what do you do for a living?") Tom rails against the many of the pressures and processes that push products, systems and services into the commercial space before they're ready from a human engineering standpoint. Although the book is relatively old, many of the points he makes are more relevant today than when the book was first published. The impluse to design user interfaces without reference or regard for users has been clearly noted by the FDA, hence the need for HE-75.
