How to Do It | Real-World .NET Applications

Creating a user profile is a collective activity. It does not come from the mind of one person or one group. It has to be decided on, fleshed out, and agreed on (by consensus or compromise) with the whole development team. Key members from each facet of the development of the product need to participate because everyone is going to bring different information to the profile and a different perspective.

The two groups who need to be part of the profile-making process are the people who know the characteristics of the users and the people who need to know those characteristics.

EXAMPLE GROUPS THAT NEED TO PARTICIPATE IN PROFILING

Knows User Characteristics	Needs to Know User Characteristics
Marketing research	Engineering
Support	Identity design
Sales	Interaction design
Business development	Information architecture

Each person will bring a unique perspective on whom they want as their user. Information architects may discuss how they expect people to organize their information. Marketing and sales may be concerned with the things the users read and the reasons they gravitate to this product versus some other one. Interaction design and information architecture may be concerned about the specific things people are trying to get done and the ways they interact with others. Everyone will shine a light on a different side of the user. When all these are seen together, the profile will have a richness that will reveal restrictions and opportunities that are difficult to determine otherwise.

Five to eight people should be invited to be part of the profiling process. More than that, and meetings tend to get unwieldy; fewer, and the profiles produced may not be useful to the whole team.

"This Is Not Quackery"

If this is the first time that this type of exercise is being done in your company or with this team, it's likely that you'll have to overcome some people's apprehension. It's easy for someone who has never participated in a profiling exercise to write it off as marketing gibberish or a fluffy team-building exercise (and we all know how much we like those). To overcome this, it needs to be presented as a legitimate, although fun, part of the development process.

The important things to communicate are that this is a way to get everyone talking about the same thing and that it's an effective way to understand the constraints and desires of your audience. By creating a customer model with a name, it creates an efficient shorthand. Rather than describing a feature for "infrequent large-scale Fortune 1000 purchasers who use SAP," you can say "it's for Leonard" and marketing, engineering, and design will all know the qualities of the audience and how they will use the feature. "Leonard" represents a shared understanding of a class of user experience issues that are important to the success of the product.

The rest of the benefits of the procedure—the ability to understand subtle interaction problems, the coupling of people's desires with a model of their understanding, the team building—are side effects of this communication benefit.

Preliminary Research

Before you get everyone together, you should do some research. Having some direct knowledge of your audience before you start creating an audience profile can jump-start the profile building and resolve issues in its development.

Begin with Internal Research

The first place you should start is right around you. Someone in your company has an idea of who your target audience is. If it's not you, then maybe someone in business development. If not biz dev, maybe the product design crew. If not the product folks, maybe the CEO. If not the CEO, maybe the CEO's hairdresser. Someone, somewhere, has an idea of who your audience is. (If no one does, then you have bigger problems than user experience research can solve.) Maybe all of them have ideas.

Start by asking local experts—the people who have contact with the audience—to describe it for you. If your product has an established client base, talk to the people who work directly with its users—salespeople, support staff, market researchers, technical sales consultants, trainers, and the like. They have had direct experience with who the audience really is. These groups often have detailed demographic profiles and market research that can give you big-picture breakdowns of your audience. Support staff sometimes have "Top 40" lists of user questions and problems.

Say you're creating a small-business banking service for an established bank. The marketing group, which has been selling the bank's services to small companies for many years, will certainly have an idea of who they're selling to and what their values and needs are. If there's a phone number just for small-business clients, then the people who answer the calls will have had special training and have valuable personal experiences with these customers.

Interview these local experts about their personal experiences with users and customers. You may want to recruit some development team members to help conduct the interviews, maybe assigning one interview to each participant. The interviews shouldn't last more than an hour or so. Collect the experts' understanding of the audience's characteristics. What kind of people are the users? What do they do for a living? How often do they use the product? Is there common behavior? Is there something that makes them particularly happy? What are common problems? Ask for anecdotes that illustrate typical client situations and particularly interesting atypical situations.

Warning

Customers are not always users! The people who spec, research, and buy a product may be people who never use it. In large information technology organizations, a manager may decide to buy a product that gets deployed companywide, yet he or she never uses it. Parents often buy educational software they never touch. Find out from your local experts who is responsible for choosing the products versus who ends up using them.

For the banking project, you may want to get the names of several managers who have experience with small-business customers and call them or visit them.

You may see conflicting profiles emerging: sales may be selling to a group of people entirely different from those who contact support; market research may have constructed a profile different from the one business development is using. This is typical and fine. Capture all the profiles, regardless of whether they're conflicting. Don't attempt to resolve them before the profiling process (and don't get into fights about which one is more "right").

Talk to Users

Having gotten some idea of who the users are (or should be), interview people who are roughly like the users. It's great if you have access to people who are actual users of the product (maybe the bank branch managers have some clients whose contact information they can share), but friends and relatives who are close to the audience are fine subjects, too. Talk to three to ten people. Ask them to talk about how they currently do the things that the product is supposed to assist them with, ask them to describe the problems they've had and the positive experiences. Keep a list of good quotations, problems, and anecdotes.

Before the day when you create the profiles, try to extract common threads from the information you have collected. What do the people have in common? Are there problems that seem to crop up frequently? Are there perceptions that seem to be popular? Note conflicts in the various descriptions since differences in the way that people approach a problem are as important as similarities.

Summarize and present your findings before the meeting or at its start.

List the Attributes

Profile building should be done all at once, preferably in one day. That way, the participants can immerse themselves in the information and create coherent models. Two consecutive days can work, but more than that, and the process starts to break up as time dilutes people's memory and enthusiasm. By making it all happen in one (sometimes long) push, the profiles come out as vivid images.

The first step is to make a list of audience attributes. Give all the people in the room a stack of Post-it notes and have them write down things they know or suspect about the audience. These can be as far ranging as the participants want. For example, one person's list for the small-business banking site could be as follows:

40-something

Store manager

Female

Stubborn

Computer literate

Doesn't have a lot of time during the day

Surfs in the evening

Manages two stores

Gets a shipment once a week per store

Has 30 employees

Has kids

Doesn't own the stores, but acts as though she does

Etc.

Have all participants keep going until they've exhausted the attributes they can readily think of (maybe for half an hour). They should finish with (typically) 50 notes apiece, although it's all right if they have more.

Tell the participants that when they're listing attributes, they should use not only the knowledge they gained from the preliminary research, but also, equally important, their gut feelings. People often have a much richer internal model than they're willing to share in normal circumstances because they're not completely confident about it. They should be encouraged to share their suspicions, hunches, and hopes, and be comforted that any one isn't more "right" than any other. There won't be definitive information about all these attributes, so some educated guesses will always have to be made. It's best that these ideas come out early, and as long as they're flagged as guesses and the profiles are revised with new information as it appears, this is fine. Further, since there are specific problems that the group will be trying to solve, it's fine to develop certain aspects of the profile (such as goals or specific tasks) more than others.

The list of attributes isn't a checklist or an exhaustive list of attributes, but it can serve as seeds when thinking about how to describe your users. Each one has a number of questions that can be asked to flesh out the profile.

Demographic

Demographic descriptions are likely to be found in marketing research reports and business development documents. They divide the audience with traditional measurable values such as age, title, industry, income, and zip code. Since we're looking to address people's experiences beyond what is merely measurable through census data (where many of the core demographic constraints come from), this information is only a beginning. There's a relatively complete set of demographic questions in the Appendix, but here are some of the key ones.

Age. How old are your users? If they're representing a company, how old is the company?
Gender. How does your user population divide by gender? Does their gender matter in terms of how they use the product?
Income and purchasing power. If you're selling something for people's personal use, what is your users' household income? What economic constraints do they face as individuals? If for business use, what is their purchasing power? What are the constraints on their industry?
Location. Are your users urban, suburban, rural? Do they come from certain regions, a certain country, or are they spread out all over the world?
Cultural. What's their primary language? Does their culture affect the way they would buy or use your product?
Title. What job titles do they hold?
Company size. If your product is for people who are working in a company, how big is the company? How much money does it make? Does it have large or small margins?

Don't overdo it on the demographics. Although it's important to have an idea of the demographic makeup of the audience, don't obsess about getting every last specific about the users' income or their geographic location (unless it's important to the product, of course).

Technological

Your users' hardware and their skill with it are key constraints on the way they're going to use your product. boo.com, an ecommerce clothing store, was a spectacular failure for a number of reasons, but the most immediate and severe was that their first site—the site that they had spent many millions promoting—was unusable to a large portion of their population. It required higher bandwidth and more computing power than their customers had. Many of their potential customers never even saw the shop because they couldn't get to it.

Computer. What kind of computer does your typical user have? How long has he or she had it?
Monitor. What kind of monitor do your users use? Do they have the latest giant high-resolution display or a lowresolution hand-me-down?
Net connection. How fast is their connection to the Internet?
Experience. How have they been using their hardware? What kinds of things do they use it for? How comfortable are they using computers, in general? What experiences have shaped your users' attitudes toward computers and the Internet?
Browser brand and version. What browser do they use? Which version? The browser platform determines a lot of someone's experience since different browsers present (sometimes drastically) different environments.
Operating system. Similarly, the operating system in which the browser is running creates constraints on how people perceive the information.

Web Use

How people have been using the Web is important in terms of the context in which they're going to use the product and their expectations for it.

Experience. How long have they been using it? How often do they use it? How often do they use it for personal versus work tasks?
Typical tasks. What do they do on the Web? How often?

Environment

The environment in which people use your product can affect the way that they perceive it. Placing a bid on a ton of steel from the factory floor is different from placing it from an office cubicle or a living room. The complexity of your description will depend on the nature of your product, but you should always have some model of the context in which people are going to be using it.

Use location. Is the service going to be used from home? From an office? If so, what kind of office? If they're using it from home, are they going to be constantly interrupted by kids and pets? Do they share a computer?
Use time. Are they going to be using the product during work or during their off hours? Will they be using it first thing in the morning, when they've just returned from the opera, or after the day's last milking?
Tool context. What other tools are they going to use at the same time as they're using your software? How important are the tools? How does your product fit in with them?
Competition. What products or services are competing for your users' attention? What is the nature of the competition? What benefit do competing products offer?

Lifestyle/Psychographic

Besides the way they use your product, people have interests, ideas, and values. They may not directly affect the immediate use of your product, but these attributes are still important when thinking about how your users experience the product. When creating a profile, consider the lives of your users outside the immediate sphere of use, and define who they are as people, not just as customers or clients.

Values and attitudes. What are your customers' values? What is important in their lives? Thrift? Speed? Ease? Fun? Comfort? What has their experience been with services like yours?
Media. How do they learn about new products, services, and ideas? What magazines do they read? Why do they read them? What TV programs do they watch? What Web sites do they go to most often?
Activities. What kinds of things do they do besides using your site? What other sites do they like? What else do your users do in their lives? What do they do for entertainment?

Roles

People play different roles in life, and they interact with other people playing roles. A public defender and a district attorney may do fierce battle in the courtroom, but play racquetball together on the weekends. The roles people play in their lives are often more important than their titles or their listed responsibilities. One materials exchange site, for example, was geared toward plastics manufacturers. Initially, it was thought that the target audience was sales and sourcing managers. However, audience research showed that the managers did little day-to-day managing of the procurement and had (as a group) weak computer skills. Their job descriptions and what they really did were different. The people who did most of the materials exchange were their assistants.

Note

Roles are especially important where target markets and user markets diverge. Target markets consist of people who make purchasing decisions. User markets consist of people who have to live with those choices. Ideally, the two sets overlap or communicate, but that doesn't always happen. If you define separate profiles for the two groups and specify the relationships between them, it can clarify the needs of the user experience.

Titles. What are the groups involved? What are they called?
Responsibilities. What are job responsibilities of each group? What do they get rewarded for (both formally and informally)? How?
Training. What training have they received at work? How often do they get retrained or trained on new features?
Power. What is their responsibility for the product? Do they choose it, or are they assigned to it? Do they pay for it, or does someone else sign the checks? What happens if something goes wrong?
Relationships. Whom do they work with? Whom do they consult with when making a choice? Whom will they be working with after using your product? What will those people need?
Interactions. How do they interact with others? Will those relationships change in the future? What is the nature of the interactions? Informational? Regulatory? Commercial?

Goals

There's a reason people use your product. They're trying to accomplish something in a way that's easier, faster, cheaper, or more fun than the way they're doing it right now. Which of those is it? Specifying the end results (both short term and long term) can help explain people's behavior and their attitudes.

Short term. What problems are your users trying to solve? Which of their business needs does this address? How are these needs going to change with time?
Long term. What effects does using this service repeatedly have on the business as a whole?
Motivation. Why are they using your product? What is driving them? Are these goals personal? Professional? What's the relationship of the goals to the user's job or life? Are they using your product voluntarily, or does their employer or school require them to use it?
Outcome. What does the successful completion of each goal mean? How is success defined? Is there an ultimate goal? What is it?
Pain. What is keeping them from solving their problems with their current tools? How severe is the pain? Are there multiple points of pain? Are they mild irritations or severe show-stopping problems?

Needs

There are two different kinds of needs: those that relate directly to the task at hand and those that are incidental and nonfunctional, but still important. The first set is an expression of goals—a completed goal is a satisfied need—but the second set doesn't have a direct relationship to the functionality of the product; it is more ephemeral, emotional. Some users may need to feel reassured. Others may need to feel they're in control. Still others may need to feel they got a bargain. None of these needs relates directly to the functionality of the product, but they're still important since they can include the secret ingredient that changes a functional product into a great user experience.

Functional. What has to happen for the problem to be solved, for the goal to be reached? What are the factors that differentiate something that works tolerably from something that works perfectly?
Emotional. What do they need to enjoy using the product? Are there needs that the user isn't aware of? What's more important: that the users aren't annoyed or that they're ecstatic? What are their fears?
Reasons. Why are they using your stuff? What are their reasons for sticking with your site? What triggers their use of it? What reasons does the competition offer?

Desires

Desires are not the same thing as needs. Desires are what people think they need rather than what they actually need. From the perspective of the user, it may be difficult to tell the two apart, but a distinction should be drawn when creating a profile. Desires, when fulfilled, may not make the product any more effective or efficient, but they may make the user experience more satisfying, so they need to be taken into account.

Stated desires. What do your users say they want?
Unstated desires. What do they really want?

Knowledge

As they say in noir detective stories, "What did she know and when did she know it?" The back story tells you how people got to your Web site and why they ended up there. There are plenty of things she could have been doing on that sultry August afternoon when she walked into your office, er, clicked to your site. So what is the context in which you find "her" on your doorstep?

Domain knowledge. How much does your audience know about what they're trying to do? Are they experts trying to find a more efficient tool or newbies who need to be taught about what's going on?
Product knowledge. How much do your customers know about your product or service? How much do they know about their own needs? About the options available to them?
Competitive awareness. How aware are they about the various brands competing with yours? How much do they care?

Usage Trends

The patterns in which people use a product determine much about what they want and expect from it.

Frequency. Will they use your service just once, or will it be a regular part of their job cycle?
Considerations. Will they do a lot of research before settling on a service the first time they use it? Will they do this research every time, or will they just do it once?
Loyalty. How loyal are they to their chosen product? Do they just choose the cheapest or most convenient one, or do they stick with one for a while?

Tasks

Ultimately, people are using your product to do something. What? Tasks are actions that users do to move themselves closer to their goals. For the purposes of the user profile, tasks should be seen from the user's perspective. They should be considered at the granularity at which the user thinks. Users rarely think of database row locking (as a software engineer would); they think of transferring money to their checking account or making a hotel reservation. The profile should contain a list of the most important tasks that the user is going to want to do with the system (whether or not the current technical implementation can do these tasks).

Reason. Why do they want to do this?
Duration. How long do they do it for?
Order. Which tasks come after which other ones? Where does the user think the sequence matters? Where does it not matter? How are tasks linked?
Criticality. How important are the tasks? Are they rare, but extremely important, tasks? For example, data recovery should not happen frequently, but it's very important when it does.
Method. How do they want to accomplish the task?
Model. Is there some way they're doing this already? What tools are they using, and how are they using them?

As you're creating tasks, you may notice clusters that are completely independent for otherwise identical profiles. For example, almost all tasks done by people selling homes and people buying homes are completely different although they're related topically, and the people doing the buying and selling are pretty similar. This is an important difference to recognize. The two clusters do more than just define two different profiles; they define two different products.

Cluster the Attributes

Once you've gathered the giant list of attributes, it's time to cluster them into profiles. This is done in a similar way to the Beyer and Holzblatt affinity diagrams used in contextual inquiry, but somewhat simpler.

Start by picking someone and asking him to put his attribute Post-its into several clusters he feels may make useful user profiles. For an online banking site, he may want one cluster with "40-something," "male," "vice president," "Internet newbie," and "responsible for corporate budget," as well as another cluster with "40-something," "female," "store manager," "does books every night." Although everyone started out with an image of his or her audience, this will likely produce multiple profiles.
Ask another participant to put her notes that relate to the clusters around them one at a time. It doesn't matter how the notes relate, just as long as the participant feels that they do relate. If necessary, have people copy their notes so that attributes can exist in more than one profile.
If a participant has notes that don't fit one of the existing clusters, put those up as new clusters.
After each person has put his or her attributes up, discuss them with the group. Do they make sense where they are? Why are they there? Move notes around until you have clusters that everyone agrees on.
Repeat with everyone in the group.

This may take several hours since there may be a lot of attributes and because the discussion can uncover assumptions about what users want and what they're going to be doing.

Warning

Be wary of bias creeping into the profile when participants with an agenda or disproportionate status (say, a senior vice president in a group that comprises primarily junior staff) emphasize a particular view of users. If there are clear contradictions in the profiles, attempt to talk through them, stress that user markets are not the same as target markets, and that unless there's hard data, it's mostly conjecture.

There may be clusters that define prominent user markets and smaller clusters that define potential markets or secondary user profiles. The clusters may be similar to the target market segments that business development or marketing has created but with greater precision in terms of the audiences' relationship to your product.

Once the attributes are put up on the board, stop and discuss the trends that you see in the clusters. Are there obvious trends? Do they fit the user types that the participants had expected? Where are the surprises?

If there are many different clusters, winnow the number of profile clusters down. Keep the number of major clusters between three and eight. More than eight clusters will probably be unwieldy; fewer than three will not provide enough diversity for the profiles to be useful.

The process is flexible. Once you've seen how the attributes cluster "naturally," feel free to combine or modify clusters such that your main user markets are represented. Viable profiles of user markets are more important than slavishly following the rules.

Warning

There is a mis-conception that each site has one user type. That's not true. There is no single profile that describes The User. Some user markets may be more important than others, but none of them will represent all of your users. Generalizing about The User or discussing users as if they were a homogeneous group is crude oversimplification and should be avoided.

At this point, the clusters you've defined—and subsequently the profiles you base on them—should be fairly different from each other. Although it's fine if several of your profiles have some common attributes, you should not have profiles that are similar in all major ways. The ultimate goal is to create a set of profiles that will not just show the breadth of potential users, but that will exercise the most important product functions. It may be true that most people will use most of the same features, but it's also important to create profiles that will need to use the less common features. This may involve stretching or overloading a "natural" attribute cluster with attributes that you feel are important for someone to have. For example, if it's critical that you examine how people can use an online banking system from multiple machines, you could add "actively uses the Web from home and work" to a cluster where it seems plausible.

Likewise, if there are large audiences who are not represented and yet you know are part of the user market, you should continue discussion with the group until you feel that you've identified your main user groups. Again, keep in mind that these are not sales markets, but user markets, and these audiences may not necessarily match the audiences that sales and marketing have in mind when selling the products.

The Guerilla Method

A less labor-intensive way of creating user profiles from lists of attributes is to shorten or eliminate the Post-it clustering and focus on fewer profiles. Try to come up with threegood profiles through discussions based on the lists of attributes rather than having everyone write down everything. This method requires the participation of a good group moderator since it'll be important that everyone in the discussion has a chance to contribute his or her perspective. The group should start by coming up with a couple of major profiles, fleshing them out until they seem relatively complete. Other profiles are added using attributes that haven't been used until everyone feels that all the important user groups have been described.

Create People Around the Clusters

Until this point, the process is similar to defining a target market, but here it starts to diverge. A target market defines a market for a good or a service that's large enough to be valuable and homogeneous enough that the differences between individuals are negligible. It does this by abstracting out the details between certain individuals. User profiling, on the other hand, introduces personal details to create a realistic portrait of a user to focus on specific user needs rather than market tendencies.

This means making stuff up.

Now is the time to make the clusters come alive by creating enough "narrative glue" between attributes so they all make sense together as a description of an individual. You may want to assign each profile to someone in the group; he or she can flesh it out and bring it back to the group for refinement. The added details should not be major defining factors (those have all been determined already), just embellishments that create a rounded character.

In many cases, adding details is as straightforward as creating a specific "fact" that falls within an attribute range you've defined. So, for example,

40-something

Female

Children

Suburban

Store manager

becomes

Doris Washington

45 years old

Married to Steve

Lives in Livonia, Michigan

Has two kids: Greg, 17, and Andy, 13

Manages three 7-11 convenience stores in Troy, Michigan

Add enough details that people seem real and believable, but try not to introduce features that are going to distract from the basic issues. If it doesn't matter whether Doris lives in Livonia, Michigan, or in Willamette, Illinois, don't make a big deal of her residence, just pick one. Don't create idiosyncrasies. Strong features tend to distract from the important attributes. So if the base audience is made up of typical teenagers, don't suddenly make your profile a 45-year-old professional ice climber and jazz trumpeter.

Now flesh out the rest of the attributes. You've decided that Doris works for someone else, is "confident in her knowledge" of her domain, and has "direct (though not ultimate) responsibility" for her business. Now you may want to write a little story about it, working those features into a more extensive profile.

The stores are all owned by Sammy, whom she's been working for since she was in her late 20s. Over the years, she's gone from working as a clerk to being Sammy's most trusted employee, to the point that they both agree that she knows how the stores run better than he does.

You may want to add some specific banking information.

She works out of the office in back of one of the stores. Every evening, she drives to the other two stores, checks the stock rooms, and picks up the day's receipts and register tapes. After dropping all three deposit bags off at Comerica (while they're still open), she goes back to do the books. Often, she ends up staying late, doing the books well past dinnertime.

This can then be mixed with specifics about her computer and software use.

Although their family has a newish PC at home—and she uses it to surf the Web when Andy's not chatting—she's been using the same machine at work for at least five years. It hasn't been upgraded because books take enough of her time that she doesn't want to risk getting behind while the new system is being configured.

Complete the profile by creating a story tying all the attributes together, highlighting the problems and anxieties Doris faces on a regular basis. Think of it as wearing someone else's life, trying to put all the elements together so that they make sense, so that they tell a coherent story about how a real person, a real character, could live. Flesh out the rest of the attribute clusters. You can break up the discussion group into teams and have each team spend an hour coming up with a story for each profile, presenting them to the whole group afterward.

After doing this, you end up with five profiles (for the purposes of this example).

Doris, manager of three 7-11 stores

Sammy, owner of the 7-11s that Doris manages

Clarence, antique and crafts store owner

Keith and Jeff, building contractors, co-owners of KJ Build

Jennifer, freelance writer

When you're done, discuss all the profiles. Are they believable? Do they seem like the kinds of people who would be using the service?

Prioritize

Not all profiles are equally important, so the group should prioritize them. The prioritization may be dictated by business needs, in which case the priorities will be similar to the target market order. It can also be dictated by the needs of design. An audience may be important for the success of the product, but what it needs is subsidiary to the needs of another group. By focusing on the needs of the more challenging group, you're satisfying both their needs and the needs of the more fiscally prominent users. Porsche's auto design philosophy, for example, is to surpass the expectations of luxury performance car geeks. Since most of us aren't luxury performance car geeks, this ensures that most of us will be really impressed and satisfied if we buy a Porsche, and the geeks, whose opinions are important for Porsche's image, keep recommending the cars.

For the banking example, this means that the needs of someone like Doris, who has three busy stores to run, will probably subsume the needs of Clarence, who has only one. Clarence may have other niche needs, but his general needs will be served by most of the same functionality that will work for Doris. It may be that there are more Clarences out there than Dorises, so Clarence may be the target market for sales and marketing, but by serving Doris's needs you satisfy them both.

From a development perspective, prioritizing also creates a coherent way of deciding between competing solutions. When you have two ways of resolving a problem, always choosing the one that favors your primary profile ensures continuity and consistency.

Tell Stories

Once you have your profiles, it's time to create scenarios with them. Scenarios are stories that describe how a person behaves or thinks about a task or a situation. They contain the narrative of what the person does along with his or her motivations, expectations, and attitudes. Scenarios are created by role playing with the profiles that you've created, by putting on the shoes of the people you've created, and looking at their problems and your solutions through their eyes.

Note

If you spent your college evenings acting or playing role-playing games, now may be your big opportunity to put that knowledge to use in the working world. Dust off those improv and Dungeons and Dragons skills and show your co-workers how it's done! (You may want to leave your Beckett collection and your 20-sided dice at home.)

To some extent, this is what the user profiling exercise has been leading up to. User profiling works on the model of the story. We are wired to think and communicate through stories and to understand the world as interpersonal relationships tied together in a narrative. Models make it easier to understand the subtleties of your product and to see relationships and issues with it. A table of statistics or an abstract market description would not reveal relationships nearly as well as a story.

Start by retelling some of the stories you may have written down in your preliminary research from the perspective of each user profile. These steps can be done as a group, by individuals, or in pairs. How would Doris handle a situation that you know has actually happened? What would she do? How would she think about it? How would Jeff, the building contractor, handle it?

Next, try to create the ideal scenario for each of your profiles. If this were Heaven, how would everything work for them? In what situations would the software anticipate their wishes? How would it help them make decisions? What would be the perfect situation?

At 5 PM Doris goes home. She talks to the kids, has dinner with Steve, and then sits down to do the books at 7 PM. She's confident that the deposit bags have been safely picked up. She signs on to the site to check the day's register totals. Dragging the day's totals into her spread-sheet, she can see how each of the stores is doing and can run a total for the week's performance, comparing it to the same time last year. At 7:20, she's done.

Introduce constraints one at a time and see how the story changes. Say that Doris can't get the day's totals input automatically into the site. What will she do? What would happen if she couldn't download it into her spreadsheet? When will she stop using the product because it's too cumbersome or too complicated? Role-play with the profile to determine which values drive Doris's decision making, what is most important to her.

Now think about the problems you have listed for Doris and the other profiles. What are the values and constraints that affect the way the characters look at those problems? What are the profiles going to do when faced with task X or problem Y? Understanding and communicating how different people approach situations will help you create solutions that work for all of them.