1.2. THE BASICS OF USER RESEARCHEmpirical discovery is the only really good way to obtain this information. To get a design started, you'll need to characterize the kinds of people who will use whatever you design (including the "softer" categories just mentioned), and the best way to do that is to go out and meet them. Each user group is unique, of course. The target audience for, say, a new cell phone will differ dramatically from that for a piece of scientific software. Even if the same person uses both, his expectations for each are differenta researcher using scientific software might tolerate a less-polished interface in exchange for high functionality, whereas that same person may trade in his new phone if he finds its UI to be too hard to use after a few days. Every user is unique, too. What one person finds difficult, the next one won't. The trick is to figure out what's generally true about your users, which means learning about enough individual users to separate the quirks from the common behavior patterns. Specifically, you'll want to learn:
I can't tell you what your particular target audience is like. You need to find out what they might do with the software you design, and how it fits into the broader context of their lives. Difficult though it may be, try to describe your potential audience in terms of how and why they might use your software. You might get several distinct answers, representing distinct user groups; that's okay. You might be tempted to throw up your hands and say, "I don't know who the users are," or, "Everyone is a potential user." That doesn't help you focus your design at allwithout a concrete and honest description of those people, your design will proceed with no grounding in reality. Unfortunately, this user-discovery phase will consume serious time early in the design cycle. It's expensive, but always worth it, because you stand a better chance at solving the right problemyou'll build the right thing in the first place. Fortunately, lots of books, courses, and methodologies now exist to help you. Although this book does not address user research, here are some methods and topics to consider.
And there's more. You might notice that some of these methods and topics, like interviews and surveys, sound suspiciously like marketing activities. That's exactly what they are. Focus groups can be useful too (though not so much as the others), and the concept of market segmentation resembles the definition of target audiences we've used here. In both cases, the whole point is to understand the audience as best you can. The difference is that as a designer, you're trying to understand the people who use the software. A marketing professional tries to understand those who buy it. It's not easy to understand the real issues that underlie users' interaction with a system. Users don't always have the language or introspective skill to explain what they really need to accomplish their goals, and it takes a lot of work on your part to ferret out useful design concepts from what they can tell youself-reported observations usually are biased in subtle ways. Some of these techniques are very formal, and some aren't. Formal and quantitative methods are valuable because they're good science. When applied correctly, they help you see the world as it actually is, not how you think it is. If you do user research haphazardly, without accounting for biases like the self-selection of users, you may end up with data that doesn't reflect your actual target audienceand that can only hurt your design in the long run. But if you don't have time for formal methods, it's better to just meet a few users informally than to not do any discovery at all. Talking with users is good for the soul. If you're able to empathize with users and imagine those individuals actually using your design, you'll produce something much better. |