Everyday UI Critique: Elevators
Elevators should be very straightforward to use: you push a button, go in, select the floor you want to go up to, wait for a few minutes, and walk out. However, the user relies on numerous affordances and identifiers to be confident in the smooth execution of this sequence of events. For instance, a common affordance that manufacturers provide to notify the user that their input floor has been received by the system is an LED light surrounding the buttons — when you push a button, the light goes on, and when the floor is reached, it turns off. This is a small detail, but it can have a noticeable effect if it’s absent.
When I use an elevator with said LED, I can push the button and relax until I reach my destination. However, if there is no such feedback provided, I first wait for the elevator doors to close, then I wait to see (in anticipation) whether the elevator will go up or not; if it does go up successfully, I then need to be alert to make sure I get off on the right floor and not some other floor the elevator was called to. Overall, the absence of something as small as a light notifier could result in an unpleasant experience. This example is intended to illustrate the importance of feedback.
The picture to the left is that of an elevator on campus. It looks like a normal elevator, with the addition of a card swiper. The swiper is an indicator that some floors are secured, whereas others are open to the public. However, which floors are the secured ones? The only way to find out is through trial and error. Additionally, if the user attempts to go to a secured floor, the LED light surrounding the button will turn on momentarily before turning back off. If the user has never been in the elevator before, what information is this supposed to provide? Does the fact that the light went on mean that the system has received the user input? Is the fact that it just blinked an indicator of a hardware issue? When I attempted to reach a floor that I thought I had access to, but was in fact secured, my first instinct was to try pushing the button one or two more times; it was only after the elevator doors opened and closed twice on me that it sunk it that I was trying to access a secured floor.
Granted, I might not have been in the best shape, but the product is supposed to provide this kind of information to the user clearly and immediately. That is my criteria for a good design. This product does not meet those criteria. Perhaps it’s because the floor restriction was added after the implementation of the elevator. Regardless, because of the lack of indicators and immediate feedback, the efficiency is low, as it takes time for the user to realize they’ve made a mistake, and react to it accordingly; memorability is also low because there is no guarantee that the same floors stay secured (as I've come to experience); learnability is high, because once it has been learned that a blinking light indicates a secure floor, it sticks; affordances are also clear — you need to swipe your card through the reader before you can access the secure floor, at which point when you push the button the LED light behaves like normal (i.e. remains lit until the target floor is reached).
The easiest modification that could be made is as simple as the addition of a warning notice stating which floors are secured (bottom left image). Alternatively, a slightly more complex solution for the manufacturer could be the addition of another set of small LED lights next to the floor buttons, with an icon of a padlock next to them (bottom middle), or the LED lights would surround the buttons(bottom right): a light on would indicate that the floor is secured, and a light off would indicate that it’s not. This would allow for custom configuration both within the same building (which is not a scenario likely to be occurring frequently) and from building to building (i.e. the manufacturer can sell the same model to multiple different buyers).
