Ask any manager in charge of developing interactive products or consumer Web sites about the importance of usability. The response is emphatic: "It's critical to product success!" So you'd think usability engineers would be immune to the economic downturn. "They need us! They can't live without us!" Yet usability engineers are among the first to go when finances get tight. Something does not compute.
Being a manager responsible for project cost is tough. Tight finances are distinctly no fun. The project must be completed, and lowering costs as much as possible becomes critical, even if the product will be less than the vision. Good enough is good enough.
The question then becomes, "Good enough for what?" The same issue that has plagued the industry for ages"What do we mean by quality?"becomes "What do we mean by usable?"
After the first few incarnations of a product, the odds are that the basic capability is relatively usableat least for current users. Users who have succeeded in learning to use a product do not clamor to make it easier to learn. If anything, they'll claim that it's easy, as do usability test participants after wrestling with a task for an hour.
Management is likely to deem such a product usable. It may not be optimal; it could be better. But usability improvements are not required. It's okay for a new feature to be difficult to learn and use. All the critical features were included in the first release anyway. The new features are for comparing against those of competitors or for tempting users into buying the upgrade. And, if users were "smart enough" to figure out how the current package works, they should be smart enough to figure out how the upgrade works.
If a product fails to function out of the box, it's broken and must be fixed before release. A somewhat unusable product can be "corrected by explanation." If the product can be developed for less cost or completed sooner without usability improvements, usability engineers are not needed. Let 'em goreduce costs even more.
Company organization can also be a factor; product development is often insulated from customer support. Companies are continually trying to correct the lack of communication between the two. An even bigger gap than communication separates these departments, however: They usually have separate budgets.
A few years ago, a newspaper reported on a software company that was very proud of its customer support capability: hundreds of people staffing support phones and a marvelous answering system psychologically engineered for the enjoyment of ticked-off customers. What's more, the company was proud of how much it was spending on customer support. But as my colleague remarked, "Why don't they just fix the problems? It would be a hell of a lot cheaper."
When customer support is separated from product development, financially and organizationally, product development managers are even less responsible for usability. Downstream support costs are not their worry. They won't feel the impact that poor usability will have on customer support.
These development managers might be costing the company in brand infamybut if all the competitors' user interfaces suck, they are still among the best.
Usability engineers wouldn't be so soon laid off if management thought their usability expertise would accompany them out the door. Unfortunately, organizations seem to hold a belief that usability expertise is easy to come by. Countless readers of either Nielsen's Usability Engineering or Cooper's About Face have decided that they are now usability experts. Although both are good, useful books, I suspect neither Nielsen nor Cooper would claim that reading their books is sufficient ground for proclaiming oneself a usability expert.
Yet, we need to be careful to not discourage new people from entering the field or to set the bar too high. Few of us started out our careers as usability engineers. A certain level of skill, proficiency, and knowledge should be required for non-entry-level positions, but that does not include five years of experience with C++. When a help wanted advertisement for usability engineers requires programming or graphic design experience, it means that management still doesn't get it. Usability is not programming; it is not graphic design. It is designing the user experience. Even more, it is designing user capability.
Adding to the confusion are people who call themselves information architects. Many present themselves as quintessential user interface and Web designers. There's nothing wrong with that, in principleno set qualifications exist for a usability engineer, and usability experts come from a variety of fields with an even wider variety of experiences and knowledge.
The Web site of the American Society for Information Science and Technology (www.asis.org) defines information architecture as "using the patterns inherent in information to develop information structures and systems." The society's goal is to help people organize, find, and manage information. That's greatwe need such people. But go a little further and you find that information architects have the same skills and responsibilities as usability engineers. Where, then, is the difference?
The panel on information architecture at CHI 2001 defined the difference by stating, "Usability engineering is a subset of information architecture." Audience questioning revealed that none of the panelists appeared to know about the usability engineering life cycle. This is highly unfortunate. People who include "usability" in their job descriptions should be familiar with how their job is done.
Claims such as these and ignorance only add to the management belief that usability is entirely an issue of following design guidelines and testing. Usability engineers can be replaced by domain experts, developers, or testers who are familiar with usability guidelines, right? Just add a bit of user testing and a dash of common sense. After all, aren't all usability problems obvious to anyone with common sense?
A few clients have asked me to join a project "right at the start." They know it's important to bring in a usability expert at the beginning of a project. And oh, by the way, they tell me, the programmers were hired yesterday and they need to start coding immediately. Can't waste time getting to know users.
Why don't more companies allow time for user studies? Don't they know how critical it is to doing usability right? Well, they think they know the users already; and no, they don't realize how critical user studies are. Too often, the user is simply defined as the "average home computer user"so what's there to study?
Besides, marketing claims to know what the user needsno need for a user study. But marketing staff don't know how imperfect their understanding of the user may be. They don't realize that understanding user needs and behaviors requires both expertise and process.
What about this idea of the typical user? It seems an alien concept to design for the range of users instead of a vaguely specified typical user. Mention a subset of users (e.g., seniors, colorblind)...nope, too expensive to consider 10 percent of the users...better to design for the typical userwhich is approximately zero percent of the real users.
Experience has taught marketing professionals that they can be successful with a merely half-decent user interface. They can survive. In hard times, survival is all that's needed. User studies would be nice, but they weren't required previously, and now they are a luxury. Worse yet, studies may delay time to marketa sin committed only by the minions of Satan.
It takes a convincing story to get managers to realize that user studies can actually reduce the time to market. To tell this story, though, you need a good understanding of current product development practices and what usability engineering is really all about.
Software engineering got no respect in the early 1970s. Companies were incorporating minicomputers into their systems. Software was a necessary evil, but what was needed was usually simple to program. Anyone could be a "software engineer" even if the code he produced was structurally isomorphic to a common Italian dinner. Few software managers would insist on having systematic development processes. It added cost, and software had only to be good enough.
Usability engineering is now in a similar situation. Systematic process isn't needed, according to management. Nor are professional knowledge and experiencethat would add cost. Designing the user interface according to guidelines is sufficient, they claim. A colleague recently mentioned that a manager had asked him to review a user interface and identify where it didn't follow design guidelines. When my colleague pointed out that usability problems were more likely to be intrinsic faults regarding the fit of the user interface to the user and the task than to guideline misalignment, his services were declined.
Management needs to learn that good usability can save money. They need to find out that doing proper user studies up front results in less development churn and quicker time to market. They need to understand that intrinsically usable products developed with a deep understanding of the human factors of interaction can reduce customer support costs, increase user satisfaction (future sales), and improve brand reputation. They need to realize that incorporating the usability engineering life cycle into the product development life cycle reduces risk and increases profit.
Until we have conveyed these concepts, we will continue to suffer from a lack of respect.
We need to define ourselves well. Let's come to a common understanding about what an information architect is, what a usability engineer is, what skills each requires, and how they differ. While we're at it, we should specify what a usability specialist is and, for that matter, a usability architect.
We usability engineers must be active, knowledgeable participants in the entire product development processincluding the politics. We need to become part of the engineering team. We won't last as "in-house" consultants. A former employer of mine recently laid off a pioneering, center-of-excellence usability group. That staff had become "redundant." The usability engineers in the same company who were working cheek and jowl with other developers as integral members of a development group were kept on. This says something, and we must listen.
We need to educate and sell management on the value of the usability engineering life cycle. In the past, we've pushed usability as being great for the user. But who cares? Do you hear the users complaining? What's important is how usability will make money for the company. We need to convince management that usability will improve the balance sheet. We need to show that incorporating usability engineering into the product development life cycle is a big win for all.
Doing this won't be easy. We need to stop talking to ourselves and start talking with executives and managers about what usability really is and how it is done. We need to make sure they understand the difference between a faux usability expert and someone with real expertise and experience. We need to make them realize that real usability is not just testing or the following of guidelines but a process requiring in-depth knowledge.
We have got to make it clear that earnestness for usability by people trained in other disciplines is no substitute for earnestness and training in usability.
Usability Architects, Inc.
P.O. Box 3222
Kirkland, WA 98083
Jon Meads is a defrocked software engineer and manager who became concerned back in the 60's about the need to design to meet users' perceptual and cognitive needs as well as their practical and functional requirements. Jon has served as Chair of ACM/SIGGRAPH, as a member of the SIGCHI Advisory Board, as Co-Chair for CHI '90, and in many ACM and CHI roles. Currently he is president and principal consultant for Usability Architects, Inc.
Whiteboard Column Editor
Senior Principal Engineer
Computer Sciences Corporation
15245 Shady Grove Road
Rockville, MD 20850
©2002 ACM 1072-5220/02/0300 $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 © 2002 ACM, Inc.