Prof. Daniel D.
McCracken is the author, with Dr. Rosalee Wolfe of
The subtitle is
key: the book is the first textbook in the rapidly-emerging field of
human-computer interaction (HCI), which is recommended in the ACM/IEEE-CS
Curricula 2001 for inclusion in the “core,” the part of the curriculum that
every student takes.
Added August 10, 2007. Well, I didn't mean that. Ben Shneiderman wrote a textbook on HCI many years before this book was published, and there are lots of others. I meant something like, "The first book on website design that strongly emphasizes the HCI factor, especially usability." Sorry.
The book has been in use in preprint form in Dan’s course in Web Site Development at City College of New York for the last two semesters, with copies provided by Prentice Hall. The preprint has also been test-taught at a dozen other schools around the country over the last two years.
This is Dan’s 26th book. He published Digital Computer Programming, the first text on programming, in 1957.
Work on the book was supported in part by National Science Foundation grant DUE 0088184, "User-Centered Web Site Design." McCracken says, "I am deeply grateful for the NSF support, for the support of the CCNY administration in granting me a sabbatical, and for the pleasure of working with students at CCNY and at DePaul University, where I taught and worked with my coauthor in the fall of 2001."
Read Jared Spool's Foreword.
See the table of contents.
Back to Dan McCracken's Home Page
I like this book, but why should you care? I’m guessing that you are reading it because you’re interested in what it takes to make a web site that people find usable. If that’s the case, then I have just one question for you: Why Bother?
It’s hard enough to build a working web site. A web site that produces the right pages at the right time with all the links and buttons in the right positions—that’s hard. Why now put in all the extra effort to make that site usable?
Let’s say we wanted to build our own airline reservation service. Just creating a database to contain an up-to-date schedule of more than 2,500,000 flights for 150 different airlines over the next three years would be a huge technical achievement. The idea that you could create an interface—any interface—where every user can choose a specific flight and reserve a seat that no other user (whether using your web site or buying a ticket any other way) can subsequently reserve is a monumental task.
In the book you’re about to read, you’ll find out that we’ll have to go to tremendous effort to make our design usable. Why go to all that effort to make it usable? Haven’t we done enough just to make it work? Moreover, once we start making it usable, when do we stop?
To understand my answer for these questions, you first have to understand where I’m coming from. Over the years, I’ve had the opportunity to watch hundreds of people interact with web site designs.
I’ve watched these people buy shirts, order pizzas, rent movies, trade stocks, and reserve flights. I’ve seen them find important medical information, learn cool facts about Mt. Everest, and find a hotel at Walt Disney World. I’ve seen them upload pictures of their newborn baby, determine the x-ray diffusion of a protein, and isolate fluid distribution problems in an automated undersea oilrig that is 1,750 miles away. As I’ve watched all these users try to do all these things, I’ve come to an interesting conclusion: We can’t actually tell when a web site is usable. We can only tell when it is unusable.
Sure, we can tell when the user you are watching has accomplished their goal. If someone comes to our airline reservation site and wants to fly from Boston to Salt Lake City in 3 weeks, we can tell if they successfully made the reservation.
In addition, we can tell if the folks developing the site have achieved their goals. Maybe our company’s goal is to have every potential travel customer book and pay for their reservation. That is certainly measurable.
However, just because the user and the organization each achieve their goal, does that mean that the design of the site is usable? Let’s say the users can book the reservations, but spend a lot of time hitting the wrong buttons, getting error messages, feeling confused, cursing at the screen, and need to ask customer support for help. Was that a usable design? After all, there are many web sites where, given enough patience, time, intelligence, and a thorough understanding of the workings of the design, any user would eventually figure it out—no matter how much pain the user experiences in the process.
To understand when something is truly usable, you actually have to look at what happens when it is not usable.
At some point in your life, I’m guessing that you’ve run into a piece of technology that just wouldn’t do what you wanted. Maybe you’ve bought a VCR and you just wanted to record a TV show when you weren’t going to be around. Perhaps you’ve rented a car and couldn’t locate the fuel door latch to fill it with gas. Possibly, you’ve spent hours unsuccessfully searching a web site for a piece of critical information that you know you’ve seen on that site before.
When you had these incidents of failure, what did you feel? Well, if you’re like the hundreds of folks I’ve watched using web sites, you’ve felt what they felt. You’ve felt frustrated.
If I asked you to tell me about a web site that you thought was perfectly usable, it would probably be difficult to find one. However, it would be easy for you to tell me about one that frustrated you, with many sites from which to choose. Frustrating sites are far more common than usable sites.Why is that? Why is frustration so common a result of design?
In design terms, frustrating is the opposite of usable. They live at opposite ends of the design spectrum.
Just as cold is the absence of all heat, a usable design is a design devoid of any frustration. You can’t tell when a site is usable, except by looking for frustration. It is only after we’ve watched every possible user attempt every possible use without any resulting frustration that we can declare a site usable.
When, in our research, users have encountered a site they consider extremely frustrating, they usually say the same thing: “How could the people who created this site think this was acceptable?” They are baffled that a designer could have let such a monster out of the lab.
When we talk with the designers of these sites, they are completely unaware that users are becoming frustrated. Until we talk with these designers, it never even occurs to them that there might be a problem. This doesn’t happen because the designers are clueless or they have some hideous disdain for the user population. Instead, the developers had focused their efforts on the technical aspects of the project, and didn’t pay any attention to the users.
However, why should we put all this effort into building something if everyone will become frustrated when using it? That is the motivation behind user-centered design.
In the early days of computing, the designers of technology didn’t have to think about the users. Users were a very small part of the general population, often highly trained and specialized. The work they did was typically repetitive (such as entering information about new customers) with little variance or exception. On a given day, a user, such as a data-entry clerk or call center operator, only used one, maybe two, program interfaces, performing the same, limited set of tasks, over and over. It was easy for these users to learn all the nuances of the system and adapt to the interface.
However, the web is a very different environment from those early information systems. Most web users only use a given site sporadically, like once or twice a month. Nobody has trained them, there are no manuals, and they’ve never really thought about how they will interact with the site. They can’t adapt to a site’s very specific interface.
Instead, they must rely on the clues given them. It is your responsibility, as a designer, to understand the clues users will respond to.
Here’s a little story from our research labs: One day, a gentleman, while participating in one of our studies, told us that he wanted to buy a sweater for his girlfriend. He knew which sweater he wanted to buy. He knew where he wanted to buy it. He knew what the price would be. He even knew he needed a size 6.
He sat in front of a machine and brought up the site that had his sweater. He had no trouble finding the sweater on the site—it took only a couple of clicks. They had the color he wanted in stock. The sweater was exactly what he wanted, at the price he was ready to pay.
He didn’t buy it.
Why not? Well, he knew his girlfriend was a size 6. To buy the sweater, he had to choose between Small, Medium, Large, and Extra Large. Being a guy, he had absolutely no idea how to map his girlfriend’s size 6 into the available sweater sizes.
Fortunately, there was a link labeled “Size Chart.” With great anticipation, he clicked this link, only to get a chart that converted “Chest Sizes” into “Sweater Sizes”, with no mention of “Dress Sizes.” He could try to guess his girlfriend’s chest size, but this could get expensive—the wrong guess could cost him, not only the price of the sweater, but also the cost of flowers and possibly even jewelry.
Therefore, he decided not to buy the sweater.
You can divide the design of a site into two categories: functionality and content. In the case of our sweater-buying gentleman, the functionality of the site worked perfectly for him. However, the content of the site failed him miserably—it had everything he needed, except for one critical piece of information.
If you were the designer of this site, how would you know that this problem even existed? Once you found out, what would you do to fix it? How would you know if your fix actually worked?
If you’re going to bother to make your site usable, you need to answer these questions for every source of frustration on your site. Of course, some problems are more frustrating than others are. Therefore, you’ll need to do some research to find out what problems are most important to tackle first.
Why go through all of this effort to make something usable? For some designers, it’s because a more usable site means that their site will capture and retain users from sites that are less usable. For others, their reason might be that they like the challenge of eliminating frustration from the user’s experience. Others might be in a situation where a more usable site means more revenues to their organization. Yet, others might do it just because they believe it’s always worth the effort.
This book will help you know
how to make your site more usable. You’ll need to find your own reason to
know why you need to make it more usable. Once you do, you’ll have all
the pieces—the desire to create a usable site and the expertise to make it
happen.
Back to Dan McCracken's Home Page
1. Human-Computer Interaction: An Overview.
2. Capabilities of Human Beings.
3. Know Thy User.
4. Content Organization.
5. Visual Organization.
6. Navigation.
7. Prototyping.
8. Evaluation.
9. Color.
10. Typography.
11. Multimedia.
12. Accessibility.
13. Globalization.
14. Personalization and Trust.
Appendix: XHTML and Cascading Style Sheets.
Index.