While coming to and from a meeting the other day, I rode in an elevator that had this user interface design:
I’m guessing the history of this elevator goes something like this:
- The elevator was designed and delivered with a very straightforward, easy-to-use user interface such as this:
- A new requirement emerged: “We need to support braille!”
- Rather than redesigning the user interface properly, additional design was merely crowbarred into the original design.
- Requirement met. Problem solved. Or was it?
I had the good fortune of watching two other people step on the elevator and try to select their floor. One pushed the braille “button” (perhaps because it was bigger and had more contrast with the background—I don’t know) before realizing that it wasn’t a button at all. A bit flustered (I was staring), she pressed the real button on her second try. Another person who got on at another floor stopped his finger mid-trajectory to analyze his options. He guessed correctly, but not without some careful thought.
I wish I could have observed a person with a visual impairment try to use this elevator. After all, this braille feature was added specifically for them. But how can braille on a button that’s not even a button allow a visually impaired person to select their floor? That’s not just unhelpful; that’s mean. This user interface redesign not only failed to address the needs of those with visual impairments, but it also made the user experience confusing for sighted users.
I realize there are all kinds of costs and barriers to modifying a physical interface such as an elevator’s buttons. However, we don’t have those same barriers with our websites, web apps, and mobile apps. So before you add that cool new feature, make sure you’re implementing it in a way that truly meets a new need and doesn’t create a new problem. As always, user test it to be sure!