Usability: Happier Users Mean Greater Profits

This article was downloaded by: [DUT Library]On: 04 October 2014, At: 17:28Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House,37-41 Mortimer Street, London W1T 3JH, UK

Information Systems ManagementPublication details, including instructions for authors and subscription information:http://www.tandfonline.com/loi/uism20

Usability: Happier Users Mean Greater ProfitsLuke Hohmann aa A usability expert who is a frequent author and speaker on the topic.Published online: 21 Dec 2006.

To cite this article: Luke Hohmann (2003) Usability: Happier Users Mean Greater Profits, Information Systems Management,20:4, 66-76, DOI: 10.1201/1078/43647.20.4.20030901/77295.10

To link to this article: http://dx.doi.org/10.1201/1078/43647.20.4.20030901/77295.10

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the “Content”) containedin the publications on our platform. However, Taylor & Francis, our agents, and our licensors make norepresentations or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of theContent. Any opinions and views expressed in this publication are the opinions and views of the authors, andare not the views of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon andshould be independently verified with primary sources of information. Taylor and Francis shall not be liable forany losses, actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoeveror howsoever caused arising directly or indirectly in connection with, in relation to or arising out of the use ofthe Content.

This article may be used for research, teaching, and private study purposes. Any substantial or systematicreproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in anyform to anyone is expressly forbidden. Terms & Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions

http://www.tandfonline.com/loi/uism20

http://www.tandfonline.com/action/showCitFormats?doi=10.1201/1078/43647.20.4.20030901/77295.10

http://dx.doi.org/10.1201/1078/43647.20.4.20030901/77295.10

http://www.tandfonline.com/page/terms-and-conditions

http://www.tandfonline.com/page/terms-and-conditions

66 I N F O R M A T I O N S Y S T E M S M A N A G E M E N T

F A L L 2 0 0 3

USABILITY: HAPPIER USERS MEAN GREATER PROFITS

Luke Hohmann

Historically, usability has been associated with the user interface, and human–computer inter-action (HCI) professionals have tended to concentrate their work on it. Usability is, however, much deeper than the user interface. Usability refers to the complex set of choices that ends up allowing the users of the system to accomplish one or more specific tasks easily, efficiently, enjoyably, and with a minimum of errors.

RCHITECTING A SYSTEM TO BE US-ABLE is a lot of work but it is worth it. A large amount of compelling evidence in-dicates that usability is an investment

that pays for itself quickly over the life of the product. A detailed analysis of the economic impact of usability is beyond the scope of this article but anecdotal evidence speaks strongly about the importance of usability. One system the author of this article worked on was used by one of the world’s largest online retailers. A single telephone call to customer support could destroy the profits associated with two dozen or more successful transactions. In this case, usability was paramount. Other applica-tions may not be quite as sensitive to usability but practical experience demonstrates that ex-ecutives routinely underestimate the impor-tance of usability.

The benefits of usable systems include any or all of the following, each of which can be quantified:

❚❚ Reduced training costs❚❚ Reduced support and service costs❚❚ Reduced error costs❚❚ Increased productivity of users❚❚ Increased customer satisfaction❚❚ Increased maintainability

Given the wide range of areas in which im-proving usability can reduce costs and increase profits, it is easy to see why senior managers should care about usability, and make creating usable systems a primary requirement of all de-velopment efforts.

CREATING USABLE SYSTEMSCreating usable applications centers around four key processes:

1. Understanding users. The cornerstone of creating usable applications is based on an intimate understanding of the users, their needs, and the tasks that must be accom-plished. The outcome of this understanding results in a description of the users’ mental model. A mental model is the representa-tion of the problem users have formed as they accomplish tasks. Understanding men-tal models enables designers to create sys-tem models that supplement and support users. System models are, in turn, conveyed to users through the use of metaphors.

2. A progression from “lo-fidelity” to “hi-fidel-ity” systems. Building usable applications is based on a gradual progression from “lo-fidelity” paper-and-pencil-based prototypes to “hi-fidelity” working systems. Such an

A

LUKE HOHMANN is a usability expert who is a frequent author and speaker on the topic.

USABILITY

Dow

nloa

ded

by [

DU

T L

ibra

ry]

at 1

7:28

04

Oct

ober

201

4

67I N F O R M A T I O N S Y S T E M S M A N A G E M E N T

F A L L 2 0 0 3

USABILITY

approach encourages exploration through low-cost tools and efficient processes until the basic structure of the user interface has been established and is ready to be realized as a working computer system.

3. Adherence to proven principles of design. Through extensive empirical studies, Human-Computer Interaction (HCI) profes-sionals have published several principles to guide the decisions made by designers. These simple and effective principles tran-scend any single platform and dramatically contribute to usability. The use of design principles is strengthened through the use of usability specifications, quantifiable statements used to formally test the usabil-ity of the system (e.g., the application must load within 40 seconds). If you are new to usability, start by focusing on proven princi-ples of design. If you want to formalize the goals you are striving to achieve, require your marketing or product management organizations to include usability specifica-tions in your requirements documents.

4. Usability testing. Each result produced dur-ing development is tested — and retested —with users and iteratively refined. Testing provides the critical feedback necessary to ensure designers are meeting user needs. An added benefit of testing is that it involves users throughout the development effort, encouraging them to think of the sys-tem as something they own and increasing system acceptance.

UNDERSTANDING USERSThe cornerstone of creating usable applica-

tions is based on an intimate understanding of

the users, their needs, and the tasks that must

be accomplished. One of the very best ways to

create this understanding is through a simple

user and task analysis. Once these are com-

plete, a function assignment can be per-

formed to clearly identify the distribution of

tasks between the user and the system, which

leads to the development of the mental model

(see Exhibit 1).

User AnalysisThe purpose of a user analysis is to clearly de-

fine who the intended users of the system real-

ly are, through a series of context-free, open-

ended questions. Such questions might in-

clude:

❚❚ Experience:– What is the expertise of the users? Are they

experts or novices?– Are they comfortable with computers and

GUIs?– Do they perform the task frequently or

infrequently?– What problem domain language would the

users most easily understand?❚❚ Context:

– What is the working environment?– Is work done alone or in a group? Is work

shared?– Who installs, maintains, and administers

the system?– Are there any significant cultural or inter-

nationalization issues that must be man-

aged?❚❚ Expectations:

– How would the users like the system to

work?– What features do they want? (If users have

difficulty answering this question, propose

specific features and ask if the user would

like or dislike the specific feature).– How will the current work environment

change when the system is introduced?

(Designers may have to propose specific

changes and ask if these changes would be

considered desirable).

Asking these questions usually takes no more

than a few hours, but the data the answers pro-

vide is invaluable to the success of the project.

EXHIBIT 1 User and Task Analysis

User and Task Analysis

Function Assignment

Task Analysis

User Analysis

Mental ModelDevelopment

Dow

nloa

ded

by [

DU

T L

ibra

ry]

at 1

7:28

04

Oct

ober

201

4


F A L L 2 0 0 3

USABILITY

Task AnalysisTask analysis seeks to answer two very simple questions: (1) What tasks are the users doing now that the system will augment, change, en-hance, modify, or replace? (2) What tasks will the users perform in the new system?

The first phase of task analysis is to develop a clear understanding of how the system is cur-rently being used, using the process outlined in Exhibit 2.

The last step, that of creating an overall roadmap, is especially important for projects involved with replacing an existing user inter-face with a redesigned user interface. Common examples of this include replacing aging main-frame systems with modern Web-based appli-cations or creating an entirely new system to work beside an existing system, such as when a voice-based application is added to a call center.

The second phase of task analysis, that of describing how the new system will work, is often done through use cases. A use case is a structured prose document that describes the sequence of events between one or more ac-tors and the system as one of the actors (typi-cally the user) attempts to accomplish some task.

Function AssignmentAs users and tasks are identified, the specific functions detailed in the requirements spring to life and are given meaning through use cas-es. At this stage, it is often appropriate to ask if

the identified tasks should be performed by the user, performed by the system automatically on behalf of the user, or initiated by the user but performed by the system. This process is called function assignment, and can be absolutely es-sential in systems in which the goals are to au-tomate existing business processes.

To illustrate, consider an electronic mail system. Most automatically place incoming mail into a specific location, often an “in-box.” As a user of the system, did you explicitly tellthe mail system to place mail there? No. It did this on your behalf, usually as part of its default configuration. Fortunately, for those of us who are heavy e-mail users, we can override this de-fault configuration and create a variety of rules that allow us to automatically sort and process incoming e-mails in a variety of creative ways.

While most systems can benefit from a function assignment, it is an optional step in the overall development effort.

Mental Model DevelopmentThe final step of user and task analysis is to pro-pose various mental models of how the users think about and approach their tasks. Mental models are not documented in any formal man-ner. Instead, they are informal observations about how designers think users approach their tasks. For example, consider a designer creating a new project planning tool. Through several interviews she has discovered that man-agers think of dependencies within the project

EXHIBIT 2 Task Analysis

∑Use videotape∑Context-free questions

∑What is the "big picture?"

Dow

nloa

ded

by [

DU

T L

ibra

ry]

at 1

7:28

04

Oct

ober

201

4


F A L L 2 0 0 3

USABILITY

as a web or maze instead of a GANTT or PERTchart. This could provide insight into creative new ways of organizing tasks, displaying infor-mation, or providing notification of critical path dependencies.

Checklist

❚❚ We have identified a target population of rep-resentative users.

❚❚ We have created an overall roadmap of cur-rent users’ tasks.– If redesigning a current system, we have

made screen snapshots of every “screen” and have annotated each screen with a description of the task(s) it supports.

– If redesigning a current system, each task has a set of screen snapshots that describe, in detail, how users engage the system to accomplish the task.

❚❚ We have created a set of high-level use cases that document our understanding of the sys-tem as we currently understand it. These are specified without regard to any specific user interface that might be developed over the life of the project.

❚❚ We have reviewed our list of use cases with our users.

❚❚ All requirements are covered by the use cases.❚❚ No use case introduces a new requirement.❚❚ We have summarized our findings with a

description of the mental model of the users.❚❚ (Optional) We have performed a functional

assignment.

LO-FIDELITY TO HI-FIDELITY SYSTEMSThe common approach to building user inter-faces is based on taking the requirements, building a prototype, and then modifying it based on user feedback to produce a really us-able system. If you are lucky, and your users like your initial prototype, you are doing OK. More often than not, your users will want to change the initial prototype more than your schedule, motivation, or skills will allow. The result is increased frustration because users are asked to provide feedback into a process that is designed to reject it.

A more effective process is to start with lo-fidelity (lo-fi), paper-and-pencil prototypes, testing and developing these with users. Once you have a good sense of where to head, based on a lo-fi design, you can move to a hi-fidelity, fully functional system secure in the knowl-edge that you are going to produce a usable re-sult.

Lo-Fi DesignA lo-fi design is a low-tech description of the proposed user interface. For a GUI, it is a pa-per-and-pencil prototype. For a VUI (voice-based user interface), it a script that contains prompts and expected responses. The remain-der of this section assumes that you are creat-ing a GUI; you will find that you can easily extend these techniques to other user interfaces.

Specific objectives of a lo-fi design include:

❚❚ Clarifying overall application flow❚❚ Ensuring that each user interaction contains

the appropriate information❚❚ Establishing the overall content and layout of

the application❚❚ Ensuring that each use case and requirement

is properly handled

The basic activities, as outlined in Exhibit 3, consist of developing a storyboard, creating a lo-fidelity prototype, and beginning the testing process by testing the prototype with repre-sentative users. Among the inputs to this activ-ity are the conceptual model (perhaps created through a process like the Rational Unified Pro-cess) or an information model (an entity-rela-tionship model for traditional systems or a class diagram for object-oriented systems) and de-sign guidelines.

Capturing the System Model: The Role of MetaphorThe system model is the model the designer creates to represent the capabilities of the sys-tem under development. The system model is analogous to the mental model of the user. As the users use the system to perform tasks, they will modify their current mental model or form a new one based on the terminology and oper-ations they encounter when using the system. Usability is significantly enhanced when the system model supports existing mental models.

To illustrate, your mental model of an airport enables you to predict where to find ticket counters and baggage claim areas when you ar-rive at a new airport. If you were building a sys-tem to support flight operations, you would want to organize the system model around such concepts as baggage handing and claim areas.

A metaphor is a communication device that helps us understand one thing in terms of an-other. Usability is enhanced when the system model is communicated through a metaphor that matches the users’ mental model. For ex-ample, the familiar desktop metaphor popular-ized by the Macintosh and copied in the

Dow

nloa

ded

by [

DU

T L

ibra

ry]

at 1

7:28

04

Oct

ober

201

4


F A L L 2 0 0 3

USABILITY

Windows user interface organizes operations with files and folders as a metaphorical desk-top. The system model of files and folders meshes with the mental model through the use of the interface. Another example is data entry dialogs based on their paper counterparts.

In the design process, the designer should use the concept of a metaphor as a way of ex-ploring effective ways to communicate the sys-tem model and as a means of effectively supporting the users’ mental model. Resist blindly adhering to a metaphor, as this can im-pede the users’ ability to complete important tasks. For example, although the desktop met-aphor enables me to manage my files and fold-ers effectively, there is no effective metaphorical counterpart that supports run-ning critical utility software such as disk defrag-mentation or hard disk partitioning. A paper form may provide inspiration as a metaphor in a data entry system, but it is inappropriate to restrict the designer of a computer application to the inherent limitations of paper.

StoryboardingA storyboard is a way of showing the overall navigation logic and functional purpose of each window in the GUI. It shows how each task identified in the task analysis and de-scribed in the use cases can be accomplished in the system. It also shows primary and sec-ondary window dependencies, and makes ex-plicit the interaction between different dialogs in the user interface. (A primary window is a main application window. A secondary window is a

window such as a dialog). The storyboard of-ten expands on the system model through the metaphor and clarifies the designers’ under-standing of the users’ mental model.

An example of a simple storyboard for a mail system is shown in Exhibit 4. The example shows the name of each window, along with a brief description of the window contents. A solid line means the users’ selection will open a primary window, while a dashed line indi-cates the opening of a modal dialog. The nota-tion used for storyboards should be as simple as possible. For example, in the earliest phases of system design, using a simple sheet of paper with Post-It notes representing each window is an effective way to organize the system.

Storyboards have an additional benefit in that they can show the overall “gestalt” of the system. The author of this article has seen sto-ryboards as large as three by six feet, packed with information yet entirely understandable. This storyboard provided the development staff with a powerful means of making certain that the overall application was consistent. The storyboard also enabled the project manager to distribute the detailed window design to spe-cific developers in a sensible way, as the com-mon relationships between windows were easy to identify.

The development of the storyboard should be guided by the use cases. Specifically, it should be possible to map each operation de-scribed in a use case to one or more of the win-dows displayed in the storyboard. The mapping of specific actions to user interface

EXHIBIT 3 Lo-Fi Prototype Design

Lo-Fi Prototype Design

Simulated Prototype

Lo-Fi Prototype

Storyboard

Mental Model

Design Guidelines

Task Analysis

Information Model

Metaphor Evaluation

Dow

nloa

ded

by [

DU

T L

ibra

ry]

at 1

7:28

04

Oct

ober

201

4


F A L L 2 0 0 3

USABILITY

widgets will come at a later stage in the devel-opment process.

Lo-Fi Window DesignFollowing the storyboard, the design process proceeds to the development of the initial lo-fi window designs. During this phase, the design-er takes paper, pencil, and many erasers and prepares preliminary versions of the most im-portant windows described in the storyboard. A good starting point for selecting candidates for lo-fi design includes any windows associat-ed with important or high-priority use cases.

One critical decision point in lo-fi window design is determining the information that should be displayed to the user. The basic rule-of-thumb is to only display the information needed to complete the task. By mapping use cases to the data model, you can usually identi-fy the smallest amount of data required to com-plete a task. Alternatively, you can simply show your storyboard to your users and add the de-tail they think is required. The resultant infor-mation can be compared with data models to ensure that all data has been captured.

Creating a lo-fi window design is fun. Freed from the constraints of the control palette asso-ciated with their favorite IDE (integrated devel-opment environment), designers tend to concentrate on design and user needs instead of implementation details. The fun part of the design process includes the tools used to cre-ate lo-fi designs. The following items should be easily accessible for lo-fi window design:

❚❚ Scissors❚❚ Glue

❚❚ Clear and colored overhead transparencies❚❚ White correction paper❚❚ A computer with a screen capture program

and a printer❚❚ Clear tape❚❚ “Whiteout”❚❚ A photocopier

A computer and a printer are included on this list because it is often more practical to print standard widgets and screens, such as corpo-rate-defined standards for buttons or the stan-dard file open dialog provided by the operating system, than try to draw them by end. Once printed, these can be glued, taped, or other-wise used in the lo-fi design. This does mean that a lo-fi design is a mixture of hand-drawn and computer-generated graphics. In practice, this mixture does not result in any problems.

While the practical use of a computer dur-ing lo-fi design is acceptable in an appropriate role, it is important to realize that developers should not be attempting to create lo-fi designs on a computer. Doing so defeats many of the fundamental goals of lo-fi design. Paper-and-pencil designs are more amenable to change and are often created faster than similar designs created in an IDE. More importantly, designers who create their designs in a computer are less likely to change them, primarily because the amount of effort put into a computer design in-creases the designers’ psychological attach-ment to the design. This increased attachment means a greater reluctance to change it, which defeats the purpose of the design.

A final reason to use lo-fi prototypes is that designers who create their initial designs on a

EXHIBIT 4 Simple Storyboard for a Mail System

SuperMail

This is the main userinterface for SuperMail.It presents a menu ofoperations. Create Message

User enters text ofmessage andrecipients.

User selects "Create Message"

Address Lookup

User can selectaddressees from a list.

Modal Dialog

Dow

nloa

ded

by [

DU

T L

ibra

ry]

at 1

7:28

04

Oct

ober

201

4


F A L L 2 0 0 3

USABILITY

computer tend to worry about how they will make these designs “work.” Specifically, they start worrying about how to connect the user interface to the business logic, or how to for-mat data to meet the needs of the user. The re-sult is premature emphasis on making things work rather than exploring design alternatives.

Checklist

❚❚ We have created a storyboard that details the overall navigation logic of the application.

❚❚ We have traced each use case through the storyboard.

❚❚ We have created a data (or object) model that describes the primary sources of information to be displayed to the users and the relation-ships among these items.

❚❚ We have transformed our storyboards into a set of lo-fi prototypes.

❚❚ The lo-fi prototypes were created using paper and pencil.

❚❚ All information displayed in the lo-fi proto-type can be obtained from the entity-relation-ship or object model or from some other well-known source.

DESIGN PRINCIPLESWhile usability testing is the only way to be cer-tain that the user interface is usable, there are several well-known and validated principles of user interface design that guide the decisions made by good designers. These principles are platform and operating system independent, and they are applicable in almost any environ-ment. Adherence to these principles is becom-ing increasingly important in the era of Web development, as there are no universal stan-dards for designing Web-based applications. This section presents a consolidated list of de-sign principles that have stood the test of time, drawing heavily from the design principles published by Apple Computer Corporation and user interface researcher Jakob Nielson, a co-founder of the Nielson-Norman consulting company (see Exhibit 5).

Checklist

❚❚ Each developer has been given a copy of the design principles.

❚❚ Each developer has easy access to a copy of the platform standards. Ideally, each devel-oper is given a copy of the platform stan-dards and the time to learn them.

❚❚ Each error situation has been carefully exam-ined to determine if the error can be removed from the system with more effec-tive engineering.

❚❚ Management is prepared to properly collect and manage the results of the usability inspection.

SIMULATED PROTOTYPINGThere are many kinds of testing systems in soft-ware development: performance, stress, user acceptance, etc. Usability testing refers to test-ing activities conducted to ensure the usability of the entire system. This includes the user in-terface and supporting documentation, and in advanced applications can include the help sys-tem and even the technical support operation. A specific goal of lo-fi prototyping is to enable the designer to begin usability testing as early as possible in the overall design process through a technique called simulated proto-typing.

Simulated prototyping means that the oper-ation of the lo-fi system is simulated. Quite lit-erally, a representative user attempts to complete assigned tasks using the prototype with a human playing the role of the computer. Before describing how to conduct a simulated prototype test, let us first explore what results the test should produce.

A simulated prototyping session should produce a report that includes the following three items. First, it must be clearly identified for tracking purposes. Second, it must identify all individuals associated with the test. Partici-pants are not identified by name, but by an anonymous tracking number. Referring to the users involved with the test as participants rather than subjects encourages an open and friendly atmosphere and a free-flowing ex-change of ideas. The goal is to keep partici-pants as comfortable as possible. Third, and most importantly, it must clearly summarize the results of the test.

It is common to see test results concentrat-ing on the negative responses associated with the prototype, but designers should also be looking for the positive responses exhibited by the user. This will enable them to retain the good ideas as the prototype undergoes revi-sion. Unlike a source code review report, the results of the simulated prototype can provide solutions to problems identified during testing.

Dow

nloa

ded

by [

DU

T L

ibra

ry]

at 1

7:28

04

Oct

ober

201

4


F A L L 2 0 0 3

USABILITY

Conducting the TestA simulated prototype is most effective when

conducted by a structured team consisting of

between three and five developers. The roles

and responsibilities of each developer associ-

ated with a simulated prototype are described in Exhibit 6 (developers should rotate roles between successive tests, as playing any sin-gle role for too long can be overly demand-ing).

EXHIBIT 5 Consolidated List of Design Principles

Principle Description

Use concrete metaphors

Concrete metaphors are used to make the application clear and understandable to the user. Use audio, visual, and graphic effects to support the metaphor. Avoid any gratuitous effects; prefer aesthetically sleek interfaces to those that are adorned with useless clutter.

Be consistent Effective applications are both consistent within themselves and with one another. There are several kinds of consistency that are important: The first is platform consistency, which means the application should adhere to the platform standards on which it was developed. For example, Windows specifies the exact distance between dialog buttons and the edge of the window, and designs should adhere to these standards. Each developer associated with the design of the user interface should be given a copy of the relevant platform standards published by each vendor. This will ensure that the application is platform compliant from the earliest stages of development.

The second is application consistency, which means that all of the applications developed within a company should follow the same general model of interaction. This second form of consistency can be harder to achieve as it requires the interaction and communication between all of the development organizations within a company.

A third kind of consistency is task consistency. Similar tasks should be performed through similar sequences of actions.

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. Make certain the kind of feedback is appropriate for the task.

Prevent errors

Whenever a designer begins to write an error message, he should ask: Can this error be prevented, detected and fixed, or avoided altogether? If the answer to any of these questions is yes, additional engineering effort should be expended to prevent the error.

Provide corrective advice

There are many times when 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”).

Put the user in control

Usable applications minimize the amount of time that they spend controlling user behavior. Let users choose how they perform their tasks whenever possible. If you feel that a certain action might be risky, alert users to this possibility, but do not prevent them from doing it unless absolutely necessary.

Use a simple and natural dialog

Simple means no irrelevant or rarely used information. Natural means an order that matches the task.

Speak the users’ language

Use words and concepts that match in meaning and intent the users’ mental model. Do not 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 an assembly-line worker.

Minimize user memory load

Do not make users 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.)

Provide shortcuts

Shortcuts can help experienced users avoid lengthy dialogs and informational messages that they do not 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.

Dow

nloa

ded

by [

DU

T L

ibra

ry]

at 1

7:28

04

Oct

ober

201

4


F A L L 2 0 0 3

USABILITY

Selecting users for the simulated prototype must be done rather carefully. It may be easy to simply grab the next developer down the hall, or bribe the security guard with a bagel to come and look at the user interface. However, unless the development effort is focused on building a CASE tool or a security monitoring system, the development team has the wrong person. More specifically, users selected for the test must be representative of the target popu-lation.

If the system is for nurses, test with nurses. If the system is for data entry personnel, test with data entry personnel. Avoid testing with friends or co-workers unless developers are practicing “playing” computer. It is critically important that designers be given the opportu-nity to practice playing computer. At first, de-velopers try to simulate the operation of the user interface at the same speed as the comput-er. Once they realize this is impossible, they be-come skilled at smoothly simulating the operation of the user interface and provide a quite realistic experience for the participant.

During the simulated prototype, make cer-tain developers have all of their lo-fi prototyp-ing tools easily available. A lot of clear transparency is necessary, as they will place this over screens to simulate input from the us-er. Moreover, having the tools available means they will be able to make the slightest on-the-fly modifications that can dramatically improve the quality of the user interface, even while the “computer” is running.

The test is run by explaining the goals of the test to the participants, preparing them, and having them attempt to accomplish one or more tasks identified in the task analysis. While this is happening, the observer(s) carefully watch the participants for any signs of confu-sion, misunderstanding, or an inability to com-plete the requested task. Each such problem is noted on a 3×5 card for further discussion once the test is completed. During the simulated prototype, designers will often want to “help” participants by giving them hints or making suggestions. Do not do this, as it will make the results of the test meaningless.

The entire test — preparing to run the test, greeting the users and running the test, and dis-cussing the results — should take about two hours. Thus, with discipline and practice, an experienced team can actually run up to four tests per day. In practice, it is better to plan on running two tests per day so that the develop-ment 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 in the overall development pro-cess.

Finally, one final word on selecting and managing participants. Remember that they are helping create a better system. The system is being tested, not the participants. Partici-pants must feel completely free to stop the test at any time should they feel any discomfort.

EXHIBIT 6 Developer Roles and Responsibilities with a Simulated Prototype

Role Responsibilities

Leader • Organizes and coordinates the entire testing effort• Responsible for the overall quality of the review (i.e., a good review of a poor user interface pro-

duces 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 test — the only person allowed to speak• Performs three essential functions:• Gives the user instructions• Encourages users to “think aloud” during the test so observers can record users’ reactions to

the user interface• 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, etc.

• Must know application logic

Observer • Takes notes on 3×5 cards, one note per card

Dow

nloa

ded

by [

DU

T L

ibra

ry]

at 1

7:28

04

Oct

ober

201

4


F A L L 2 0 0 3

USABILITY

Checklist

❚❚ We have prepared a set of tasks for simulated prototype testing.

❚❚ A set of participants who match the target user population have been identified.

❚❚ Any required legal paperwork has been signed by the participants.

❚❚ Our lo-fi prototype has been reviewed — we think it supports these tasks.

❚❚ The simulated prototyping team members have practiced their roles.

❚❚ The “computer” has simulated the operation of the system.

❚❚ We have responded to the review report and made the necessary corrections to the user interface. We have scheduled a subsequent test of these modifications.

HI-FI DESIGN AND TESTINGOnce simulated prototyping has validated the lo-fi prototype, the design process moves into the last stage before implementation: the cre-ation of the hi-fidelity (hi-fi) prototype. This is an optional step in the overall process and can be safely skipped in many circumstances. Skip-ping this step results in taking the lo-fi proto-type and simply implementing it without further testing or feedback from users.

Motivations for creating and testing a hi-fi prototype include ensuring that there is suffi-cient screen real estate to display the informa-tion identified in the lo-fi prototype, checking detailed art or graphics files, and making cer-tain that the constraints of the delivery plat-form do not invalidate prior design decisions. Hi-fi prototypes are required when the design team has created a customized component, such as a special widget to represent a unique object. These must be tested to ensure they will work as desired.

A hi-fi prototype allows developers to en-hance presentation and aesthetics through the use of fonts, color, grouping, and whitespace. Doing this most effectively requires experience with graphic design, a rich topic beyond the scope of this article. However, graphic design details substantially contribute to overall feel-ings of aesthetic enjoyment and satisfaction, and should be considered an essential activity in the overall development effort. Unless the development team has solid graphic design ex-perience, the choice of fonts should be kept simple, using predominantly black on white text and avoiding the use of graphics as adorn-ments.

If you are taking the time to build a hi-fi pro-totype before final implementation, test it with a few users. Doing so will help clarify issues that are difficult or impossible to test in a lo-fi design, such as when a button should be en-abled or disabled based on prior user input, re-sponse times for key system operations, or the operation of custom controls.

While the results of a hi-fi prototype test are the same as a lo-fi test, the process is substan-tially different. First, the test environment is dif-ferent. It is typically more formal, with tests conducted within a usability lab, a special room with the equipment necessary to con-duct and run the test.

Second, the nature of the tasks being tested means that the structure of the test is different. For example, lo-fi prototypes are most effective at determining if the overall design created by the development team will be effective. Specif-ically, the lo-fi test should have helped deter-mine the overall structure of the user interface: the arrangement and content of menus, win-dows, and the core interactions between them. When the lo-fi testing is complete, the concep-tual structure of the interface should be well-understood and agreed upon with the users. The hi-fi test, on the other hand, should be or-ganized around testing one or more concrete performance variables.

The real managerial impact of hi-fi testing is twofold. First, there is question of finding the right individuals to conduct the test. Does the team have access to individuals who can prop-erly conduct a hi-fi test? Most development teams do not. While most developers can quickly and easily learn how to run an effective lo-fi test, conducting a properly structured hi-fi test requires significantly more training.

The second, and far more important ques-tion, is this: What is going to do be done with the results of the test? Like lo-fi test results, the results of a hi-fi test must be evaluated to deter-mine what, if any, modifications are needed in the user interface. The problem is that modify-ing a hi-fi prototype takes a substantial amount of design and coding, and, as discussed earlier, the likelihood of substantially changing prior design decisions decreases as the effort invest-ed in creating them increases. Do not test a hi-fi prototype if you are not willing to change it.

Checklist

❚❚ Our hi-fi test is measuring a specific perfor-mance variable.

Dow

nloa

ded

by [

DU

T L

ibra

ry]

at 1

7:28

04

Oct

ober

201

4


F A L L 2 0 0 3

USABILITY

❚❚ We have identified a qualified human factors specialist for hi-fi testing.

❚❚ We have prepared precise definitions of test requirements.

❚❚ We have secured the use of an appropriately equipped usability lab.

CONCLUSIONThe first main conclusion of this article deals with process. Creating usable systems is much more than following a series of checklists or ar-bitrary tasks. Ultimately, the process of creating usable systems is based on working to under-stand your users and performing a number of activities to meet their needs. These activities,

such as user and task analysis, lo-fi design, and simulated prototyping, must all be performed, keeping in mind the primary objective of creat-ing a usable system.

The second main conclusion of this article concerns motivation. There are several motiva-tions for creating usable systems, the most im-portant of which must be the goal to create satisfied customers. Satisfied users are satisfied customers, however you might define custom-er, and satisfied customers are the foundation of a profitable enterprise. Given the correlation between usability and profitability, it is impera-tive that senior management takes usability se-riously.

Dow

nloa

ded

by [

DU

T L

ibra

ry]

at 1

7:28

04

Oct

ober

201

4

Documents

Usability: Happier Users Mean Greater Profits