Many HCI professionals spend a good deal of their time proselytizing about user-centered design (UCD). Often, attempts at persuasion involve or even hinge on cost justification. Developing a comprehensive model of costs and benefits can be quite complex, depending on how many factors you try to include, such as the time value of money, indirect and direct effects, and tangible and intangible effects. (See Bias and Mayhew , still probably the best collection of articles on cost justification of usability, and unfortunately not "unnecessary" 10 years later as they optimistically predicted.) Because of this complexity, and because it may be difficult to get real numbers to prepare a comprehensive cost-benefit analysis, in practice, UCD champions often use simplified pro forma analyses to relate "sample" expenditures on UCD activities to particular estimated financial benefitsa reduction in support calls, reduced training time, reduced errors, and increased productivity, to name a few. Of course, the variables emphasized depend on the nature of the product, for example, whether it is intended for internal or external use.
If we approach these efforts at persuasion with the attitude that the value of usability is self-evident, it can be frustrating when business decision makers don’t seem to understand. We can lapse into viewing this attitude as irrational or politically motivated resistance to change. We need to recognize that these arguments can fail to persuade an intelligently skeptical person for several fundamental reasons.
Cost-justification arguments often use reasonable, but hypothetical numbers, which may have low credibility. In addition, the analyses may be anecdotal, and although case studies can be persuasive, an audience may not be convinced that their current situation is analogous, especially if they are initially skeptical.
We would love to be able to show that UCD increases sales and market share, but the impact of UCD on sales is difficult to quantify and often indirect. The nature of the product, the product space, and the balance of all other factors that influence buying behavior complicate how much UCD affects sales. This complexity can make it difficult to convincingly predict specific sales improvements from specific usability changes. It also can make it show retrospectively that actual sales improvements were attributable to actual usability changes. After all, while those changes were being made, other things were probably happening, for instance, changes in the marketing plan or the pricing structure, a great TV commercial, positive reactions in the press (which might have nothing to do with usability), a successful trade show, or missteps by the competition.
When we try to persuade executives that spending money now will lead to future cost avoidance, we encounter a built-in conservative bias. Avoiding a real outlay of money now (the money you are asking for) often counts for much more than hypothetical future cost avoidance (the savings you are promising). Product team managers who are rewarded for keeping their development budgets low and meeting target release dates may not even be held accountable for future costs affected by usability problems. In many companies, those costs, such as support calls, are not tracked by product team. Moreover, by the time those costs have been determined, the product development team may have disbanded and been reassigned to other things. Similarly, the cost of problems resulting from product liability, some of which are classified as "user errors" (that is, usability problems) are typically paid out of general funds and not counted against the downstream cash flow of the product.
Finally, activities that are not already part of current practices and represent a new approach face another obvious conservative bias, not to mention the resistance that may come from people who feel their turf threatened, such as designers or marketing professionals. It is sad but true that people tend to keep reapplying a familiar but failed solution instead of attempting something radical.
Strengthening Persuasive Power
Clearly the challenge of promoting UCD to a skeptical audience is significant. No single simple answer exists, but the preceding discussion of the difficulties does suggest some of the following things to keep in mind to help you make the strongest business case for UCD.
Show a conservative bias
One of the common principles of estimating costs and benefits is to be liberal in estimating costs and conservative in estimating gains . Doing so demonstrates that you share management’s cautious attitude about new endeavors and reassures them that you have been prudent. It also helps ensure that when you gain support for a project, not only are you more likely to succeed, but the actual results may exceed expectations.
Identify hard-to-measure impacts of usability that are not included in your analysis
This not only helps to show that your numbers are conservative but can also raise awareness of other factors that make the case for usable design, beyond those you have captured. For example, you may be able to find out how much is spent on training for a particular application. Point out that you are not taking into account the productivity lost by workers interrupting each other to ask for help. In one case, we were able to convince management of the importance of usable design by pointing out that competent design of their Web site would likely influence customers’ overall impression of the company’s competence.
When using anecdotes, show how they are relevant
When using anecdotal evidence, be prepared to show which factors are analogous to the present situation and which are notand make "conservative" adjustments for those. If the anecdotal information is not rich enough to allow you to do this, or if it does not clearly resemble your circumstances, it might be better not to use it. Similarly, when using general statistics and rules of thumb, do your best to show how they are relevant to your own organization’s experience.
Target your analysis
When using a cost-benefit analysis intended to relate to a real internal problem, target your analysis at cost factors most obviously and directly linked to product design and usability problems. Try to obtain real data from your own context about these actual costs. You will have the easiest time getting real numbers and making a convincing case if you can target a variable that has already been identified as a source of concern in the company.
Lay the groundwork
You may have to focus efforts strategically on promoting activities that will help build a case for UCD before you can sell specific UCD activities themselves. For example, you may need to promote the idea that future costs related to product design (training, errors, support, liability, or whatever is most relevant in your setting) be tracked by product and that accountability be maintained.
Be careful about highlighting that your recommendation is coming from a different paradigm of product development.
People are inherently suspicious of proposals that seem ideologically motivated, and you may inadvertently raise resistance if you are not sensitive to this. Once interest has been piqued by some demonstrable successes, it may be a better time to reveal that there is a broad spectrum of activities that are similarly useful at different points in the development cycle. But remember that each recommended activity must be defended on its own merits as a solution to a real problem, rather than as part of an attractive design philosophy. Target your recommendations at places where the company is already feeling the most "pain," when you can show that specific UCD activities are available to help address that "pain."
Focus on effectiveness in doing what the company is already trying to do
Rather than focusing the discussion on trying to get staff to adopt an approach they are not now using (user-centered design), focus the discussion on the most effective ways of doing what they already see themselves as trying to do. Even if their efforts are not intensive and systematic, most companies see themselves as doing at least something to "know their users." One way or another, they will also spend some resources on design. Our arguments need to show not just what is gained for a dollar spent on UCD, but also how our methods complement and strengthen other things the company views itself as already trying to do. Similarly, try to link UCD activities and other themes that are accepted priorities in the company, to show how they are an inherent part of good "due diligence," or that they help achieve other corporate goals, like quality, service, or innovation. It can also help to show how proposed UCD expenditures compare to other expenditures that the company does not question, such as marketing.
Remember that UCD can save money on the front end
Don’t just look for downstream benefits. Certainly, in practice, initial UCD efforts often look very much like an added up-front cost, because they are attempts to solve problems too late in a process that was not planned to take them into account from the beginning. But this is of course not inherent to UCD and is not even always true of those initial efforts. Some of the most interesting and powerful counter examples are situations where design before the introduction of UCD was seriously bogged down, and UCD provided methodologies to move the process ahead much more effectively. We have experienced many situations in which UCD provided methodologies to resolve design disputes objectively, including one in which the team had been delayed for almost a year. Sometimes product requirements (derived from the usual heterogeneous sources) can greatly complicate the design challenge and significantly delay the product. In our experience, UCD methods have enabled teams to persuade management to modify requirements that simplify and refocus the product concept to better target user needs.
In cases like these, the fair comparison is not the cost of the original development plan with UCD versus without UCD, but the cost of UCD versus the cost of continuing development stalemate, or even more to the pointthe hypothetical cost of timely UCD versus the cost of the delay in implementing UCD. When delay in the development schedule is the "source of pain," you may be able to show that a UCD activity is a reasonable approach at solution and that its cost is a small fraction of the cost of continued delay. Sometimes, in cases like this, the "pain" may be so great that convincing decision makers to try a new approach may be easy. It is still good to try to quantify the benefits in terms of reduced development costs to provide a teaching example for future reference within the company.
Beware of "incrementalism" in looking for post-release benefits
When people frame the demand for cost justification as, "Show me the incremental benefit I will gain for this incremental expense," the almost unconscious assumption tends to be that the existing design is good enough for current business purposes and that the potential gains from UCD are only a modest percentage of the total, the frosting on the cake. In reality, many influences in the product development process can lead to product concepts that do not fit user needs or to cripplingly bad design, unless they are actively countered by UCD. Thus, UCD can be the difference between success and catastrophic failure in the market. In other words, focusing cost justification only on incremental benefits may overlook order-of-magnitude benefits.
UCD can also contribute to innovation, by revealing unsuspected product opportunities, including things that would not emerge in other forms of idea generation or methods to elicit customer needs, like focus groups. It can also be an important aspect of risk management. Of course, the earlier in the development process UCD is introduced, the more likely it will have an order-of-magnitude effect on both product quality and development cost. An opportunity may arise to produce a sound conceptual model at a point where it can really guide the design, before so many layers have been built on top of it that it becomes effectively immutable. Savings through avoidance of wasted effort on development of unneeded products, increased efficiency in design and development, and increased chance of product success or even product breakthroughs compound each other.
Order-of-magnitude benefits may be difficult to factor into a quantitative cost-justification analysis because they may be viewed as low probability despite their high potential impact (expected cost = probability of incident times cost of incident). It is important to be careful not to violate the principle of conservative cost-benefit estimation by too easily predicting order-of-magnitude impacts of a particular UCD intervention. However, sometimes an organization develops a perception of heightened risk that increases the probability (and believeability) of a dramatic rather than an incremental impact of UCD. This can happen because the product is inherently dangerous, bringing liability concerns; because the product breaks very new ground; because some influential stakeholder has expressed serious concerns about the current design direction; or because of failure of a previous release. In such situations, estimating a reasonable probability of order-of-magnitude impacts of UCD can be meaningful.
Use the right arguments for the right audience
Different cost-justification arguments may make sense for stakeholders at different levels. The insulation of product development teams from some of the long-range costs of bad design means that some arguments need to be directed to different stakeholders at higher levels of the company. Although some costs may not be attributed to a project team, they are likely to be tracked at the divisional level, depending on the size and structure of the company. Depending on how effectively it is communicated to the organization, buy-in from senior management can help you motivate individual teams. Also, as a general rule, it may be wiser to aim general arguments for comprehensive UCD practices at higher levels in the hierarchy and arguments for specific UCD interventions at project teams or their immediate management. (The exception may be when you are attempting to develop broad grassroots support for UCD through educational efforts not targeted at a specific product.)
We should be clear that we are not objecting to the use of simplified cost-justification arguments. Although we need to develop comprehensive ways of estimating the many cost-impacts of bad design, the reduction in these costs that can be expected from user-centered design, and the relative costs of the user-centered-design approach versus traditional approaches, we will only be able to present simplified analyses. We certainly must be able to give straightforward answers to reasonable questions about cost justification. But we must not be naïve about the dynamics of persuasion. Numbers alone may not do it. We need to understand the context and incentives of the people we want to persuade and frame our arguments in the most effective ways possible. We also must remember that a particular cost-benefit analysis is only one part of a larger dialogue. Success will hinge not on a single convincing argument, but on the many interrelated ideas we introduce into our organizations, on the kinds of relationships we build with various stakeholders, and on how we demonstrate our value to them first hand.
David A. Siegel, Ph.D.
Dray & Associates, Inc.
2007 Kenwood Parkway
Minneapolis, MN 55405
Susan Dray & David A. Siegel
Dray & Associates, Inc.
2007 Kenwood Parkway
Minneapolis, MN 55405, USA
612-377-1980 fax: 617-377-0363
©2003 ACM 1072-5220/03/0500 $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 © 2003 ACM, Inc.