Hello, Joe! It was good to get your e-mail. Congratulations on your promotion to director and your increased project responsibility. You asked for some advice on how to ensure that your applications are able to be used by your users. It seems that all my ranting and raving when we worked together had an impact. I'm thrilled about that!
Obviously, I can't possibly provide you with a full grounding in usability and humancomputer interface (HCI) design in the short space of this note. Instead I'll discuss some of the statements I've frequently heard from managers, developers, and others who don't realize the benefits of applying usability activities during software design and development. I'll explain why these are myths, using some examples from the projects we've worked on together.
Curiously, the very people who voice these beliefs often attest to the need to have usable software and systems. I find this inconsistency is usually due to a lack of understanding. Use this list of myths as an early warning system: If you hear members of your team, your management, or even yourself making pronouncements such as these, step back and assess what the implications may be for your applications and your users.
Myth #1: Usability only increases development costs and lengthens development time.
If it is applied too late in the development process or when it is treated as a disposable add-on rather than an integral part of development, usability can appear to increase cost and time. Unfortunately, it is often treated as an afterthought or as merely one component of final quality assurance (QA) testing. The problem with that approach is that after coding is complete, design changes are much larger, time-consuming tasks than if they are done early. In actuality, applied usability practices can lower overall development cost and time by reducing or eliminating the need for rework and updates. Paraphrasing the IBM ease-of-use website:
It pays to make ease of use a priority from the beginning. Industry data show that each dollar spent on user studies during product design saves $10 on problem fixes during product development, or $100 or more in rework after product release. Also, maintenance costs can be substantially reduced if user requirements are gathered at the beginning of a project. It's estimated that 80% of maintenance costs are spent on unforeseen user requirements, while only 20% are due to bugs.
Myth #2: The user interface is really just adding good graphics to make the application appealing.
Many people misinterpret the visual design of an interface as the interface itself, but doing so ignores the entire interaction sequence needed to complete a task. Watching people using a difficult interface might show them slowed by a visually cluttered screen or they may not feel it is aesthetic, but their real difficulty arises when they can't figure out their next action or are surprised when they arrive at an unexpected location in the application. Remember our first attempt at an intranet, Joe? It looked great, the layout was pleasing, and the graphics were excellent; yet, the major complaint was that it took too many clicks and page loads to find any information. Finding someone's phone number usually required navigating five screens of choices.
Myth #3: Usability is user interface design.
This is like saying that database design is defining fields and field lengths. It is simple to restate this erroneous view to convert it from a myth to reality: "Good user interface design is the result of properly applied usability techniques and practices." This would include carefully and precisely identifying who the users are, their capabilities, their goals, the tasks they need to perform to achieve their goals, and the context in which they will be using the software.
Myth #4: Usability is really just common sense.
In retrospect, everything is just common sense! Since all designers and developers have common sense, why do we have so much software that is difficult to use? An excellent example of the fallacy here was the HR [human resources] self-service project we did last year. Instead of using paper forms for changes in benefits, such as the addition of a child as a new dependent, users would fill out an electronic form at an intranet site. We built the system with a fourth-generation development tool and environment.
Many of these forms contained one or more required date fields. Using common sense, the developer defined these fields as the tool's intrinsic date field. The version of the development tool we were using demanded a specific format in date entry fields, remember? It would reject the slightest deviations as incorrect. A serious problem was immediately apparent during usability testing, when several participants were unable to complete a date field "correctly" after multiple attempts over several minutes. Furthermore, there was no way to modify or intercept the tool's cryptic error message "There is invalid data in the form." We ended up specifying the date fields as plain text that accepted any date format, then parsing the user's entry and correctly populating the real, hidden, date fields. Just common sense, right? (Not!)
Myth #5: As long as developers are familiar with guidelines, good user interfaces will be designed.
User interface guidelines can greatly assist in the design of software. Most guideline recommendations come from human-factors research and incorporate best practice in interface design. However, anyone who believes that following any set of guidelines will ensure a usable interface is sadly mistaken.
Guidelines and standards are good at things like specifying the placement and spacing of buttons in a dialog box, and they can assist in the selection and use of interface controls. If the guidelines are tailored to be company specific, items such as the standard color palette and unique terminology can be included. Selection of an appropriate set of guidelines is not a trivial task, however, and tailoring them to be specific for your organization is a significant undertaking.
Guidelines can ease the design process by reducing the number of look and feel decisions that need to be made, but they address only a fraction of the questions that come up during interface development. The major difficulty of guidelines is that they are general in nature and do not address the specifics of the problem at hand. A guideline might state, "Allow the user to cancel a potentially destructive action;" however, it will not specify how to accomplish this. How many times have you seen this implemented with the ubiquitous confirmation dialog box? It seems that every time you attempt to overwrite a file, delete a website, or modify a template, you're pummeled with "Are you sure?" "Are you sure?" Would you put up with an employee who asked this after you gave each assignment? Have you ever accidentally clicked on "Yes" when it was the one time you weren't sure? A much better implementation would be to allow unlimited undo of actions so that nothing is irreversible.
Adherence to a set of guidelines during the development of the user interface (UI) is certainly better than designing by guesswork, but just be aware of their limitations.
Myth #6: Usability testing is not needed if the development team has been working with the users a long time and knows what they want.
This one always surprises me. Simply put, even if the design team does succeed in "knowing what the users want," this does not necessarily mean they have identified what the users need. Like any other software aspects, interface design assumptions need to be validated by testing. In any system, database models are validated with walkthroughs, and database designs are tested. Program modules are designed, implemented, tested, and redesigned as necessary. System architecture is validated. Integration testing can last weeks. Why should the design of the UI be any different or any less important?
Sometimes the myth that usability testing will not reveal anything useful is expressed as, "Well, we (the developers) use it all the time, so how is usability testing going to tell us anything we don't know?" The problem here is that the developers do not have the same job, thus do not have the same goals, tasks, knowledge, or skills as the end users. It is just not possible for them to use the software in the same manner as the actual users. Having built the software, the developers are so familiar with its operation and idiosyncrasies that any difficulties have ceased to be noticed.
Remember our first iteration of the data warehouse report module, Joe? Would you say the developers knew and behaved like users? This module allowed a user to select a predefined report and specify parameters such as products, time periods, geographic areas, and financial measures to tailor the report. The developers' functional testing of single reports and parameter sets demonstrated that these features worked as designed. However, they had not included a capability to save these user-defined parameter sets. Although it was acceptable to the headquarters analysts (who tended to run a single report once), most of the users were field sales personnel who had responsibility for specific products and geographic areas. These people ran the same reports with the same parameters weekly or even daily and were completely overlooked in interface design. Each time they ran a report, they had to endure a repeat of the parameter selection process. Only after a "save custom report" capability was added did the user community accept the system.
Myth #7: "We'll handle that in the help/training/documentation."
All of these statements are saying the same thing: We'll supply the user with a halfhearted attempt to address a poor design, by giving them workarounds with other materials. It may seem to be a truism, but users really do tend not to use online help systems or read documentation. In his 1991 booklet Secrets of User-Seductive Documentation, William Horton noted that in one survey, more than 90 percent of users ignored system manuals and 60 percent refused to read a minimal four-page instruction manual.
More recently, User Interface Engineering reported in 1997 (R. Danca, personal communication) that when users described their use of documentation and reference materials:
- 9 percent read the printed "Users' Guide"; 80 percent skim it.
- 11 percent read printed tutorials; 26 percent skim them.
- 11 percent read printed reference manuals; 46 percent skim them.
- 17 percent read printed reference or hint cards; 35 percent skim them.
- 7 percent read online documents; 54 percent skim them.
- About 40 percent say they run online tutorials.
The results of both of these surveys are open to interpretation and are also somewhat dated, and certainly they should not be construed as an argument against providing documentation and help. However, the implication is clear: You cannot depend on documentation to overcome a usability problem.
Well, Joe, I've only been able to scratch the surface here; the list is truly endless. There are many more myths about usability that you will encounterand you probably have some of your own. (I know, I've heard you in meetings!) Your best defense is to raise your own awareness and that of your team. These books are excellent starting points: The Trouble With Computers, by Thomas Landauer; Usability Engineering, by Jakob Nielsen; and Cost Justifying Usability, by Randolph Bias and Deborah Mayhew.
I wish you the best of luck, Joe. Drop me a line and let me know how things are going. Oh, yes, and hire a usability professional for your team!
Bias, R.G., and Mayhew, D.J. (eds.). Cost-Justifying Usability. Academic Press, Boston, MA, 1994.
Horton, W. Secrets of User-Seductive Documentation: Wooing and Winning the Reluctant Reader. Publication # STC-136-91r. ISBN 0-91458-60-3. Society for Technical Communication, Arlington, VA, 1991.
IBM Ease of Use (http://www.ibm.com/easy). Specific reference at http://www-3.ibm.com/ibm/easy/eou_ext.nsf/Publish/23
Landauer, T.K. The Trouble with Computers: Usefulness, Usability, and Productivity. The MIT Press, Cambridge, MA, 1995.
Nielsen, J., Usability Engineering. Academic Press, Boston, MA, 1993.
Spool, J., et al. Eye for design. User Interface Engineering (JulyAugust 1997). North Andover, MA (www.uie.com).
Marc Chrusch is the Director of Usability and Design at Flywheel Media in Stamford, CT, where he is responsible for the usability of Flywheel's technology and content products. A former systems developer with experience in an assortment of languages, platforms, and development methodologies, Marc began writing software in the mid-1980s and for the past 8 years has focused on usability and user interface design. In a distant past life he was a food scientist involved with new product development in several food and beverage companies. When he's away from work, you will usually find him in the mountains, dancing with gravity. Marc can be reached at firstname.lastname@example.org
Whiteboard Column Editor
Senior Principal Engineer
Computer Sciences Corporation
15245 Shady Grove Road
Rockville, MD 20850
©2000 ACM 1072-5220/00/0900 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2000 ACM, Inc.