Affordances, Constraints and Conventions

Diego Doval
5 min readJul 28, 2017

--

The term ‘affordance’ is used less frequently than it should be, but even when it is, it is sometimes misused to refer to something that is either a constraint or a convention. Clarity on each of these is useful to avoid design traps.

“Yes, it has a handle, a spout and a cover, but I wouldn’t call THAT a teapot”

Don Norman popularized the concept of affordances with his book The Design of Everyday Things (Previously called The Psychology of Everyday Things). It is a powerful idea, and one that I return to time and again when analyzing and working on interface designs. In the book, Norman also discussed what he called “constraints” and later expanded it to “conventions.” In my view, these are three things that should be thought of as different axes on which to evaluate a design.

Some Definitions

To start off from common ground, let’s look at how Norman defined them. He returned to the subject in the essay Affordances and Design, clarifying early definitions and his own intentions:

The word “affordance” was originally invented by the perceptual psychologist J. J. Gibson (1977, 1979) to refer to the actionable properties between the world and an actor (a person or animal). To Gibson, affordances are a relationship. They are a part of nature: they do not have to be visible, known, or desirable.

Some affordances are yet to be discovered. Some are dangerous. I suspect that none of us know all the affordances of even everyday objects.

So in psychology, where the term originated, affordances are all actions that are physically possible on an object or environment: what the environment offers or furnishes (“affords”) the person or animal. Norman expanded his use of the term with “perceived affordances”

The concept [of affordances] has caught on, but not always with true understanding. Part of the blame lies with me: I should have used the term “perceived affordance,” for in design, we care much more about what the user perceives than what is actually true. What the designer cares about is whether the user perceives that some action is possible (or in the case of perceived non-affordances, not possible).

He defines constraints/conventions as follows:

In graphical design, one is really talking about conventions, or what I called logical and cultural “constraints” in POET. Physical constraints are closely related to real affordances: Thus, it is not possible to move the cursor outside the screen: this is a physical constraint.

Logical constraints use reasoning to determine the alternatives. Thus, if we ask the user to click on 5 locations and only 4 are immediately visible; the person knows, logically, that there is still location left.

Cultural constraints are learned conventions that are shared by a cultural group. The fact that the graphic on the right hand side of a display is a “scroll bar” and that one should move the cursor to it, hold down a mouse button, and “drag” it downward in order to see objects located below the current visible set (thus causing the image itself to appear to move upwards) — all this is a cultural, learned convention.

This is not bad to start, but I think that separating constraints and conventions is not only useful but critical, as I argue below.

Here’s my (slightly revised) definitions:

A real affordance allows an actor (a person, an animal, a robot) to interact with an object or environment in specific ways.

A perceived affordance is one that a person can sense (with one or more senses) to be conceptually like an affordance, but that may not be really there.

Perceived affordances can be generally identified because they are not congruent across all senses. For example, buttons are sometimes drawn to create the appearance of volume, and therefore create a visual affordance that is not matched by the sense of touch.

Affordance v Constraint v Convention

First, an example that I think shows all three :

Let’s try to find examples of each in the picture above:

  • Affordance: the handle, which with its shape, size and location (which we presume to be roughly at waist-height) it suggests a relationship between it and the hand of a standing person. A downside: it seems that the handle is too close to the door, probably for aesthetic reasons, but that could make it difficult to use for someone with big hands or some affliction (like arthritis).
  • Constraint: the left frame, which blocks and prevents the door from moving forward. This is actually great design since the visibility of the constraint immediately informs the person that they should push, not pull.
  • Convention: We assume that the handle rotates clockwise and should therefore be pushed downwards. That’s convention. However, purely from observation we can’t say with certainty whether that’s the case here. If it did rotate clockwise in this case then it makes that particular door handle pretty well designed.

Sometimes software relies entirely on one of these attributes. For example, consider the “Apple menu:”

The Apple menu is understandable only by convention. It’s has no constraints or affordances. While there are many ways to shut down macOS, the most direct for a non-technical user, outside of pressing the power button on the machine, is in one of the options in the Apple menu. Someone using the menus would probably discover the Apple menu quickly, but if you gave a macOS machine to a person that had never seen one and told them to “turn it off without pressing a hardware button” there is nothing except cultural convention to guide them to the Apple menu.

Good design relies on all three

Good design not only makes it easy to perceive an interpret controls to allow an actor to perform certain action, it also leads to discovery of the desired actions and discourages undesired actions.

An effective combination and use of affordances, constraints and conventions go hand in hand with good designs. Taking all of these factors into account is a pretty good step in the road to better design.

--

--

Diego Doval

Avid reader, occasional writer. Drexel CS Alum, Trinity College Dublin PhD CS. Previously CTO & CPO at Ning, Inc. Now building n3xt! (http://bit.ly/whatsn3xt)