Karen A. Holtzblatt, Sandy Jones, and Michael Good
Digital Equipment Corporation
Nashua, New Hampshire, USA
Originally published in SIGCHI Bulletin, 20 (2), October 1988, pp. 46-48 as part of a section on CHI ’88 Interactive Poster Session Papers and Abstracts. Copyright © 1988 by Karen A. Holtzblatt, Sandy Jones, and Michael Good. All rights reserved.
Over the past two years, our field research with users has indicated that elements of an application design can disrupt users’ work. Understanding how applications disrupt users’ work has helped us to articulate the meaning of interface transparency. Interface transparency and related concepts have previously been explored from theoretical perspectives, but have not been grounded in user data.
The relationship between the user’s work and interface transparency is a key element of our understanding. Disruptive systems distract users from their task. Systems can disrupt users by fragmenting the task into elements which do not match the user’s view of the task. Insufficient functionality and awkward interface mechanisms for a particular task also disrupt users. We need to understand users’ work in much richer detail than we do now in order to build systems that assist them with that work.
Interpretive Field Research
Interpretive field research on human-computer interaction (Whiteside et al., 1986) is a process that allows the researcher to collect and interpret users’ responses to software as they are engaged in the use of that software. The researcher is present during the use of the software in the context of the user’s actual work setting and work task. The researcher can both observe and question the user about his or her experience with the software and its impact on their work as it unfolds. Data collected in these contextual interviews includes:
- Users’ ongoing experience with the product,
- The nature of the users’ work,
- The impact of the product on the users’ work,
- The meaning of usability for the user,
- Directions for future products,
- Specific problems and strengths of specific products,
- Interaction of specific products with other products, and
- Interaction of the product with the users’ environment.
We do not assume that something is experienced as disruptive to work because it seems that way to us. We check out our interpretations with the user to establish a shared understanding of user experience which grounds our interpretations. Similarly, if we see a user doing something effortlessly, seemingly without awareness, we check this out. With the user as co-researcher, we can track aspects of usability to elements of the system implementation.
Development of Usability Concepts
A concept is “A general understanding derived from particular instances or occurrences” (Webster’s).
We want to develop a set of concepts that describe usability as it is understood and lived by users. We want to derive concepts which are useful for guiding the design of new systems and interfaces.
We are building a set of descriptive concepts that crystallize user experience. These concepts will provide designers with a new way of “seeing” user’s work and usability, with specific implications for system design. We are not trying to build a cause-and-effect model of usability. For instance, we are not trying to predict that x units of transparency will automatically produce y units of usability.
Building concepts from interpretive field research is an inclusive process. As we interview each person, new instances modify and expand the concepts in our understanding of usability.
Interviews reveal instances of the phenomenon. The instances are used to build concepts. The concepts form a framework for communicating user experience to designers. Designers use the concepts to design the next system.
Transparency: An Example of a Usability Concept
Transparency is not a new concept. Rutkowski (1982) proposes that transparency is the ideal relationship between user and tool, with the tool seeming to disappear. Winograd and Flores (1986) relate this aspect of computer system design to Heidegger’s principle of readiness-to-hand. Similar concepts are first-personness (Laurel, 1986) and direct engagement (Hutchins et al., 1985).
We see the experience of transparency when users remain in the flow of their work and are not disrupted by the computer system. Users of more transparent systems focus on the accomplishment of their tasks, and feel satisfied with how their work is moving along. The focus of users’ attention is not diverted to the use of the interface.
One user described his experience of remaining in the flow of work:
What I really like in the workstation interfaces that I have used are those tools where I can feel especially coordinated when I work; where I can develop a rhythm to what I do.
I like to do my work click-click-click here and then zip over to or pop up something else, click, and click-click on it, and then, maybe pop down a menu or other window to decide what I want to do next. The more immediate the feedback that what I intcndcd to do is done (or being done), the sooner I can develop a rhythm and muscle memory for oft-repeated tasks, the “crisper” the interface, the sooner I feet coordinated and enjoy using the machine.
I like to touch type, play racquetball and dance for the same reasons I like a crisp workstation interface: it makes me feel coordinated and feeling coordinated helps me feel in control. Sometimes I just like the sound of the clicks.
Disruptions in the flow of work point to opportunities for understanding transparency. Understanding the source of disruption reveals a way of understanding usability that can guide designers.
When the users are forced to attend to the application, or are blocked from completing a task by the application, we see disruption in thc work flow.
Understanding thc user’s experience of their work helps designers avoid disruptions. Here is our current understanding of user’s work, revealed by looking at the source of disruptions. We include examples from our data and some of the implications for design.
Implications of Understanding the User’s Work for Minimizing Disruptions
|Current understanding of user’s work:||Possible actions by designers:|
|Users think of themselves as working on a task, not as using a computer application.||Understand the details of diverse users’ work. Look for ways to integrate different applications.|
|Example: One user of a desktop publishing system produced data sheets for integrated circuits. The design of the publishing system required the user to break his work into three parts: text editing, graphics editing. and layout. The user was unable to move smoothly between these three sub-tasks. If, during layout, the user decided to make major changes in the text, he had to exit the publishing application and enter the text editor, which caused a long delay. After re-entering the publishing system, he had to erase the old text and import the new text file.|
|Users implicitly or explicitly structure their task while in the flow of work.||Support the different ways that users structure their tasks..|
|Example: One user of a word processing system manually paginated the document as she typed rather than using the pagination function. For this user, text input and formatting are part of a single process. “It’s as if it has a mind and is saying this is how you do it. But it’s not how I wanted to do it… It didn’t really fit my need. You work around the computer.”|
|Tasks that appear similar can have fundamental differences due to the specific characteristics of the work and work environment.||Study different types of work and environments to identify necessary functionality.|
|Example: Documentation writers working with long files requested a text editor function that would tell them their current page number, line number, and general location in the document (e.g., 50% mark). Managers working with short documents did not need this function.|
|The outcome of a task is not always pre-planned. Results are achieved by creative iteration.||Identify points in the user’s work where the user relies on creative iteration and support user experimentation with appropriate software tools.|
|Example: A LISP programmer used the integration of the editor, interpreter, and inspector functions to follow his flow of thought while programming. One keystroke let him flip back and forth between editing, testing, and debugging, supporting experimental programming.|
|Users do not want to be distracted from their work to access needed functions.||Choose interaction techniques to minimize eye and hand motion.|
|Example: A user found that using the desktop publishing system’s pop-up menu did not disrupt his work. “All the most frequently used commands are on the [pop-up] menu. It encompasses 80% of the commands used on a regular basis. I find it somewhat irritating to have to go up to a menu bar.”|
Boland, R. J., Jr. Phenomenology: A preferred approach to research on information systems. In Research Methods in Information Systems, E. Mumford et al., Eds., North-Holland, Amsterdam, 1985, pp. 193-201.