Norman Doors, The Design of Everyday Things, and Better UX

A couple of months ago I was watching some videos on YouTube and I found this interesting video that talked about doors. In the video, there’s a door in the office where the author works and he simply hates it. Why? Because whenever he tries to open it, he gets it wrong! He pulls the door? Sorry, you’re supposed to push it. What about pushing it instead? You’re wrong again; now you have to pull it. You might think that’s stupid—everybody knows how to open a door… but do they?

Don Norman started complaining about doors over 25 years ago. He claims doors shouldn’t need instructions—their shape should tell you how to interact with them just fine. Wait, what? Instructions on a door? Indeed! Those Pull/Push signs you see on doors are no more and no less than instruction manuals! Isn’t that silly? Because, you know, do you really think doors are so complicated that we need instructions to properly operate them? I don’t think they should, but a lot of them include such instructions nonetheless, presumably because they’re poorly designed.

Surprising, isn’t it? We’ve been using doors for a long time. Doors are simple devices that serve a simple purpose. But Norman highlighted an obvious, yet unnoticed truth—we keep getting them wrong. They might look beautiful. They might be secure. But, still, a lot of them are difficult to use. In fact, it’s so common to find such doors that they now have their own name—Norman Doors.

So why are we talking about doors, if this blog is supposed to be about WordPress? Because doors and WordPress have one important thing in common—us. We, people, use them both! We’re WordPress users as much as we’re door users. So the previous video got me into thinking: if a thing as simple as a door can pose so many problems, what about our software? What about the plugins we create at Nelio?

The Design of Everyday Things, by Don Norman

The video mentions a book by Don Norman entitled The Design of Everyday Things. I decided it’d be a good idea to purchase and read this book, because I hoped that, by doing it, I’d become a better programmer and I’d be able to deliver better products to our users. Spoiler alert: I think I did ?

Even the smartest among us can feel inept as we try to figure out the shower control in a hotel or attempt to navigate an unfamiliar television set or stove. When ‘The Design of Everyday Things’ was published in 1988, cognitive scientist Don Norman provocatively proposed that the fault lies not in ourselves but in design that ignores the needs and psychology of people. Alas, bad design is everywhere, but fortunately, it isn’t difficult to design things that are understandable, usable, and enjoyable. Thoughtfully revised to keep the timeless principles of psychology up to date with ever-changing new technologies, ‘The Design of Everyday Things’ is a powerful appeal for good design, and a reminder of how—and why—some products satisfy while others only disappoint.

The first thing that surprised me the most is the fact that this book was first published in 1988 (that’s almost 30 years ago!) and, yet, all the principles stated in it are still applicable today. In a fast, ever-changing world like ours, you might wonder how’s that even remotely possible. Well, as Norman states:

The design of technology to fit human needs and capabilities is determined by the psychology of people. Yes, technologies may change, but people stay the same.

Overview of the Book

The book is designed in the following seven chapters:

1. The Psychopathology of Everyday Things
2. The Psychology of Everyday Actions
3. Knowledge in the Head and in the World
4. Knowing What to Do: Constraints, Discoverability, and Feedback
5. Human Error? No, Bad Design
6. Design Thinking
7. Design in the World of Business

All chapters are extremely interesting, but if I had to choose one, it’d probably be the first one. The Psychopathology of Everyday Things covers all the important concepts that you should know about. All of them are discussed in detail later on the book, but it amazed me how much information one could extract from the very first lines of the book.

When we interact with a product, we need to figure out how to work with it. Discoverability is the process that helps us achieve that goal, and is based on five fundamental psychological concepts:

• Affordances. What an object is able to do given a certain user. Affordances determine what actions are possible. For instance, a door affords (“is for”) pushing and pulling.
• Signifiers. Any mark or sound (i.e. any perceivable indicator) that communicates appropriate behavior to a person. They tell us where actions should take place. For example, the sign Push on a door.
• Constraints. Being physical, logical, semantic, or cultural, they guide the possible actions and ease interpretation. For example, a disabled button.
• Mapping. It’s very important in the design and layout of controls and displays. Borrowed from mathematics, the term refers to the relationship between the elements of two set of things. For instance, the mapping of switches to lights, that specifies which switch controls which light.
• Feedback. It communicates the results of an action. In order for it to be effective, it has to be immediate. Just think about the amount of feedback mechanisms embedded in our bodies: visual, auditory, and touch sensors, as well as vestibular and proprioceptive systems, all help us achieve our daily tasks.

The Lazy Programmer

One of the most enlightening passages in the book can be found in the second chapter. As you already know, we spend hours filling out forms on computers, where we are asked names, dates, telephone numbers, addresses, monetary sums… According to Norman (and I bet you’ll agree), the main problem about all these forms is their stiffness—you have to type the information in the exact format the program expects, or it won’t work. And, what’s worse, you won’t know what the correct format is until you get it wrong (and, sometimes, even after that, you’ll be forced to go through a trial-and-error process until you do get it right).

When we face these problems, we tend to blame ourselves, especially when they occur whilst using a program we should know how to operate (because, you know, you work with it everyday). Why not figure out a variety of ways a person might fill a form and accommodate all of them? Norman presents the following example:

Consider Microsoft’s calendar program. Here, it is possible to specify dates any way you like: “November 23, 2015,” “23 Nov. 15,” or “11.23.15.” It even accepts phrases such as “a week from Thursday,” “tomorrow,” “a week from tomorrow,” or “yesterday.” Same with time. You can enter the time any way you want: “3:45 PM,” “15.35,” “an hour,” “two and one-half hours.” Same with telephone numbers: Want to start with a + sign (to indicate the code for international dialing)? No problem. (…)

That’s great, isn’t it? It definitely works better than forcing the user to fill in dates in a fixed, rigid format. But I’m sure you can think of a ton of examples where the software is not as flexible as the example above. So, if it’s possible to do things better, why don’t we (programmers) do it? There’s two reasons for it: laziness and business constraints.

From the programmer’s perspective, it’s always easier to think that the user will proceed as we taught him to than offering different alternatives. Why? Because there’s less code to program and, if things go wrong, there’s someone we can blame—the user. But people are not machines, they don’t like rigid formats, they want flexibility; they make mistakes and they need a safety net to recover from them (did someone say “confirmation dialogs” before deleting anything?); they get interrupted while working, so they need our software to give them some clues to resume their activity…

I was one of those who thought that all the “user-friendly code” was boring. After all, it was oblique to the core functionality of our product—it didn’t add value. But I was completely wrong. They say God is in the detail, and they’re absolutely right. All these things won’t add any features to your product, but they’ll make it much more pleasant to use. And believe me when I tell you this: at the end of the day, what and how people feel when using your product is what they’ll value the most.

Working with Business Constraints

The last chapter of the book is devoted to present the severe constraints upon the design of products. From chapters one to six, Norman discusses the “ideal case”, assuming that human-centered design principles could be followed no-matter-what. Truth is, though, that in the real world that’s not possible (usually). There’s competition, costs, and schedules, and you’ll be facing conflicting requirements. I think it’s interesting the author acknowledges this reality in his book. Otherwise, you might be tempted to discard his claims, simply because “he obviated such an important aspect of any business”.

Nelio Content

I’m so happy about Nelio Content that I will sound like a payed advocate… but here’s why you’ll love it: it works as promised, its auto-scheduling feature is top-notch, Nelio’s value for money is unmatched, and the support team feels like your own.

Panozk

WordPress.org

View Plans

Applying these Design Principles in our Plugins

After reading Norman’s book I value the user experience more than ever! I’m not saying I didn’t value it before… but I really look at this from a different perspective. Now, whenever I add anything in the UI, I always try to think about the user. How will he use this new component? Is it useful? Is the best component possible or are there better alternatives available? These and similar questions are in my mind. I want to make sure that the experiences our users feel when using Nelio’s products are great!

I feel like you’ll be able to notice all the lessons I learned from this book when you use our new plugin, Nelio Content. I read the book while we were developing the plugin and I think most of the design principles Norman proposes have been properly applied in Nelio Content. Want to see how these principles look like in it? Just take a second look at the screenshots I shared in this post; they’re all Nelio Content‘s! ?

In summary, if you want to improve your understanding of human’s psychology and how your products look like and feel, don’t miss Norman’s book—The Design of Everyday Things is inspiring, educational, and a joy to read.

By the way, if you were wondering how a well-designed door looks like, it’s actually quite easy. If the door is to be pushed, add a flat surface on it. There’s nothing you can grasp, and thus the only possible action would be to push it. Moreover, this flat surface will act as a signifier, for it tells the user where to push. If it’s to be pulled, add a handle or a bar; this element can be grabbed and, because of the motion you apply at grabbing it, it’s telling you to pull the door. Easy, right?

Featured Image by Federica Campanaro.