Know How to Uncover Reality

The way to uncover the reality of what users really want and need should seem obvious. After all, if you're like the rest of us, you've had at least one argument in your life about whether you were listening to your spouse, your parents, your best friend, or [insert person here].

But it's not obvious at all.

When we communicate with our spouses, we have a history to rely on. We know how to talk to and listen to our spouses. Our users, on the other hand, are alien to us. We have no history with them, we've never hung out with them at a bar on a Friday night, and we don't typically have long conversations over dinner with them. So when we're faced with trying to understand what our users really need, it's very easy to forget everything we know about communicating with other people.

For example, if I were designing and building an application used to track sales trends for the Sales department in my own company, my first instinct, if I decided to research my users, would be to hunt down Molly from Sales and ask her what she would like the application to do. Tell me, Molly, how should the Sales Trends Odometer display the data you need?

I would never ask my fathersomeone I have history withthe same type of question. My father knows next to nothing about how Web sites are built, what complicated technologies lie lurking beneath the pretty graphics, or the finer points of information architecture. He wouldn't even be able to pick a Web application out of a lineup, because he doesn't understand what I mean by the word application. Is Amazon.com an application? He doesn't know. He just knows it's a Web page and he bought a book there once.

What my father does know is that the model rockets he builds for fun on weekends require several parts that he has to hunt down on a regular basis.

He has to make sure he gets to the model rocket store on time every week so he has the parts he needs to complete his rockets, so he can head off to the airstrip and boost a few with his friends. (These are big, professional-level rockets that are often upwards of 8 feet tall and use small explosives as engines. The Federal Aviation Administration regulates the launching of such rockets because they can fly high enough to actually hit planes that have recently taken off; hence the need to use an actual airstrip.)

If I told my dad he could buy these parts online, he'd be interested. If I asked him how the application should filter the online catalog and allow him to make purchases, he'd look at me like I was nuts.

Molly from Sales would likely do the same thing.

Molly has no idea what your software might be able to do, and she almost certainly doesn't have the technical chops to explain it. She likely doesn't realize that your product could make the task of creating a client birthday list (for mailing out discount coupons) a matter of two clicks, and therefore, she would never mention that this task is particularly gruesome and ask if your software could do it for her. Thus, you need to look a little deeper to find out what Molly needs.

If you want to know what Molly wants the software to do, don't ask her directly. Instead, find out what she does, how she does it, and what she will want to do later. Eventually, you'll figure out how all that translates into a Web application. For now, don't think about Web applications. Think about users.

Assume nothing

There are several ways to uncover what's most important to the people who use (or will use) your applications. The first way is simply to assume you know what your users want, how they work with computers, and how your application will fare under their nimble, Web-savvy fingertips. I don't recommend this approach.

If you want to know how users work, don't assume anything. Almost on a daily basis, my wife encounters a customer in her library who has entered his email address into the Address bar in Internet Explorer and is wondering why he can't check his email. A few days ago, she told me about someone who added .com to the end of his username for his Web-mail program and wanted to know why he couldn't access his home computer. If only it were so simple!

These people are not dumb, by any means. Some of these people are business owners, managers, organizers, and stellar employees. They're experts at something. But they are new to using computers and don't yet understand how to interact with them.

You probably don't know these people. You are surrounded by people who know the Web extremely well because they spend most of their time building it. And you are probably surprised to hear that the less computer-savvy among us can have such a difficult time performing basic operations. But these people are real, and they might one day use your application. Don't assume you know anything about them without finding out firsthand. The second you do, someone will come along and ask why he can't scan his printed document by holding it up to the monitor. (Yes, this has happened.)

Use surveys

An effective way to find people who fall into your target user category is to survey people doing the job your application is meant to support. If you're developing a sales support tool, for example, look to your own company's sales department. Put together a quick screening survey and send it out to the whole department to determine who might have the most useful information. If your product is aimed more at senior salespeople, the survey should weed out the trainees and leave you with a shortlist of qualified sales veterans.

SurveyMonkey.com makes quick work of creating nice, easy-to-use survey forms, and it offers a set of tools to analyze the results. I highly recommend it, but you can use whatever survey tool makes you happy and gives you the information you need.

Surveys are effective for acquiring high-level information; for example, they can help you determine satisfaction levels in regard to an existing application, or poll people about how they do their jobs. It's difficult to pinpoint what areas cause the most trouble for users or which ones take the most time, but surveys can help you gather information about how people rate the overall usability of an application, what they like best about it, what they like least, what part of their job takes the most time, and so on. You shouldn't expect to learn the subtle details of how a person interacts with the shopping cart on a site, but you can gather focus-groupstyle information pretty easily.

Rely on SurveyMonkey.com as a tool to more fully understand your target user.

Contextual inquiry

Contextual inquiry is an abbreviated version of ethnographic research, in which the researcher lives and works with people in a particular culture with the intent of learning about them from an inside perspective.

Most of us don't have the time, will power, or energy to go live and work with a bunch of accountants so we can better understand how to build an effective Web-based invoicing system. But we can perform ethnographic research on a smaller scale, in the form of short, "shadow"-style interview sessions known as contextual inquiry. The idea behind contextual inquiry is to observe target users on their own turf so you can see how they really do things. I find this method especially useful when the people I'm observing are already using an existing version of the application I'm working to improve.

For example, I once worked on an application that was meant to support the development of nonlinear e-learning courseware. The application was supposed to show learners a version of a course that was customized according to their input during different sections of the course. (That is, if a user answered a question about a particular topic incorrectly, the next set of screens might focus more heavily on that topic, whereas users who chose the correct answer would not see this set of screens, instead moving directly to the next section.)

The initial users for this application were internal employees, as the company had a group of instructional designers on hand to create audio scripts and guidelines for the company's courseware. Thus there were daily opportunities for contextual inquiry, and endless amounts of quality information could be extracted from simple conversations with those users. This application had no road map at allno design work had been done to plot it outso contextual inquiry became a primary method for determining how to evolve the tool. Most of us working on the application had no experience as instructional designers, and the best way to understand how to create the application was to get to know the people who did instructional design for a living.

To find out how well people handled the simple task of accessing a course that had already been created with the tool so it could be edited, I could simply walk over to an instructor's desk and ask a question about how she had set up a particular course. She would open up the application, navigate to the course I was asking about, and give me a guided tour. From watching the user perform that sequence of operations, I could clearly see where the tool was giving her trouble and make mental notes about what was difficult about it.

There's nothing complicated about contextual inquiry. It's just a matter of hanging out with a few users for a while to see how they work, how they think, what issues arise while they're working, how they make decisions, and, ultimately, how they interact with your application so you can see how effective or ineffective it really is.

At the interaction level, if a user is interrupted by a phone call in the middle of a complicated task, is it easy for him to jump right back into the task when the call has ended? Can he move quickly to another part of the tool (perhaps to check a setting) and come back without missing a beat? If this happens, why does it happen? How can the application address this need?

At the application level, is the tool meeting the user's expectations? Does it behave the way she thinks it will, or does she often end up muttering at her screen while trying to understand what just happened? Is the tool well organized, making things easy for her to find? What types of things is she doing repeatedly, and are those things easy to get to on a frequent basis?

Contextual inquiry can actually be very similar to usability testing. The key difference is that the users being observed are working in their own environments, at their own desks, dealing with all the things they deal with during a normal workday, including manipulating several applications at once.

If a version of your application is not in use yet, contextual inquiry can be effective for determining what things a tool still in the conceptual phase needs to do so, you can Know What To Build.

Shadowing

If you're a programmer, the last thing you want to do is talk to those peppy salespeople down the hall who ring a big gong every time they make a sale. But if your product is aimed at salespeople, try to find a few who don't completely clash with you and latch onto them. These folks are your users, and they have the most information about how their jobs are done and what they need to know to do it well. If you're building a product for a client company and can't simply wander down the hall to perform such inquiries, make arrangements to spend a few days at the company so you can talk to users there and learn what you can on-site.

Set up a time to shadow several users individually, and go have some fun bonding with your new best friends. Shadowing is the act of quietly hovering over the shoulder of someone who knows what they're doing, with the goal of learning to do that person's job so that you may one day also become a Jedi Master. Contextual inquiry is really just a fancy name for shadowing.

Shadowing doesn't have to be overly formal. In fact, the more rapport you have with the users you observe, the more likely they are to open up and tell you about the things they struggle with all the timethings your application can help resolve.

Naturally, there are a few tricks to shadowing. You can't just waltz in and expect someone to tell you exactly what the application needs to do.

• First, make it abundantly clear that you are not trying to build a tool that replaces them; you're trying to build a tool that makes their jobs easier. You certainly don't want your users thinking you're stealthily finding ways to make them homeless for the holidays.

• Next, follow them around and see what it is they do and how they do it. Take notes using a notepad and a pen. Although it's ridiculously low tech, it's still the best way to write quick notes when you're running around.

• Ask questions, but not so many that you become a major distraction. Just ask simple questions to clarify anything that isn't perfectly clear.

• As you're doing all this, quietly think of all the ways a good application could eliminate Redundant Task A, Annoying Task B, and I Hate This Part of My Job Task C.

• Keep things casual and light. Spend a day with one or two people, or half a day with each of several people. If time is tight, spend two hours with five or six people over a two-day period and stop there.

• Try doing the job your application is supposed to support. This is a fantastic way to uncover reality. No one can explain the finer points better than you can after actually dealing with them directly for a while. Putting yourself on the firing line gives you incredible insights in a very short time. This idea can also be applied later by "eating your own dog food" (that is, using your own products), which I'll discuss in Chapter 4.

Remote-user research

If you don't have direct access to your usersperhaps because you are building commercial software meant to be used by millions of people, none of whom work within 100 yards of your desk, and you can't visit your client's siteyou can perform remote research and gain some of the same insights using Web-based tools like WebEx and GoToMeeting, or by making a few simple phone calls to some of your customers.

You won't get the same in-depth knowledge you would from contextual inquiry, and the environment will be less natural than if you were stalking a coworker in person for a day. But you can still get information that helps you build an organizational structure and feature set that make sense for your application by interviewing people over the phone about what they do, or by having them perform tasks in the current version of your application or a related product and taking notes about how they work, what trips them up, and what you can do to help them. (But don't make any promises. Promises backfire big-time when whatever it is you promised doesn't make it into the next release.)

To persona or not to persona?

Alan Cooper, author of The Inmates Are Running the Asylum, posits that a great way to keep the goals of your users in mind is by creating a persona for each one. A persona, at its core, is a user profile focused on goals and activities rather than demographics, where each fictitious user has a name, photo, and some personal details that bring him or her to life. The basic idea is that attaching a name and face to the very flexible notion of a user helps lock down who the user really is, making him less open to interpretation when it comes time to decide whether or not the real users out there will be able to decipher how the Data-Juicer application works.

Personas are also meant to help programmers realize that the person on the other side of the screen is not made of rubber, and cannot be bent at random to fit arbitrary ideas of what a user can handle and will find useful. Programmers and managers alike are forced to acknowledge that Molly from Sales may not really understand how the word publish translates to pushing her unfinished content to the intranet where the whole company can see it.

A persona doesn't have to be anything complicated. The description can be as short as a single paragraph or as long as, um, two or three paragraphs. The important part is that it describes a fictitious user who represents the real people who will be using your product, how savvy they are, how and why they'll be using the product, and so on, topped off with a couple of fictitious personal details, a name, and a photo. (The photos don't need to be high quality. The inexpensive, low-resolution versions from any stock photography site will do just fine. You can get them for just a couple of bucks on sites like iStockphoto.com, or Getty Images, at www.getty-images.com.)

Even if your product will be used by a wide range of people, it's not necessary to create a persona for every single user type. When it comes to the particular activity your product is meant to support, the problems of one group will often be extremely similar to the problems of the others. In fact, using too many personas is counterproductive because you end up trying to please everyone, which is not usually possible.

The goal is to narrow your list of user types down to three or fourpreferably fewerand create a persona for each of them. One in particular should serve as your primary personathe one that absolutely must be satisfied for your product to be a success.

Throughout the rest of your design and development process, Cooper recommends keeping the personas in front of everyone involved, all the time. Everyone on the development team should know the userslet's call them Greg, Anna, and Marywell enough to know exactly how they're likely to respond when faced with a complicated interaction.

For example, if you're designing a stock photography Web site, one of your personas might be described like this:

Greg is a 26-year-old print designer from San Jose, California. He has extensive experience with tools like Adobe Photoshop and Illustrator. He has very little experience designing for the Web, but has been picking up more and more Web projects in recent weeks and would like to expand his skills. His design work, which often includes ads for trade magazines and brochures, has won several awards, and he is comfortable using stock photography sites, particularly Getty Images, where he frequently purchases high-resolution photographs. His No. 1 pet peeve with such stock photography sites is the time it takes to wade through thousands of images to fi nd exactly what he needs.

This persona is Greg the Print Designer.

This simple description of the fictitious user Greg reveals several key points. First, Greg is comfortable with computers and the Internet and wants to focus more on Web design. Second, as a contractor, his time is probably limited, making it even more frustrating to wade through thousands of images to find what he needs. Third, he needs high-quality images so he can continue winning awards.

Pleasing Greg is critical to the success of your stock photography site. Despite being relatively new to Web design, he will be taking on Web projects more and more, and he would love to have a one-stop shop online for all the images he needs. Greg could be a loyal, frequent customer if you design something that works well for him.

To address Greg's time constrains, you can do several things in the interface. First, you can point out which images, or which versions of an image are suitable for the Web by including the file size within the image information and perhaps a small icon that makes Web-ready images easy to spot. You could also provide links to relevant supporting material on the site to educate Gregfor example, articles about the differences between images on the Web and those intended for print work.

Next, you can create a way for Greg to save the searches he performs, and a way to store groups of images in a personal library so he can quickly access personalized categories of images and find the ones he likes more easily. This will save Greg huge amounts of time in the long run. When he first begins to use the site, he'll have to wade through images as he does on other stock sites, but each time he does so, he can add the images he likes to his library, even if he doesn't use them right away. The more he uses the site, the larger his library will grow, and the more he'll be able to find images he likes quickly.

These few features will help Greg a lot, and the simple act of writing out a description of who he is has helped you take a big leap toward designing an effective application.

But one part of the feature set is still a concern: the first several times Greg uses the site, he still has to wade through tons of images, just as he would on any other site, and it may be difficult for him to see the benefit of having a personal library during the first three or four visits. We know Greg is already using other stock photography sites, and he may be hesitant to start digging through a new one, so you need to give him a good reason to switchand make the shift immediately beneficial. This issue might have never surfaced if you hadn't gotten to know Greg.

Now that you know him, you can address this issue by offering him ten free images in the first month, and guide him toward adding images to his library during each of his first few visits. (I'll talk about how to get people up to speed with an application in Chapter 5.) While browsing for his ten free images, he'll start adding images to his library, and by the time he's used all his free photos, he'll have built up a small arsenal that he can use in the future. Now you've given Greg a reason to visit, a way to personalize what he sees on repeat visits, and a reason to keep him coming back.

Greg's happy. You're happy.

As you can see, having a persona like Greg by your side during the design process can be really helpful when you're starting to narrow down the feature list for an application. You know Greg, you know what his goals are as a designer, and as a result, you Know What To Build. You can refer back to the persona again and again to keep yourself in check when considering new features.

Greg is not real, of course, but you can leverage what you now know about your users as a result of personifying them through Greg, so you have a better idea of what to leave in, what to leave out, when to walk away, and when to run.

The theoretical benefits

Personas are a vital part of what is known as Goal-Directed Design, a process developed by Alan Cooper to help designers better understand the goals of users so interactive systems can be designed to help them meet those goals.

The essence of Goal-Directed Design is to try to break down the wall that exists between our users and us. As a metaphor, consider a conversation between a developer and a user. The developer explains how and why something happens, and the user nods his head and says, "I don't care how it happened, or whyI just want to know it's fixed so I can move on with my life."

Developers tend to want to put up dialog boxes and error messages and all sorts of intrusive widgets that explain what's going on behind the scenes, but users don't care. They only want to know the thing is working so they can accomplish their goals.

A user's goals live outside the application. The goals are personal. Very few users have a goal of understanding how PeopleSoft works. That goal is usually encapsulated by a larger goal. Perhaps Molly wants to earn a promotion at work and thinks that understanding PeopleSoft better will enable her to be more productive. The application itself is not a goal at allit's an obstacle between Molly and her goal.

Acknowledging that the user's goals have nothing to do with your Web application allows you to design something that pays more attention to the user's real goals. Thus, Goal-Directed Design involves performing thorough user research, creating personas through which to gauge how well a design holds up, and designing something that works for the target users, in the context in which they use the application. Goal-Directed Design means listening to users, getting to the truth of what they want, and creating applications from a more informed perspective.

The reality

Goal-Directed Design can be very effective, and it's a process used by many successful designers. That said, it seems to work best when the application being designed is intended for a niche audience: It's much easier to establish a core set of users when the user base is fairly narrow at the start. Trying to execute Goal-Directed Design when your application is to be used by millions of people across a wide array of user types may not produce the results you need.

Furthermore, personas are meant to be used in conjunction with scenarios, which are essentially short stories about how a persona might interact with the system designed for her. And it's at this point that the practicality of using personas starts to become a little . . . fuzzy.

I, for one, am no character actor. I can't easily pretend to be someone elsenot in any realistic way. And I can't safely predict how I, as this other person, would handle the interactions laid out before me as a shiny, new Web application, or whether or not the application would even be interesting to me.

When you start imagining how a fictitious character would respond to a hypothetical situation using an imaginary interface, it's probably time to put down your little plastic army men and crack open the sketchbook.

We can do the research, get to know our users on a personal level, and dream up something we think will work very well for our intended users, but time spent on fiction will eventually begin to interfere with reality. When the fuzzy starts to get too fuzzy, it's time to start moving toward something tangible.