Norman's Design Principles - Design Stories 3

Prepare your coffee or tea and let's get ready to go through the second design story, part of the Design Stories series.

In this article, we're going to look at Don Norman's design principles that he discusses in his book called The Design of Everyday Things. If you didn't read it already, I fully suggest you check it out. I'm going to discuss the principles and give some examples along the way, but I'm not going into too much detail as that can be found in the book.

Throughout this article, I keep repeating "object" and "artefact". These can be a physical device, a user interface, anything really. I use those terms because the definitions that are discussed below apply to anything.

Performing actions

When using an object, an interface or taking any action, we do it because we set some goals in our mind. Without goals, we wouldn't need to take any actions, right? Taking actions is an iterative process that happen on two dimensions: Execution and Evaluation.

Execution - In this dimension we examine our goals, intent to act, build up a sequence of actions and execute them.

Evaluation - After we completed the actions we notice what has happened, we interpret and lastly evaluate the results which helps us generate new goals and then everything repeats.

A good example that came in my mind now that I was writing this article is the actual keyboard typing. I have the goal to write a sentence, I intend to use the keyboard, I know what I'm going to write and which buttons to press, and then I type everything down. I examine the screen and I evaluate the situation. I notice that I made a spelling mistake in the middle of the sentence and then my new goal will be to correct this. The new sequence of actions will be to click where the mistake is and type the right thing. And this process goes on and on because that's how we function as human beings. This seems pretty obvious, but as designers it helps to think about these basics to create useful interactions that doesn't break the cycle of coming up with new goals.

Conceptual Models

Whenever we want to interact with an object we already have an idea how it works or we can consult the instruction manual to learn more. So how does the conceptual model work when it comes to designing a new artefact?

The designer has his or her conceptual model and the trick is to be mindful of that and make sure that this translates well in how the user conceptualises this. A good example here is an open-source project where the designer/developer created a documentation to unify the creator and user conceptual models. Take a look below at a diagram describing this scenario:

Of course, you might say the documentation example is too much and a good designer should design something that can be easily used without having to write pages of instructions. And you're right to think that! This is where the following come in:

Affordances

This means that the object that is designed should have perceivable actions. The user should be able to look at the object and know how to manipulate it without having to consult the instructions. When a door has a handle on one side and a plate on the other, you know that you can pull and push respectively.

Signifiers

Signifiers are used to indicate certain actions. In the example with the door above, a signifier can be a hand drawn on the plate to indicate that the door can be pushed with the palm. Sometimes it's a bit tricky to distinguish between Signifiers and Affordances. My usual approach is to think about affordances as being the innate properties of the object that can be perceived and signifiers are any perceivable signs that point to how an object can be used. So you can think that signifiers make the affordances more clear.

The signifiers term was added in the latest version of The Design of Everyday Things book. If you're reading an older version you won't find the term described there.

Mapping

This concept refers to the relationship between the actions performed and the results in the world. The mapping should be easily remembered so it becomes obvious the next times the object is used. Another aspect of mapping is that the controls should match the effects in some way. This can be done through shape or positioning (grouping and patterning). Norman gives several examples, but I selected two of them to better explain what I mean by mapping through shape and position.

In terms of shape, Norman gives and example of the seat adjustment controls that are placed in the shape of the seat itself. You can see the example in the image below where the the two buttons that resemble the seat map nicely to the effects you expect as the user - left button controls the lower seat and the one on the right, the back rest.

When looking at the position, I like Norman's example of light switches. For a good mapping the light switches should be grouped by which room they control the lights in and in which order. So let's say you enter a hall and the hall leads directly to the living room. As you enter there are three switches. The first one should be for the hall itself and then the two others should be for the living room in the order in which the lights are placed apart from each other.

Constraints

The constraints are a powerful concept to keep in mind when designing an artefact. They come in multiple shapes and forms, but they basically do what they say - they don't allow users to perform certain actions. Take the scrollbar on the side of this page as an example. You can see where you are on the page and how much you will be able to scroll. You can't scroll more than the top or bottom of the page. Also, since we are on the topic of UI design, the greyed our menu options or buttons are examples of constraints as well. They allow easy communication with the users to let them know certain actions are not possible.

Feedback

So we have a nicely designed artefact that has all the affordances and signifiers in place, it's properly mapped and limits the user from taking the wrong actions with the constraints. Now the user is using the object and something happens. This "something" should be visible to the user so that we can complete the execution evaluation cycle that I talked about above. If the user takes an action and there's no feedback, then the tendency is to try again and then declare the object broken. A button on an interface can have "pushed" and "released" animations and some kind of result should appear on the screen. This could be a loader and a checkmark when the process is complete.

Mistakes happen

Even if all the concepts above are extremely well implemented, the user is bound to make a mistake at some point. As a designer you should prepare for these situations by making sure users can recover from them. The mistakes can happen for a several reasons:

• Lack of knowledge
• Instructions errors
• Losing concentration
• Slips, etc

The user tends to blame themselves when something wrong happens when using the object. So the errors must communicate the situation to let the user know what happened. The designer should design for errors in this case.

It might seem strange, but the design should allow mistakes. The reason being that the mistakes should be there for the user to know what is allowed and what is not in certain situations. Of course, this only works if the user is told that the action was a mistake. Another way is to allow the mistakes, but then ask the user how to proceed, like in the scenario where a user wants to exit a document that wasn't saved. In some cases that can be a mistake, but it can also be on purpose. So to solve that problem the system can display a dialogue asking the user if they would like to save the document before exiting. Another important function for designing for errors is to allow to recover from mistakes. An example can be the undo function.

Bonus: If you want to explore other ways to think about interaction design search for Schneiderman's rules for interaction design. Here is a good article on that

Next time you design an object or an interface try and think about all the concepts above, especially the affordances, signifiers, mapping, constraints and feedback. Or you can even take an existing interface and take it through all of those to see how they check certain things. If you find something interesting feel free to get in touch with me and we can discuss it.

Also, if you haven't done so, feel free to subscribe to the newsletter to know when I post the next article in the series.

Until next time, with more design theory!

-Raz - @razvanilin

This article was based on a lecture by Patric Dahlqvist from KTH University and Don Norman's The Design of Everyday Things book (which I fully recommend for reading).

Cover photo by Firdaus Roslan on Unsplash