Five Design Books

I was tempted to title this Five Design Books You Should Read Before You Die, but I hate those titles, so I won’t. (Maybe Five Design Books You Should Read Before I Die would really lay on the guilt trip, though. New trend?)

Anyway, someone on twitter asked for favorite UX books, and these five popped to mind immediately. Interestingly, they’re all old books, and I haven’t read them in a long time, so I don’t remember them well, but they each have something distinctive that stuck with me.

The Design of Everyday Things by Donald Norman #

If any book was a revelation to me, this book by Don Norman was it. This was the book that showed me the light: if something is confusing or difficult for the user, it’s not user error, it’s a design problem.

The example of the ubiquitous blinking VCR clocks may puzzle the those who are so young they’ve never seen a floppy disk, but doors that have no indication whether they’re to be pushed or pulled open are still with us today.

This is the book that got me to notice everyday things that could be better, and to think about how they could be better, and to appreciate the details of those things what work well (I recently noticed how there’s a raised border around the lock/unlock-all-doors button in my car, so that I won’t accidentally hit it while driving and operating the adjacent open/close-windows buttons).

The Evolution of Useful Things by Henry Petroski #

I like all of Henry Petroski’s books; my favorite perhaps is To Engineer Is Human, but The Evolution of Useful Things is focused on how products evolve and proliferate in variety over time.

The example from this book that I remember is the fork, its history and variations, and in particular how the spork didn’t quite catch on, even though it seemed to make sense.

Designing Interactions by Bill Moggridge #

I love books that collect the experiences of various luminaries Masterminds of Programming, Game Theory: Design and Practice…), and this compilation by Bill Moggridge features plenty, including those who don’t get nearly enough press, like Doug Englebart.

But the account in this book that sticks in my mind is that of Palm Computing and how the first prototype was a block of wood they carried around in their shirt pockets and simulated using to get a feel for it. There’s no substitute for actually using, or pretending to use, your own design.

Tog on Interface by Bruce Tognazzini #

This collection of essays is written by “Tog”, one of the original Mac interface designers. I remember the one that explained how surprisingly efficient it was to access the Mac menu bar. Since the menu bar was at the top of the screen, users didn’t have to move the mouse precisely over the desired menu. Instead, they could just whip the mouse up the screen, as the top essentially acted as a mouse barrier, and then move the mouse laterally as needed. (This of course doesn’t hold true on window systems that have menu bars on floating windows)

This example actually came to mind years ago when I was arguing with some coworkers about why our 3D graphics tool had a bizarre right-click-to-mouse-warp-to-the-right-side-menu feature. The rationale was that it was too slow to manually move the mouse there for power users.

I had almost too many objections to articulate: the right-side menu was always at the right side of the screen, so like the Mac menu bar, moving the mouse there just takes a quick movement without danger ofovershooting; mouse-warping is a UI design no-no; it warped to an arbitrary position that was most unlikely to be the desired menu item; the side menu only existed because they decided to do their product design by surveying potential customers who were used to seeing a side menu in similar products; power users were likely to use our original popup menus that would popup wherever the mouse was, like Maya’s radial menus; and I’ve never seen anyone say how come Maya doesn’t have side menus?

But that’s what happens when you start reading about UI design. You get into exasperating arguments with those who haven’t.

The Macintosh Human Interface Guidelines by Apple Computer #

Tog, as a member of the original Mac team, was also an author of the original Macintosh Human Interface Guidelines, the grandaddy of the current Apple Human Interface Guidelines.

The current guidelines are worth reading and should be read by everyone in a coffee shop or startup who says they have a great app idea, but the original guidelines could lay a valid claim as being the definitive UI design text of the time.

This was the Apple whose mantra was making interfaces intuitive, clear and consistent, not the current form-over-function Apple that babbles on about “delightful apps” and crams their engineers into a hamster cage where they walk into glass walls (which, by the way, happened to me in a WeWork building). Some of Apple’s current interfaces are terribly inconsistent by the standard of their original guidelines (single-click on the Dock is the same as double-click in the Finder, some operations in context menus should be in the menu bar but aren’t…)

The Apple II BASIC Programming Manual got me into programming on the Apple II+, the Lisp Machine Manual was another absorbing read that started me on Lisp machines and the first part of my career programming in Lisp, and in that tradition, the Macintosh Human Interface Guidelines made me want to be a Mac developer (Macs did not come with a copy of the Guidelines, but they should have…)

And, just as I’m trying to wrap up this article today, I finished rereading Snow Crash and discovered in the end notes that the Macintosh Human Interface Guidelines was one of the inspirational sources for that story!