Books & People

back Books & People Overview

Books, People

Archives

Book Reviews

 

Book Review: Designing with the Mind in Mind

Book | Authors | Review

By Gerd Waloszek, SAP User Experience – October 26, 2010

This review takes a personal look at Jeff Johnson's book Designing with the Mind in Mind.

 

Book

Cover of Designing with the Mind in Mind     

Jeff Johnson
Designing with the Mind in Mind: A Simple Guide to Understanding User Interface Design Rules
Morgan Kaufmann, 2010
ISBN-10: 1-012375030X, ISBN-13: 978-0123750303

Usability: UI Design

 

Author

Photo of Jeff JohnsonJeff Johnson is a consultant at UI Wizards, Inc., a product usability firm (www.uiwizards.com). He has worked in the field of human-computer interaction since 1978 as a software designer, usability tester, manager, and researcher. In addition to GUI Bloopers 2.0, its predecessor GUI Bloopers from 2000, and Web Bloopers, Jeff Johnson has written numerous articles and book chapters on aspects of topics human-computer interaction and the impact of technology on society.
(From GUI Bloopers 2.0 cover and GUI Bloopers tutorial, modified)

 

Review

Introduction to the Review and the Book

I heard of Jeff Johnson's book Designing with the Mind in Mind for the first time shortly after the UPA International Conference 2010. As the book had just been released, Johnson expected it to be available at the book stand – but it was not, as my colleague Christine Ronnewinkel told me. This news inspired me to include the book in our book list and publish a short presentation on the SAP Design Guild. In time, however, the book disappeared from my horizon. Recently, however, Dan Rosenberg, Senior Vice President, SAP User Experience, asked me whether I had read the book – he had just finished reading it and had also attended a presentation by Jeff Johnson about the book's topics. This brought the book back to my attention – I rushed to buy a copy, read it, and review it. Here is my review!

When replying to Dan Rosenberg, I wrote that Johnson's book is probably the one that I had always wanted to write, namely – as the book presentation states – a book that "provides designers with just enough background in perceptual and cognitive psychology that UI design guidelines make intuitive sense rather than being just a list of rules to follow." But is it really the book that I had always wanted to write? In that case, Johnson would have saved me an awful lot of time. I will answer this question at the end of my review.

Purpose of the Book

In my UI Design Blinks column, I provide a lengthy substantiation of the book and discuss the connection between the daily UI design practice and the science behind it. I conclude that design rules and the science behind them have to be tied closer together and that Jeff Johnson's book Designing with the Mind in Mind comes to the rescue and closes this gap: It is exactly an attempt to "unite design rules with the supporting cognitive and perceptual science that is at their core."

Jeff Johnson himself does not need lengthy substantiations to tell readers the purpose of his book, which "is to provide a brief background in the human perceptual and cognitive psychology that underlies interaction design guidelines." He points out that early UI practitioners were trained in cognitive psychology, from which UI design rules were derived, but as the field evolves, designers enter it from many disciplines. While they have sufficient experience in UI design and have been exposed to design rules, they lack the background and do not understand the psychology behind the rules. With his book, Johnson seems to have found a format that enables them to acquire the necessary background fast and efficiently.

Why Background Knowledge Helps

Why should designers know the scientific background behind UI design rules? Johnson argues that having this background UI design guidelines will make more sense to them. They will also recognize that the basic set of guidelines is the same, regardless of the authors (see the book's appendix) – thus, there is a lot of agreement in the field. But most importantly, designers will be able to apply the design rules more effectively: They are now better equipped to interpret, tradeoff, and apply the guidelines in real-world design situations. But why can UI design rules not be followed as straightforwardly as cooking recipes? Shouldn't well-made and detailed guidelines enable designers to answer a large number of design questions? This may indeed be the case, but it is not sufficient for the daily design work. Johnson lists a number of reasons why designers still need to interpret design rules, apply them thoughtfully, and make tradeoffs (I made a few additions to this list):

  • Firstly, UI design rules are often general on intention, describing more goals than actions: "They are purposefully more general to make them broadly applicable." However, this strategy has a drawback: "Their exact meaning and their applicability to specific design situations is open to interpretation." In other words, as the rules lack detail, designers have to interpret the situation in the "spirit" of the existing guidelines.
  • The existing design rules do not cover the current situation, that is, rules are missing. Once again, designers have to interpret the new situation in the "spirit" of the existing guidelines.
  • Design rules conflict, and the conflicts need to be resolved on the basis of user-related criteria (for example, primary context of usage of the application, types of users, human limitations regarding perception/memory/attention, etc.). That is, designers have to decide which rule should take precedence (and often, which rules can be violated without causing much harm).
  • Design goals conflict and cannot be met all at once. Here, designers have to decide, which goal (and consequently, which rule) is of primary relevance.
  • Furthermore, in real world projects, external influence factors, such as deadlines and resources (time, people, budget) constraints, add to the complexity and force UI designers to make further tradeoffs and prioritize competing requirements, which UI design requirements are only a subset of (often, they are even not taken into consideration).

But Does it Guarantee Success?

I agree with Johnson that UI designers who are armed with the science behind the rules are better equipped for making informed decisions in all the above-mentioned cases. However, design decisions are rarely made by a single person. Designers work in teams, and this often means that the team members differ in their opinions on a given design issue. Moreover, particularly in mixed teams or if you are the only UI designer in the team, not all of the team members will be interested in the scientific background of the design rules. It may be that those who are equipped with the respective knowledge about human strengths and weaknesses typically will have an edge in the discussions, but I would not count on that – a knowledge edge does not guarantee success. I have experienced that developers trusted their own gut feelings more than a UI design authority and science-based arguments. Therefore, I will add these colleagues to the list of prospective readers of Johnson's book below...

Intended Audience

Johnson conceives of two groups of UI designers as the audience of his book: Primarily, it is aimed at "software development professionals [coming in many variants and sub-types] who have to apply user-interface and interaction design guidelines." Secondly, the book addresses software development managers who want "enough of a background ... to understand and evaluate the work of the people they manage." In the end of my review, I will ask whether there are more potential readers who might profit from Johnson's book – I just mentioned one such group.

Overview of the Book

The book's volume was a pleasant surprise for me: It has less than 200 pages. What a delight for the readers – and also for the reviewer. I was glad that I had not bought the electronic version as I had intended originally – this is a book that you can take everywhere. Nonetheless, the book comprises twelve chapters, six of which are devoted to visual perception, five to attention, memory, and learning, and a final one to time requirements, or in more technical terms, responsiveness. For an overview of the book chapters, see the appendix to the review. In the following, I will provide a brief walk-through of the book based on the three "unofficial" sections: (1) visual perception, (2) attention, memory, and learning, and (3) time requirements.

Visual Perception

The section about visual perception comprises chapters and begins with demonstrating that our perception is biased by our expectations from the past (experience), the present (current context), and the future (our goals) and optimized to perceive structure – exemplified through the most prominent Gestalt laws and illustrated with good and bad layout examples from Websites. Johnson devotes a whole chapter to making designers aware of the fact that reading is an "unnatural" human habit – spoken language is much more natural to humans. He illustrates how designers can make reading harder through careless design and how they can support it, including omitting unnecessary text.

The chapter on color vision does away with some old myths. According to newer research, our vision is optimized to detect contrast, not absolute brightness. Johnson explains how we perceive color – or do not perceive it, if we are color blind (8% of the male population is affected). He shows that our ability to discriminate colors is limited and affected by various factors, such as paleness, color patch size, and separation. The chapter closes with guidelines for using color in user interfaces. Finally, Johnson turns to peripheral vision, its weaknesses (lack of detail), strengths (sensibility for movements), and the resulting consequences for UI design. He offers suggestions for making messages more visible to users – including using "heavy artillery" that should be resorted to only sparingly.

Attention, Memory, and Learning

In this section, Johnson discards the well-known "boxes model" of human memory in favor of a more modern one: It holds that short-term and long-term memory are functions of a single memory system that is also more closely linked with perception than previously assumed (see Ware for a more modern view of visual perception). He introduces briefly both memory functions and then digs more deeply into their characteristics; he also includes the respective implications for UI design. As a bonus, Johnson offers two tests for readers to check their short-term and long-term-memories.

When people interact with computer systems they exhibit certain predictable behavioral patterns. These result from the limits of human short-term memory and attention. In the next chapter, Johnson discusses the following prominent patterns:

  • Focusing on goals and paying little attention to tools
  • Using external aids to expand our memory and keep track of what we are doing
  • Following information "scent" toward our goal
  • Following familiar paths
  • Following the human thought cycle: define the goal, execute the plan, evaluate the outcomes
  • Forgetting cleanup steps after achieving a task's primary goal

Another chapter is devoted to the "classic" distinction between recall and recognition and its implications for UI design. Most readers will probably know that older command-line interfaces were based on recall, whereas modern GUIs support recognition, sometimes at the expense of efficiency. This chapter is, so to speak, at the core of modern GUIs.

The section closes with two chapters about learning. First, Johnson explains that humans have three brains, each of which affects different aspects of our thought and behavior: the old brain, the midbrain, and the new brain. The latter controls intentional and conscious activity. Then Johnson contrasts things that are easy for humans with those that are hard for us. Learning from experience (and its pitfalls) and performing learned actions (here, he discusses automatic versus controlled processing) is easy for humans. Problem solving and performing calculations, that is, conscious activities that are performed by the new brain, is hard. In his implications for UI design, Johnson provides tips for minimizing the amount of attention that users must devote to interactive systems instead of their tasks. Finally, he asks how the progression from controlled to automatic processing and, thus learning, can be made faster. He identifies and discusses three such factors:

  • Task-focused, simple, and consistent operations
  • Task-focused, familiar, and consistent vocabulary
  • Low risk (for example, by providing undo functionality)

The chapter includes a digression into task analysis, its variant objects/action analysis, and as a specific method, the objects/actions matrix.

Time Requirements

In the final book chapter, Johnson carries forward work that he had started in his GUI Bloopers books: He discusses human time requirements and their implications for UI design. This chapter is the most extended coverage of this important topic that I know of in the literature. After defining responsiveness, Johnson turns to the many time constants that govern the human brain. He simplifies this list for engineering purposes to orders of magnitude (powers of ten from a millisecond to 100 seconds) and provides design recommendations for each of them. The chapter closes with a collection of design recommendations for responsive computer systems, such as the timing of busy and progress indicators, delays between and within small tasks, and a lot more. All in all, this section is written in a less technical style than the respective chapters in the GUI Bloopers books.

As I was recently involved in a project that dealt with responsiveness (see our highlight topic "Human Performance at the Computer"), I read this chapter with particular interest. I find the chapter very useful but also have to note that we came to somewhat different conclusions in a few aspects.

General Guidelines: Introduction, and Appendix

In the introduction, Johnson mentions a number of general UI guidelines, the most comprehensive of which are the guidelines from Smith and Mosier (1986). In the book's appendix, he also lists the rules contained in some of the collections (the guidelines from Smith and Mosier (1986) are far too numerous to be listed in the book), including rules from his own book GUI Bloopers 2.0. However, there is no list of recommendations from the current book; I supply an attempt at such a collection in the appendix to my review.

Interestingly, apart from one citation, Johnson does not refer to the Research-Based Web Design & Usability Guidelines, which are similar in spirit to his book because, like Johnson, the guidelines' authors strive for a scientific foundation of their design rules. However, both seem to go in opposite directions: The authors of the research-based guidelines point from the rules back to science, whereas Johnson points from science to the rules.

A Few Comments

The Pluses

Above, I mentioned already that I regard and – let me add here, recommend – the book as a fast and efficient means to acquire the scientific background behind UI design rules, particularly in the areas of visual perception, attention, memory, and learning. Johnson's "tools" are an easy to read writing style, a multitude of positive as well as negative illustrated examples, and boxes that expand on certain topics. Last but not least, design implications and practical design recommendations (the difference between both is not quite obvious to me – implications seem to be more general than recommendations) provide the connection between science and UI design practice. Moreover, Johnson brings readers into contact with up-to-date psychological models of perception, attention, and memory. Perhaps, I should also add that Johnson's remarks about forgetting cleanup steps after achieving a task's primary goal really rang a bell for me (one of my examples would be not closing the sunroof of my car after arriving at the destination).

What Is missing?

This is a very useful book, but it is not perfect, and I see still some room for improvement in a forthcoming, second edition of the book. First, I hit on a number of omissions, which particularly come into play when the book is used as a reference after the first reading. As the book boasts of figures, a list of figures would have been a welcome addition to it. Such a list would help readers quickly jump to illustrations and examples of design issues. Furthermore, while the book includes a bibliography, I found it hard to track back citations in the print version of the book – an authors index would have made this task much easier. Finally, I mentioned already one more feature that I found lacking from the book: There is no collection of the design implications and recommendations given throughout the book. Such a list (including page references) would definitely have increased the book's usefulness as a reference (see an attempt at such a collection in the appendix). Or does Johnson fear that people would only read this list if he had provided one?

One More Suggestion for Improvement

Secondly, I would like to suggest that the author provides the book with a more consistent structure, which clearly distinguishes between background information, illustrative examples of instances of it, and design implications and recommendations. While some chapters follow such a structure, others do not, or blend the pieces together. I am tempted to supply a proposal for a more consistent structure to make my critique more constructive, but I think I had better leave this task to the author (in the case that he agrees with my comment).

Conclusions: Reading Recommendations and Returning to Questions from the Beginning

Reading Recommendations

It makes perfect sense to read the book from cover to cover, because it follows a natural progression from perception to memory and finally to the more specific topic of time requirements. But, depending on the readers' background and preferences, they can also jump right into the book. However, I would like to suggest that they observe the boundaries between the major sections of the book, because some chapters within the sections build on previous ones. Thus, the chapters 1, 7, and 12 are natural entry points into the book. I would also like to recommend that readers start with Stuart Card's preface to "tune in" to the book.

After the initial reading, the book will, despite a few reservations that I have mentioned, also be a helpful source of reference that can be consulted when ambiguities or conflicts arise in the daily design practice.

Who Should Read the Book?

To whom should I recommend the book? Dan Rosenberg, Senior Vice President, SAP User Experience, wrote in an e-mail: "I think everyone on the guidelines team should read this." Of course, they should read it, but is it sufficient that only the members of guideline teams read the book? Johnson himself conceives the audience of his book more consisting of people who apply guidelines (and their managers) than of those who write them. (If he would agree with Dan Rosenberg, he would only sell a few hundred copies of his book all over the world.) I agree with Johnson and would also like to add more players in the UI design field to his audience. Thus, I wholeheartedly recommend the book to everyone who is concerned with UI design in one way or the other, either by creating UI design rules (and backing them up with science), by designing user interfaces and observing design rules (UI and visual designers), as well as the many people who take part in UI design discussions such as UI managers, product/solution managers, developers, writers of end user documentation, and marketing people, just to name the most important ones. Finally, as I already mentioned above, I would like to add those people to the target audience who trust their gut feelings more than UI design authorities. They should read and consult the book just to listen to one more independent and objective voice.

Back to Another Question from the Beginning

At the end of my review, I have to stick to my promise from the beginning and answer my question: "Is Jeff Johnson's book the one that I always wanted to write?" Definitely it is not as already indicated, I would have done a number of things differently from Johnson, but this is probably more a matter of taste than of significance. As the book comes so close to my ideas, I will save my time for other activities instead of writing a duplicate of Designing with the Mind in Mind.

P.S.: To my surprise, I found a SAP Design Guild article from 2005 authored by me in the references (the citation refers to an illustration).

 

References

See the Appendix to the review

 

top top