- Why You Should Research Users
- How to Research and Understand Users
- What to Do with the Data
- Creating Personas and Designing for Them
- Moving On
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
How to Research and Understand Users
Now that you know why it’s important to talk to your users, and that it’s pointless to ask them broad questions (like "What should the software do?"), you might wonder how to get to the core of Molly’s innermost desires. The way to do this should seem obvious. You’ve likely had at least one argument in your life about the fact that you weren’t listening to your spouse, parents, best friend, whomever—but I’ll spell it out for you just for clarity’s sake.
- Accept that Molly has no idea what your software might be able to do. She certainly doesn’t have the technical chops to explain it. She likely doesn’t even realize that your product could simplify the task of creating a client birthday list (for mailing out 10% off coupons); therefore, she’ll never mention that this task is particularly gruesome and it would be great if your software could do that for her.
- Look a little deeper. Don’t ask Molly what the software needs to do. Instead, find out what she does and how she does it now. Molly only knows her way of doing things, so find out what she knows. In other words, listen to her.
Surveys
A great way to find people who fall into your target audience is to look around your own organization. In the case of the aforementioned sales support tool, look to your own company’s sales department. Use SurveyMonkey or something similar to put together a quick screening survey you can send 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 short list of qualified sales geniuses. SurveyMonkey makes quick work of creating nice, easy-to-use survey forms, and offers a set of tools used to analyze the results, so I highly recommend it, but you can use whatever survey tools make you happy and give you the information you need.
Contextual Inquiry
Once you’ve found some people who fall into your target audience, get close to them. I know, the last thing you want to do as a programmer 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 some people who don’t completely clash with your nerd-like tendencies, and latch onto them. Get permission from whoever is in charge over there on the Gong Show and go bug the people who on your short list. Of course, by bug, I mean speak with, very nicely, which roughly translates to beg. These people are your users, so play nice. (If you’re building a product for a client company, by the way, you should go there for a few days and learn what you can onsite.)
Set up a time when you can "shadow" each one of your users, and go have some fun bonding with your new best friends. Shadowing, for those of you who never worked in retail or waited tables, is the act of quietly hovering over the shoulder of someone who knows what she’s doing, with the goal of learning to do that person’s job so that one day you may also be a Jedi Master. Naturally, there are a few tricks to doing this well:
- Make it abundantly clear that you’re not trying to build a tool that replaces the user. You’re trying to build a tool that makes the user’s job easier. You certainly don’t want users thinking that you’re one of the two Bobs from the movie Office Space, stealthily finding ways to make them homeless for the holidays.
- Follow the user around and see what she does and how she does it. Take notes. (Hint: You’ll need a notepad and a pen. Though it’s ridiculously low-tech, it’s still the best way to write quick notes when you’re running around.)
- Ask questions. Not so many that you become a major distraction, like meetings, causing undue stress and anxiety. Just ask simple questions to clarify anything that isn’t perfectly clear. And take more notes.
- Think about ways in which software could eliminate Redundant Task A, Annoying Task B, and I Hate This Part of My Job Task C. When you have a good sense of what problems the user faces and how your tool might solve some of those problems, strut on back to your desk and get all those notes in order. You’ll need them later.
Card-Sorting Exercises
If you’re designing an information space, perhaps a company intranet, a great way to determine how users will expect the information to be organized is through card-sorting exercises. The gist is that you write down on index cards all the topics that need to be organized, hand the cards to a group of people who fall into the target audience, and have them sort the cards into piles of related topics and then name the piles. Sounds pretty simple, right? It is, but there are hidden tricks when performing such exercises, and other things to consider about how to run a card-sorting session, so be sure to get the scoop in more detail before you attempt this approach at home. To get started, here’s a nice tutorial on the subject from Step Two.
Remote User Research
If you don’t have direct access to users, perhaps because you’re building commercial software meant to be used by millions of different people (none of whom work within 100 yards of your desk), you need to get more inventive. Online tools such as WebEx and GoToMeeting can be used to perform remote user research. You won’t be able to get the firsthand knowledge you can get from contextual inquiry, and the environment will be a little unnatural compared to stalking a coworker in person for a day, but you can still do card-sorting and other exercises that help reveal an information architecture that makes sense for your site or product.
WebEx and GoToMeeting are quite affordable, but for them to work with these exercises you’ll need to create some way for users in the web-based meeting to perform the exercises. For example, use PowerPoint to create a box for each topic that would normally be an index card, and have a designated moderator for the group take charge of doing the physical card sorting (via the magic of application sharing, available in each of these tools), based on the input of everyone in the meeting.
You can also do something a bit more complicated: Whip up a card-sorting engine with Flash, complete with drag-and-drop cards and dynamic card creation based on loaded data. If you don’t have Flash chops, hit up the geek down the hall who makes all those cool software simulations your marketing department uses, and see whether he or she can put together a Flash program for you. No geeks down the hall? Try the online forum for your local Flash users group and find a contractor. It’ll cost more but take less work in the long run, because you can simply make a list of your topics in an XML or text file and the Flash template will handle the rest. Of course, your new Flash toy will also need a way to dish out a report on the results, so you don’t lose them the second the e-meeting is over.
Another good option, but a bit on the expensive side, is MindCanvas. Among other features, this web-based tool performs card-sorting and divide-the-dollar exercises—in which users assign a certain portion of a total (fictitious) dollar value to different features, thereby ranking them by importance—and is well equipped to give you reports on everything you do. There is no pricing information on the MindCanvas site (a sure sign it ain’t cheap), so you’ll have to talk to MindCanvas folks directly and work out those details.