Links

Improving Usability Through Lo-Fi Design and Simulated Execution

September, 1999

This is a draft of a paper that appeared in the Sep. 1999 issue of Software Testing and Quality Engineering. Special thanks to Brian Marick for his help in getting this article ready for publication.

Usability pays. Literally. User interfaces that allow users to efficiently and easily accomplish their tasks with a minimum of errors result in many direct and indirect benefits, including reduced training and support costs, increased productivity, and increased satisfaction. Building a highly usable user interface is an investment that quickly pays for itself over the life of the product.

Unfortunately, most software development methodologies fail to address usability. As a result, project teams often spend whatever resources they may have on well-intentioned but ultimately unsuccessful attempts to seriously improve usability.

This articles explores the single most effective techniques I've found to substantially improving usability: lo-fi design and simulated execution. Lo-fi design is the process of creating paper-based prototypes of a proposed user interface. Simulated execution is the process of testing these prototypes. Together, lo-fi design and simulated execution support a low cost, rapid iteration approach to substantially improving usability. Best of all, these techniques work well in most any software development context. I've used them extensively on the design and implementation of several client/server software systems, while colleagues and students of mine have used them in projects ranging from computer games to the highly complex direct manipulation interfaces found in high-end Computer-Aided Design/Engineering.

What Happens Before Lo-Fi Design

Because lo-fi design deals with the issue of design, it should not be considered the first step of any development project. Regardless of the specific outcomes of your software development process, there are two essential prerequisites for lo-fi design: understanding your user and the motivation to iterate.

1. Understanding Your User. The cornerstone of building highly usable user interfaces is building as thorough an understanding of your intended users as possible. At a minimum, you should strive to understand their most important tasks (e.g., "merge departmental budgets" or "search for patents that relate to e-commerce"). Ideally, you will have detailed, step-by-step descriptions of how those tasks are normally accomplished (such descriptions are referred to as "use cases"). It is also helpful to have a model of the conceptual objects in the system (sometimes called "Entity-Relationship Diagrams", Class Diagrams, or Object Models).
    

2. Motivation to Iterate. There is a wide variety of published reference material available on how to design and build user interfaces. Much of this is stuffy academic research, opinion pieces, or several newer books on formalized processes. Most of this huge body of knowledge is not required to be successful using the techniques described in this article. What is required is a willingness to work with paper-based prototypes through multiple iterations. Simply out, if you can't--or won't--iterate on your designs, the lo-fi design approach won't do you much good. The process is helped considerably by a certain sense of playfulness as you explore new ideas, approaches, and options.

What is not needed is a formal experience or training in user interface design, although these can certainly help. Our own daily use of user interfaces has prepared us to understand the basics, and I trust in the iterative development process to help you create highly usable interfaces even if you don't have formal training or experience in user interface design. That said, there are several well accepted principles of user interface design that are easy to understand and easy to follow. Best of all, adhering to these principles often results in fairly dramatic improvements in usability. You can find a copy of these principles at the end of this article.

Creating Lo-Fi Designs

Creating lo-fi designs centers around three activities: storyboarding, or creating a representation of the overall flow of the user interface; lo-fi design, paper-based prototypes of the specific user interface; and simulated execution, which tests the lo-fi designs and storyboards and provides the feedback necessary for the iterative process to work. Once the lo-fi designs have been validated they are implemented, a process covered later in this article.

Step 1: Storyboarding

Storyboards are designed to show the overall flow of the user interface. Effective storyboards are quite simple: boxes represent windows, while lines between boxes describe how the user moves between boxes. Keep your storyboard diagramming notations as simple as possible. My favorite approach, especially in the development of the first storyboard, is to represent each window in a separate Post-It™ note.

An example of a simple storyboard for a mail system is shown in Figure 1 . The example shows the name of each window along with a brief description of the window contents. In Figure 1, a solid line means the users selection will open a primary window, while a dashed line indicates the opening of a modal dialog. (A "modal" dialog is a dialog that "takes control" of the application - the user must exit this dialog before they can perform any other work. An common example of a modal dialog is the "File>>Open" dialog on your favorite word processor).

Figure 1 : SuperMail Storyboard

A good storyboard can help you uncover usability problems before you begin the detailed design work associated with any specific window. Once I was asked to help a development team overcome a usability problem in which their users rated the overall application experience unsatisfactory. What perplexed the development team was that the users thought that each individual window of the application was well designed.

To diagnose the problem I had the development team prepare a storyboard of their finished application. Developing the storyboard helped them realize that there were simply too many cascading modal dialogs in the application. Specifically, in order to accomplish a task the user would be presented with one modal dialog, then another, then another. After just a few dialogs the users became lost. Even though each individual dialog was well designed, the interactions between dialogs caused problems. We redesigned the application flow through a new storyboard and modified the application accordingly. The results were dramatic, and this development team agreed to always begin with a storyboard in the future.

This example illustrates one of the ways you can evaluate your storyboard: look for too many modal dialogs and for operations that require multiple sequences of modal dialogs. You should also look for windows that try to accomplish too many-or too few-user tasks. The hard part, of course, is determining what is "too many" or "too few". If you can't do this, don't worry: the simulated execution phase will identify overall problems with the application. If you can show how most user tasks can be completed in the storyboard you are ready to move to the next step.

Step 2: Lo-Fi Window Design

The next step is to create lo-fi window designs. Using paper, pencil, and lots of erasers, the design team prepares preliminary versions of the most important windows described in the storyboard, including the "main" window displayed to the user, as well as any dialogs that control critically important information. The windows that must be designed are those associated with the use cases that represent the most important functions of the system.

Creating a lo-fi window design is a lot of fun. You are free to explore whatever aspect of system interaction you feel will most benefit your user, without being constrained by design tool limitations. When I am engaged in lo-fi window design I always have the following items easily accessible:

• scissors
• clear and colored transparencies with marker pens of different colors
• white correction tape (white correction tape is like liquid whiteout but can be easier/cleaner to use)
• a computer with a screen capture program and a color printer
• clear tape
• whiteout
• a photocopier

You can use clear transparencies to simulate data entry forms: draw a dialog, cover it with a clear transparency, and use a marker pen to simulate data entry. You can use colored transparencies to highlight important information.

The computer helps you efficiently create your lo-fi prototypes. Instead of drawing common dialogs (such as "File>>Open" or "File>>Print"), buttons, list boxes and other common widgets by hand, take screen snapshots of the desired widget, print it, and then glue or tape them into the lo-fi design. Don't worry if your lo-fi designs are a mish-mash of hand drawn and computer generated graphics. In practice, I've found that potential users respond quite well to such diagrams.

Don't create your lo-fi designs on a computer. Paper and pencil are far faster than any CASE tool at exploring alternatives. Perhaps more importantly, unless you have superb discipline, you will be inextricably drawn into making the details of your design correct (making buttons the same size, precisely aligning input fields , and the like). While these details must ultimately be finalized, worrying about them at this stage of the development is a time-wasting distraction.

Lo-fi prototype also provides a psychological advantage over computer-based tools. Both designers and users are less likely to modify computer-based prototypes than their paper-based alternatives, albeit for different reasons. Designers don't want to see their creations become radically altered. And users, who are looking for rapid turn-around, are often fearful for asking for changes because they know that modifying software takes time. When you start with a computer-based prototype you almost always ship it.

This not true with paper-based prototypes. Designers and users are much more willing to change a paper-based prototype when usability issues are surfaced. Designers haven't invested as much time. Because a lo-fi prototype isn't expected to work, users are likely to give even radical feedback on how to create a more usable interface. Your primary goal with a lo-fi prototype is to obtain feedback and rapidly turn around new designs based on this feedback. Choosing paper-based prototypes is the most pragmatic approach.

Don't limit your lo-fi approach to just doing windows. Anything produced by the system that interacts with a user can be subjected to lo-fi design. Other examples include reports, printed receipts, data entry or validation forms.

Step 3: Testing Lo-Fi Designs Through Simulated Execution

In simulated execution, a representative user attempts to perform one or more tasks using the lo-fi design created in the previous step with a human actually "simulating" the execution of the system by "playing" computer. During the test, observers are carefully watching the user to identify the strengths and weaknesses of the proposed user interface (it is important to focus on both; I've seen some designs become worse through iteration when the positive features were not properly retained). When finished, the test team discuss their observations and prepare a simple report detailing the results. It is best to identify the report with a number or other label for tracking purposes. Individuals associated with the test are named while participants identified an anonymous tracking number.

Simulated execution of the lo-fi design is just one kind of usability testing. More generally, and depending on the kind of system you are creating, you may want to also test user and technical documentation, the help system, and even the technical support operation. A description of these tests is beyond the scope of this article.

You need three to five people to conduct a simulated execution, structured according to the roles and responsibilities described in Table 1. Individuals participating in the test should rotate roles between successive tests, as playing any single role for too long can be overly demanding. I strongly encourage the participation of developers on the test team.

Table 1. Simulated Execution Roles & Responsibilities

Role	Responsibilities
Leader	Organizes and coordinates the entire testing effort Responsible for the overall quality of the review (that is, a good review of a poor user interface produces a report detailing exactly what is wrong) Ensures that the review report is prepared in a timely manner
Greeter	Greets people, explains test, handles any forms associated with test
Facilitator	Runs the test; the only person other than the participant who is allowed to speak Creates an open and friendly environment to foster a free-flowing exchange of idea Gives the user instructions Encourages users to think-aloud during the test so observers can record users reactions to the user Makes certain test is finished on time
Computer	Simulates the operation of the interface by physically manipulating the objects representing the interface. Thus, the "computer" rearranges windows, presents dialogs, simulates typing, and so forth. Must understand the "execution" (application) logic
Observer	Takes notes on 3x5 or 5x7cards, one note per card!

Select participants for the simulated execution according to the following guidelines. First and foremost, select participants who are representative of the target user population. If the system is for nurses, test with nurses. If the system is for data entry personnel, test with data entry personnel. Second, avoid testing with co-workers, friends, or other people who are intimately familiar with the project.

To ensure the test runs smoothly, practice! This advice is especially important for the person playing the role of the computer. Inevitably, such people will try to simulate the operation of the user interface at the same speed as the computer. The net effect is frustrating for everyone involved. Once they realize this is impossible, they will become skilled at smoothly simulating the operation of the user interface and will provide quite a realistic experience for the participant).

The greatest errors are often found within the first few tests. Sometimes you will find that you need a dialog to communicate an unanticipated error condition. As a result, and only in the first one or two tests, I recommend that developers have a few blank "windows" (sheets of blank) handy so that they can create new windows on the fly for the computer. That said, any modification to your lo-fi prototype should be undertaken with caution, even in early tests, as this can invalidate the results. The real objective is to provide a "safety valve" that is only used when needed that will allow the test to continue should a serious problem in usability be found.

Begin the test by reviewing the goals with the participants. Stress that the system is under scrutiny-not them. Participants are free to stop the test at any time should they feel uncomfortable. Then ask them to accomplish one or more tasks. While this is happening, the observers carefully watch the participant for any sign of confusion, misunderstandings, or inability to complete the requested task. Each such problem is noted on an index card for further discussion once the test is completed. Similarly, the observers will note any good comments made by the user. During the simulated execution members of the test team will often want to "help" the user by giving them hints or making suggestions. Don't do this, as it will make the results of the test meaningless.

Some consultants recommend videotaping the entire process for a more extended analysis. While this can be helpful, I've found that few companies can afford the time or expense to create and then carefully review the results. The goal is to shorten feedback cycles, not lengthen them. If you decide to videotape the sessions, hire a competent usability professional who has substantial experience in this area.

The entire test, from preparation, running the test, and discussing the results should take about two hours. Plan on running two tests per day so that the development team can make critical modifications to the user interface between tests. In general, three to eight tests give enough data to know if the development effort is ready to proceed to the next phase.

Implementation

Once simulated execution has validated the lo-fi prototype, the team moves into the implementation stage. By "implementation", I mean the creation of the user interface that will be delivered to the user. Ideally, the rest of the development team has been working in parallel with the user interface team, creating the necessary infrastructure for the user interface. In this case the user interface team will create and then connect their validated interface to the rest of the application.

The basic implementation work is the realization of the lo-fi design. Data entry fields are drawn in a precise manner, complete with edit masks. Iconic buttons that were merely sketched in the lo-fi prototype must be rendered according to the constraints and requirements of the delivery platform. This means drawing the icons, making certain the proper states for each button exist, and testing the actual working of the button in source code. The specific contents of windows may change slightly, as developers struggle to convert their lo-fi designs into the harsh constraints of a specific window size in pixels.

I refer to the design activities undertaken during implementation as "hi-fi design". Hi-fi design provides the development team with additional opportunities to enhance the user interface presentation and aesthetics through the creative use of fonts, color, grouping, and white space. Unless you are skilled in graphic arts I recommend proceeding with caution in these areas. One development team actually invalidated their successful lo-fi prototype by adding too many complex colors and fonts. Most development teams will find the best results when they keep the choice of fonts simple, using predominantly black on white text, and avoiding the use of graphics as adornments.

Please note that simply implementing the lo-fi prototype does not necessarily mean you are finished. Other areas that must be addressed include the on-line help system, external documentation, installation and upgrades, error messages and error handling, and performance, to name a few.

Creating highly usable systems is based on a healthy collaborative relationship between the development team and the users. This relationship is strengthened when users know that developers are responding to their needs, their feedback, and their suggestions.

The processes of user and task analysis, lo-fi design, simulated execution, and hi-fi design and implementation serve to increase the interaction between the development team and the user. This interaction is completely focused on the needs of the user as supported by the system in a manner that ensures all parties benefit. Users will enjoy their systems more, developers can take more pride in their work, and management can take the savings enhanced usability provides directly to the bottom line.

Further Reading on Usability

The field of GUI design, and books that purport to tell managers and developers how to do it better, is growing every day. Fortunately, the following few timeless classics provide real value if you wish to find more information about a specific topic.

GOULD, J. D. "How to Design Usable Systems." in Handbook of Human-Computer Interaction, M. Helander (ed.) Elsevier Science Publishers B.V., New York (1988) This article is one of the most important articles ever written on the topic of designing usable systems. Gould provides his own set of checklists, and numerous examples to support his claims.

Nielsen, J. USABILITY ENGINEERING. NEW YORK: HARCOURT BRACE & COMPANY, PUBLISHERS, 1993. This book provides a more in-depth view of usability engineering. It includes a concise executive overview and a detailed list of testing techniques. This book is suitable for technical leads and senior architects who want to be aware of the issues without expending the energy to create an in-dept understanding of design.

Collins, Dave Designing Object-Oriented User Interfaces, Redwood City, CA: The Benjamin/Cummings Publishing Company, Inc. 1995. This book should be required reading for any developer given primary responsibility for the design of the user interface. Collins addresses the proper construction of the system model and shows how they should be implemented.

Microsoft Press, The Windows Guidelines for GUI Design Chances are good your applications will have to run on Microsoft Windows platforms. Why not make certain it adheres to the standard?

Apple Macintosh Design Principles

The first set of important design principles was published by Apple Computer Corporation for Macintosh developers. The principles are based on the idea that the designer is creating a "world" that supports the user in the achievement of well-defined tasks. (In this article, the world created by the designer is referred to as the system model). These principles are summarized in the following table.

Apple Computer Design Principles
World-Building	The over-arching goal is to design a "world" that is natural and comfortable for users.
Use of metaphors	Use concrete metaphors and make them clear and understandable so that users have set of expectations to apply to computer environments. Whenever appropriate, use audio and visual effects that support the metaphor, but use these carefully. Gratuitous sounds, no matter how realistic, are annoying.
Aesthetic integrity	Visually confusing or unattractive displays detract from the effectiveness of human-computer interactions. Users should be able to control the superficial appearance of their computer work places-to display their own style and individuality. Messes are acceptable only if the user makes them-applications are not allowed this freedom.
Consistency	Effective applications are both consistent within themselves and with one another.
Perceived Stability	Users feel comfortable in a computer environment that remains understandable and familiar rather than one that changes randomly. A perfect example of what not to do can be found in the America Online user interface, which often automatically repositions windows. The net effect is to severely disrupt the users sense of trust in the application, detracting from the overall usability of the application.
World-Controlling	How do the user control the world created by the designers?
Direct manipulation	Every action has a concrete and logical effect. Each action results in the common-sense display of the new state of the object.
See and point	Users select actions from alternatives presented on the screen. The general form of user actions is "Object/Action", or "Hey, you--do this." Users rely on recognition, not recall; they shouldn't have to remember anything the computer already knows. For example, in a word processing application a user selects some text ("Hey you") and then chooses to apply formatting changes such as making the font boldface or underlined ("do this").
WYSIWYG (What you see is what you get)	There should be no secrets from the user, no abstract commands that only promise future results.
Feedback	Keep the user informed. User activities should be simple at any moment, though they may be complex taken together.
Forgiveness	Users make mistakes; forgive them. The user's actions are generally reversible-let users know about any that aren't.
User control	The user, not the computer, initiates and controls all actions. The user decides what is done, and in what order, period. If a designer feels that a certain action might be risky, they should by all means alert the user to this possibility. But don't prevent them from doing it. The design philosophy of the Macintosh assumes that users are intelligent and can decide for themselves what they need the program to do.

Nielsen and Molich Design Principles

Another important set of design principles were created by Nielsen and Molich, which are summarized in the following table.  (Adapted from Nielsen, J. Usability Engineering, New York, Harcourt Brace & Company, Publishers, 1993.)

Nielsen and Molich Design Principles
Use a simple and natural dialog	Simple means no irrelevant or rarely used information. Natural means an order that matches the task.
Speak the user's language	Use words and concepts that match in meaning and intent the user's mental model. Don't use system-specific engineering terms. When presenting information, use an appropriate tone and style. For example, a dialog written for a children's game would not use the same style as a dialog written for a assembly line worker.
Minimize user memory load	Don't make the user remember things from one action to the next by making certain each screen retains enough information to support the task of the user. I refer to this as the "scrap of paper" test. If the user ever needs to write a critical piece of information on a piece of paper while completing a task, the system has exceeded memory capacity.
Be consistent	Users should be able to learn an action sequence in one part of the system and apply it again to get similar results in other places.
Provide feedback	Let users know what effect their actions have on the system. Common forms of feedback include changing the cursor, displaying a percent-done progress indicator, and dialogs indicating when the system changes state in a significant manner.
Provide clearly marked exits	If users get into part of the system that doesn't interest them, they should always be able to get out quickly without damaging anything. Examples of clearly marked exits include the consistent and correct use of Cancel buttons and an "undo" feature.
Provide shortcuts	Shortcuts can help experienced users avoid lengthy dialogs and informational messages that they don't need. Examples of shortcuts include keyboard accelerators in menus and dialogs. More sophisticated examples include command-based searching languages. Novice users can use a simple interface, while experienced users can use the more advanced features afforded by the query language.
Prevent errors	Whenever a designer begins to write an error message they should ask: Can this error be prevented, detected and fixed, or avoided altogether? If the answer to any of these questions are yes, additional engineering effort should be expended to prevent the error.
Good error messages	There are many times the system cannot prevent an error (e.g., a printer runs out of paper). Good error messages let the user know what the problem is and how to correct it ("The printer is out of paper. Add paper to continue printing.")