Understanding Your Users: A Practical Guide to User Requirements Methods, Tools, and Techniques

endeavors.

PART 1

WHAT YOU NEED TO KNOW BEFORE CHOOSING AN ACTIVITY

CHAPTER 1

INTRODUCTION TO USER REQUIREMENTS

INTRODUCTION

USER-CENTERED DESIGN

Principles of User-centered Design

Incorporating User-centered Design Principles into the Product Lifecycle

A VARIETY OF REQUIREMENTS

The Product Team’s Perspective

User Requirements

GETTING STAKEHOLDER BUY-IN FOR YOUR ACTIVITY

Arguments and Counter Arguments

Preventing Resistance

THE METHODS

Introduction

User requirements refers to the features/attributes your product should have or how it should perform from the users’ perspective. User-centered design is a discipline for collecting and analyzing these requirements. This chapter introduces the basic concepts behind user requirements and the processes involved in capturing them. We discuss what user-lefted design is, the different requirements stakeholders collect during product development, and how to get buy-in for your user requirements activities. The chapter also provides an overview of the methods presented in this book.

At a Glance

> User-centered design

> A variety of requirements

> Getting stakeholder buy-in for your activity

> The methods

User-centered Design

User-centered Design (UCD) is a product development approach that focuses on the end users of a product. The philosophy is that the product should suit the user, rather than making the user suit the product. This is accomplished by employing techniques, processes, and methods throughout the product lifecycle that focus on the user. If you are new to usability you should refer to Appendices A (page 678) and B (page 688) at the end of this book to learn about usability resources and classes that can help bring you up to speed.

Principles of User-centered Design

There are three key principles of UCD (Gould & Lewis 1985):

An Early Focus on Users and Tasks

The first principle focuses on the systematic and structured collection of users’ requirements. That is the focus of this book. We will teach you how to effectively collect users’ requirements using a variety of methods.

To maximize the usability of a product, the user should be involved from the product’s inception. The earlier the user is involved, the less repair work needs to be done at the final stages of the lifecycle (e.g., after a usability test). The UCD process should begin with user requirements gathering. By collecting user requirements, you can gain an understanding of such things as what your users really want and need, how they currently work or how they would like to work, and their mental models or mental representations of their domain. This information is invaluable when creating a superior product.

Empirical Measurement of Product Usage

The focus here is on ease of learning and effective, error-free use. This can be assessed early in the lifecycle via usability testing of prototypes. Metrics such as errors, assists, and task completion rates gauge this. In a usability test, users are given a prototype or the final product and asked to complete a series of typical tasks using the product. This activity allows you to identify usability issues with your product. Then changes are made to improve the product before its release.

Image based on cartoon #5 at http://www.usability.uk.com/

SUGGESTED RESOURCES FOR ADDITIONAL READING

This book does not dive into the detailed process of usability testing, but there are plenty of great books that do. These include:

• Barnum, C. M. (2002). Usability Testing and Research. New York: Longman.

• Dumas, J. S. & Redish, J. C. (1999). A Practical Guide to Usability Testing, 2nd ed. Exeter, UK: Intellect Books.

• Nielsen, J. (1994). Usability Engineering. San Francisco, CA: Morgan Kaufmann.

• Rubin, J. (1994). Handbook of Usability Testing. New York: John Wiley & Sons.

Iterative Design

The final principle recommends that requirements are collected and the product is designed, modified, and tested repeatedly. You do not go through the development cycle once; you continue to iterate and fine-tune with each cycle until you get it right. No one gets all the information the first time, no matter how expertly you execute each usability activity.

Incorporating User-centered Design Principles into the Product Lifecycle

Figure 1.1 illustrates the ideal product lifecycle with these UCD processes incorporated. The key elements of an early focus on users, empirical measurement of usage, and iterative design are all incorporated. Stage 1, the Concept phase, encompasses the early focus on the user. The Design phase (stage 2) ideally incorporates the early focus on the user and empirical measurement principles of UCD. The Develop and Release phases (stages 3 and 4) tend to focus on the empirical measurement principle of UCD. Sample activities in each phase are discussed in this section.

Figure 1.1 Product lifecycle with UCD processes incorporated

Stage 1: Concept

This is the idea phase of your product. You are:

 Developing usability goals and objectives

 Creating user profiles and personas

 Executing user requirements activities, such as interviews, field studies, task analysis, etc.

Stage 2: Design

At this stage, you begin using the information collected in stage 1 to create iterative designs. Some usability activities include:

 User walkthroughs of low-fidelity prototypes (e.g., paper)

 Heuristic evaluations

 Execution of user requirements activities, such as focus groups, interviews, card sorts, etc.

Stage 3: Develop

The developers or engineers now begin to create the product. Some usability activities include:

 Preparation, planning and execution of pre-product release heuristic evaluations

 Preparation, planning and execution of pre-product release usability testing.

Stage 4: Release

The last stage is when your product is released to the public or customer, or within your organization. This stage often blends both user requirements activities with empirical measurement. In software environments, formal usability tests are typically executed on the live code. In addition, requirements collection for the next product release often begins at stage 4, to gauge users’s feedback on the product that has been released in the real world. Some stage 4 activities include:

 Usability testing

 Surveys or interviews to gain feedback on released code

 Site visits to see the product being used in its environment.

The third principle of UCD – iterative design – is employed throughout the entire cycle, as well as within each stage of the process. For example, you may do a wants and needs (W&N) session in the concept phase. This activity will begin your user requirements collection, but may open up new questions so you may run a follow-up activity such as a group task analysis (GTA). You will then use the results of the analysis to go back and revise and refine or iterate your user requirements document based on your new data.

SUGGESTED RESOURCES FOR ADDITIONAL READING

If your company has not adopted a user-lefted design process within its product lifecycle, you have a larger issue on your hands. Conducting a few user requirements activities will not lead to a cure. You will need to employ a change management strategy in order to affect the organization structure, processes, and culture of your company. This is no small task. There are a variety of books and papers that we can recommend if you fall into this category. These include:

• Bias, R. G. & Mayhew, D. J. (eds) (1994). Cost-justifying Usability. San Francisco: Morgan Kaufmann.

• Bloomer, S. & Croft, R. (1997). Pitching Usability to your Organization, Interactions 4(6), Nov./Dec., 18–26.

• Kotter, J. (1996). Leading Change. Boston: Harvard Business Press.

• Rohn, J. & Braun, S. (1993). Structuring Usability within Organizations. Presented at the Usability Professionals’ Association Conference, Redmond, WA, 21–23 July.

• Sato, S. & Panton, A. (2003). Using a Change-Management Approach to Promote Customer-lefted Design. Presented at the Designing for User Experiences Conference, San Francisco, 5–7 June.

• Schaffer, E. (2004). Institutionalization of Usability: A Step-by-Step Guide. New York: Addison-Wesley.

A Variety of Requirements

Thanks to market pressure and a growing awareness of usability, many product teams now realize the importance of understanding their users and the consequences that result when users are unable to utilize products with maximum ease. As a result of this awareness, many companies have incorporated some of the UCD process into their product lifecycles. For many companies, usability begins and ends with the usability test.

There is a clear difference between usability testing and user requirements gathering. Usability testing determines whether a given solution is usable. Requirements gathering provides insight into the many possible solutions and allows a person to select and investigate the best solution from the users’ perspective. The difference between a good designer and the outstanding designer is the latter’s vision of solutions. Without requirements gathering, your vision is seriously limited.

Although usability testing is a critical part of an effective user-lefted lifecycle, it is only one component of the UCD. This book is focused on the requirements gathering stage, which often receives less attention than usability testing, but is equally important. By requirements, we mean the features/attributes the product should have or how it should perform. Requirements can come from a variety of sources – marketing, product development, end users, purchasing decision-makers, etc. All sources have valid requirements and they must be taken into consideration by the product team. For example, if you are building a website for booking travel, some user requirements might include:

 All pages must download in 5 seconds or faster.

 Users must register with the site before making purchases.

 The site must be available in English, Spanish, and French.

 The site should appeal to all demographics of users.

 Users should not require training.

We next describe the different types of requirements you may encounter. By understanding a product’s competing requirements, you can better position the user requirements for inclusion in the product.

The Product Team’s Perspective

The requirements gathering phase is the period when the product team must do its initial research in order to determine the direction of the product. They must collect requirements from a variety of sources (e.g., sales, marketing, managers in your company, customers, end users) and use this information to determine what functionality will be included in the product, the technology that will be used, the task flows they will model, etc. This stage is critical in creating a basis for the design. Poor requirements collection will impact the remaining stages of the product life-cycle depicted in Figure 1.1. You will end up with a misguided product that won’t sell, or will be unusable and useless to the users and/or the company that purchases it.

There are a variety of different requirements that factor into product development and there is often confusion between them. Figure 1.2 illustrates some of the many requirements and sources that a product team must deal with.

Figure 1.2 Requirements sources (image based on Weigers 1999)

We often encounter teams who say We have already collected our user requirements, but in reality they have collected functional or marketing requirements, not actual user requirements. Below we discuss business, marketing, and sales require because they are often confused with user requirements. It is important to note that each of these is important, but they are not user requirements. There may be overlap, but it is critical for all of the different sources of requirements to be independently collected and then prioritized as a group. You cannot assume that what the sales person wants to see in the product is the same as what the end user wants to see in the product. In order to collect the different requirements effectively, you must be able to distinguish between them.

DILBERT reprinted by permission of United Feature Syndicate, Inc.

Business Requirements

The people who are considering purchasing your product have requirements for that product. These people are typically corporate professionals or executives. We often refer to them as the decision-makers. Their requirements often reflect the current business practices of their company or new practices they want to adopt to employ cost savings. They want to make sure that the product matches their requirements. If you want to keep these customers, being aware of their business requirements is very important. Sometimes these requirements overlap with the users’ requirements, but often business requirements tend to be more high-level and/or technical.

Marketing and Sales Requirements

The marketing and sales departments want to ensure that the product sells and their requirements reflect this goal. They may have requests for features or functions that they think customers want, that competitors have or don’t have, etc. Marketing requirements tend to be at a higher level rather than detailed. Marketers are not interested in sending a message about the minute details of the product; they want to send high-level messages to potential customers that will lure them to the product. For example, for a travel website they may have a requirement that the application should have more airline choices than all other competitors, or that it will find you the lowest airfare guaranteed.

The sales representatives are in the field with customers day-in and day-out so the requirements they seek are frequently based on what they are hearing from their customers during product demos. Keep in mind that they are usually demonstrating the product to purchasing decision makers and not end users. These requirements tend to be more detailed than marketing requirements. They may have requirements such as It needs to be fast or It needs to look like the number-one travel website in the marketplace. It is important to remember that these requirements may be very customer-specific and not applicable or scalable to other current (or future) customers.

Sales and marketing departments do not typically collect detailed information regarding what the user must be able to do with the product, how they must be able to use it, and under what circumstances they must be able to use it; however, some marketing and sales requirements do represent end user requirements. Consequently, you will likely see some overlap between the user requirements and what sales and marketing have uncovered. The reality is that if the product doesn’t do what users want, it doesn’t matter how usable it is. Marketing and sales folks often talk to end users and sometimes they even talk to them about usability, even if only at a high level. Mostly, they talk to users about features and capabilities. This is valuable information. Its weakness is that the information they collect is often incomplete, and they almost always collect it in demo mode (i.e., selling rather than listening). They work hard at trying to understand users, but because it is not their primary goal they don’t have enough time to gather true user requirements. In addition, they may encourage new features to be included in the product because the latest technology is easier to sell, not because users want it.

SUGGESTED RESOURCES FOR ADDITIONAL READING

We do not delve into the processes for collecting these other types of requirements as this book is focused on user requirements. However, if you would like to learn more about this important topic there are a number of books available that deal with the collection and management of these types of requirements. One such book is:

• Weigers, K. E. (1999). Software Requirements. Redmond, WA: Microsoft Press.

User Requirements

Just like product development, marketing, and sales, you want your product to sell – it’s what pays your salary! If you are creating the product for use in your organization, you will want users to be more productive and satisfied. Consequently, you need to listen to what your customers, marketing, managers, and sales people have to say. Of course, selling the product is just part of the effort. But before the product is sold, you want to make sure that end users can actually use it and that it contains the features they need. If you ignore this important goal, increased training and support or decreased user productivity will lead to unsatisfied customers, and that can harm future sales or decrease renewed licenses or product upgrades. It can also lead to a poor reputation and no new customers.

As was discussed above, you may think you understand what the end users want and need because other sources have told you on their behalf. This is the number-one mistake that product teams make. In reality, purchasing decision-makers, sales, and marketing may think that users interact with the product in a certain way, but because they (decision-makers, sales, and marketing) are not the true end users, they are frequently mistaken. In other cases, they receive information from one single source that has spoken to the end user, but much gets lost in the translation and interpretation by the time the information gets to you. Figure 1.3 illustrates many of these problematic communication paths from which the product team receives user information.

Figure 1.3 Communication paths from the user to the product team (image based on Weigers 1999)

As a result you must talk to the actual users, the people who will use the product at the end of the day, to gain an understanding of their perspective and needs. This understanding includes their tasks, goals, context of use, and skills.

By addressing your users’ requirements you can create a product that fulfills their needs. This fulfillment will in turn:

 Increase sales and market share due to increased customer satisfaction and increased ease of use

 Decrease training and support calls that result from user interfaces that don’t match the users’ mental model

 Decrease development time and cost by creating products that contain only the necessary functionality.

Getting Stakeholder Buy-in for Your Activity

It can be difficult to convince people to support user requirements activities with limited time and budgets. Today’s products must be developed on tighter and tighter budgets and deadlines. Below are some of the arguments you may encounter and how to address them. We also discuss ways to prevent this resistance from occurring in the first place.

Arguments and Counter Arguments

We simply don’t have the time or money for such a study.

This will probably be the first response you will hear when proposing such an activity to a product team unfamiliar with user requirements. The reality is, schedules slip. Even if you cannot get the information in to influence the upcoming release of the product, there will be future releases where your data can be used. You want your information to make an impact as soon as possible but do not let schedules prevent you from collecting the information altogether. There are also a variety of methods that can be used to collect information. Some, such as the wants and needs analysis, group task analysis or card sort, can collect the information within an hour or two and you can complete the data analysis in just as little time. You may also want to show documented cases where products went wrong and could have been saved by conducting user requirements activities – see Hackos & Redish (1998) for a plethora of case studies. Better understanding your users can also provide a competitive edge.

SUGGESTED RESOURCES FOR ADDITIONAL READING

The book below contains a plethora of case studies of real-world products that went wrong and could have been saved by conducting a field study.

• Hackos, J. T. & Redish, J. C. (1998). User and Task Analysis for Interface Design. New York: John Wiley & Sons.

Sales owns the customers. We don’t want to ruin any potential deals. We don’t want to make the customer unhappy by pointing out what our product doesn’t do.

If you are working on a commercial product, you will likely hear lots of arguments against letting you go near customers. In all of our years of gathering user requirements and conducting usability tests, we have never caused our company to lose a deal or caused a customer to be unhappy with our products. If anything, we have improved relationships between customers and our product development teams because we understand many of the requests customers have been making. Customers may not understand the true cause of their difficulties and have made requests that do not adequately address their problems. The product team may be responsive in making the requested changes; but if the root cause is not understood, more damage can be done to the product. If customers perceive that the product development or sales team is not meeting their needs, this will lead to unhappy customers and frustrated developers or sales people. When you conduct user requirements studies, customers see that your company is trying to understand them and their needs. This will only result in grateful customers. In the end, if you cannot get access to customers, there are other ways of accessing end users (refer to Chapter 5, Preparing for Your User Requirements Activity, Recruitment Methods section, page 173).

You’ll make promises we can’t keep. You’ll let out confidential information.

Obviously, you do not want to make promises to customers (whether you know you can keep them or not). You are there simply to collect data. Also, you are not there to share confidential information about the new feature/product/service you are developing. If it is obvious to your participants what you are working on based on your questions, confidential disclosure agreements (refer to Chapter 3, Ethical and Legal Considerations, Legal Considerations section page 103) can be put in place to keep them quiet. To calm stakeholders’ fears, develop a standard script and pass it by everyone for review.

We have information already. Why collect more?

It can be hard to win support for your study when everyone is telling you they know it all already. The product team may have already conducted their own focus groups, or the marketing department may have already interviewed potential users, or the sales team may have already conducted their own site visits. Often, these are product demos or QA tests, asking users whether they prefer A or B. Product teams sometimes give users a click sheet to walk through a prototype to get users’ impressions. This is not the kind of data you want to build from. Find out who did the studies, who the users were, and the techniques used. You want unbiased, empirical data. State that all their information is good and you do not intend to replace it; you simply need additional information to supplement what they have learned. You need new details. Show how the information you plan to collect will be different. For example, you want to interview actual end users, not purchasing decision-makers; or you want to learn how users currently complete tasks, not get feedback on a prototype.

We are introducing a different process, so don’t waste your time studying the current process.

You need to understand how people currently work so that you can leverage the good and leave the bad behind. You also want a transfer of training. You could end up designing something that is incompatible with the user’s current environment – even if your product/system/process is better. You need to understand what challenges you may end up facing when changing the process. Maybe people like the way things are, even if they are inefficient. You also need to understand the ripple effect of your changes. You may end up inadvertently affecting other groups/systems/customers.

This product/process/service is completely new. There is nothing to observe.

There has to be a manual or automated process currently in place. How was a need for the product determined in the first place? If the potential users do not exist for you to study, who will buy the product? There is always someone or something you can learn from to inform your designs; it just may not be obvious at first.

Everyone does it differently so there is no point studying a few users.

There will always be individual differences; that is why you want to study a range of users and environments whenever possible. The differences may also be smaller than everyone assumed. If the differences are large, perhaps you can determine the most efficient process. Maybe you can find a pattern in the differences. At the very least, you can identify alternative ways your product should support users.

We’re changing just one part of the system/product/environment. We don’t need to study more than that.

You need to understand the context that the change fits into. Users do not work in isolation. Systems are much more interrelated than most people realize. The most successful systems are developed when all parts integrate seamlessly – and this cannot happen if you consider each part in isolation.

We do need this method, the product is only for our own organization.

You will often hear this from managers of internal products. But the productivity hit is actually twice as bad when an unusable product is implemented in your organization. The end users are less productive and they depend on the support of people in your organization to help them.

Chapter 14, the concluding chapter, contains a great case study about a company called Calico Commerce (no longer in business) that illustrates the kinds of resistance that one often encounters when planning user requirements activities and selling the results (see page 666).

Preventing Resistance

The best way to combat resistance is to avoid it all together. Two ways to accomplish this are:

 Get stakeholder involvement

 Become a virtual team member.

Get Stakeholder Involvement

One of the key themes that is reiterated throughout this book is getting your product team (or stakeholders) involved. You want them to feel ownership over the activities that you conduct. You want to have their agreement and buy-in that the user requirement activities will benefit their product. If they do not believe in what you are doing, or are skeptical, then they will likely be hesitant to implement your recommendations after the execution of your activity. To gain acceptance for user requirements collection you need to involve them in all stages of the activity from the preparation stages through to the recommendations stage.

Become a Virtual Team Member

If you are not organizationally a member of the product team, you will want to virtually become a member. From the moment you are assigned to the project you will want to work to become an active, recognized member of the product development team. You want to be perceived as part of the team, otherwise it is too easy to be forgotten in the distribution of critical information or in a meeting that is deciding directions without critical input that you can provide.

If you work in a consulting capacity, the product development team may view you as an outsider. Even if you are a dedicated resource to that product, the developers or management may not view you as a team member because of your unique skill-set. Deliverables such as your activity proposals and activity findings may not be taken with the same sense of ownership if you are not seen as one of them. The product team may even feel that you are not knowledgeable enough about the product to be taken seriously. Clearly, this is a detriment to your work.

The ideal situation is when you can become a virtual member of their team. You need to be as knowledgeable about the product and the factors that feed into the process as possible. You want to be perceived as someone who contributes to developing solutions for the product, rather than just identifying problems with existing solutions. This may require you to develop more technical expertise or force you to attend weekly staff meetings that do not always apply to usability and design. You will need to gain the respect and trust of the team and this takes time. You are not there to sabotage their hard work; you are there to help them develop the best product they can. In order to do this you need to understand how the user requirements fit into the big picture. Of course, user requirements are critical for a successful product, but you must be willing to acknowledge that they are not the only requirements. In order to increase your influence this is critical.

The earlier you can get involved the better. The more time you spend with the team and the more familiar you become with the product, the more the team will respect you and your effort. This anecdote from a professional colleague illustrates how important being a member of the group can be:

I was once working on a project as a contractor for a major software firm. Unfortunately, as a contractor, I was a second-class citizen and was not invited to many of the design discussion meetings that the software engineers held. After a while it became clear that I was no longer up to date on what features and capability that the product was to provide and was unable to contribute to how they should be realized as a user process. In spite of that, the project manager thought that I should still be able to design a user interface. After a while it became evident that things weren’t going to change and it made more sense to leave the effort than to remain on and charge them without being able to do the work they were paying for.

Here are some quotes to help you and your organization understand just how important user requirements collection is (Marcus 2002):

 "Incorporating ease of use into your products actually saves money. Reports have shown it is far more economical to consider user needs in the early stages of design, than it is to solve them later. For example, in Software Engineering: A Practitioner’s Approach,author Robert Pressman shows that for every dollar spent to resolve a problem during product design, $10 would be spent on the same problem during development, and multiply to $100 or more if the problem had to be solved after the product’s release." (IBM 2001)

 One [well-known] study found that 80 percent of software life-cycle costs occur during the maintenance phase. Most maintenance costs are associated with ‘unmet or unforeseen’ user requirements and other usability problems. (Pressman 1992)

 When systems match user needs, satisfaction often improves dramatically. In a 1992 Gartner Group study, usability methods raised user satisfaction ratings for a system by 40%. (Bias & Mayhew 1994)

 Although software makers don’t seem liable to the same sorts of litigation as, for example, a manufacturer of medical equipment, poor usability may be an element in lawsuits. For example, the Standish Group reported that American Airlines sued Budget Rent-A-Car, Marriott Corporation, and Hilton Hotels after the failure of a $165 million car rental and hotel reservation system project. Among the major causes of the project’s disintegration were ‘an incomplete statement of requirements, lack of user involvement, and constant changing of requirements and specifications,’ all issues directly within usability’s purview. (Standish Group 1995)

In addition, it has been discovered that inaccurate user requirements are responsible for up to 60% of the errors in software production alone (Weinberg 1997). Another study found that 63% of large software projects significantly overran various estimates when planning (Lederer & Prasad 1992). They cited 24 different reasons for the inaccuracies in the estimates, and the four with the highest responsibility were related to a lack of poor user requirements gathering! The reasons stated were:

 Frequent requests for changes by users

 Overlooked tasks

 Users’ lack of understanding of their own requirements

 Insufficient user analyst communication and understanding.

The Methods

One of the big myths surrounding user requirements gathering is that it takes too much time and money. This is not usually true. There are activities that can be conducted in as little as two hours, while others can be designed to take two months. Each type of activity provides different information and has different goals. There are a variety of user requirements methods to match any schedule and budget. Regardless of your budget or time constraints, in this book you can find a user requirements activity that will answer your questions and improve the quality of your product. These methods are:

 Interviews

 Surveys

 Wants and needs analysis

 Group card sort

 Group task analysis

 Focus group

 Field visits.

The methods were chosen because each offers a different piece of the picture that describes the end user. In addition to teaching you how to conduct each of these methods, this book discusses user identification and recruitment, moderation techniques, and incorporation of user requirements into the product. We also discuss our own lessons learned and modifications for each method. Finally, case studies are provided so that you can see how other usability professionals have leveraged these techniques to support their products. You can benefit from their lessons learned.

In this section is a brief description of each method. Table 1.1 below compares the methods.

Table 1.1

Comparison of user requirements techniques presented in this book

Interviews

Interviews are one of the most frequently used user requirements gathering techniques. In the broadest sense, an interview is a guided conversation in which one person seeks information from another. There are a variety of different types of interviews you can conduct, depending on your constraints and needs. They are incredibly flexible and can be used as a solo activity or in conjunction with another user requirements activity (e.g., following a card sort). Interviews can be leveraged when you want to obtain detailed information from individual users that you cannot obtain through another activity (e.g., group task analysis, survey, etc.).

The end result of a set of interviews is an integration of perspectives from multiple users. If you conduct interviews with multiple user types of the same process/ system/organization, you can obtain a holistic view. Finally, interviews can be used to guide additional usability activities.

Surveys

Surveys allow you to ask every user the same questions in a structured manner. Users can complete them in their own time and from the comfort of their home or work. Since they can be distributed to a large number of end users, you can typically collect much larger sample sizes than with interviews or focus groups. In addition, you can get feedback from end users around the world; however, response rates can vary from 1% (charity surveys) to 95% (census surveys).

Unlike interviews, surveys should not ask users a lot of open-ended questions because that will decrease the response rate. Use surveys when you have a good idea of the most likely answers an end user would like to select from. Providing set responses for users to choose from will allow you to collect quantitative rather than qualitative data.

Wants and Needs Analysis

The W&N analysis provides information about the kinds of content, features, and characteristics users want and need in a product. This brainstorming activity works for any product or service and results in a prioritized list of users’ wants and needs. This technique can be used to both validate current feature plans as well as to learn about new features that users would find valuable. Although it can be used at any time, this technique provides the most benefit when used during the conceptual stage of product development.

The W&N analysis can be conducted in about an hour and it takes even less time to analyze the data from a session, making this technique light on resources, but powerful in terms of results. Most often, the results of this activity are fed directly into the product’s functional specification and design documentation.

Card Sort

A card sort is used to inform or guide the development of the information architecture of a product. For example, it can help determine the tab and sub-tab structure ture in applications. It can also provide information when deciding how to lay out displays and controls on an interface.

To conduct the technique, cards describing objects or concepts in a product are sorted into meaningful groups by each participant. By aggregating the sorts created by several users, we can learn how closely related each of the concepts are. This method tells us how a product’s features should be structured to match the users’ expectations about how those features are related. This technique can be conducted with individuals or with a group of users working individually. If a group is used, the data can be collected in two hours or less and then analyzed with one of several automated tools available today.

Group Task Analysis

This method is used to gain an understanding of the steps users take to complete a particular task and the sequence in which they take those steps. Users work in small groups of four to six people and discuss the steps involved in completing a particular task (e.g., booking a vacation). By having people from different companies work together, you end up with a task flow that works for everyone. The flows generated by the activity are used to determine the task flows in a product. The activity takes about two hours and the results are analyzed in even less time – making the group task analysis ideal for those short on time and resources.

Focus Group

In a focus group, eight to ten end users are brought together for an hour or two to provide information in response to a series of questions, or to provide their subjective response to product demonstrations/concepts. Often, participants are given tasks to complete with prototypes of the product so that they may have a better frame of reference from which to speak. Presenting the questions or product to a group usually sparks group discussion and can provide more information than interviewing individuals alone.

Focus groups are one way to gather information about a target audience that you have very limited information about, but they are better suited to the generation of ideas rather than evaluation and analysis. You can also discover problems, challenges, frustrations, likes, and dislikes among users; however, you cannot use focus groups to generalize the exact strength of users’ opinions, only that they are adverse to or in support of a concept or idea. If conducted well, a focus group can provide a wealth of useful information in a short period.

Field Study

The term field study is a larger category of usability activity that can include contextual inquiry, on-site interviews, simple observations, and apprenticeship. During a field study, a researcher visits end users in their own environments (i.e., home or workplace) and observes them while they are working. Field studies can last anywhere from a couple of hours to several days depending on the goals and resources of your study.

Using this technique, a usability professional gains a better understanding of the environment and context surrounding the user’s work. By observing users in their own environment, you can capture information that affects the use of a product – including interruptions, distractions, and other task demands – and additional context that cannot be captured or replicated in a lab environment. Field studies can be used at any point during the product development lifecycle but are typically most beneficial during the conceptual stage.

These seven methods provide you with a variety of options. Some techniques can be intensive in time and resources (depending on your design), but provide a very rich and comprehensive data set. Others are quick, low-cost, and provide the answers you need almost immediately. In addition, each of these techniques can provide different data to aid in the development of your product or service.

It is important that you choose the correct activity to meet your needs. In Table 1.1 above we outline each of the activities proposed in this book and take you through what it is used for, its advantages, and the level of effort, cost, and time required relative to the other methods.

CHAPTER 2

BEFORE YOU CHOOSE AN ACTIVITY: LEARNING ABOUT YOUR PRODUCT AND USERS

INTRODUCTION

LEARN ABOUT YOUR PRODUCT

LEARN ABOUT YOUR USERS

Step 1: User Profile

Step 2: Personas

Step 3: Scenarios

PULLING IT ALL TOGETHER

CASE STUDY A: COMPETITIVE INTELLIGENCE: MINING DESIGN CONCEPTS FROM BUSINESS SCHOOL LIBRARIES

CASE STUDY B: PERSONAS: A CASE STUDY BY MICROSOFT CORPORATION

Introduction

When working with a product team, your first objectives are to learn about the product and the users. It is key for you to ascertain as much as possible about the existing product in terms of its functionality, competitors, customers, etc. In addition, you need to assess what is currently understood about the users and begin to create user profiles. This information will enable you to choose appropriate user requirements activities so that you can ultimately improve your product. In this chapter we will detail how to collect product information from a variety of sources and how to make sense of the information readily available to you. We will also discuss how to create user profiles, personas, and scenarios, and how to use these as design tools. Finally, we present two excellent case studies. The first illustrates how to conduct a competitive analysis and the second details the successful use of personas.

At a Glance

> Learn about your product

> Learn about your users

> Pulling it all together

Learn About Your Product

Before you even begin working with a single user, you need to understand the domain you are working in. We cannot stress enough how important it is to do your homework before jumping into one of the user requirements activities described in this book. You may be extremely pressed for time and think you can learn the domain while you are collecting data from users. Big mistake! You will need to answer many questions for yourself. What are the key planned or available functions of the product? Who are the competitors? Are there any known issues with the product? Who are the product’s perceived users? In addition to helping you collect effective requirements, this knowledge will also earn you necessary respect and trust from the product team (refer to Chapter 1, Introduction to User Requirements, Become a Virtual Team Member section, page 19).

Limiting your homework to speaking with the product team is often not enough. We hope that the product team you are working with is composed of experts in the domain and that they have done their homework as well. Unfortunately, this is not always the case. Particularly with new products, the product team is learning about the users and the domain at the same time you are. It is important to interview the product team and learn everything you can from them, but you must also supplement that information with data from other sources. In addition, the more you know about the product and domain, the more respect you get from the product team. You may never know as much as some of the product managers; however, there are always some fundamentals they will expect you to know or to pick up quickly. In the very beginning you can get away with being naive; but with time, stakeholders will expect you to understand what they are talking about.

In this chapter, you will read about a variety of sources that you can use to learn about the product you are dealing with, and your end users. Keep in mind that this section is not intended to tell you what to do instead of collecting user requirements. It is intended to tell you about some of the research you will want to conduct before you even consider running a user requirements activity. In addition, we have included two very enlightening case studies, one related to gaining a better understanding of your product, and the other to gaining a better understanding of your users. The first study is from Diamond Bullet Design and it discusses a competitive analysis that was done to compare online business school libraries. The second study is from Microsoft and it details the process of creating and using