Observing the User Experience (eBook)

A Practitioner's Guide to User Research

Mike Kuniavsky (Autor)

eBook Download: EPUB

2003 | 1. Auflage
576 Seiten
Elsevier Science (Verlag)
978-0-08-049756-3 (ISBN)

Infos

The gap between who designers and developers imagine their users are, and who those users really are can be the biggest problem with product development. Observing the User Experience will help you bridge that gap to understand what your users want and need from your product, and whether they'll be able to use what you've created.

Filled with real-world experience and a wealth of practical information, this book presents a complete toolbox of techniques to help designers and developers see through the eyes of their users. It provides in-depth coverage of 13 user experience research techniques that will provide a basis for developing better products, whether they're Web, software or mobile based. In addition, it's written with an understanding of how software is developed in the real world, taking tight budgets, short schedules, and existing processes into account.

?Explains how to create usable products that are still original, creative, and unique

?A valuable resource for designers, developers, project managers-anyone in a position where their work comes in direct contact with the end user.

?Provides a real-world perspective on research and provides advice about how user research can be done cheaply, quickly and how results can be presented persuasively

?Gives readers the tools and confidence to perform user research on their own designs and tune their software user experience to the unique needs of their product and its users

Inhalt

Front Cover 1
Observing the User Experience 6
Copyright Page 7
Contents 10
Preface 14
PART I: Why Research is Good and How It Fits Into Product Development 18
CHAPTER 1. Typhoon: A Fable 20
The Short History of Typhoon 21
CHAPTER 2. Do A Usability Test Now! 26
A Micro-Usability Test 26
What Did You Learn? 31
What to Do Next 32
CHAPTER 3. Balancing Needs Through Iterative Development 34
Success for End Users Is 35
Success for Advertisers Is 37
Success for the Company Is 40
A System of Balance: Iterative Development 45
Iterative Development and User Research 52
Example: A Scheduling Service 53
CHAPTER 4. The User Experience 60
Information Architecture 61
Interaction Design 65
Identity Design 67
The User Experience Research 69
PART II: User Experience Research Techniques 72
CHAPTER 5. The Research Plan 74
Goals 74
Schedules 82
Budget 92
Research Plan for Company X 94
Maintenance 99
CHAPTER 6. Universal Tools: Recruiting and Interviewing 100
Recruiting 100
Interviewing 134
CHAPTER 7. User Profiles 146
When to Do It 148
How to Do It 149
Using Profiles 167
Example 172
CHAPTER 8. Contextual Inquiry,Task Analysis, Card Sorting 176
Contextual Inquiry 177
Task Analysis 199
Card Sorting 209
CHAPTER 9. Focus Groups 218
When Focus Groups Are Appropriate 219
How to Conduct Focus Groups 224
Focal Group Analysis 257
Example 265
CHAPTER 10. Usability Tests 276
When to Test 277
How to Do It 281
How to Analyze It 310
Example 314
CHAPTER 11. Surveys 320
When to Conduct Surveys 321
How to Field a Survey 322
How to Analyze Survey Responses 357
Follow-Up and Ongoing Research 374
CHAPTER 12. Ongoing Relationship 384
Background 385
Diaries 386
Advisory Boards 402
Beta Testing 408
Telescoping 410
Taking the Longer View 410
CHAPTER 13. Log Files and Customer Support 412
The Customer Support Process 413
Collecting Comments 414
Reading Comments 415
Organize and Analyze Them 416
Log Files 419
What’s in a Log File, and What’s Not 420
Logs and Cookies 423
Some Useful Metrics 426
Extracting Knowledge from Data 431
CHAPTER 14. Competitive Research 436
When Competitive Research is Effective 437
Competitive Research Methods 438
Analyzing Competitive Research 448
Acting on Competitive Research 450
Example: A Quick Evaluation of ZDNet 451
CHAPTER 15. Others’ Hard Work: Published Information and Consultants 456
Published Information 457
Hiring Specialists 464
CHAPTER 16. Emerging Techniques 476
Variations on Techniques 476
Combining 486
PART III: Communicating Results 494
CHAPTER 17. Reports and Presentations 496
Preparation 497
The Report 500
The Presentation 511
CHAPTER 18. Creating a User-Centered Corporate Culture 522
Integration 523
Justification 533
What If It’s Too Difficult? 542
The Only Direction 544
Appendix A: The Budget Research Lab 546
Appendix B: Common Survey Questions 549
Appendix C: Observer Instructions 555
Bibliography 559
Index 562
About the Author 577

Textauszug

CHAPTER 1 Typhoon: A Fable

Sometimes it takes a long time for something to be obvious: a shortcut in the neighborhood that you’ve known all of your life, a connection between two friends, the fact that your parents aren’t so bad. It can take a while for the unthinkable to seem clearly natural in retrospect.

So it is with Web sites and user research. For a long time in the short history of Web development, the concept of putting an unfinished product in front of customers was considered an unthinkable luxury or pointless redundancy. The concerns in Web design circles were about branding (“make sure the logo has a blue arc!”) or positioning (“we’re the amazon.com of bathroom cleaning products!”) or being first to market. Investigating and analyzing what users needed was not part of the budget. If a Web site or a product was vaguely usable, then that meant it was useful (and that it would be popular and profitable and whatever other positive outcomes the developers wanted from it). Asking users was irrelevant and likely to damage the brilliance of the design.

Recent history has clearly proved that model wrong. It’s not enough to be first to market with a blue circle arc and an online shopping cart. Now it’s necessary to have a product that’s actually desired by people, that fulfills their needs, and that they can actually use. That means user research. User research is the process of understanding the impact of design on an audience. Surveys, focus groups, and other forms of user research conducted before the design phase can make the difference between a Web site (or any designed product) that is useful, usable, and successful, and one that’s an unprofitable exercise in frustration for everyone involved.

Nowadays, it seems obvious that a product should be desired by its audience. But that wasn’t always the case. Let’s step back to the Web world of the mid-1990s, when perfectly smart and reasonable people (including me) couldn’t imagine designing a product that users wouldn’t like. Here’s what happens when you don’t think about the user.

The Short History of Typhoon

In the heady days of 1996, PointCast was king. A service that ingeniously transformed the mundane screen saver into a unique advertising-driven news and stock service, it was the wunderkind on the block. It attracted tens of thousands of users and landed its creators on the covers of all the industry magazines. Information coming to people, rather than people having to ask for it, was a brand-new concept and quickly acquired a buzzword summarizing it. It was push technology, and it was the future. Soon, everybody was on the push bandwagon, building a push service.

Let me tell you a fable about one company that was on the bandwagon. It’s based on a true story, but the details have been changed in the interest of storytelling (and to protect the innocent, of course). Let’s call the company Bengali. Bengali had several high-profile successes with online news and information services, and now was confident, ready, and eager to take on a new challenge. They wanted to create something entirely revolutionary—to challenge everyone’s assumptions about media and create the next television, radio, or printing press. They decided that their dreams of creating a new medium through the Internet had its greatest chance for success in push.

It was going to be called Typhoon, and it would put PointCast to shame. Bengali went into skunkworks mode, developing Typhoon completely in-house, using the most talented individuals and releasing it only when it was completely ready.

PointCast Killer development takes a lot of work. The developers worked on the project in secret for a year, speaking about it to no one outside the company (and few inside). Starting with “How will the society of the future interact with its media?” the development team created a vision of the medium of the future. They questioned all of their assumptions about media. Each answer led to more questions, and each question required envisioning another facet of the future.

The software and the vision grew and mutated together. The final product was intricate, complex, and patched together in places, but after a year Bengali was ready to release it.

When it was ready to launch, it was shown to top company management. Although undeniably impressed with the magnitude of the achievement, the executives felt some apprehension. Some wondered who the audience was going to be. Others asked the team how people would use it. Although the team had answers for everything (over the year, they had developed a very thorough model of the program and how it was to be used), they admitted that they had to qualify most of their answers because the software had not been put in front of many end users. They were experienced developers, and they had done some in-house evaluation, so they figured that—if not right on—their design was pretty close to what their users would want. But, to placate the executives and check where the rough spots were, the developers decided to do some user research before launching it.

A dozen people were picked and invited for one-on-one user tests. They came in, one at a time, over the course of several days. The plan was to have them sit down, give some initial thoughts about the product, and then let them try a couple of different tasks with it.

The tests were a disaster. This is a portion of a verbatim transcript from one session.

USABILITY TEST SESSION TRANSCRIPT

If this is just graphics that are supposed to look that way it’s kind of confusing because you think that maybe it’s supposed to do something … I don’t know.

All of these words down here are barely legible.

If this is supposed to say something that I’m supposed to understand, I guess it’s very hard to figure what that stuff is.

None of these headlines are making any sense to me.

I don’t know what to make of these.

I know if I click on them they’ll do something but …

It’s not inspiring me to click on any of them so far.

Also, there’s no status bar so you’re not really sure when a page is finished being loaded.

I don’t know if these numbers have anything to do with that or not … I don’t know.

I hope that that’s a story that I’m going to follow the link to.

This must be [downloading over] a 28.8 [modem] I’m assuming.

It seems a little slow.

This doesn’t seem like what I was looking for.

I’m really curious about what these numbers are down here.

They may be nothing.

I just want to know what they’re about.

OK, I don’t really want to follow that …

I’m waiting for some sort of text to tell me what this is going to be about.

Since there’s nothing, I don’t know what’s it’s about.

I’m not even sure if the page is finished loading.

OK, there it is …

When I hold that down I would hope that it would stay there but it keeps going away.

Even without seeing what the user is talking about, the frustration and confusion are clear. When the test participants tried to use it, either they used it differently from how the developers intended or, when they used it as intended, it didn’t behave as they expected. From a usability standpoint, it was largely unusable.

As bad as this situation was, one point was even worse: none of the participants knew what Typhoon was. It became clear that people would never begin trying to work with it because they had no idea what it was for. Usability was beside the point because the product was incomprehensible.

The developers scrambled to fix the problems, to make Typhoon clearer, and to help people use it, but there were no clear directions for them to go in. The product launch was coming up fast, and they were able to fix some of the most obvious problems. Many problems remained, however, and their confidence shaken, they nervously suspected that many more problems existed.

When Typhoon launched, it was met with confusion. Neither the press nor its initial users knew what to do with it. It got significantly less traffic than Bengali had projected and, despite an aggressive advertising campaign, the number of users kept dwindling.

As the development team worked on the next revision of Typhoon, the direction in which to take it became less clear. Fundamental questions kept popping up. There was constant debate about scope, audience, purpose, and functionality. What had seemed certain suddenly seemed precarious. The executives were quickly losing confidence in the team’s ability to fix Typhoon. The debates continued. Their fixes failed to keep visitors from abandoning the product, and after a couple of months, the project leader was replaced with someone who had a more traditional software background. The new project leader tried to revamp Typhoon into a more ordinary news service, but the new specs made Typhoon look just like the company’s other products, which ran contrary to the very premise of the service. Requests for additional staff to implement deeper changes were denied. Opinions about how to attract visitors began to multiply and diverge. The team felt betrayed; they felt that their creativity had been wasted and that their good ideas had been being thrown out by management.

Four months after the project launched, the...

Produkt-Details

• Erscheint lt. Verlag: 22.5.2003
• Sprache: englisch
• Themenwelt: Sachbuch/Ratgeber
• Themenwelt: Mathematik / Informatik ► Informatik ► Betriebssysteme / Server
• Themenwelt: Mathematik / Informatik ► Informatik ► Datenbanken
• Themenwelt: Informatik ► Software Entwicklung ► User Interfaces (HCI)
• Themenwelt: Mathematik / Informatik ► Informatik ► Theorie / Studium
• Themenwelt: Mathematik / Informatik ► Informatik ► Web / Internet
• ISBN-10: 0-08-049756-X / 008049756X
• ISBN-13: 978-0-08-049756-3 / 9780080497563