on February 7, 2004
Personas and goal-directed design are great techniques for putting together a quality product and really making sure that you're building the right things for your users. In particular, this book provides a process for doing design that would help most teams do a better job of being more customer-focused.
Unfortunately, this book has a few bones to pick with the current ways that users work. In many cases, while I may agree with statements such as that the File menu is not strictly necessary, users of many programs already understand how things work under the hood and want to know about it directly. He sometimes preaches design as if all customers of software are and should be ignorant of the system they're working on. I write software for other developers, so a lot of the tips and advice he gives are actually things that would cause my customer to become quite angry -- they understand the system, want to work in terms of it, and want to be able to to understand how your program deals with it. There are a number of commercial software tool failures to prove the mistakes of those who've tried to force a model the designers thought was superior on developers who knew better (ever used Visual Age Java?).
There's also a lot of material duplicated from his earlier book, _The Inmates Are Running the Asylum_. If you're only going to read one of the two, I'd advise reading that one, and skipping this one.
on February 6, 2004
The main goal of usability engineering is creating the right interface for the right audience.
The target field (cf. the users) of this book are developers, every programmer should have a copy, is not?
A software package, which is unfriendly, laughing and bashing to its user, such a package would be considered as a computer program with a bad design. The user would not like to use it.
Now, I'm wondering why the so self-declared software design god of the modern times is bashing, laughing and unfriendly against the users of his product.
Mister Alan Cooper does not have a clue how a company works and what the background of a developer is all about. He is bashing the wrong people. Bad software interfaces are not the fault of the developer but the management and the methodologies that are used in most companies.
Developers are trained in schools and universities to produce code and to design the internal architecture. Few of them receive cognitive psychology courses, which is needed to create five star interfaces.
The average management in a company, small or big just allows that developers do the graphical interface design, a task for which they were not prepared. The outcome is indeed bad software but don't shoot the pianist, instead turn the spotlight on the choirmaster.
The content-worth of the book is average. It is heavily focusing on one aspect of creating better software interfaces: design guidelines.
While these guidelines are important, it is not enough to create excellent interfaces. The risk is that a developer, after finishing reading the book will think he or she knows everything about the job and this is not his or her fault but the author.
No words are spoiled by instance on User Profiles, Contextual Task Analysis and so many other aspects of user interface designing.
The design guidelines itself are mostly not new, I have read them long ago in other works and with some research you find them for free on the internet. Some guidelines-laws described in the book are even examples of bad designs, which is dangerous, at least in a way.
I can imagine that for an average programmer the book is still revealing, but he or she should know that other grasslands are much greener. Best case, you have a design guideline book, nothing more, nothing less.
I do not know I am allowed to do this, but if you want a real step-by-step guide for creating better software you should try "The Usability Engineering Lifecycle" by Deborah. J. Mayhew, also available on Amazon.
on December 20, 2003
I loved "The Inmates Are Running the Asylum", and bought "About Face" looking for some concrete examples of how to implement its ideas. Unfortunately, all of Cooper's concrete ideas are just awful. Half of them would require strong AI in order to implement, and many of them would actually require the computer to have psychic powers.
For instance, he spends a lot of time explaining that programs need to be written to assume that users will make mistakes (because they will), rather than considering mistakes to be a break in the workflow. Sure, sounds good. But then later on, he suggests that if the user of an accounting system enters a record with an invalid account number, the computer should just assume that it's actually a valid account number that the user just hasn't told it about yet. And worse, he suggests that the system should accept it *silently*, and not tell the user that anything at all odd happened until it gets around to generating the end-of-month report and there's still no matching account number. Can you imagine the user of such a system, when the computer finally tells him that *a month ago*, he made a typo while entering a record, and now he has to go digging through paper records (assuming he still even has them) to find the correct information?
It's the same thing with many of his other examples. He suggests ways for the computer to be "smart" that are clearly smart in the very specific cases he's thinking of, but often dumber than before in every other case.
on October 26, 2003
When Alan Cooper wrote the first edition of About Face in 1997, the software industry was in the midst of its biggest change ever. Just about every new user interface was being created in the context of a Web browser. Cooper was the leading advocate to persuade software developers, graphic artists, usability designers, and interaction designers to avoid bringing the mistakes that got baked into desktop application software developing into Web development. His impact has been profound, but not very easy for most software developers.
Key to this book is to understand that it challenges software developers to consider a user's goals first. And the book means "a user", not all of the users, but a single user. I've been to Alan's presentations and you can see the software developers in the audience squirm in their seats. "Don't I have to build my software to work for the largest group of users?" they ask. Alan's book says "No. Instead, build for a single user, and make sure your work accomplishes their one goal." About Face might be better titled "User Goal Oriented Software Development."
The book's focus on "interaction design," as opposed to user interface design, matches the key theme of user goal oriented development. For example, when my printer runs out of ink a dialog box appears on my computer asking for me to put more ink into the printer and then click one of the following buttons: Finish and Continue. As the user, my goal is to Finish, but the software wants me to put more ink in the printer and then to Continue. Interaction Design addresses this problem, where user interface design would more likely tell the software developer where to place the buttons in the dialog box. Interaction design keeps the focus on user goals.
I loved the original book, and find the new release to be refreshing.
-Frank Cohen, [...]
on October 9, 2003
There seems to be some misunderstanding among previous reviewers of who this book is for, and I have to say I'm confused as well. I see the term "developer" used all over the place, but what exactly does it mean? Part of the problem is that according to Cooper (and just about anyone with basic reasoning skills)developers should be writing code and interaction designers should work on the interfaces. So, it would be reasonable to conclude that this book is targeted towards interaction designers. Then why bother mentioning developers as the source of all evil over and over again?
Who is this book for, anyway? When the author says "requirements" is he talking about project requirements in general or specific interface-related requirements? When he says "design" does he mean software design or interface design? If you have read anything about software engineering in general, I'm sure you will have lots of questions like these.
Although it is a book about interface design issues, it's a big disappointment that the author somehow forgets about the bigger picture and makes it seem like the product is the interface and the design of the product is the design of its interaction with the user.
The author also makes some arguable points. For instance, he claims that there is no such thig as computer literacy - we only have to talk about computer literacy because software is obscure and overly complicated to use.
Somehow it was no surprise to learn that the author also happens to be "the father of VB" :)
on October 9, 2003
To sum it up briefly:
"This book was filled with several good ideas and obvious shortcomings in today's software, but the authors' ideas are lost due to poor delivery."
The long story:
Although I was impressed with some of the authors' "radical ideas", I became distracted with their choice of words and constant finger pointing at obvious shortcomings in today's software interfaces. If this was the authors aim at humor, they missed their target completely. It becomes excessive when the negativity spills over from chapter to chapter. (I could have lived with less negativity directed at software developers...) I found that the authors' choice of words and finger pointing at software developers became the topic of my development team discussions versus the true matter at hand: "The problem with today's software interfaces and what can WE do to improve them."
I feel the book could have delivered its message better if only the first few chapters dealt with shortcomings leaving the remainder of the book to focus on new ideas or solutions. I would caution seasoned professionals to ignore the author's finger pointing and negativity and to focus on his ideas. Some of which are good and others are not, but it is obvious that software user interfaces have problems and the authors provide some ideas at addressing those. I would only recommend this book to those who are able to see beyond the authors' tone and truly listen to their ideas.
on September 23, 2003
I've read the book once, and I'll read it again. So will my colleagues. The authors had done a very good job gathering together the high-level problems concerning user interface (or user interaction) desing. They don't provide out-of-box solutions to every existing usability problem, but designing an interface is not like boolean logic.
The book introduces some new terms, to me that's fine. For example, "user profile" or "user role" is not the same as "persona", as the authors state in p. 61. It's a design tool for their design process, and the meaning behind the terms should not be considered the same.
We're propably going to apply this book's methods in our organization. But we're also going to use usability professionals. After all, we all have a developer background too.
Some developers might think that the book has an offensive attitude against them, as seen in other reviews. Hopefully in version 3.0 the authors find words that would be easier to swallow also for the people who actually do the coding. Then I'd rate it five stars.
on September 19, 2003
My best advice for you regarding this book is to avoid it like the plague. The worst thing about it is the anti-developer attitude the authors take and the tone of their writing. They are highly critical of developers in general and seem to think that all the shortcomings with modern day software have been intentionally placed there.
Also, the authors feel the need to pepper the user with "big words" in what appears to be an attempt to make themselves sound smarter. Look at one of the other reviews where the reviewer actually documents some of these usages. The reader is advised to have a dictionary handy when reading this book.
Another problem I have with this book is that the authors like to talk about software usability problems yet in many cases offer no solutions or ideas on how to fix them. What's the point in bringing up a negative if you can't offer up a solution? If all the author is going to do is complain about something, why would anyone buy the book?
What is really unfortunate about this book, aside from the fact that I wasted $25 on it, is that the authors do raise some valid points but these are lost amidst all the wordy blather that is so prevalent.
One thing for sure is that in the future, I will think long and hard before I purchase any book authored by Cooper and/or Reimann.
on September 19, 2003
Although this book contains some very good observations, it is underpinned by an agenda which is the creation of a new craft called "Interaction Designer". Since any new craft needs its own jargon to confuse those who are "less learned", Cooper wastes no time creating one. His frequent use of less-familiar terms for the sake of exactness is distracting and weakens the effectiveness of his message. Here are a few examples:
"Interaction design" instead of "user interface design"
"aphorism" and "axiom" instead of "principle"
"Subject Matter Experts" instead of "expert users"
"Ethnographic Interviews" instead of just "interviews"
"Personas" instead of "user profiles"
The list goes on and on. Almost every other page introduces some new or uncommon term to be included in the jargon to be used by this new profession that Cooper wants to create.
Personally, I think this book makes some really good points that deserve to be heard. Unfortunately, those "tender morsels" are buried in so much diatribe that most of the people who read the book are likely to miss them.
I hope the authors get busy soon on a "About Face 3.0" edition that eliminates at least a third of the text and replaces the academic "high-brow" vernacular with common words and phrases that are already in common use. They also need to provide more examples of potential solutions to the problems that they point out.
In the meantime, I can't honestly recommend this book.
on September 19, 2003
If you want a good example of how NOT to write a book, than this is it. It's unfortunate that Cooper and Reimann chose to take the condescending, developers are evil approach when trying to make their point because all it did was alienate me as a reader. As an example, in their discussions regarding scrollbars (page 360), they say "In many cases, though, it is used inappropriately only because designers and programmers don't have any better ideas. That's a poor rationale for any aspect of software design." What they are really saying is "You didn't invent something new, therefore, you suck." Or how about in the Chapter 34, Notifying and Confirming (page 449), the quote "Promise that you won't ever create one of these, please?" OK, I'll promise to never create one of these if the authors promise to never write another book.
It is my opinion that 70% of this book is a waste of paper and served no other purpose than to get the page count up to justify the price. Also, the authors seem to get some perverse enjoyment out of using obscure and unrecognizable words in order to sound more intelligent and give their book a college textbook feel. And the lack of examples for many of the problems they cite is inexcusable. If you're going to bring up a problem, then offer up a solution. Many times they fail to do this.
It's unfortunate that the authors failed so miserably in the delivery of their message because of their overall poor writing style since they do bring up some valid points. As a developer, I agree that software in general has to be made more user-friendly and have seen first hand many of the problems the authors cite throughout the book. I think they would have succeeded in bringing more developers around to their way of thinking if they would have just changed the delivery of their message.
One thing that will come from reading this book is that in the future, I will refrain from purchasing any book authored by Cooper and/or Reimann.