“How do we go about learning who our users are and what they really need? And how do we do this in a way that helps us make a strong case for our design decisions to the people in charge?”
Design is disorienting. Especially when you are designing something in a collaborative environment, with multiple stakeholders, pressured deadlines, business objectives and budgetary constraints. We all go into design with the firm belief that the user is our pole star, but so often we lose that focus because of tossing waves, buffeting winds, and the crew screaming in our ears–never mind the dense cloud cover that always seems to obscure that trusty star just when a committee forms to gather requirements.
With all the attention to usability over the last five years or so and the wonderful swelling of information-architecture-related books just since 2001, you would think we would have enough methods and advice to keep our projects in perfect tack. But so many of these resources, excellent though they are, tend to be more about how to pilot the ship than how to find that all-important star and keep it in sight.
I promise not to drive this metaphor hard into the rocky shore, but think of the projects that could have been saved from being lost at sea if every team had a better grasp of user requirements through direct experience of users and their needs. Think also of how many projects could have stayed the course if only there had been an expert way to sell the findings from that experience to the stakeholders, who so easily forget the users for whom their project was intended.
For precisely these reasons Mike Kuniavsky’s Observing the User Experience: A Practitioner’s Guide to User Research is a welcome addition to the half dozen essential books on my cubicle shelf. This book provides lucid, personable, experienced advice that could only come from a seasoned consultant who has seen the good, bad, and ugly of web and application design. Its purpose is to give a solid foundation to any design team in the crucial beginning stages of a project by answering the questions: How do we go about learning who our users are and what they really need? And how do we do this in a way that helps us make a strong case for our design decisions to the people in charge?
Kuniavsky begins Observing with a cautionary tale about a failed corporate web project, a situation he experienced firsthand (changing identifying information to protect the innocent, of course). This situation involved misguided good intentions from corporate management and developers, where something they thought would be just what their users wanted turned out to be a huge waste of time and money. This is just one of many real-life lessons used as background throughout the book.
Kuniavsky introduces us to web user research methodologies by showing us how they fit into an overall process and by defining various roles within a design team. These descriptions are clear and sensible, and they are more descriptive than prescriptive: he is not trying to tell us these are the roles you have to use and this is what you have to call them in guru-speak, but describing with conventional labels what tends to happen in a successful project.
The chapters are well-organized and consistent, and content is cross-referenced from chapter to chapter where appropriate. Unlike many design-related books, this one is actually fairly heavy on text and light on visuals. Where visuals are used, they are very helpful and serve to explicate the content. A good example is his spiral model of Iterative User Research,which cycles from Examination to Definition to Creation and, as it deepens, gets more granular through Contextual Inquiry, Focus Groups, Usability Tests, and so on. Kuniavsky wisely points out that many companies already have marketing research results that may be expected to yield the results necessary for web design, but explains how the tools used by conventional marketing approaches are only part of the solution for user-centered design. Focus groups and surveys can supply valuable information, but focusing on direct experience of user behavior using a combination of appropriate methods offers a stronger core for design.
Kuniavsky goes on to provide an excellent mixture of step-by-step direction and experienced advice on the practicalities of user research. Beginning with how to put together a research plan (invaluable instruction, since planning seems to be the Achilles heel of so many projects), he explains how to make sure business goals are being considered along with user goals. He admits these instructions present a somewhat idealized situation that starts as a blank slate as far as user experience product goals are concerned. However, Kuniavsky manages to keep his advice from being so lofty that no real-world team could actually follow it.
The chapter on recruiting and interviewing is especially thorough. It provides a sample phone screening script and boilerplate recruiting communication, as well as advice on how to handle no-shows, heavily biased users, and people who do not end up fitting your model. In fact, it may be the coverage of so many aberrations and anomalies that make this book so unusually valuable. This is advice one would normally only gain on the job or working side by side with a highly experienced researcher.
Kuniavsky devotes the bulk of the book to describing a series of proven techniques for researching user needs and behaviors, including user profiles, contextual inquiry (plus task analysis and card sorting), focus groups, usability tests, and surveys, as well as more secondary-research approaches such as diaries, log files, customer support, and competitive research. He presents each method in a separate chapter, describing when each one is most appropriate and various methods of execution. Throughout, Kuniavsky glosses his text with marginal notes, giving a reality check or bit of wisdom in each one, such as the reminder that Focus groups uncover people’s /perceptions/ about their needs and their values. This does not mean that they uncover what people /actually/ need or what really /is/ valuable to them-however-knowing perceptions of needs is as important as knowing the needs themselves.
In his descriptions of various methods, there is surprisingly little dogma. In an industry that has spawned a thousand do’s and don’ts lists for design, it is refreshing to find so many techniques described with equal value and rationale. I personally have long held a bias against focus groups, surveys, and marketing research as being especially valuable for fully understanding users, but this book has helped me see these resources in a more positive light.
It is also a relief to read this book’s conversational and low-jargon voice. There are a number of books I find essential in my work that I still have trouble actually comprehending during a busy workday. Somehow this one cuts through the fog of design-speak to present some very sophisticated concepts and methods in a way so that a relative novice could read it and hit the ground running. Take, for example, his lucid description of the role of information architect: It’s the information architect’s job to make the implicit architecture explicit so that it matches what the users need, expect, and understand. The architect makes it possible for the users to navigate through the information and comprehend what they see. I have never seen my job explained with such clarity anywhere else.
Another strength is Kuniavsky’s business-savvy approach to design. In the very first chapters he does an excellent job explaining the various tensions between different groups with their own agendas encountered in any collaborative design effort. He shows how having solid and documented user research can help to defuse these tensions and keep the user as the central focus of the work. In fact, Kuniavsky even has a chapter on Creating a User-Centered Corporate Culture, an ambitious but necessary topic for any corporation finding its business model being warped into a whole new shape by the powerful gravitational pull of the web.
So much of design involves a kind of tea-leaf reading voodoo that is hard to justify or describe to managers and stakeholders. When we do the typical routine–look at some users, have some conversations, and then come back with all these ideas on how to design an expensive project–aren’t the people paying for it fully justified in asking Why do you think you really know how we should build this thing? And how can one blame them for thinking their own ideas are just as valid as ours? Observing the User Experience provides solid techniques for knowing our users from a 360-degree perspective in a way that we can document, communicate, and even sell to other team members and project owners. Think of it as a combination navigational chart, captain’s log, and sextant for web endeavors–a one-stop shop for tools that help your team stay the user-centered course.
About the book: