John Graham-Cumming's blog: The Elevator Button Problem

2010-06-21

The Elevator Button Problem

User interface design is hard. It's hard because people perceive apparently simple things very differently. For example, take a look at this interface to an elevator:

From flickr

Now imagine the following situation. You are on the third floor of this building and you wish to go to the tenth. The elevator is on the fifth floor and there's an indicator that tells you where it is. Which button do you press?

Most people probably say: "press up" since they want to go up. Not long ago I watched someone do the opposite and questioned them about their behavior. They said: "well the elevator is on the fifth floor and I am on the third, so I want it to come down to me".

Much can be learnt about the design of user interfaces by considering this, apparently, simple interface. If you think about the elevator button problem you'll find that something so simple has hidden depths. How do people learn about elevator calling? What's the right amount of information to present to people? Do people need to know where the elevator is, or just that it's coming? Are up and down buttons necessary? What about having a single call button?

1. I don't know how I learnt that the correct thing to do was press the button indicating the direction I wished to travel. It's sort of elevator folk wisdom. Somehow you learn through experience or an elder passing on the knowledge. I've never actually seen an elevator with instructions. Have you?

So, it's quite natural that some people won't have learnt the user interface of an elevator. If you're designing a user interface it's worth stopping and pondering the things you assume 'everyone knows' about it.

2. The information about the current floor the elevator is on actually presents a problem for the caller. It's additional information that the person I interrogated assumed was needed to make a decision. Sometimes extraneous information takes on an importance all of its own. Here the user was assuming that you needed to know where the elevator was.

Actually all you need to know is that the elevator system has responded to your request and an elevator is coming.

3. Another oddity is that you call the elevator with up and down buttons (indicating a travel preference) and then get in the elevator and press a button. There's nothing to stop you contradicting yourself by indicating a different direction of travel. Which makes you wonder why you had to indicate the direction in the first place.

Typically, you have to tell the elevator your direction because an arriving elevator may already have people in it who have already instructed it to go to a certain floor. Thus the elevator is going up or down. If you register your request then the elevator can tell you whether it can meet that request.

One interface optimization would be to replace the up and down with a single call button. Passing elevators would stop and indicate which direction they were traveling. This simplifies the interface while placing a burden on the system which will perform wasteful stops for people who want to travel in the opposite direction. Here's where UI and internal system dynamics trade-off. A UI decision might actually make the system less efficient.

PS Of course, you can do away with buttons altogether and just have a Paternoster. I used to love riding in one in the engineering building in Oxford.

at

June 21, 2010

Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest

Labels:<br>pseudo-randomness

55 comments:

The Lorax<br>said...

Well done, you've hit it exactly.

Here's a similar example that bothers me. This shows up in various GUIs. A two position control, say, On and Off for some feature. There can be two levels of ambiguity. First, most heinous, is that sometimes they draw them in a way you can't actually tell which position the control is in. The old Palm interface was like that. Half black, half white, but without reference you didn't know which was which. This can be cured by smarter graphics. The second ambiguity would be does this switch represent the current state of the feature, or my desired state? This can be cured by clarifying the context.

3:49 AM

said...

Apparently this person didn't realize that on the first floor, the only button is "up". That wouldn't make sense if the button specified the direction to where you are now rather than where you want to go.

3:54 AM

Max Lybbert<br>said...

We didn't do this exercise in my programming classes, but I understand that if an elevator only goes to the closest floor that somebody called it from then people on the highest and lowest floors suffer from starvation -- i.e., they never get to see the elevator because it's busy servicing requests from the central floors.

Not that it's impossible to fix this. I would, however, consider it an improvement if you chose your floor as the way to call the elevator. Like the original post said, it's...