Understanding user interface design rules - Part 1: Task analysis and conceptual model

An optional but sometimes useful step in designing an interactive system is to illustrate its conceptual model as a matrix of objects and actions. Objects are listed down the left edge; actions are listed across the top (see Fig. 11.2). For now, we are ignoring the object type hierarchy and simply listing the objects. The more objects, the taller the matrix; the more actions, the wider.

Constructing an objects/actions matrix lets you visualize the simplicity or complexity of your interactive system's conceptual model. The larger the matrix, the more concepts there are to learn. A tall matrix indicates many objects to master. A wide one indicates many actions to learn. The matrix also illustrates how consistent or inconsistent the conceptual model is - how easy it is for users to transfer what they have learned about one part of the system to another.

A small, dense matrix indicates a design that will be easy to learn: few objects, few actions, and the operations on every type of object are the same (see Fig. 11.3A). For example, the conceptual objects in a simple drawing program would be graphical elements: lines, ellipses, arcs, rectangles, triangles, text labels, etc. The applicable actions on graphical objects would presumably be create, delete, view/edit attributes, move, copy, resize, rotate, flip, etc. The objects/actions matrix for such a simple drawing application would have a row for each object type and a column for each action. All the actions would apply to every object type, so the matrix would be densely packed, like that in Figure 11.3A.

A large, sparse matrix reflects an inconsistent design that will be hard to learn and remember because every conceptual object has different actions (see Fig. 11.3B). Such a design will be hard to learn and remember, no matter what user interface is plastered on it.

A good rule of thumb is to simplify the conceptual model so that the matrix representing it is as small and dense as possible. However, a small matrix reflects limited functionality. Achieving a small matrix is difficult when the application is anything more functional than, say, a simple drawing program, a personal phone directory, or a Web site for looking up postage rates. Consider, for example, the objects and actions an intensive-care patient-monitoring system would have. Even a typical word processing application - e.g., Microsoft Word or Apple Pages - embodies a nontrivial array of conceptual objects and actions.

However, for any desired functionality, a designer can develop conceptual models of varying complexity. For example, most personal bank account tracking applications have similar functionality, but Intuit's Quicken has an ultra-simple conceptual model, which may be one reason that it is so popular. Software designers should just aim for the simplest conceptual model (with the most compact objects/ actions matrix) for the required functionality.

Although easy-to-learn, easy-to-use systems often have small, dense object/action matrices, they can have other matrix configurations as well. Consider an application in which all functionality is accessed through five or six generic actions that apply to all objects. Such a system could have a large number of objects without much negative impact on learnability, because all objects operate in a totally consistent way. The object/action matrix for such a system, although tall, would be narrow and dense.

This approach has been used to design some highly functional systems, such as the Xerox Star office workstation (Johnson et al., 1989). In Star, the same six commands - move, copy, open, delete, show properties, and copy properties - applied to all objects: characters, words, paragraphs, table rows, tables, charts, email messages, documents, folders, printers, etc.

If we include the object type hierarchy in the matrix, we can see another sort of conceptual model that is easy to learn: one in which objects fall into clear categories, each one having its own actions, perhaps with a few actions that apply to all objects (see Fig. 11.4). The matrix for such a model isn't small or dense, but it also isn't scattered. It has a regularity and consistency that aid learning and retention.

An example would be a real estate service offering both commercial and residential properties, with different actions for each as well as actions that apply to both types of properties.

I regard creating an objects/actions matrix as an optional design step for two reasons:

• Experienced interaction designers rarely need to actually draw the matrix to know whether the conceptual model underlying their design is simple or complex, consistent or inconsistent.

• Usability testing can reveal aspects of an application's conceptual model that designers did not know needed to be simplified.

It may be enough for designers, as they design the conceptual model for an application, to imagine what its objects/actions matrix would look like if they drew it.

The goal is to devise a conceptual model that is task-focused, as simple as possible, and as consistent as possible. From such a model, one can design a user interface for it that minimizes the time and experience required for using the application to become automatic.

Keystroke consistency
When a designer moves from conceptual design to actual user interface design, keystroke-level consistency becomes important.

Keystroke-level consistency is harder to illustrate and measure, but it is at least as important as conceptual consistency in determining how quickly the operation of an interactive system becomes automatic. The goal is to foster the growth of what is often called "muscle memory," meaning motor habits.

Achieving keystroke-level consistency requires standardizing the physical actions for all activities of the same type. An example of a type of activity is editing text. Keystroke-level consistency for text editing requires the keystrokes (and pointer movements) to be the same regardless of the context in which text is being edited - documents, form fields, filenames, etc. Other types of activities for which keystroke-level consistency is desirable are opening documents, following links, choosing from a menu, choosing from a displayed set of options, clicking buttons, scrolling a display, etc.

A system that is inconsistent at the keystroke level does not let people quickly fall into "muscle memory" motor habits but, rather, keeps them guessing about what keystrokes to use in each context, even when contexts differ only slightly.

A common way that developers promote keystroke-level consistency is to follow look-and-feel standards. Such standards can be presented in style guides or they can be built into common user interface construction tools and component sets. Style guides exist for the entire industry and they exist separately for desktop software (Apple Computer, 2009; Microsoft Corporation, 2009) and Web design (Koyani, Bailey, & Nall, 2006). Ideally, companies also have internal style guides that augment the industry style guides to define a look and feel for their own products.

However conventions are encapsulated, the goal is to stick to conventions at the keystroke level while perhaps innovating at the conceptual and task levels. We as designers really don't want our software's users to have to keep thinking about their keystroke-level actions as they work, and users don't want to think about them either.

Printed with permission from Morgan Kaufmann, a division of Elsevier. Copyright 2010. "Designing with the mind in mind: A simple guide to understanding user interface design rules" by Jeff Johnson. For more information about this title and other similar books, please visit www.elsevierdirect.com.

Bibliography:
Apple Computer (2009). Apple human interface guidelines. developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines

Beyer, H., & Holtzblatt, K. (1997). Contextual design: A customer-centered approach to systems design. Morgan-Kaufmann Publishers.

Card, S. (1996). Pioneers and settlers: Methods used in successful user interface design. In M. Rudisill, C. Lewis, P. Polson, & T. McKay (Eds.), Human-computer interface design: Success cases, emerging methods, real-world context. San Francisco: Morgan Kaufmann.

Hackos, J., & Redish, J. (1998). User and task analysis for interface design. New York: Wiley.

Johnson, J. (2007). GUI bloopers 2.0: Common user interface design don'ts and dos. San Francisco, CA: Morgan-Kaufmann Publishers.

Johnson, J., & Henderson, A. (2002). Conceptual models: Begin by designing what to design. Interactions, 25 – 32.

Johnson, J., Roberts, T., Verplank, W., Smith, D. C., Irby, C., Beard, M., & Mackey, K. (1989). The xerox star: A retrospective. IEEE Computer, September, 11 – 29.

Koyani, S. J., Bailey, R. W., & Nall, J. R. (2006). Research-based web design and usability guidelines. US Department of Health and Human Services. Website: usability.gov/pdfs/guidelines.html.

Microsoft Corporation (2009), Windows User Experience Interaction Guidelines: http://www. msdn.microsoft.com/en-us/library/aa511258.aspx

Norman, D. A., & Draper, S. W. (1986). User centered system design: New perspectives on human – computer interaction. Hillsdale, NJ: CRC.

Schneider, W., & Shiffrin, R. M. (1977). Controlled and automatic human information processing: 1. Detection, search, and attention. Psychological Review, 84, 1 – 66.