An “affordance” is an element of a design which suggests to the user how to use or operate an object. For example, the handle of a teapot suggests how to grab the teapot to lift it; a doorknob suggests a means to opening a closed door.
Affordances are inherently cultural: an amazonian tribesman who has never visited the modern world may need help discovering how to open a closed door. But affordances that work well are common: once he learns how to open one door he should be able to open all doors–even those with slightly different affordances. (A lever rather than a knob, for example, so long as it is located where the knob would be located.)
Because they are cultural, like all cultural things we take them for granted: we don’t recognize that, for example, there are multiple different ways to latch a closed door and an accident of history could have us reaching down for the floor latch to unlatch a door, rather than rotating a knob or lever.
Design failures are those where affordances are not clearly discoverable or which follow the design language we’ve learned. For example, if one were to design a door with a latch at the floor, and no knob or push plate, how long would it take you to discover the thing closing the door was a latch at the floor rather than a knob at waist height? Probably a few moments and you’d probably be very frustrated.
Now unlike the physical world, where there really are only so many interactions you can have to open a door or a window or lift a teapot from a hot surface, the software world is completely abstract. There are no limits, really, on what you display or how you interact with that display. In custom installations (such as in your car or at a kiosk), you can literally use any hardware interaction you like: the BMW iDrive system, for example, uses a rotary knob that can be pushed around like a joystick and depressed, as well as two separate buttons. Modern touch screens make it possible to tap with multiple fingers and tap, press and hold, tap and drag, or any combination of those motions.
And because affordances are, in some sense, cultural (there is no reason why a door knob is at waist level except custom, for example), affordances become part of a “design language”–a means of representing things on a screen that say “I can be touched” or “I can be clicked” or “This is how you back up a level on the screens.”
A well designed set of affordances as part of a well designed visual language can do three things:
They can provide a way for users to quickly discover how to use your interface, thus reducing user frustration. (A common ‘back’ button to back up from a modal display in a car would make it easier on a driver who may be operating the car’s systems while driving down the road at 70 miles/hour.)
They simplify the design of a new application. A common visual design language makes it easier for designers and developers to follow a common design language by essentially following a short recipe book of design objects and design attributes.
They simply user interface development, by allowing software developers to design common control elements which embody these design elements. For example, if all action buttons look the same, a developer could write a single action button class (or use one provided by the UI framework), thus saving himself the task of building separate buttons for each screen of the application.
Likewise, a poorly executed design visual language creates problems for each of these items above: it can increase user frustration as none of the elements of an app (or multiple apps on the same system) work enough the same for the user to know what is happening. They complicate designers who feel free to design each page of an app separately, and who may not follow similar design patterns. They increase the workload on developers who cannot use common controls or common design elements in the application.
The most frustrating part to me is that at some level the computer software industry has come to consider these three failures features rather than bugs: a lack of a common design language allows elements of the application to be partitioned across different teams without having to worry about those teams needing to communicate. And at some level some users have come to believe some level of difficulty in using an application is a feature; a list of hurdles to overcome in order to become an “expert” on a product.
Though why one must become an “expert” to use a poorly designed radio function embedded in a car computer boggles my mind.
One of the most serious problems I have with Apple’s iOS design guidelines is twofold.
First, while Apple’s section on UI elements is rather complete in describing each of the built-in controls provided by iOS, it provides no unifying theory behind those controls which give any suggestion to designers seeking to design custom controls how to proceed.
For example, there is no unified theory as to how tap-able items should stand out that says to the user “I can be tapped on.”
As it turns out that’s because there is no unified theory: along the top and bottom of the screen controls are tappable based solely on their placement. For example, a tab bar at the bottom assumes all icons are tappable and represents switching to a different tab, at the top of a navigation bar the words on the left and right corners are tappable; the left generally takes you back a level and the right generally represents an action appropriate to the screen you are looking at. Tappable areas in an alert view are suggested by a gray hairline breaking the alert box into sections, and often (but not always) icons suggest tappability.
Second, the only suggestion Apple provided for custom controls is to “Consider choosing a key color to indicate interactivity and state,” and “Avoid using the same color in both interactive and noninteractive elements.”
In other words, the only design affordance Apple talks about is using color to indicate interactivity: a colored word may indicate a verb for an action, a colored icon may indicate a control that can be tapped on.
Which, in my opinion, directly conflicts with: “Be aware of color blindness.”
My own rule of thumb, by the way, is that if the affordances of your application cannot be discovered when your interface is rendered in black and white, then they cannot be discovered by people who are color blind.
Color, in other words, is a terrible affordance.
Google, apparently, is trying to resolve this by proposing a different user interface paradigm of “material.”
Many of the suggestions seem a little whacky (such as the idea that larger objects should animate more slowly as if they have greater mass), but the underlying theory of using shadows and hairlines to subtly indicate components of a user interface goes a long way towards solving the problem with affordances on a touch display.
(Which is why the idea that material can “heal itself” bothers me, because if an item is separate and can be moved, it should be represented as a separate object.)
Which is why I’ve taken the time to write this long blog post: because at least Google is trying to create a unified theory behind its user interface choices, and that suggests that Google may be heading in a completely different direction than Apple when it comes to user design.
In other words, Apple appears to be headed towards using the design elements of book design (typography, color, subtle use of shapes and typeface that may change from product to product) to suggest functionality, while Google is taking a more traditional HIG approach of creating an underlying unified theory as to what it is we’re manipulating, then building the basic building blocks off of this.
So, for example, a table cell in a table with a detail button may look like this on Apple’s iOS devices, but on Google the theory of “material” suggests we may separate the individual rows and separate out the right part of the each table to form a separate pane which is clickable:
And while the design on the right, the Google “material” style looks considerably busier than the design on the left, functionality makes itself extremely apparent rather quickly.
It’s also, in a sense, far easier to design: icons do not need to be designed to differentiate a ‘verb’ action button from a status icon. Components can be separated out so that they are obviously clickable by simply bordering the control appropriately. Actions can be made apparent on the screen.
And while it is true that it gives rise to what appears to be a more “clunky” screen, the reality is on any mobile device–especially a phone form factor device, the user will be confronted with dozens (or even hundreds) of different screens, each one capturing one bit of information (a single item from a list of choices, for example), and configuring the equivalent of a single dialog box on a desktop machine may involve passing in and out of dozens of different screens on a mobile device.
Quickly being able to design those screens and make their functionality extremely apparent is extremely important, and if you don’t have the aesthetic design sense of a Jonathan Ives, having guide rails that results in some degree of clunkiness may be more desirable to the end user than a design which is completely unusable.
Development Chaos Theory 