This isn’t a book “review”; this is quick summary of what I got out of reading The Design of Every Things, by Don Normal. This content comes from what I’ve shared as a lightning talk for my fellow Improvers. I’ll keep referring to this book as DOET, for short.

Do I recommend this book?

Yes, I do. However, I’d recommend reading Kathy Sierra’s Badass: Making Users Awesome first; it helped me appreciate DOET more.

I have similar thoughts when comparing the canonical GoF book on Design Patterns to Head First Design Patterns; the former is a very dry read, although very comprehensive, whereas the latter is much easier to read (not coincidentally, Kathy is also involved in that one, and I really like that style of book).

DOET was originally published in 1988; the edition I’ve read is the “expanded and revised” one published in 2013. Even though some of the revised content may not resonate with younger readers, it did resonate with me.

Does it relate to software development?

As its title implies, the book is not about software development. However, it does mention some examples in software. But the way I see it is that it brings a shared vocabulary to design-related terms, much like design patterns do in software development.

Besides myself, two of my teammates participated in the book club, and we’ve been able to leverage the concepts learned in the book as we work in our project. Some concepts include:

• Affordances
• Signifiers
• Constraints
• Mapping
• Feedback
• Conceptual model

Here’s how I understand some of those concepts…

Affordances

I think of it as a door to a building. That door is how I relate to the building; it’s how I can get in.

Signifiers

For whatever odd reason, this is the image that comes to mind when I think of signifiers:

Constraints

For constraints, this is what comes to mind:

If you don’t get the reference, here’s a great 51-second video.

Contextual Model

As a hobbyist musician, I really appreciate how recording software models the experience we get in the real world.

For example, instead of showing me data entry forms to indicate how I want to my recorded guitar to sound, I get something that looks and behaves similarly to its counterpart in the real world.

As I move the microphone around on the screen, looking for a better positioning in front of the speakers, I hear the sound that reflects that setting, very similar to the experience in a real world studio.

To learn about those concepts, consider checking out Denny’s Improving Talk, Improving Software Design with Everyday Things, built on the lightning talk he shared with us at the end of the book club:

Human-Centered Design

Two points that resonated with me in the Human-Centered Design (HCD) section of the book:

• Solving the right problem, doing so in a way that meets human needs and capabilities
• Find the right problem, then find the right solution

I’ve recently shared my thoughts on approaching behavior-driven development without focusing on system behavior.

Most developers tend to immediately jump into their favorite technical solution, neglecting the needs and context of the humans who should benefit from it.

In the book, Norman says “I never solve the problem I am asked to solve“. I agree, and have been working hard for years trying to always separate the wants from the needs.

One of the examples in the book mentions a person walking in a store wanting to buy a drill bit. They don’t want a drill bit, they want a hole? Or do they? Their book library is growing, so they want new shelves. Would they consider trying ebooks instead? Do they want more books for their need to grow their knowledge through reading?

What have I been pondering?

There is a section later in the book that talks about humans and machines. Here are some thoughts that came from that…

Humans have been coaching other humans for a long time now. Even people at the top of their game have coaches.

The book good me thinking about the aspect of:

• Humans coaching Machines, and
• Machines coaching Humans

week human + machine + better process
superior to
strong human + machine + inferior process

Trying to think about that in the context of an accounting software:

novice accountant + computer + software with a built-in coaching process
superior to

seasoned accountant + computer + bad software

This next passage also got me thinking:

“Once technology can do our arithmetic, can remember for us, and can tell us how to behave, then we have no need to learn these things.”

Woah. Hold on. Technology telling us how to behave? So, what if we approach behavior-driven development with a spin of “the valuable desired behavior we’d like to coach humans into“? Food for thought.

I’ve enjoyed watching “The Future Of” Series on Netflix. The episodes on Gaming and Headphones are my favorites.

Best advice in the book

I’ve marked several passages in the book. This is my favorite one, which I come back to fairly often:

• Do not blame people when they fail to use your products properly.
• Take people’s difficulties as signifiers of where the product can be improved.
• Eliminate all error messages. Instead, provide help and guidance.
• Make it possible to correct problems directly from help and guidance messages. Allow people to continue with their task: Don’t impede progress. Never make people start over.
• Assume that what people have done is partially correct. If it is inappropriate, provide the guidance that allows them to correct the problem and be on their way.

For more…

If you crave for more, look up Don Norman’s videos on YouTube; there are some great ones out there.

And there’s also this one by yours truly!