Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.
Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.
Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.
Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.
Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.
Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.
2003 Paperback New Book New and in stock. 5/22/2003. *****PLEASE NOTE: This item is shipping from an authorized seller in Europe. In the event that a return is necessary, you ...will be able to return your item within the US. To learn more about our European sellers and policies see the BookQuest FAQ section*****Read moreShow Less
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
Audience: HCI practitioners, usability engineers, software developers, Web page designers and developers.
"The no-nonsense approach includes guidelines, tables for estimating costs, and plenty of detailed practical advice. Simply written, well-structured and highly informative. Don't leave home without it."—Gerry Gaffney, Founder and Director, Information & Design
Mike Kuniavsky is a user experience designer, researcher and author. A twenty-year veteran of digital product development, Mike is a consultant and the co-founder of several user experience centered companies: ThingM manufactures products for ubiquitous computing and the Internet of Things; Adaptive Path is a well-known design consultancy. He is also the founder and organizer of Sketching in Hardware, an annual summit on the future of tools for digital product user experience design for leading technology developers, designers and educators. Mike frequently writes and speaks on digital product and service design, and works with product development groups in both large companies and startups. His most recent book is Smart Things: Ubiquitous Computing User Experience Design.
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.
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 last of the original members abandoned it for other projects within the company. Two months after that, it was quietly closed down and written off as a complete loss. Today, only the T-shirts remain.
Sadly, this is a true story. The details have been changed, but the core of the situation is true. It happened to me. I watched Typhoon's creation, was the person who ran those tests, and watched it disintegrate. Years later, some of the people involved still have feelings of bitterness that so much effort, so many ideas, and so much innovation was abandoned.
It was abandoned for good reason. It was a bad product. What made it bad was not the quality of the code (which was very tight) or the core innovations (which were real and legitimate). What made it bad was that it was a good product with no understanding of its audience. And a good product that doesn't satisfy the needs, fulfill the desires, or respect the abilities of its audience is not a good product, no matter how good the code or the visual design.
This book is about knowing your audience and using that knowledge to create great software. It will help you avoid situations like Typhoon while still retaining the creativity that leads to innovative, exciting, unique, profitable products. User experience research is a collection of tools designed to allow you to find the boundaries of people's needs and abilities, and its core, the philosophy espoused here, is not about creating solutions but defining problems. The ultimate goal is not merely to make people happy; it's to make successful products by making people happy. When you know what problems people have, you are much less likely to create solutions that address the wrong problem, or worse, no problem at all.
Chapter Two
Do a Usability Test Now!
Basic user research is easy, fast, and highly effective. Some form of user experience research can be done with any product. The question is whether you want to do it yourself. And there's only one way to find that out. Try it. In this chapter, you will learn how to do a fast and easy user research technique, a usability test done with your friends and family. After 15 minutes of reading and a couple of hours of listening, you will have a much better understanding of your customers and which parts of your product are difficult to use.
A Micro-Usability Test
The usability test will tell you whether your audience can use what you've made. It helps identify problems people have with your site and reveals difficult interfaces and confusing language. Normally, usability tests are done as part of a larger research series and involve preparation and analysis. That's what Chapters 5 through 16 of this book are about. However, in the interest of presenting something that's quick and that provides good bang for the buck, here is the friends and family usability test. It's designed to let you get almost immediate feedback on your product, with minimal overhead. If you're reading this chapter in the morning, you could be talking to people by the end of the workday and rethinking some of your product's functionality by tomorrow. But give yourself a day or two to prepare if this is your first time conducting user research.
There are four major steps in the process of conducting a usability test.
1. Define the audience and their goals.
2. Create tasks that address those goals.
3. Get the right people.
4. Watch them try to perform the tasks.
1. Define the Audience and Their Goals
"An evaluation always proceeds from 'why does this thing exist?" —Dave Hendry, Assistant Professor, University of Washington Information School, personal communication
You are making a product for some reason. You have decided that some people in the world can make their lives better with your idea. Maybe it helps them buy something cheaper. Maybe it's to get them information they wouldn't have otherwise. Maybe it helps them connect with other people. Maybe it entertains them.
Part I: Why Research is Good and How It Fits Into Product Development
1. Typhoon: A Fable
2. Do a Usability Test Now!
3. Balancing Needs Through Iterative Development
4. The User Experience
Part II: User Experience Research Techniques
5. The Research Plan
6. Universal tools: Recruiting and Interviewing
7. User Profiles
8. Contextual Inquiry, Task Analysis, Card Sorting
9. Focus Groups
10. Usability Tests
11. Surveys
12. Ongoing Relationship
13. Log Files and Customer Support
14. Competitive Research
15. Others' Hard Work: Published Information and Consultants
16. Emerging Techniques
Part III: Communicating Results
17. Reports and Presentations
18. Creating a User-Centered Corporate Culture
Appendices
A. The Budget Research Lab
B. Common Survey Questions
C. Observer Instructions
Our reader reviews allow you to share your comments on titles you liked,
or didn't, with others. By submitting an online review, you are representing to
Barnes & Noble.com that all information contained in your review is original
and accurate in all respects, and that the submission of such content by you
and the posting of such content by Barnes & Noble.com does not and will not
violate the rights of any third party. Please follow the rules below to help
ensure that your review can be posted.
Reviews by Our Customers Under the Age of 13
We highly value and respect everyone's opinion concerning the titles we offer.
However, we cannot allow persons under the age of 13 to have accounts at BN.com or
to post customer reviews. Please see our Terms of Use for more details.
What to exclude from your review:
Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the
information on the product page, please send us an email.
Reviews should not contain any of the following:
- HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
- Time-sensitive information such as tour dates, signings, lectures, etc.
- Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
- Comments focusing on the author or that may ruin the ending for others
- Phone numbers, addresses, URLs
- Pricing and availability information or alternative ordering information
- Advertisements or commercial solicitation
Reminder:
- By submitting a review, you grant to Barnes & Noble.com and its
sublicensees the royalty-free, perpetual, irrevocable right and license to use the
review in accordance with the Barnes & Noble.com Terms of Use.
- Barnes & Noble.com reserves the right not to post any review -- particularly
those that do not follow the terms and conditions of these Rules. Barnes & Noble.com
also reserves the right to remove any review at any time without notice.
- See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend
Create a Pen Name
Welcome, penname
You have successfully created your Pen Name. Start enjoying the benefits of the BN.com Community today.
If you find inappropriate content, please report it to Barnes & Noble
More About This Textbook
Overview
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
Audience: HCI practitioners, usability engineers, software developers, Web page designers and developers.
Editorial Reviews
From the Publisher
"The no-nonsense approach includes guidelines, tables for estimating costs, and plenty of detailed practical advice. Simply written, well-structured and highly informative. Don't leave home without it."—Gerry Gaffney, Founder and Director, Information & DesignProduct Details
Related Subjects
Meet the Author
Mike Kuniavsky is a user experience designer, researcher and author. A twenty-year veteran of digital product development, Mike is a consultant and the co-founder of several user experience centered companies: ThingM manufactures products for ubiquitous computing and the Internet of Things; Adaptive Path is a well-known design consultancy. He is also the founder and organizer of Sketching in Hardware, an annual summit on the future of tools for digital product user experience design for leading technology developers, designers and educators. Mike frequently writes and speaks on digital product and service design, and works with product development groups in both large companies and startups. His most recent book is Smart Things: Ubiquitous Computing User Experience Design.
Read an Excerpt
Observing the User Experience
A Practitioner's Guide to User ResearchBy Mike Kuniavsky
MORGAN KAUFMANN PUBLISHERS
Copyright © 2003 Elsevier Science (USA)All right reserved.
ISBN: 978-0-08-049756-3
Chapter One
Typhoon: A FableSometimes 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.
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 last of the original members abandoned it for other projects within the company. Two months after that, it was quietly closed down and written off as a complete loss. Today, only the T-shirts remain.
Sadly, this is a true story. The details have been changed, but the core of the situation is true. It happened to me. I watched Typhoon's creation, was the person who ran those tests, and watched it disintegrate. Years later, some of the people involved still have feelings of bitterness that so much effort, so many ideas, and so much innovation was abandoned.
It was abandoned for good reason. It was a bad product. What made it bad was not the quality of the code (which was very tight) or the core innovations (which were real and legitimate). What made it bad was that it was a good product with no understanding of its audience. And a good product that doesn't satisfy the needs, fulfill the desires, or respect the abilities of its audience is not a good product, no matter how good the code or the visual design.
This book is about knowing your audience and using that knowledge to create great software. It will help you avoid situations like Typhoon while still retaining the creativity that leads to innovative, exciting, unique, profitable products. User experience research is a collection of tools designed to allow you to find the boundaries of people's needs and abilities, and its core, the philosophy espoused here, is not about creating solutions but defining problems. The ultimate goal is not merely to make people happy; it's to make successful products by making people happy. When you know what problems people have, you are much less likely to create solutions that address the wrong problem, or worse, no problem at all.
Chapter Two
Do a Usability Test Now!Basic user research is easy, fast, and highly effective. Some form of user experience research can be done with any product. The question is whether you want to do it yourself. And there's only one way to find that out. Try it. In this chapter, you will learn how to do a fast and easy user research technique, a usability test done with your friends and family. After 15 minutes of reading and a couple of hours of listening, you will have a much better understanding of your customers and which parts of your product are difficult to use.
A Micro-Usability Test
The usability test will tell you whether your audience can use what you've made. It helps identify problems people have with your site and reveals difficult interfaces and confusing language. Normally, usability tests are done as part of a larger research series and involve preparation and analysis. That's what Chapters 5 through 16 of this book are about. However, in the interest of presenting something that's quick and that provides good bang for the buck, here is the friends and family usability test. It's designed to let you get almost immediate feedback on your product, with minimal overhead. If you're reading this chapter in the morning, you could be talking to people by the end of the workday and rethinking some of your product's functionality by tomorrow. But give yourself a day or two to prepare if this is your first time conducting user research.
There are four major steps in the process of conducting a usability test.
1. Define the audience and their goals.
2. Create tasks that address those goals.
3. Get the right people.
4. Watch them try to perform the tasks.
1. Define the Audience and Their Goals
"An evaluation always proceeds from 'why does this thing exist?" —Dave Hendry, Assistant Professor, University of Washington Information School, personal communication
You are making a product for some reason. You have decided that some people in the world can make their lives better with your idea. Maybe it helps them buy something cheaper. Maybe it's to get them information they wouldn't have otherwise. Maybe it helps them connect with other people. Maybe it entertains them.
(Continues...)
Table of Contents
Part I: Why Research is Good and How It Fits Into Product Development
1. Typhoon: A Fable
2. Do a Usability Test Now!
3. Balancing Needs Through Iterative Development
4. The User Experience
Part II: User Experience Research Techniques
5. The Research Plan
6. Universal tools: Recruiting and Interviewing
7. User Profiles
8. Contextual Inquiry, Task Analysis, Card Sorting
9. Focus Groups
10. Usability Tests
11. Surveys
12. Ongoing Relationship
13. Log Files and Customer Support
14. Competitive Research
15. Others' Hard Work: Published Information and Consultants
16. Emerging Techniques
Part III: Communicating Results
17. Reports and Presentations
18. Creating a User-Centered Corporate Culture
Appendices
A. The Budget Research Lab
B. Common Survey Questions
C. Observer Instructions
Bibliography
Index
About the Author