3

Making the Business Case

“Drive thy business; let not that drive thee.”

—Benjamin Franklin

Topics Covered in This Chapter

Gaps Between Stakeholders

Developing a Business Case Framework

The Benefits of Good Design

The Case for Profitability

Proving ROI

The Usability Engineering Life Cycle

In the days of the Internet revolution from the mid to late 1990s and early 2000s, any company related to the Internet—or computing in general—was considered gold. Indeed, many companies without a comprehensive business plan received funding because they were involved with the Internet.

Those days are long gone. Although the go-go days are over, what’s been left in its wake is a more mature realization about what’s needed to survive. You need all the help you can get to beat the competition. And, as always, customer satisfaction is the key to survival and growth.

This is why usability analysis is so important—it lets you understand how your users react to your user interface so you learn what’s wrong and what’s right in your user interface design, as well as any other peripheral materials that ship with your product, such as the documentation. Usability analysis includes early customer involvement to gauge their reaction to and productivity with an interface. This feedback gives you the opportunity to make changes before you release your product to your customers, which can result in more satisfied customers.

User interface design, usability design, and usability testing are all strongly linked. Without good user interface design, users won’t like your product, whether it’s a software product, hardware product, or Web site. Without usability design and testing, you’ll never know if your design is useful until you receive input from the public. If your user interface is a flop, you and your project team will have to spend time, money, and effort fixing problems that could have been fixed during the development process, not to mention that the product team will have to endure customer service headaches.

To show the benefits of good interface and usability design to your stakeholders, you need to make a strong business case. The business case not only explains design benefits to company stakeholders, but also how the company benefits from the investment, called return on investment or ROI.

The first step is to identify and understand not only the users’ goals, but also the goals of the various stakeholders in your company. Then you need to create an overall plan for your project to present to your stakeholders so you can get your plan approved. The plan should not only address the benefits from good design, but the plan should also discuss who in the company benefits from good design. As part of that discussion, you should make the case for profitability. Finally, you should make an ROI study that shows just how much money you expect will be made from the investment based on reasonable estimates of time and money.

Gaps Between Stakeholders

The product creation system includes four distinct stakeholder groups (Donoghue, 2002):

• Users
• Engineers and designers
• Sales and marketing personnel
• Managers

Each group has its own stake in the success of the product, be it a hardware, software, or Web product (or some combination of the three). Therefore, each group has different expectations of what it wants the product to be. These different expectations create gaps between the stakeholders that you must bridge in your usability business case.

What Users Expect

Users expect to have a successful experience with the product or documentation the first time around. Because the users are the people who determine whether something is useful, the characteristics of your users will go a long way toward determining what is actually usable, as Chapter 5, “How Users Behave,” will discuss in greater detail. However, users look for some general goals when they use a product, whether the product is a Web site, a software program, or a piece of hardware such as a cell phone (Donoghue, 2002):

• The product must be easy to learn.
• The product must solve the user’s needs.
• The product help must be both easily accessible and effective in resolving the user’s problem quickly.

Your customer base will likely have other criteria that define success, and these criteria will be more specific to the product. For example, if you have a Web site, your customers will want to get to the information in the fewest clicks possible.

What Engineers or Designers Expect

Product engineers and designers expect that they will largely be left alone to produce their product. They don’t want to spend a lot of time fixing problems that arise after the product has been shipped, or having to answer questions from internal and external customers about how something works. In my experiences as a technical writer, I’ve found that during the development process, engineers and designers liked me to ask them as few questions as possible, and they liked it even more if those questions required short answers.

What Sales and Marketing People Expect

Sales and marketing people expect an outcome that makes as much money for the company as possible. There are a number of internal and external factors that sales and marketing people look at when a new product is released, including these:

• The company’s client base and contacts, especially if there are good candidates to be usability test subjects.
• The public environment, such as the public and the media. The public and the media can be good or bad for business depending on the subject matter. Poor reviews of a software product can negatively affect sales, but favorable reviews can help make the jobs of sales and marketing people easier.
• Macro forces, including economic, political, and technological. For example, if you sell software to airline and trucking companies, the high cost of fuel may prevent them from spending money on your product, no matter how much they like your product. Your product may also require people to have the latest version of the operating system they use or the latest service releases installed for your program to run properly.
• Competing businesses. Businesses are always looking for every advantage, so sales and marketing people are always researching the competition to identify and exploit weaknesses, or perceived weaknesses, in competing products.

What Managers Expect

Managers expect to see how a product or initiative affects the bottom line, which is the only thing that matters in business. Therefore, managers want to see a cost-benefit analysis to gauge the company’s ROI from usability testing.

Managers want this analysis to include the following so they can decide whether usability design and testing is feasible:

• How much usability design and testing will cost. These costs must not only be projected to what you plan to test in the short term, but what you want to test in the long term. For example, if you develop a software product that will be upgraded over time, you may want to include usability tests for subsequent versions.
• What will be tested. For example, will you test a software product, the associated customer support Web site, or both?
• How many other resources are needed, including people, facilities, and equipment. For example, if you need to conduct in-person usability testing using computers in your lab or on the customer site, you need to include the costs and people involved. You should also measure the amount of work people do in terms of people days that your usability project will use.

You can be sure that the higher you go up the corporate ladder in the company, executives are aware of not only the expectations of the manager making the decision, but also of other departments in the company.

Developing a Business Case Framework

Now that you have identified what the benefits are, you need to tie your usability plan to the entire production process. If possible, you should start the usability process at the same time the project design process begins.

Starting the usability process at the beginning allows you to couch the design of not only the usability tests but also the product interface and documentation in terms of the total user experience. The user experience is a five-step process (Donoghue, 2002) that encompasses the entire customer experience:

1. The process starts with the business goals. These customer goals can include, but are not limited to, converting customers, increasing retention, and increasing transactions.
2. The project team factors in the customer goals, including ease of learning, a solution that solves the users’ needs, and access to help when needed. That help should also be designed to resolve users’ needs quickly. Help design usually falls under the purview of the documentation specialist. Chapter 4, “Good Design,” expands on the need for good documentation design.
3. The appropriate project team members design the user interface or documentation to meet both the business and customer goals.
4. When the interface is ready for testing, the team participates in the engagement and interaction processes and provides feedback. You can obtain this feedback in a number of ways, from user surveys to controlled tests. You’ll learn more about creating a usability test in Chapter 9, “Usability.”
5. After testing, the testers’ goals are satisfied. This doesn’t guarantee that you’ll meet all the goals of all your customers, because testing is limited to a selected group of users. However, usability testing minimizes problems you will encounter when you release your software, hardware, or Web site to the public.

At the end of the five-step process, the satisfaction of the customer goals naturally leads into the satisfaction of the business goals. You can use this process as a framework for developing the rest of your plan, starting with the benefits of good design and how it affects your business goals.

The Benefits of Good Design

You’re going to encounter skeptics when it comes to communicating the benefits of good design. For example, you may have had the following conversation with your software development team once or dozens of times before:

You: “We need usability testing to make sure that our software is not only usable, but easy to use.”

Developers: “But the software is so easy to use—we don’t need usability testing!”

A rejoinder to this argument can be hard to come by, because the developers are correct—if the developers are the only ones using the product.

Of course, other people outside your company will pay money to use your software, and if the users disagree with your developers, your company isn’t only going to be deficient in the financial space, but it will also be deficient in the idea space. That is, your company will gain the perception that it doesn’t meet the needs of users, and that perception can be hard to overcome.

Other people in your company may just shrug and say “so what?” in response to your request for usability testing. Without something tangible to present to other people, those people can’t wrap their heads around what you’re trying to convey. So what will you tell them?

You should start your business case by discussing with the company the benefits of good design (Mayhew and Tremaine, 2005). Good usability design and testing positively affect four key business areas:

• Production costs
• Customer support costs
• Customer productivity
• Customer retention

Long-Term Production Costs

Good design helps your company reduce both your short-term and long-term production costs.

Lower Short-Term Costs

The promise of popular “desktop” GUI interfaces, such as Windows and Mac OS, became popular in the 1990s. The promise was that, because users would now be using a standard interface, people would be able to use any software at all. The reality is much more complicated. The desktop GUI interface didn’t solve an old problem: Application software usually brings new tasks and new ways of doing tasks along with it, and users need to know how to perform those tasks efficiently.

You will save money in production costs by focusing your production teams as early in the development process as possible on updates to existing products as well as new products. If your sales and marketing teams learn from users about faults in the product that are attributed to faults in the user design, your entire company will have to devote a great deal of time, effort, and perhaps money to fix the problems. The results could be that your company’s reputation suffers, your product’s reputation suffers, and any other products under development are delayed because your production team has to devote its time to fixing the existing product.

Lower Long-Term Costs

Spend less money on fixing things that users have found unacceptable, and spend more time including improvements to help make the product and your customers’ lives even better. You will also take what you learned from user interface design on your current project and apply it to other projects, thus making the products produced by those projects better for your users. Better products positively affect your company’s bottom line.

Lower Customer Support Costs

Customer support costs account for as much as 60 percent of a high-tech company’s total costs. If users find the user interface easy to use, they will likely not need to contact customer support. Without guidance afforded by good user interface design, users will use their own judgments, for better or worse, to get something to work the way they feel it should. That guidance must also be in front of users so they cannot ignore it, because there is no guarantee that users will read the documentation that comes with the software or hardware.

For example, there are stories of users who broke CD-ROM drive trays when they used the trays as cup holders. These users used the trays as cup holders because the manufacturers didn’t tell them up front that the trays weren’t cup holders, not even adding a sticker on the drive tray stating something like, “Not a cup holder.” Such a sticker may have saved a lot of people money and grief.

If your product is well designed, your users will rely on online help and training materials less often and be more productive because they will find your product easy to use. They won’t encounter or make as many errors, but if they do make errors, good documentation and online help will get them back on their feet more quickly.

Good product design lowers training costs. Certain products are complicated and require more training, but good interface design can reduce the amount of unnecessary training that your company needs to provide. For example, if your software is easy enough to use that you can have online training that anyone can access from your company’s Web site, you will save the time and money necessary to have one of your employees train users at your facility or another facility. If you want to have in-person training, a well-designed product will ensure that you minimize the number of days you train people so that users can become more productive more quickly.

Greater Customer Retention

Documentation is the first line of support for most customers, and customers usually use it to look for the answer to a problem they’re having. The inevitable result of poor or nonexistent documentation is that more people try calling the customer support lines for help. The company tries to mitigate the costs of hiring and training customer support staff by charging for those calls.

Users, who don’t want to pay for those calls if they don’t have to, usually search the Internet to get answers instead. Some users visit the company Web site for those answers. Many companies not only have lists of frequently asked questions (known popularly by the acronym FAQs), but also have online forums to ask and answer questions. Also, there are often online forums and mailing lists not affiliated with the company that users may consult with. However, the users may still not have the answers they need, so they have two choices: pay and hope they get the information they need, or give up. The users will either call your customer support line and won’t be happy about it, or they’ll decide that your competitor’s product is a better solution.

Any extra time that the users put into solving the problem reinforces negative feelings about your company. In the worst-case scenario, poor design can result in damage to users’ computers or data and cause them to seek reimbursement from your company for those damages. If you have aggressive competitors, this isn’t good news for you or your team. A popular aphorism in the business world is that it costs about 10 times more to acquire a new customer than it does to retain one.

Therefore, good design not only results in less user frustration, but it also results in more positive reinforcements of your company. Happier customers not only means that you keep the customers you have, but it also increases the chances that you will be able to attract new customers through testimonials and word of mouth, the latter of which remains the most effective marketing method.

The Case for Profitability

After you show your stakeholders how good design as well as usability design and testing will lower costs, you need to show them how design and testing will make the company money.

Usability expert Karen Donoghue (2002) has eight guidelines to successfully attach profitability to usability studies in your company. Following are those guidelines:

• Drive the design and development of the user interface and usability design closely against the product business case. If the production team has a business case already, be sure to integrate your interface design, usability design, and usability testing business case with the product business case as much as possible. Doing so will help make your argument that the usability design business case will positively affect the product business case.
• Make sure all project team members (including business, technology, and design) clearly understand the business goals and how usability affects those goals. It’s important to identify the stakeholders in your project and talk with them as soon as possible about your desires and needs. Not only will this communication help stakeholders understand that you’re serious about usability and good user interface design, but you’ll also be able to learn what those team members want, and that will make your business case even stronger.
• Connect financial metrics to customer satisfaction and usability metrics, and measure them in an ongoing fashion. You’ll learn about creating financial metrics using an ROI study and using usability metrics with the Usability Engineering Life Cycle, later in this chapter.
• Make the success measurement the responsibility of one person. Share this information with the team as an index (or set of indexes) of usability. This person can be the usability expert, someone else on the project team, or someone outside the project team whose job it is to manage company quality efforts.
• Share knowledge among the project team, and create a learning culture so that each team member understands what other team members contribute to the user experience. Constant communication is the key not only to meeting good design goals, but also to acquiring accurate and meaningful usability results.
• Build the user experience for scalability. Making the user experience scalable helps your usability efforts evolve as the business model changes and the user population expands and evolves. Also, you should make capital investments in architecture before look and feel. For example, if user needs require that your software upgrade to a new version of programming software, you need to prioritize your investment for the architecture required for upgrading the software.
• Know the customer’s needs, tasks, and goals—and make sure the user experience satisfies them. This is where the usability design and testing comes in, but usability testing isn’t the end-all and be-all of finding customer information. For example, you can bring users into the project team so they can contribute information, or you can survey users and hold focus group meetings to determine what your users want and don’t want in the interface.
• Only add features and functionality that blend value for the customer with value for the company. This gets back to the first guideline, where you have to dovetail the design and development of a good user interface and usability testing with the product development business case. Good customer feedback before the design process starts can determine what features are important to the customer. Then you and the product team can determine what features that the user requests will bring the most value to the company.

Proving ROI

All the value propositions listed earlier in this chapter are compelling, but they lead to the most powerful value proposition of all: the ROI analysis. ROI provides a financial metric that can help crystallize the impact of usability testing on the bottom line.

An ROI study is a way of calculating payback—that is, if you’re putting money into something, an ROI study lets you and other members of the business know if that something will pay for itself in a certain period of time. If you come to one or more decision makers with an ROI study in hand, you will have a far better chance of implementing your proposed usability study.

ROI Specifics

When you create your ROI proposal as part of your business case, you must write down the basics of your benefit, including (Mayhew and Tremaine, 2005) the following:

• The cost of developing the benefit—These costs can be based on the number of hours it will take for people to create the benefit and tangible items needed to realize the benefit, such as renting space and equipment to perform usability tests.
• The value proposition of the benefit—This proposition explains how the company will benefit from the investment. You can use much of the information in this chapter to show the value of the benefit.
• The dollar amount of the benefit—Provide your best estimate based on the amount of money your company will save as well as how much profit you expect to make. You should discuss this issue with other stakeholders in the organization, such as the customer support manager, to get some solid numbers so you can construct a solid dollar amount estimate.
• The length of time until the benefit is realized—This length of time is calculated in years or a fraction of a year (such as 0.5 years for a 6-month length of time). Provide your best estimate after you talk with the project team. The project timeline will greatly affect this figure. You will factor this amount into calculating the dollar amount of the benefit.
• The interest rate for the particular business for the same length of time—You may be able to get this information from your project team or from your company’s financial officer.

Calculate the Dollar Amount

To calculate an accurate dollar amount of the benefit, you must first calculate the net present value (NPV) amount, which discounts the benefit into today’s dollars. If your ROI analysis shows you’ll make an amount of money two years from now, that amount of money will be less valuable today because of inflation during that period.

You can calculate the NPV amount by using the following equation (Mayhew and Tremaine, 2005):

NPV amount = Future dollar amount × (n)/(1+k)ⁿ

In the preceding equation, n is the number of periods, and k is the amount of interest. For example, if you’re looking for returns one year from now, you would use the number 1 for n. The interest rate is a fraction of 1. In this example, we’ll use a 5-percent interest rate that will be represented in the equation for k as 0.05.

If you project the future dollar amount to be $50,000, the NPV amount would be as follows:

50000 × 1/(1+0.05)1 = $47,619.05

Next, you must calculate the ROI value. Use the following equation to calculate the ROI value:

ROI = (NPV amount - cost) / cost

If the cost to develop the usability test is $10,000, the ROI calculated from our example would be this:

(47619.05 - 10000) / 10000 = 3.76

So, in this example, the benefit will produce a 376 percent return, meaning that for each dollar spent on your usability design and testing, the company will get $3.76 back. If you were to send a figure similar to this example, it would likely get the attention of your stakeholders.

The Usability Engineering Life Cycle

Bias and Mayhew (2005) created the Usability Engineering Life Cycle (UEL) as a means to build a usability test plan. If you can integrate the UEL into your product development cycle at the beginning, it will provide you with a rigorous analysis and testing regimen that will help you get the most out of your usability design, analysis, and testing.

The UEL is a cyclic model that incorporates three phases (Bias and Mayhew, 2005):

1. Requirements analysis—In this step, you establish your user characteristics, what tasks the product requires for operation so you can determine what the users need to do, set your goals for the usability study, and determine the usability study design guidelines.
2. Design, testing, and development—In this step, you create a structured, top-down approach to designing the product, be it a user interface, Web site, documentation, or a combination of the three. This is the step that requires the most feedback from your project team.
3. Installation—In this step, you gather feedback from users during and after the development process and share this feedback with the project team to determine if you need to make any product changes.

If you and your team find that any changes do need to be made, you will likely go back to Phase 2 and design, test, and develop the changes that your project team made. However, user testing could also expose flaws in the requirements analysis that would require you to reanalyze your requirements and then go through the steps again.

Mayhew and Tremaine (2005) assert that implementing the UEL to develop a usable Web site or Web-enabled application takes 8 to 12 months to develop and provide a decent ROI, but this assertion is an average estimate. My experience has shown that it doesn’t take 8 to 12 months to design and publish a Web site, depending on how much programming is included in the site.

Therefore, for a Web site that doesn’t incorporate a great deal of programming, more time may be needed to market the Web site and make incremental changes as needed. Web sites that require a lot of programming, such as dynamically driven Web sites that use databases to manage and output information, will take more time to develop. This could lengthen the amount of time to realize a decent ROI or keep the amount of time the same and require less time to realize ROI. The same is true of software development.

As the car commercials say, your mileage may vary. The UEL is only a guideline, and you can adapt the UEL to suit your needs, because every project is different. You may also be constrained by tight schedules that don’t permit a thorough usability test. However, it’s good to have a by-the-book description of how to engineer a usability test ready to go, and the UEL is flexible enough for you to select the tasks you need to perform a solid usability test. However, you should keep the 8 to 12 month timeframe in mind when you implement the UEL in your product development processes.

Phase 1: Requirements Analysis

You can gather your users’ requirements for your product in a number of ways. For example, you can use paper prototyping to give people printed representations of what your product will look like and how the system will react to user input. You’ll learn more about paper prototyping in Chapter 4. You can also observe the users and see how they work; you will learn more about user observations in Chapter 9.

No matter how you decide to obtain your requirements, you should ensure that you have covered the following points in your requirements analysis. Even if you did create a paper prototype or observe the user at work, be sure to review the following points to ensure that you have all the bases covered.

• User profile—A description of your users’ specific characteristics. There is no standard set of characteristics to measure, but you should pay particular attention to any issues that the user has with using the software, such as physical limitations.
• Contextual text analysis—A study of your users’ current tasks, workflow patterns, work environments, and conceptual frameworks. This context will help you understand why the user reacts the way she does to the software, hardware, or Web site being tested.
• Usability goal setting—You need to set specific, qualitative goals that reflect the requirements you glean from the user profile. For example, you may want to have the users complete a task within a certain period and see if they can do that. If a user has some constraints that require a different method for completing the task, you should reset the goal for that user appropriately.
• Platform capabilities and constraints—You must define the scope of possibilities for addressing usability needs by determining the capabilities and constraints of the interface or product. This information can also be affected by the usability needs of the users.
• General design guidelines—You must apply generally accepted design guidelines for designing your interface. For example, there are guidelines for creating Web pages so that they appear correctly in every Web browser. You will learn more about design guidelines for user interfaces in Chapter 7, “Designing a User Interface,” and for Web sites in Chapter 8, “Designing a Web Site.”

Phase 2: Design, Testing, and Development

This phase is split into three levels of design work. Each level takes you from designing the concepts in the requirements analysis to developing a working product that users can test.

Level 1 Design

Level 1 design is the conceptual design level, which is where you design functionality, workflow, and rules. If you and your team have the time, you should get as much information from the users as possible before you decide how to design conceptual models. Models conceived from user input stand a far better chance of being accepted by users during the design evaluation stage in Level 3. The four steps in this level are as follows:

• Work re-engineering—Your project team organizes functionality and workflow design based on the users’ tasks and streamlines work before you begin design. No interface design is produced in this task.
• Conceptual model design—The team creates high-level design rules for presenting information and interacting with the hardware, software, or Web site interface. If you have product screens or Web pages, this task doesn’t go into that level of detail.
• Conceptual model mockups—You can create paper prototype mockups, as you will learn about in Chapter 4. You can also create wireframe versions, which are small programs that show some functionality but not the entire program, or you can even create a prototype with non-operating functionality such as small colored paper squares that represent lights on a hardware prototype.
• Iterative conceptual model evaluation—The project team evaluates the mockups and modifies them through iterative evaluation processes. In other words, if the team decides it doesn’t like one or more portions of the mockups, it works on those portions repeatedly until it decides that the portion looks good.

Level 2 Design

Level 2 design is where you create the standards for your project. Creating standards is especially important because everyone on the team needs to understand how the project will be put together. Having people creating their own standards as you develop the user interface design is a recipe for chaos. Four steps comprise this design level.

1. Design standards—Now that you have settled on a model, the project team must construct a set of interface- or site-specific standards and conventions that will apply to the design of the product.
2. Design standards prototyping—The project team applies the interface standards to product functionality. This functionality can be presented in specific screens or Web pages that you create to test the look and feel as well as links to other screens or Web pages.
3. Iterative design standards evaluation—The project team conducts formal usability testing or other types of evaluation to refine the screen design standards in the interface. This process continues until major usability issues have been resolved and usability goals are within reach. You’ll learn more about usability testing in Chapter 9.
4. Style guide development—After you have a stable and validated set of screen design standards, you document this information along with the results of the requirements analysis in the product style guide and then distribute the documented information to all project team members. Other style guides, such as a general style guide for the company and the documentation style guide, could also affect the product style guide, and vice versa.

Level 3 Design

Level 3 design is the level at which you actually design the product after making all your preparations in the previous two levels.

• Detailed user interface design—The project designers design the product based on the style guide conventions created in Level 2 design. The product that results is the “beta” version available for internal or external testers to use and test and for which they can provide feedback for the product team.
• Iterative detailed user interface design evaluation—The project team conducts formal usability testing or other types of evaluation to refine the screen design standards in the interface. This process continues until the project team validates the product against usability goals.

Phase 3: Installation and Feedback

After the product has been installed and used for a period of time, the company should gather feedback from users about what they like and don’t like about the product and how they use it.

You can obtain feedback in any number of ways: by e-mail, phone, mail, or on your Web site. You can send surveys to customers, and you may want to offer prizes or special offers to entice customers to return the surveys, especially if the surveys are long. You may also want to conduct focus groups either in person at your company building or at the client, or online using a collaborative software tool that employs real time videoconferencing such as WebEx, Microsoft LiveMeeting, or Raindance.

The Never-Ending Process

One thing to keep in mind is that the UEL really never ends. Feedback during the development process will ensure that you don’t have many problems to fix after the product is out the door—and good feedback is always a feather in your company’s cap. You will also need product feedback from your customers after the development process ends.

In addition, you may have upgrades to your product that need to be produced—or updates to the documentation you may want to place on the company Web site. So be sure to include the additional costs of implementing continual feedback as needed, especially between product releases, into your ROI proposal and your business case.

The Case Study: Mike’s Bikes

This book uses a single example as a case study to illustrate the steps involved in the usability design and testing processes. Other books in the For Mere Mortals series use the case study approach, which enables the author to present a process with some degree of continuity. In this book, I apply each technique to the process of designing a Web site and associated database application for use by both internal and external customers.

You may remember Mike’s Bikes from Database Design for Mere Mortals by Mike Hernandez. In that case study, Mike’s Bikes is a new bike shop located in the Seattle suburb of Green Lake. This case study picks up three years later to find that Mike’s Bikes is doing so well that Mike has opened eight other shops in the greater Seattle area and now employs close to 120 employees. Given this growth, Mike has discovered that his customers now want to customize and order bikes and purchase other supplies online, and his employees want a more robust application that they can access quickly to get the information they need.

Mike has a project team of 10 people dedicated to the creation of the new Web site and database system. Following are the 10 team members:

• Mike, the owner
• Traci, the finance manager
• Jay, the marketing manager
• Laura, the production manager
• Michelle, the customer support manager
• Tony, the company Webmaster
• Maureen, the database and networking administrator
• Bruce and Travis, two database programmers
• Paul, the documentation writer

The team is excited to get going but not certain why a usability test is necessary for this project. That’s why you and your assistant Evan are in the kickoff meeting with the team: to create a business case framework.

The first step in the business case framework is to interview the project team to learn what the business goals are. You let Evan conduct the interview.

Evan: “What are the business goals for this project?”

Mike: “Make more money!” (The rest of the group laughs in appreciation.)

Jay: “The recognition from customers and competitors that Mike’s Bikes is the best resource for bicycles and accessories.”

Michelle: “The capability for customers to order their bikes and supplies from anywhere and have that information available immediately for production.”

Laura: “My workers will have easier access to more information, so they will be able to get their work done more quickly.”

Maureen: “My programmers and I can work on more important things rather than enter information into the database from customers phoning their orders in.”

After a discussion of the business goals, including the due date for completion of the project, the interview continues with a discussion of the customer goals, and Evan continues to ask questions prompted by the discussions. For example, the following discussion is concerned with what the users want to get out of the user interface so that all users can specify and access the information they need quickly.

Evan: “What do you think of the current database application you’re currently using?”

Mike: “What do you mean, exactly?”

Evan: “I’d like to know if there’s anything about the interface that drives you crazy and what you would like to improve.”

Michelle: “I wish there was a page on the site that I could access from any screen in the database to show me what parts are available in what stores so a customer in one store that needs a part can find the part in another one of our stores.”

Jay: “That would be huge. If a customer can’t find what she needs from us, she won’t come back to us.”

Laura: “I think the database needs to tell us when a store is low on a part, not just tell us when the store can’t send another store a part, because then that store wouldn’t have a part available for its customers.”

Mike: “How do you suggest we do that?”

Laura: “We need to have another column in the product table that presents a visual reminder, like a flag, to let me know that we need to order more parts to keep the pipeline filled.”

Maureen: “That won’t be hard.”

Laura: “I also think we need to have a button next to the flag column to let me order parts. The button would open up the manufacturer’s Web site so I could order from them online.”

Traci: “If the manufacturer lets you order online.”

Evan: “Laura, what happens if the Web site is down or the manufacturer doesn’t let stores order from them online?”

Laura: “Hmmm. Perhaps the button could open a small window that lists contact information, and that contact information would also include a link to the company’s Web site if we can access that site to order products.”

Evan: “But that adds an extra step to get to the Web site. How about creating a separate button that connects to the manufacturer’s Web site?”

Laura: “Good idea. If the company lets you order online, then there can be a second button with a different color that will take me directly to the Web site order page.”

Maureen: “We’d have to build another module in the database to manage the contact information, but we could do it.”

Jay: “But how would you get the product to the store without making the customer drive over to that store? Unless the customer needed the part right away, she wouldn’t drive all the way across town to our store—she would drive two blocks to Rob’s Cycle World.”

Mike: “We’d need to hire people, maybe high school and college students, who would drive or bike to the store where the customer is and deliver the part. That would mean that the application would have to provide an alert for store managers that another store needs a part it has. I’ll have to think about that.”

The roundabout discussions provide you and Evan with a good amount of information you can use to create a list of objectives for both applications. For example, here are a few interface objectives for the Mike’s Bikes Web site and database application:

• The customer must be able to find what she needs on the Web site as quickly as possible.
• The Web site must reflect accurate information, such as the number of products available for purchase.
• The customer must be able to customize her order easily and order her product(s) quickly and securely.
• If the customer gets lost, she must be able to go back to the home page quickly and start over.
• The customer needs quick access to product and support documentation.
• We need to access customer, inventory, sales, supplier, and employee information quickly.

You review the initial list of interface objectives with Mike and the rest of his team. Afterward, you and Evan refine the list and present it to the team. You and Evan present a report to the team that lists three key design objectives in bullet form:

• The product availability page must be accessible from any window in the database application. This page provides the following functionality:

• It displays how many products are available in each store.

• It enables employees to find parts more easily and quickly.

• The “Parts Maintenance” page should display visual cues that indicate key status points for each part. This page will provide employees with the following functionality:

• Employees will be able to see alerts indicating that another store needs a given part that is currently in stock.

• Employees will be able to determine how many parts are defective in each store.

• Employees will easily be able to determine which parts need to be reordered.

• A search box must be accessible from any window in the database application. This page will provide employees with the ability to find a product, customer information, or order information.

With the initial list in hand, you then ask the team what it will take to develop the product and interface. When you talk about what development will take, include the associated costs such as combined employee hours dedicated to the project and any future anticipated costs; for example, the company may need to hire contract employees to finish the project by a certain date. You and Evan also inquire about the interest rate for the business, about the profit that the company expects to make, and about when the company will realize that profit.

Armed with this information, you and Evan create an ROI statement that you will review with Mike and Traci before your next team meeting. This ROI statement is the equation you learned about earlier in this chapter:

NPV amount = Future dollar amount × (n)/(1+k)ⁿ

Then you must plug the NPV amount into the ROI equation:

ROI = (NPV amount - cost) / cost

The NPV amount is the percentage return that the company will realize from its investment in usability design and testing. You and Evan received estimates from Traci of $45,000 for the future dollar amount ($5,000 per store) in 1 year at a 5.25 percent interest rate. You and Evan have estimated a cost of $12,500 for the production of test materials and the final report as well as paying testers to interview Mike’s employees, create a paper prototype, and view how the employees use the current system as well as the new system as it’s being built. Those costs are documented in a worksheet, as shown in Figure 3.1.

Figure 3.1. Cost Worksheet

Given the figures that you and Evan have, you calculate the NPV amount as follows:

$45,000 × (1)/(1+0.0525)¹ = $42,755.34

Now you plug this NPV amount into the ROI equation:

($42,755.34 - $12,500.00) / $12,500.00 = 2.42

This follow-up team meeting will present not only your final list of objectives but also your ROI statement that proves your case for profitability—and in this case, a 242 percent return on Mike’s usability investment should make him happy indeed.

Now that you have the ROI calculation, where do you store it? Place this ROI statement in a written report that you circulate to the rest of the team, and be sure that the written report contains the date you last updated the document. If you need to update the report, be sure to save the old report as an archive and place it in an archives directory either on your hard drive or on an external drive (like a rewritable CD-ROM) so you have a traceable record of all changes that have been made to the document. If you use Microsoft Word, another way to keep track of your changes is to turn Track Changes on.

What’s more, when you distribute these changes to the team, be sure that each team member has access to the latest version of the documents online, such as through a folder on the network that is accessible only to team members. You and Evan should each keep a copy of the printed reports that you give to the rest of the team so that you have everything the team does and you have reference material easily available in case the online versions aren’t available for some reason.

In the next chapter, you’ll see how to apply paper prototyping to Mike’s project.

Summary

This chapter took you through the steps needed to create a business case for good user design, usability design, and usability testing. The chapter began with a discussion about why you should include usability studies when you develop your user interface.

Next, the section on gaps between stakeholders discussed who the stakeholders are when it comes to your user interface design. This section also discussed the expectations that each stakeholder has regarding the interface and the outcomes from good interface design, as well as usability design and testing.

Then the chapter discussed building a business case framework and the five-step user experience process that you should build your business case around. You know that the process starts with the business goals and then factors in the customer goals. The appropriate project team members design the user interface or documentation, and then the team participates in the testing process to acquire feedback. The testers’ goals are satisfied after testing, and that satisfaction leads to the satisfaction of your customer and business goals.

The section on the case for profitability listed eight guidelines for ensuring that your argument for usability studies will win over the skeptics and help your company’s bottom line. The first and most important guideline is to drive the design and development of the user interface and usability design closely against the business case. You also need to bring your team members on board with the effort and share information with them constantly. You and your team need to know what the customer’s needs, tasks, and goals are. From that information, you can create a scalable user experience that only adds features that blend value for the customer and value for the company. As you meet your design goals, you must make one person responsible for measuring the success of your design.

A discussion of calculating the return on investment for your usability studies followed, which is crucial to your making a valid business case for good user interface design, usability design, and usability testing. You learned how to use the net present value amount equation to calculate the ROI percentage return so you can present this return to your stakeholders and justify the usability study.

The chapter ended with a discussion of the ongoing process of usability testing and the Usability Engineering Life Cycle that places your usability testing inside a rigorous and ongoing process. Then you can incorporate the costs of that ongoing process into other product development as well as your product if it will have future releases.

Review Questions

Now it’s time to review what you’ve learned in this chapter before you move on to Chapter 4. Ask yourself the following questions, and refer to Appendix A to double-check your answers.

1. Why is the satisfaction of customer goals important?

2. Who are the four stakeholders in a project?

3. What are the benefits of good design?

4. Why should you start the usability process at the same time as the project design process?

5. What should be the first topic of discussion when starting your business case?

6. How can you make sure that your customers’ goals are satisfied by the user experience?

7. When should you add features and functionality into the product?

8. After you show stakeholders how good design, as well as usability design and testing, will lower costs, what do you need to show them?

9. Why do you conduct an ROI study?

10. Why should you use the Usability Engineering Life Cycle?

11. What are the three phases of the Usability Engineering Life Cycle?

12. Why should you get feedback during the development process?