6

Analyzing Your Users

“Observation more than books, experience more than persons, are the prime educators.”

—Amos Bronson Alcott

Topics Covered in This Chapter

The Users’ Mental Model

The Experience Bell Curve

Understanding the User’s Goals

User and Task Analysis

In Chapter 5, “How Users Behave,” you learned about how users behave as well as the personality types, experiences, and behaviors that they bring with them. This users’ mental model is the user vision for your user interface—what they expect the interface will look like and how it will behave. The closer you come to this vision in your interface design, the happier your users will be.

If you plotted user experience levels on a graph, you would find that they adhere to a bell curve. Most of the users on this bell curve have an intermediate level of knowledge, and you can design your user interface to meet the needs of this large group of users.

To create a good interface or product design for your users, you need to have goals. Therefore, this chapter discusses the Goal-Directed Design Process promoted by Cooper and Reimann (2003). This process is composed of five phases for understanding the users’ goals. You can get an idea of what you’re looking for by answering a series of questions during the design process. You will also learn where the Usability Engineering Life Cycle from Chapter 3, “Making the Business Case,” fits into the Goal-Directed Design Process.

Users have goals, but how do you find out what those goals are based on their situations? You do this through user and task analysis, which also fits into the Goal-Directed Design Process. Then you can create personas of your users, which are representations of specific types of individuals with specific needs. After you have personas in place, you can prioritize them to determine the personas for which you want to design your user interface.

The Users’ Mental Model

As Cooper and Reimann (2003) point out, the software development process has gone through four phases. When computers first came about, people who knew how to program them were hackers. Originally, programmers did everything when it came to designing computers. This was also true as the first home computers—such as the Commodore PET and 64, Atari 400 and 800, Radio Shack TRS-80, and Apple II—became popular in the late 1970s and early 1980s.

The advent of VisiCalc for the Apple II, and later the acceptance of the IBM PC and compatibles in business, forced the programming industry to fall under the rubric of business processes, where managers drove new software projects. Much of the work that the managers did involved specifying a list of features and then watching as all the features specified for version 1 still didn’t make it in time for version 3.

As graphical user interfaces (GUIs) became standard in the 1990s and more people bought computers for the home to connect to the Internet, more companies became interested in the look and feel. In part, that was because they found that a lot of people were calling them to complain about usability features, and they wanted to keep their customer service costs from rising. The use of beta testers (preferred customers who test the software and identify bugs before general use) as well as usability testing became common during this period.

In the past 5 to 10 years, the issue of good design prior to the coding period has been gathering steam. Unfortunately, despite the introduction of design in the software development process, most engineers still design software from the point of view of adding features and functionality, because the functionality is what’s important to engineers. As a result, many software programs either clumsily implement or don’t implement digital-age improvements to mechanical-age structures.

Take the calendar as an example. Early Windows programs simply showed the calendar one month at a time and didn’t provide any other functionality, such as the ability to scroll month by month or even year by year. My calendar in Outlook 2003 is better, as you can see in Figure 6.1, but it’s still functionally limited. For example, for the next three months, I can see the calendar summary in the upper-left corner of the Outlook window, but I can’t see a yearly calendar in Outlook. I can view only one month at a time.

Figure 6.1. The calendar in Outlook 2003.

The point is that software engineers are still building to mechanical-age standards. They’re only slowly building in technologies that help extend the functionality of familiar systems such as the calendar.

The Result

The result of this mechanical-age design is that you have four primary bad behaviors that still haven’t been fixed (Cooper and Reimann, 2003):

• Software makes assumptions about the user’s ability to understand why something needs to be done—If the program doesn’t tell you why something is being done, you could make a mistake that could cause you to lose a lot of work. For example, if you presume that the software saves your work before you close it, and you decides not to save the file when prompted because you think the file is saved automatically, you’ll get a rude surprise when you try to open it.
• Software is often rude to the user; it blames the user for problems that are instead the fault of poor design—How many times have you received an error message that doesn’t tell you anything about why the problem occurred? (See the one in Figure 6.2, which asks for installation media even though it’s installed.)

Figure 6.2. Software behaving badly.

• Software is obscure—Many of the error messages that you find in Windows are obscure and don’t provide information about how to fix the problem. The only “improvement” in this regard that Microsoft has implemented is to include a list of programming codes that show where the problem is, ostensibly to help the technical support people determine what’s causing the problem. (Few users take the time to contact technical support.) This information is largely useless to anyone but the developers (and perhaps even to them), but that’s not entirely the case. With some error messages, you can look up the error code on the Web and see if there is any information about the problem associated with the code. Hopefully, you’ll find suggested solutions to the problem as well.
• Software behavior can be baffling—For example, when I check the word count in a document in Microsoft Word, which is a task that doesn’t change anything in the document, Word asks me to save the file again. This behavior hasn’t changed in subsequent new versions of Office. WordPerfect, however, closes the program without asking me to save it.

Implementation Versus Mental Models

Cooper and Reimann (2003) differentiate between the implementation model and the users’ mental model:

• Implementation model—The representation of how a product actually works.
• Users’ mental model—Stipulates that users don’t need to know all the details about how something works to use it. For example, you don’t need to know how your CD-ROM drive burns data onto the CD—all you need to know is how to put the disc into the drive properly so that the computer will write the data to the disc (and not use the CD-ROM drive as a cup holder).

Unfortunately, most software designed by engineers follows the implementation model because the interface conforms to the logic within the software. For example, a separate dialog box represents every user action (Cooper and Reimann, 2003), and the user is prompted for information when the program needs to receive it instead of when it’s natural for the user to provide that information.

Because people form mental models that are simpler than reality, designers should always strive for simplicity—one of Norman’s (2002) principles for transforming difficult tasks into simpler ones. (You may have heard of the acronym KISS, which means Keep It Simple, Stupid.) Users don’t care about how something works, and they don’t care if their perceptions are accurate or even true. They understand what they interact with, and they expect the interface to reflect their own model as much as possible. The closer that the implementation model is to the mental model, the easier the interface for the user.

The Experience Bell Curve

Chapter 5 discussed the experiences, behaviors, and other personality traits that people bring with them, and the previous section discussed how the users create a mental model from all these components. If you polled several different groups of users and plotted their experience levels on a chart, you’d find that most of them fall into the range that Cooper and Reimann (2003) describe as perpetual intermediates. Cooper and Reimann call intermediate users perpetual because most of them have neither the time nor the interest to learn more about the program than they need to know to complete their regular tasks in a timely manner.

The chart would look like a bell curve, as shown in Figure 6.3, with the bulk of the curve being populated with perpetual intermediates, and beginners and advanced users on either end.

Figure 6.3. The experience bell curve.

The bell curve is not an accurate representation of every computer user for every user interface through all time. People who are beginners don’t stay that way for long, in part because people don’t like to feel incompetent. Also, users are likely interested in learning how to use the interface because it will benefit them. People can also transition from the intermediate to the advanced stage if they use enough features for a certain period.

The curve can also be skewed depending on how you define experience. For example, if you have a large number of people using a program for the first time, the curve will be skewed so that most of the people using the program are beginners, and a much smaller group in the graph (usually the developers) are in the intermediate to advanced stage. However, if all the users in the test are proficient in Windows, the chart can skew the other way to show that there are no Windows beginners in the group—just intermediates and advanced users at different stages of knowledge.

Different Needs for Different Groups

The three groups of users—beginners, intermediates, and advanced—have different needs (Cooper and Reimann, 2003). If you design your user interface (as well as peripheral information such as your documentation) to meet these needs, all these groups will be more satisfied than if you design primarily for one group or the other.

Beginners

Beginners know they’re novices when they start using a program, and they don’t want the program to reinforce that feeling. Users want to be treated as intelligent people, and they want to learn as quickly as possible. Therefore, instruction needs to be delivered quickly and effectively. This is a good reason to design your user interface as closely to your users’ mental models as possible. You’ll learn how to analyze your users’ mental models later in this chapter.

Beginners have questions that are more basic and broad:

• What does this product do?
• Where do I begin?
• What do I need to do to complete the tasks?

Some pieces of software simply refer to online help as their only means of support, but online help is not designed to be a tool for getting beginners up to speed. If online help is designed well, it is for intermediates and experts to get quick information about a question or issue. A better method for getting beginners up to speed is a demonstration that shows them basic tasks and how to use the program to complete those tasks. This demonstration should be interactive whenever possible so that the tutorial can reinforce the steps needed to complete a task. There are programs that provide interactive tutorials. You can even design an interactive design tutorial in PowerPoint if you want (see Figure 6.4).

Figure 6.4. A sample interactive PowerPoint tutorial.

Intermediates

Intermediates are looking for specific answers to questions, including these:

• Can you remind me how to perform this task?
• How do I find this function?
• What new features are in this upgrade?
• Can I undo my last action?
• What’s the command to perform this task?

These users want access to the tools they need to use, so it’s important to design your user interface to get them those tools right away. You can do a lot of this in the user interface. Intermediate users depend on online help that’s easily accessible from within the program and provides answers quickly.

Intermediates don’t need to know about advanced features, but they like to know they’re there in case they need them at some point in the future. However, many intermediates are assured by having the Microsoft Word advanced features there in case they ever need to use them in the future.

Advanced Users

Advanced users use the user interface constantly, so they develop an instinctive feel for its nuances after a certain period. Therefore, their questions are about connecting their actions to the program behaviors:

• Are there shortcuts for completing this task?
• Can I automate this task?
• How can I customize the interface for my needs?

Some experts are also looking for specific information about a feature of the program that they use regularly but most people don’t use, such as the equation editor in Microsoft Word (as shown in Figure 6.5) or Adobe FrameMaker.

Figure 6.5. Word’s equation editor.

Understanding the User’s Goals

The Internet has changed the way people think about interfaces and the way companies market to users (Eisenberg and Eisenberg, 2006). This is both a problem and an opportunity for user interface designers. The problem is that users are now driving not only the marketing of products, but also the user interface design. The opportunity is that the designer(s) can get a better grasp of the disconnections between the users’ goals and the user interface design.

Cooper and Reimann (2003) identified the problem as being a disconnection between research performed by market analysts and the design of the interface performed by designers. To fill in the gaps, Cooper and Reimann created the Goal-Directed Design Process for software engineering and user interface design. These gaps are in the forms of three new primary activities between the research and refinement stages.

The entire five-step Goal-Directed Design Process combines ethnography (a method of studying and learning about a person or group of people), research, modeling, and design into five phases, in the following order (Cooper and Reimann, 2003):

1. Research—This phase uses observational and contextual testing as well as interviews to learn more about potential and actual users of the product. One of the primary outcomes of research is the discovery of usage patterns, which suggest the goals and motivations for using the product. For example, if you do research on word processors, one motivation is to write and edit documents more quickly than doing so by hand. You will learn more about observational and contextual testing in Chapter 9, “Usability.”
2. Modeling—After the research is completed, the modeling phase analyzes the research for user and workflow patterns, and from that creates user models based on those patterns. Those models are based on groupings of user goals, motivations, and behavioral patterns. From these user models, or personas, the project team determines how much influence each persona will have on the interface design. You’ll learn more about personas in the next section.
3. Requirements—In this phase, the project team creates requirements that meet the needs of one or more of the personas you identified in the modeling phase. To meet the requirements, you need to learn more about the user in the environment in which he would be using the interface. That takes user and task analysis, which you’ll learn about later in this chapter. The result of this phase is a requirements definition that balances the needs of the user, the business, and the technical necessities.
4. Framework—Designers create an interaction framework that produces a structure for the program so they can add the remainder of the code later. This framework melds general interaction design principles with interaction design patterns to create a flow and behavior for the product. Parts of the framework include input methods, views, data elements, functional elements and groups, and group hierarchy. You’ll learn more about creating an interaction framework in Chapters 7, “Designing a User Interface,” and 8, “Designing a Web Site.”
5. Refinement—This phase refines the framework and includes detailed documentation of the design as well as a form and behavior specification. This phase defines what the design should do to meet the goals of each persona identified in the Modeling phase as well as the business that employs the persona. For example, you should identify a problem that both the persona and business are having, such as having inadequate tools to gain customer feedback, and then identify the solution that your interface will provide to the persona and the business.

The Goal-Directed Design Process also includes important questions that project teams should ask during the process (Cooper and Reimann, 2003):

• How do I find out who my users are?
• How do I learn what my users are trying to accomplish?
• How should my product behave?
• What form should my product take? For example, should the product be GUI-based or Web-based?
• How will users interact with my product?
• How can my product’s functions be most effectively organized?
• How will my product introduce itself to first-time users? In other words, how will first-time users know where to start?
• How can my product put an understandable and controllable face on technology?
• How can my product deal with user problems?
• How will my product help infrequent users become more expert?
• How can my product provide sufficient depth for expert users? For example, how can I automate things so that expert users can become more productive?

---

Note

In this list, the use of the word product doesn’t just include your user interface; it also includes all contact with the user through the program, including error messages and online help. You will only be able to answer all these questions effectively if you take into account all the messages that your interface sends your user.

---

The Goal-Directed Design Process was designed to keep everyone in the loop, keep guesswork out of the design process, and provide a clear rationale for decisions. Note that this process is not linear. You will likely go back and forth between different phases as required to obtain as much information as possible to create an effective user interface.

If you’re on a product project team, it may adhere to this or a similar process. You should not only be aware of this process, which is similar to discovering information from users and refining documentation, but you should also strive to dovetail all related efforts, such as documentation and training, with this process. Dovetailing your efforts will ensure not only that all on the team understand the process, but also that they perform some joint research to gather information and give you an opportunity on the product’s interactive processes.

User and Task Analysis

The users’ mental model is based on many factors, including their experiences, behaviors, beliefs, and situations. As you analyze your users’ mental models, what you’re really doing is marketing to them. As mentioned in the previous section, users are now driving the marketing and acceptance of user interfaces, so it behooves you to make every effort to find out what users are thinking about.

The Research phase of the Goal-Oriented Design Process involves researching how users behave in a number of ways using qualitative and quantitative research (Cooper and Reimann, 2003). Quantitative research is the most objective type of information, but there are numerous ways to interpret statistics to fit a certain point of view. In addition, quantitative research can’t capture the complex interactions between a human being and a user interface.

Qualitative research is research based on the characteristics of something rather than a number or measurement. This book has been building up to this point by discussing the questions you need to ask as well as the different user types. To answer these questions and learn what sorts of users you have, you need to employ qualitative research techniques. These techniques include the following (Cooper and Reimann, 2003):

• Reviews of competing products.
• Reviews of market research, such as computing media Web sites and technology white papers.
• Researching market demographics in the area you’re developing in. That research can include analyzing demographic, geographic, or behavioral variables to see if any patterns emerge.
• Interviews with stakeholders (such as the sales and marketing department), developers, subject matter experts (SMEs), and other experts as needed.
• Ethnographic interviews, in which one or more members of the project team interview a group of users. This group is based on a hypothesis about what the team wants to get out of an interview, such as learning what needs users have.
• Conducting focus groups in a room and asking the groups to answer a structured set of questions or make certain choices.
• Engaging in usability and user testing. The most effective means of user interface testing is user and task analysis, which is done by observing the user as he works in his natural environment. That environment is usually the workplace, but it is more than just the user’s cubicle or office—it’s about the user’s work day and how he employs the tasks every day.

Constructing Personas

Part of user and task analysis is constructing personas, which is also part of the modeling phase of the Goal-Directed Design Process. Before you engage in user and task analysis, you need to learn who your users are by constructing personas. As you read at the beginning of this chapter, personas are user models based on groupings of different user characteristics.

Eisenberg and Eisenberg (2006) discuss the creation of personas in terms of sales, which is essentially what you’re trying to do with your user interface: persuade the user that the interface is worth using. Personas connect three different dimensions of information into one cohesive persona:

• Demographics—This segments some of the persona features. For example, demographic data shows such data as the user’s gender, location, and income.
• Psychographics—This segments some of the persona needs and determines questions that each persona may ask. For example, a spontaneous type and a competitive type will ask different questions and will want different types of information.
• Topology—This allows you to segment by determining how complex the persuasion process is; that complexity is based on a customer’s perceptions and experiences.

Regarding the topology dimension, Eisenberg and Eisenberg mapped a four-dimension model for the process of persuasion in sales:

• Need—This is the urgency that a user feels for a product or service.
• Risk—This is the amount of risk the user is willing to accept regarding such features as a career or self-esteem.
• Knowledge—This is how much knowledge the user has about the product, which can affect need and risk. For example, if someone feels he doesn’t have enough information about a product or service, the risk factor for that user is higher.
• Consensus—This is the understanding during the persuasion process of how many people need to be convinced and when.

The information from the three dimensions of information—demographics, psychographics, and topology—begins to reveal the motivations of your persona types so you can learn what motivates your users to do something.

The Advantages of Personas

Personas overcome several problems that you have at the start of the user design process (Cooper and Reimann, 2003). As you develop personas, you communicate with developers, designers, and other stakeholders to learn what their understanding of user needs are, which encourages more collaboration. The project team uses that input to determine what a product should do and how it should behave. Then it builds several design choices for prospective users to test.

Learning about your users through personas helps minimize or eliminate four design issues that can arise during product development (Cooper and Reimann, 2003):

• The elastic user—that is, the definition of the user in the mind of the designer, developer, or other project team member that allows the member to design the interface and claim he is serving the user. By identifying the typical users of the software, the project team can design the interface to the users’ needs as shown through research, not what’s in a particular team member’s head.
• Self-referential design involves designers or developers projecting their ideas onto the project and claiming that this is what the user wants. In other words, the designer or developer thinks he is a typical user.
• Designing for edge cases, meaning that the project team will design for every eventuality that could happen but probably won’t. With a list of personas available through research, the project team can focus on tasks and functions that will be most important to the majority of users.
• Targeting people who are not end users. There is a tendency to target people who review the software or people in your IT and customer support departments who will be administering and supporting the software. However, by knowing who your real end users are, your project team will be able to design for those users.

The project team then measures the effectiveness of the design by testing design choices on different personas. The feedback from those choices helps the project team build a consensus about and a commitment to the final design.

Personas are also useful for other product-related development efforts, because you can apply what you learn in creating personas for one project to other projects.

Fusing Behaviors, Characteristics, and Goals

Constructing a persona requires you to fuse the behaviors and characteristics of your users with the goals of your users to create a narrative that explains the persona (Cooper and Reimann, 2003).

This chapter has already discussed the project team goals as part of the Goal-Directed Design Process, but users have their own goals and motivations. These goals include the following:

• Life goals—These are met through personal motivations such as wanting to become the president of the company or learn all there is to know in a particular field or area of software.
• Experience goals—These are met by a deep desire to feel competent by not making mistakes, avoid feeling stupid, and enjoy oneself as much as possible.
• End goals for using a specific product—These can include finding the most “bang for the buck” when it comes to the best combination of features and service, finishing tasks quickly and efficiently, and finishing short-term and long-term goals such as fulfilling a customer service request or completing development of a product.

User goals are not the only ones you have to consider when you create your personas. You must also manage the goals of other stakeholders who are both inside and outside your company. In addition, there are three other goals that you have to consider in design (Cooper and Reimann, 2003):

• Technical goals—These goals include ensuring that the program runs in all modern operating systems and that it is secure from viruses, worms, and other malware. If you have a hardware product, your product team must ensure that the hardware is reliable and performs as expected. If your product is not reliable and secure, no one will buy it.
• Customers’ goals—Customers are different from users in that they are not going to use the product, but they will give the product to someone else to use. Therefore, customers are very interested in ensuring that the recipient is satisfied by the customer’s purchase. Customers may also manage products but not use them regularly, such as a product that manages a network server. In these cases, the customers are more interested in the program’s stability and security.
• Business goals—Examples are decreasing costs and increasing profits for the company that is developing the product. Satisfaction of business goals can also show stakeholders that there is a return on investment (ROI) for user interface design and usability testing, which can ensure that such techniques are valid and should be used with other projects,

These goals should never supersede the users’ goals, but in the case of the customer goals, they may require you to create a new persona, as you’ll learn about later in this chapter. You can also use these goals as part of your approach to stakeholders for good user design so that you can show them how good design addresses those goals. See Chapter 4, “Good Design,” for more information.

Interviewing Your Users

Personas are represented as individuals and are synthesized from observations of real people. Those observations take the following forms (Cooper and Reimann, 2003):

• Interviews with users outside of the context of their jobs, such as interviews in conference rooms.
• Interviews about users by other people in the company who can supply that information, such as sales and marketing personnel, executives who meet with users, as well as other stakeholders such as subject matter experts (SMEs).
• Market research data, such as surveys, and other forms of direct feedback, such as feedback at tradeshows, literature reviews, market segmentation studies, and other studies, such as white papers. Figure 6.6 shows a white paper.

Figure 6.6. An example of a white paper.

As you interview your users, map those subjects to behavioral variables, as discussed in Chapter 5, “How Users Behave,” as well as any other demographic data that you or your project team wants to find out, such as age groups. Then you will begin to see patterns in the data to compare against the persona hypothesis and determine if the hypothesis needs to be changed. For example, if your data patterns show something unexpected, you may need to account for these unexpected behaviors by holding new interviews or adding these behaviors to a new persona that you weren’t expecting to add.

This “drilling down” for information about your persona obtains a deeper understanding of your users than a high-level profile, which provides only small amounts of information about the user, such as the user’s name and some demographic data you find in market segmentation studies.

Watching Users in Action

Interviewing your users in a conference room doesn’t give you the opportunity to see how their perceptions and ideas mesh with an impartial view of their work environment and how they react to changes there. The work environment doesn’t just include the work that users do in their cubicles, but how they interact in their larger environment. That includes contact with other people in the company through meetings, phone calls, and e-mail, but also the physical environment.

Therefore, it’s important to perform user and task analysis “in the field” to get the answers to questions about how users operate in their work environment. User and task analysis is the process of learning about ordinary users by observing them in action (Hackos and Redish, 1998). Only by observing users of your products will you be able to obtain a clear picture of how they use your products and how to minimize their problems as much as possible—a condition called extreme usability (Donoghue, 2002). User and task analysis will enable you to understand the following:

• What users’ goals are and what they are trying to achieve
• What users do to achieve those goals
• The personal, social, and cultural characteristics that users bring to the task(s)
• How the physical environment affects users
• The influence that users’ previous knowledge has on how they think about the work, and the workflow they use to perform their tasks
• What users value that will change the interface or make the documentation more usable for them

JoAnn Hackos and Ginny Redish (1998) formulated a list of questions that you will want to have answered about your users before you begin your observations. These questions include the following:

• How do your users think about their relationship to their work? For example, do they like their work, or do they dread coming to work each day because of problems they continually face?
• What motivates your users in their jobs?
• Is the product you’re developing related to the users’ primary work, or will they use it only occasionally?
• What and how much do users know about the subject matter you’re designing for? You may be designing a new interface for a type of product they already know, or this may be a program or type of program they have never used before.
• Have the users had any experience doing similar jobs or tasks?
• What technical skills and tool knowledge do the users bring to the job?
• Do your users embrace or run from technology? There are people who use technology because they like it, and there are those who use technology only because they have to.
• Do your users prefer learning from written documentation or via other methods? People react differently to different types of media and training. Some like to learn on their own, and others like to learn in groups.
• What languages are the users comfortable using? If you’re creating software for a multicultural audience, language is a significant factor to consider in your user interface design.
• Do the users like new experiences, or do they adhere to the “if it ain’t broke, don’t fix it” philosophy? Some users like using the products they have now and are more irritated about having to learn something new than learn how the new product will improve their workflow and the business at large.

You should strive to view as many users in their “natural habitats” as possible. This may require you to work with more than one person to get as much information as possible. For example, you may interview a group of users and then perform an onsite user and task analysis for a different group of users. Another person will perform an onsite analysis of the group of users you interviewed, and interview the users for whom you performed an onsite analysis.

You will likely encounter resistance to onsite user and task analyses both during the Modeling phase as well as usability testing during the Refinement phase. You’ll learn how to resolve those objections in Chapter 9.

Persona Evaluation

After you learn about users’ behaviors and goals from your research, it’s time to review your data and form the personas (Cooper and Reimann, 2003).

As you form your personas, be sure to check your data for completeness and distinctiveness. If there are gaps in the data, such as missing data that needs to address the concerns of your stakeholders, you need to fill them in. If you find that you have two personas that are very similar, you may want to eliminate one or change one enough so that they are distinct enough. Each persona must differ in at least one significant behavior.

When you have your list of personas, it will help your project team and stakeholders to develop narratives for each persona that show what this type of person is like. These narratives help your team get to know your users. For example, “Lisa is a nurse who manages eight patients a day. She’s very busy, and she becomes aggravated easily when the interface doesn’t get her to where she wants to go within two clicks. Her goal is to get reliable information about her patients quickly.” Lisa’s sample persona appears in Figure 6.7.

Figure 6.7. A sample persona without a photo.

You can also add a stock photograph of this typical user to give people a visual cue about what the persona is all about. For the Lisa persona, you could select a stock photo of a frazzled-looking nurse in her uniform. Be sure you select the right stock photo for the right persona, because if you don’t, you’ll create confusion among your team members and stockholders.

Prioritizing the Personas

A persona is only a candidate for the design you want to create. Don’t try to design a product to appeal to every possible persona. After you have your set of personas, you need to determine which comprise the target group for your design. After you create designs tailored for each person in the target group, you can combine those designs into a balanced composite that appeals to the broadest cross section of your likely or potential users. That carefully balanced composite will be the final design for your user interface.

You need to prioritize your personas by placing them into one of six categories (Cooper and Reimann, 2003):

• Primary persona—This is the primary target of an interface. If the primary persona is the target for the user interface, all other personas are at least minimally satisfied with the interface. If there is no clear primary persona, the product might need multiple interfaces for multiple personas, or the program or Web site might be trying to do too much. If you identify more than one primary persona, your product might have too many features.
• Secondary personas—These are personas that would be satisfied with the interface features if one or two specific needs were added. If you have more than two secondary personas, your program might have too many features.
• Supplemental personas—These are completely satisfied by either the primary persona interface or the secondary persona interface.
• Customer personas—These address the needs of customers, who won’t be using the product but want to make sure the person who uses the software likes the user interface.
• Served personas—These are personas that are directly affected by the use of the product. Lisa the nurse’s patients aren’t direct users of the interface but are served by a good interface because of the improved care that Lisa provides for them.
• Negative personas—These are people who are not users of the product and shouldn’t be the design target for it. For example, a candy striper probably won’t use the interface that Lisa is using.

How many personas should you create? That depends on your situation. For example, you may have stakeholders who have concerns about certain user characteristics, and you should have personas that address these concerns. At the very least, you should have two personas (Eisenberg and Eisenberg, 2006). One of these personas should be the primary one, but the second one can fit into any one of the other five categories.

Now that you have learned how to prioritize the personas, you need to translate your goals and the users’ goals into design, as you’ll learn about in the next chapter.

---

Note

Don’t apply personas to all products in your product line, as tempting as this may be. Although you can use many of the things you learned in creating a persona in one product, the primary difference between personas from product to product is the context in which the users use the product. For example, if users use a Web browser and an e-mail program, you may think those activities are tightly linked, but you will likely find that the context in which users use both programs are different.

---

Case Study: Producing a Primary Persona

Your personality type and conceptual model interview questions were only the start of the interview process. You and Evan now need to ask some follow-up questions of each user about individual behaviors and goals so you can produce a primary persona for your group.

You put together a list of questions patterned after the list proposed by Hackos and Redish as follows:

• Do you like your work? Why or why not?
• What motivates you in your job?
• Is the database product related directly to your primary job? That is, do you need to use this product every day to get your job done?
• How much do you know about the subject matter you’re designing for?
• What technical skills and job knowledge do you bring to the job?
• How do you approach technology? Do you love it or put up with it?
• Do you prefer learning from written documentation, or do you prefer online help? What do you think of the documentation of the current system?
• Do you like new experiences, or do you think if it isn’t broken you shouldn’t fix it?

Because none of the employees are using different languages with the software, you and Evan decide not to ask this question but save it for later. After all, when you broke up from your first interview, Mike told you that Mike’s Bikes plans to go international in the future, and at that point, multiple language support will become an issue.

You and Evan decide to ask these questions in person instead of giving the users a list of questions to fill out on their own because you want to see the users’ nonverbal behaviors and listen to their tone of voice as they answer their questions. Users may also qualify their answers with some additional information.

For example, when you interview Jay, the marketing manager, he tells you that he likes his job, but you can tell from his tone of voice and his gestures that he’s clearly frustrated with it. He also tells you that he thinks Mike could be doing more to market Mike’s Bikes to a wider area, but his tone of voice and gestures mellow out when he talks about the changes to the database application and Web site because he believes these changes are going to help meet his goal. Therefore, the answer to the question, “Do you like your work?” is no, but you understand that the new database application is motivating him to like his job more in the future.

With the information about personality types, conceptual models, and individual behaviors and goals, you and Evan review your information and place each of the 10 project team members into different categories based on the following characteristics:

• The personality type of the respondent
• The conceptual model
• The individual behaviors and goals

As you place people into these three categories, a significant number of respondents have the same characteristics, and these people become your primary persona. Your primary persona ends up looking like the following:

• You give the persona the name “Bob” (after all, Bob is a friendly name). He’s someone who knows the system inside and out.
• Bob is an extrovert and is an intuitive, thinking, and judging person. Therefore, he enjoys his job and how technology can make it better.
• Bob is someone who already knows the system and likes new experiences, but only if they make his job easier. Bob also knows his own division intimately and can tell you exactly how his division helps the company.
• Because Bob uses the system every day, he’s come up with a list of ideas for improving the system, and he’s made a lot of judgments about what works in the system and what doesn’t.
• Bob likes the fact that the database is interconnected and that the system affords him a real-time view of what’s going on.
• Bob doesn’t like the fact that he can’t search for a product or term instantly on the site. He considers the current system search functionality to be tedious to nonexistent, which he feels is a constraint.
• Bob wants to have more immediate methods of finding information on the system presented in the appropriate place. For example, the search function should be on all pages so he can immediately find anything he wants on the site. Also, the search function should return relevant results, and there should be functionality on the search results page to quickly go to the previous page or any other page in the system.

Place this information along with a mockup of Bob’s picture and the bulleted persona text on a piece of paper. Make a copy for all the team members to share during the paper prototype test (see Figure 6.8).

Figure 6.8. Bob and the persona text.

In the next chapter, you’ll learn about applying user interface features such as visual and audio cues into your paper prototype test.

Summary

This chapter began with a discussion about a users’ mental model by differentiating between the implementation model, which is a representation of how the product actually works, and the users’ mental model, which stipulates that the user doesn’t need to know everything about how the product works to use it. The users’ mental model requires that designers design user interfaces for simplicity.

The experience bell curve was covered next. You learned that users fall into three categories of experience: beginner, intermediate, and advanced. Most users fall into the intermediate range of knowledge. These “perpetual intermediates” are most interested in specific answers to questions about the product. Beginning users want to know answers to questions such as where to start, and advanced users want to know how they can work more efficiently with the product.

Next, this chapter covered the Goal-Directed Design Process. You learned what the five phases of the Goal-Directed Design Process are, why the process helps fill in the gaps in user interface development, how the process provides a clear rationale for decisions, and what questions the process answers. The Goal-Directed Design Process is not a linear process; you may have to go back and forth between the different phases as needed to create an effective user interface.

The chapter ended with a discussion about user and task analysis and how you use it to obtain as much information as possible to generate personas, which are representations of specific types of individuals with specific needs. You learned about constructing personas and how personas minimize four key design issues: designing for the “elastic user,” creating a self-referential design, designing for “edge” cases, and targeting people who are not end users. You also learned the way that personas fuse behaviors, their characteristics, and goals to create a narrative that explains the persona. Finally, you learned to prioritize your personas by placing them in one of six categories: primary (which is the most important and is populated by one persona), secondary, supplemental, customer, served, and negative. The number of personas you should create depends on your situation.

Review Questions

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

1. Why are designers still building to mechanical-age standards?

2. Who are perpetual intermediates?

3. What questions do beginners always have?

4. What questions do intermediates always have?

5. What are the five phases of the Goal-Directed Design Process?

6. Why should you conduct user and task analysis?

7. What three dimensions of information do personas connect together?

8. What types of goals do users have?

9. Why should you perform user and task analysis “in the field”?

10. Why should you prioritize your personas?