4 - Knowing What to Do

Consider this: how do you attempt to use a device you have never seen before to accomplish a goal? You begin by using a theoretical model of the actions that must be taken to accomplish your goal and then inspecting the device for visible signs that match the task. Or in smaller words, it's figuring out how the device does the things I want it to do.

(EN: No example is provided, but I imagine that on approaching a photocopier, I assume that I put the original document in somewhere, a copy comes out somewhere, and my original is returned to me somewhere. I look to the device for a slot or place to "feed" it, then a button to make it work, then the place the copy comes out.)

This chapter will focus on the device, and the way in which designers must provide clues to a person who needs to know how the device operates, and what things he must do to make it do what he wants.

He mentions the example of a Lego set: there is a picture on the box of the outcome and a bunch of pieces inside that must be assembled. The shape of the bricks and the way pegs fit into holes give the user an idea of how they fit together. The picture on the box, which shows the assembled product, provides clues that indicate a piece of a given color and shape must be fitted to another in order to form part of the outcome. Without step-by-step instructions, most children can figure out how to build the model - and in this instance figuring it out is a kind of puzzle that makes the experience fun - provided the user can succeed.

He mentioned doing an experiment that involved providing the parts without the picture, and even then most people were able to assemble it without difficulty. The visible affordances of pegs and holes, the constraints of certain pieces that could only be fit together at a specific angle, etc. all gave the users sufficient information to do the task, without instructions or a picture of the final outcome.

(EN: an interesting adjustment would be to take out a few of the necessary parts or drop in a few extras. The emotional reaction would not be positive - and might be strongly negative.)

(EN: Another thing worth noting is that the notion of "gamification" is over-hyped in design. Putting together a puzzle is an interesting diversion and people accept the trial and error process. But if getting money out of an ATM requires trial and error, it's less amusing - it's a task with a specific end, and one that can have financial consequences. People are less amused when a task has a purpose and they have limited time to get it done.)

Four Kinds of Constraints: Physical, Cultural, Semantic, and Logical

Constraints are obstacles to doing things the wrong way, which guide us to the correct path by blocking off the ones that are incorrect. The author suggests four categories, which he means to describe in detail

Physical Constraints

Consider the Lego example: a physical constraint of Lego pieces is that the pegs and holes must be fitted together in a certain way in order for the pieces to lock together. If you lay one piece diagonally on top of another, they cannot be pressed together. This is a physical constraint.

Physical constraints are tangible and rely upon properties of the physical world, and no special training or advanced knowledge is needed to do things the right way when there are physical constraints that prevent it from being done otherwise. (EN: which is mostly true, but even if you block off every wrong option, the user generally has one of his own - to give up and walk away. This happens a lot when it is too difficult to figure out how to do something right.)

The author gives the example of batteries. The typical cylinder shape is not a sufficient constraint from being able to insert it upside-down into a device. But consider the nine-volt battery, which cannot be snapped into place unless it is oriented the right way. Electric plugs are the same way - until they discovered and standardized a format that made one prong slightly larger than the other, people were plugging in devices backward, and in some cases the crossed wiring damaged the device, but the three-prong plug can only be inserted one way into an outlet.

Cultural Constraints

Each culture has a set of allowable and expected actions in social situations, which often becomes clear when encountering someone from a different culture. We know how to behave in a restaurant - what is expected and what is unacceptable - and tend to follow these constraints when we enter one that we have not visited before. (EN: Said another way, cultural constraints are not like physical ones in that they are not really constraints, but merely habits.)

Devices are built to accommodate cultural norms. Consider, for example, that most devices are designed to be operated using the right hand - even though the prejudice against the left side of the body is no longer actively promoted, it remains. Think not? Consider that the flush handles on are typically located on the left - to be operated by the left (unclean) hand rather than the right (clean) one.

It's also been mentioned previously that the concept of "start on the left, move to the right" is a convention in cultures whose writing systems read from left to right - the opposite is true of cultures whose writing systems read from right to left.

It's finally noted that because cultural behaviors are matters of custom, they can change over time.

Semantic Constraints

Semantic constraints are suggestions that can be interpreted from a device - which should seem meaningful and sensible to a user who pauses a moment to consider what he will be doing with the device.

If you know only that a motorcycle is a transportation device for carrying one user, you can probably figure out where to sit upon it because the seat is padded. The arrangement of gauges, handlebars, and windshield should give you a clue as to which way you should be facing. There is no physical barrier to sitting on the gas tank and facing backward, but just by looking at the device and knowing its purpose should enable a person to recognize that is not going to be productive.

(EN: I find it curious that this is listed as a constraint rather than a signifier, but perhaps the distinction will be clear later.)

Logical Constraints

There's a brief indication of logical constraints, as things that signal a person that something has been done correctly (or incorrectly). For example, when you put together an item that has to be assembled and there are parts left over, this is a logical indication that you probably did something wrong.

(EN: Again, it seems a bit of a stretch to classify this as a constraint, as the user is not prevented from doing things correctly, and may conclude that the manufacturer included some spare parts.)

Applying Affordances, Signifiers, and Constraints to Everyday Objects

Any object that is fabricated is designed to have capabilities and means of accessing them. When making something as simple as a knife, the producer knows that there must be an edge for cutting and a way in which it can be held.

It cannot (or should not) be assumed that the user of a device has the same idea as its designer, and will naturally recognize what it does and how to make it do that thing. Sometimes this is true, but most of the time it is not.

And so the designer and producer of an item must consider the way in which users approach the object to ensure those two crucial bits of information are communicated.


The author began the book talking about doors - and how something as simple as a door that needs to be pushed to open it can confound people when it doesn't look like a door at all and gives them no indication of how it might be opened.

It would seem that there's nothing more simple, but designers insist on making it complicated. There are doors that must be pulled or slid sideways to open them. Others have foot pedals, buttons, pressure plates, motion sensors, or any of an array of devices to make them "easier" to open. Still others have devices in place to keep the door shut when not in use, which adds difficulty in opening them (most commonly, turn a knob clockwise to retract a metal tongue that holds the door in place when closed). And others are designed to prevent access by unauthorized persons, requiring those who are authorized to learn to bypass the technology that holds the door closed (to use a key or swipe a badge).

The author mentions the doors on automobiles: the outside door handles are excellent examples of design, but the inside door handles are quite rotten. On the outside, horizontal slits "guide the hand into a pulling position" such that it is very intuitive to reach into the groove, grip the handle with the fingertips, and pull - the same pulling motion that lifts the handle is continued to open the door. On the insider, most vehicles require the user to pull a small, flimsy lever, such that the door comes slightly ajar, then release the lever and grip a handle that is used to pull the door shut, only to push against it to open the door. It's an awkward double-motion that defies common sense.

He also considers kitchen cabinets to be the bane of human existence, particularly when designers attempt to craft a smooth appearance and avoid having any knobs or handles: to open a cabinet that pulls outward, you must first push it, then release it - in a place that has no signifier - so that a spring-loaded device will pop the cabinet slightly open, at which point you must wedge your fingers into the crack and pull the door open. He's also right miffed by drain plugs that are opened by being pressed. It's particularly disgusting to reach into a sink full of dirty water to press down on the drain.

It's a bit worse for travelers. In most subway systems, the doors open automatically at each station, but in Paris you must press a button to open a door when it reaches the station. Visitors will often stand in front of the doors waiting for them to open, and miss their station. It gets worse, because the Paris subway is a mishmash of cars from different eras. Some require you to press a button, others require you to press down a level, and others must be manually slided open.


The author has spoken in a number of auditoriums, and comments that the lighting system is always a tragedy. Whether it's a panel of mechanical levers in the backstage or a control booth with all manner of switches, dials, and sliders, it always seems to be quite a problem simply to switch on the lights.

He speculates that the main difficulty in flying an airplane is the time it takes to learn what all the various switches do. It's not that the average person can't fathom the mechanics of flight, but simply cannot find the switch to turn the engines on.

The trouble is not in knowing how to operate a switch - as most people do fairly well with turning on the lights as they enter a room at home. But when there are two or more of them, knowing which switch to flip can become confusing. Beside the main door to many homes is a panel of four to six switches: the inside light, the porch light, and various lights in the front yard. He mentions a house that had a vertical column of six identical switches and no indication of what they controlled. He complained to his architect, who brushed him off with "you will get used to it." He never did.

Part of the issue, particularly with electrical work, is that switches are not placed with the needs of the homeowner in mind, but for the convenience of the electrician who installs them: to make efficient use of wire, to use standardized components. No-one pauses to think of where a person might be standing when he wants to turn on a light, or how the switches in a given location might make better sense to him. He mentions needling the CEO of a company who manufactures switches for "smart" homes - and who was decidedly indifferent to the issue of the homeowner's convenience.

He also mentions that in the present day, it should not matter. Wireless technology would seem to make the notion of physical switches obsolete - there need not be a hard-wired switch because commands can be sent via remote control from a switch located anywhere in the room. Or a switch could be connected to an existing device (using your smartphone to turn on lights in your home, from any room, or even from outside). It may take considerable time before this is adopted.

He speculates about things such as lights that run on infrared sensors, or can be bumped with an elbow if your hands are full, or camera systems that enable a person to use gestures to merely point at the light he wishes to turn on.


He stumbles on the notion of multi-purpose areas. For example an auditorium isn't designed just for one person speaking at a podium, as sometimes the space is used for a film or theatrical performance, or the chairs may be moved out of the way so the room may be used for an activity.

In those instance, a spatial mapping of the switching systems is less valuable than an activity-centered control. He mentioned that "many" auditoriums that have computer-based controls have default settings such as 'video" or "lecture" that can, at a click, change the lighting to be appropriate to the activity. Unfortunately, these are often done badly, such that the operator may begin with one of those settings, but then adjust the lights and sounds to overcome the shortcomings of the design.

There's also the problem of things that don't go exactly as planned - the lighting changes in a theater cannot be fully automated because the actors may get through their lines a little slower or faster from one performance to the next. He also mentioned a talk he gave in which he wanted to interrupt a video clip to provide commentary - but switching the venue from lecture to video not only changed the lighting but retracted the screen and switched off the projector, making it clumsy and inconvenient to make the change from one to another.

Constraints That Force the Desired Behavior

Some engineers wish to employee constraints to control the user - to attempt to get the user to do what the engineer wishes them to do, rather than accommodating their natural behavior. In general, it is a very bad practice to "force" the user to do something in order to operate the device - there should be a reason other than the engineer's indifference or incompetence to compel the user to do something in a specific manner, particularly when it seems unnecessary or unintuitive.

Security is one common reason for forcing the user to do something. There is no reason that a person should have to place a key in a slot to start an engine - but to prevent vehicles from being stolen, this artificial constraint has been added so that only the driver, or someone to whom he has presumably given his key, will be able to start the car.

Safety is a second reason for forcing behavior. Keeping to the automotive metaphor, it's likely a good thing to prevent a driver from shifting his vehicle into drive unless his foot is on the brake pedal, to prevent the vehicle from lurching forward unexpectedly. "Safety" may include not only damage to a person, but damage to the equipment.

Whatever the excuse, there are three basic methods for constraining user behavior: interlock, lock in, and lock out, which the author means to discuss. (EN: These three categories are poorly conceived, or at least poorly described in the sections that follow. In all instances it is a method of preventing a person from taking an action unless they, or someone else, does something else first.)


An interlock requires the user to do one thing before doing another. For example, the door of a microwave oven is generally rigged to ensure that the user turns off the oven (disengage the electromagnet that heats the contents) before they are able to open the door.

The "dead man's switch" in industrial equipment functions the same way: the user must stand on a pressure plate to start a forklift, and if weight is removed from the plate the lift will disengage the engine and lock the brakes. This is also incorporated into residential machines, such as lawn mowers that require the user to maintain pressure on a lever to rotate the blades.


A lock-in function is used to prevent someone from prematurely stopping a process. A common example is the function that brings up a dialog when a person closes a window on a computer, to ask them if they are sure they wanted to do so (because the content of the window will be lost - be it a web page they were viewing or a document they have not yet saved). It's observed that these lock-ins are so common that they have coached users to save before closing a window to avoid being nagged.

(EN: It's worth nothing that lock-ins are by their nature a nuisance, and if the user sees no value in it he will seek a way to disable it. And worse, he may become trained to ignore other dialogues that provide actual value.)

A few more examples follow:

He cites a specific lock in device that he finds to be particularly clever - a spring-loaded shelf in a toilet stall that blocks the door from being opened. The user ahs to remove their package or handbag from the shelf to open the door, minimizing the risk that they will forget their items when they leave.


A lockout prevents a person from doing something, such as the lock on an electrical panel that prevents unauthorized people from accessing the electric switches. The author also mentions physical doors that prevent people from entering a space.

(EN: At this point there is some ambiguity as to whether something is a lock-in or a lock-out. It seems largely a matter of perspective - whether a deadman's switch locks the operator into a position or locks anyone who is not in that position out of operating the controls is a matter of perspective.)

Some random examples:

The design of a lock-out is a delicate matter. Making a door secure against unauthorized entry entails making it difficult for unauthorized personnel to enter a space - and if they find it too difficult, they may simply prop the door open, defeating the value of the device to prevent unauthorized access.

(EN: More confusion. These examples seem like interlocks because they do not really prevent an action from being taken - they merely require one action to be taken before another.)

Conventions, Constraints, and Affordances

Earlier in the book, the author spoke of affordance - which are "handles" that provide the user with an ability to interact with a device. However, the fact that something is an affordance does not mean that the user will recognize it as such - he may not recognize that it is a button that is meant to be pressed, or even if he recognizes that it can be pressed he does not immediately see what will be accomplished by pressing it.

When there is any confusion, the designer can implement a signifier that tells him what to do and what his action will cause - but in some instances this is not necessary because the user's perception and expectation of an affordance can be predicted with some degree of accuracy. The reason for this is that there are certain conventions that users can be expected to recognize without the need to be told.

A doorknob is a basic example of a convention. There is nothing about the round, metal protrusion that indicates what it is or what should be done with it - and it is only because people have learned to recognize and use doorknobs (in early childhood, in their own home) that they can be implemented without an accompanying panel instructing people how to use them.

(EN: An interesting and somewhat comical example of this is when pets learn to use affordances. They see their master open the door to the pantry and somehow manage to work out how work the knob with paws and teeth to gain access to the food inside. The point being, even animals can learn conventions.)


Conventions are learned behaviors, and they are learned in the context of a given culture. Culture affects our daily actions: the way we eat, the clothing we wear, the way we speak to other people, and even the way we enter or exit a room. Conventions are not a matter of functional ability, but are what is considered to be proper or improper, polite or rude, in a given culture.

An individual is generally inclined to follow the conventions of their culture unless it becomes clear to them that it is inappropriate to do so (EN: it must not merely be "inappropriate" but improper or offensive enough to cause them to recognize the need to deviate). Even in entirely new and unfamiliar situations, people will attempt to apply cultural conventions that are similar to the situation in which they find themselves.

Consider that human beings have not shed their cultural conventions when dealing with technology as old as the telephone. Watching people in a phone booth, when such things existed, could be amusing because they would gesture and make facial expressions as if they were speaking to a person who was present. The same can be seen with cell-phone users in the modern day, and particularly amusing when they are using a hands-free headset: until you notice the earpiece, they seem like raving lunatics having conversations with imaginary people.


A particular problem arises when designers decide to violate conventions - either because of new capabilities of a device, engineering limitations, or simply to be quirky. In essence, people assume that a device of a given type all work the same way, and the introduction of a new convention or violation of a previous one confounds them, because their experience and cultural learning are derived from other devices, which have coached them to adopt a given mental model and set of behaviors that do not apply to this new or unusual device.

There's an extended case-study of elevators to demonstrate this point.

The first elevators had human operators who operated the machinery: a user would enter the elevator, greet the operator, and announce the desired floor - much like a vertical taxicab. When human operators were eliminated, a grid of buttons was used to indicate the floor. Pushing a button was a simple substitute for speaking a number.

In 1985, a designer got cute: figuring that the elevator bank in a building can operate more efficiently if the system was aware of which floor a person intended to travel to, the cars could be operated more efficiently - saving wear on the machinery and enabling buildings to operate with fewer elevator cars. And so, he placed the keypads for the desired destination on each floor, outside the elevator, with no keypads inside the elevators.

This did not go over well at all. When people are going to different floors, some up and some down, they have no way of knowing if the elevator that stopped is responding to their call or someone else's. Passengers were not comfortable with the lack of control inside the box - even though changing one's mind after pressing a floor is rare, being "trapped" inside an elevator is a common fear and having controls and indicators alleviate that anxiety.

Granted, the designer built in signifiers (the light for the floors would be highlighted on the panel when the lift arrived) and counted on people to figure out how to error-correct (if you make the wrong choice, get off the elevator and try again) - and while the system seems sensible enough, people were acculturated to elevators that work a specific way.


It's been observed, and rightly so, that the first reaction people have to any change in a convention is to complain - they blame the device, and rightly so, for making them learn something different or special. The merits of the new system are irrelevant to their initial emotional reaction.

The authors look to the metric system, which Americans stubbornly refuse to adopt. In spite of the fact that it makes measurements easier to calculate by virtue of being base-ten, people are simply used to thinking in terms of the conventional weights and measures they are used to seeing.

(EN: The author, and most enthusiasts of conversion to metric, totally misses the point: it's not about calculating the numbers, but knowing what they mean when there is a practical need. I know how long it takes me to walk seven miles, can add a half-teaspoon of salt without measuring, and that if it's under sixty degrees I might need a jacket. I would need to do some calculations to figure out how long it will take to walk seven kilometers, would need a measuring spoon to add three milliliters of salt, would have to convert Celsius to Fahrenheit to know whether to bring a jacket. Granted, I would likely learn to make these assessments in time, and become as fluent in one as the other, but I would waste time and make a lot of stupid and potentially costly mistakes during the process.)

The Faucet: A Case History of Design

The author mentions a conference he attended in which participants were lodged in a dormitory at a local university, which had printed up a helpful flier with information about meals, local attractions, and instructions on how to use the taps in the bathroom. Why should that be necessary? The taps themselves had the normal handles, which people turn to increase the flow of water - but turning them did nothing. The user has to push them down into the pipes to turn on the water, adjusting them to just the right vertical height to get the temperature desired.

He muses about faucets for a while, as the device does two things: it adjusts the temperature of the water and the rate of flow.

Fortunately, there are some fairly standard conventions that the cold water is on the right and hot is on the left, and that turning something clockwise opens it and turning it counterclockwise closes it. But nothing is universal. There is certainly someplace where the hot is on the right, and turning counterclockwise opens it.

Between inconsiderate engineering and precocious design, anything is possible.

He also mentions that there is a feedback problem with taps in general. There is no way to tell in advance how far to turn the taps to get the temperature you want from one faucet to the next, so you must turn the taps first, then test the water with your hand to see if you scald or freeze yourself (which is even more delightful if you're in a shower and the water will spray your whole body), and then use a trial-and-error process to get it right. Not to mention it takes time for the hot water to run at full heat, so you will have to adjust it several seconds later.

And oddly enough, faucet design has become the topic of quite a bit of attention - given that companies such as Moen, Price Pfister, and other firms have done significant television advertising to promote their sleek, elegant, and thoroughly unusable products.

Granted, the standard design of faucets leaves a lot to be desired, and in many instances standardization is the equivalent of a shrug - when a designer can't think of a good way to solve a design problem, just do what everyone else is doing. (EN: From a design perspective, it's the same reason that so many printed documents are in "helvetica" or "arial.")

There's absolutely nothing wrong with using a standard if it works well - but it is a considerable act of cowardice and a dereliction of duty to default to standards in the face of a difficult design problem.

Using Sound as Signifiers

Most of design is focused on the visual sense, but other senses can be brought into play. Sound, for example, is quote common just because of the physical properties of things.

In your everyday life, you are accustomed to the way things sound. There are sounds that you recognize that reassure you that things have gone right (the familiar sound of the lock engaging when you turn the key), or that alert you to things going wrong (your car's engine doesn't sound quite right), or tell you it's time to do something (you hear the sound of the toast popping up). Many of these aren't intentionally designed into the experience, but just happen to occur as a natural consequence of the way things work.

In some instances, sound is designed into an object: a computer's circuit board makes no sound when it has been turned on, but the device has been programmed to play a chime when the power is turned on (to assure the user that, even though he doesn't hear anything from the box, that his command to turn on has been received). Well-designed sounds are reassuring, but poorly-designed ones become a nuisance. Imagine if your refrigerator chimed every ten minutes to reassure you it was still running. Now imagine if every device in your kitchen did the same.

But at the same time, if you have a refrigerator with a motor that constantly hums, you may eventually notice the absence of the noise and become distressed by it. It's "too quiet" and something is not quite right, and you eventually discover that the refrigerator has stopped running.

In many instances, sound is added to a process that has no visible component - when a device sits silently when it ought to be doing something, the user's first inclination is to think that his command was not received.

In general, sounds that indicate an expected condition - a device is running normally, or a command has been received - are smooth and non-distracting. Sounds that indicate that there is a problem, particularly a serious one, should be loud and harsh because their purpose is to distract.

The design of sound is "in its infancy" as most manufacturers simply allow their devices to make the sound that they actually make by virtue of their mechanical operation, and if sound enters the mind of an engineer at all it is to make a machine that runs quietly. (EN: Though in some instances products are modified so that they will "sound" or "feel" right to a user.)


The author mentions working with BMW to design the sound of their electric cars. The electric motors in cars are extremely quiet, and it was found to be a danger to pedestrians, who often listen for the sound of an approaching vehicle rather than looking for oncoming vehicles when they cross a street.

According to the United States National Highway Traffic Safety Administration (NHTSA), pedestrians are "considerably more likely" to be struck by hybrid or electric vehicles than those with a fuel engine, particularly when those vehicles are moving slowly.

Adding sound to warn of a moving vehicle is not new: for many years commercial trucks and construction equipment beep loudly to alert others that the vehicle is backing (as the driver can't see what's behind him) and the horn on a vehicle was originally added to enable the driver to send a warning to others (rather than merely being obnoxious).

Various manufacturers experimented with adding synthetic sounds to vehicles. Some gave their vehicles a high-pitched hum, and still others experimented with sounds like "tweeting birds." The problem with nonstandard sounds is that they are unconventional - a blind person would have to learn that a dozen or more sounds might be associated with an oncoming vehicle. The simple solution, proposed by a panel of blind people, was simply to make them sound like cars with gasoline engines.

The author pauses for a moment on the notion of skeuomorphic design, a notion that comes in and out of fashion: it is the practice of making new designs "slavishly imitate" old technology so that people do not need to learn to use it. The author suggests that this is the reason that early automobiles looked just like horse-drawn carriages (EN: it's actually because the early automobiles were made by carriage-builders who simply added an engine to their design - there was no intention to be "retro"), why plastic is often made to look like wood, folders in computer system look like paper folders, and so on. All of this presumes that people will be fearful of new technology and cling to the old.

The author suggests skeuomorphic design keeps us mired to the past and prevents us from taking advantage of technological capabilities. Moreover, the premise is rather ridiculous: you have likely never seen a simulated rotary dial on a smart phone - people simply learned to use keypads. (EN: I recall seeing a video of some children being given a rotary phone and not being able to figure out to dial it - and finding it ironic that they still use the word "dial" though they have never seen a phone with a dial on it.)

Going back to the electric car example, there is to date no standard and vehicle manufacturers are hiring all manner of experts to help them determine what sound an electric car should make ... or more aptly, what sound it should fake. Government steadfastly refuses to legislate the issue, but has developed a 248-page document that provides "principles" and "requirements" for manufacturers to follow.

It is likely that tens of millions of dollars is going to be spent over a period of decades for everyone to agree on what fake sound should be added to a noiseless vehicle ... largely because people can't remember to look both ways before crossing the street.