An elevator UX

This is a (very bad) picture I took with my phone, in the elevator of a modern looking-IT company hosting building.  Not being used to disruption in the rather bland world of elevator UX, I was struck by this “innovative” design.

The picture shows the various buttons allowing you to select the floor you want to go to. I can see the benefit of this in comparison of the more traditional “one-button-per-floor” design, at least for the company providing it: no more specific order (“Yes, our building has two underground levels, then the ground floor start at “2”), no more specific on-site work, the command panel is the same for everyone (after all, using this, you can select any possible floor on any building!), just have to put it in place, the rest is software.

And this “genericity” is precisely what is making it awful for its users for various reasons.

Genericity failure

Missing information

As an elevator user, what I want to know is on which floor is the company I’m visiting, and having this information right near the button makes it easy. No chance here, and although you could get it on a separate panel, it is not the place you’ll look at first.

Go where no man ever did

Nice, I can go to the 9th floor! Except the building was only 5 floor high, so half of this panel is actually not useful in this elevator. Actually, I can use this to go to the 666th floor !

Speaking of invalid commands

This “.” really puzzles me. It looks very useful to go to floor 1.1, or better yet, to floor 3.141592. A pity that architects do not yet use real numbers to define building floors.

Generic feedback

With so many possibilities to issue non application commands, the constructor had the wisdom to include feedback, in the form of the screen showing the current floor using a seven-segment display that cleverly shows an inverted E for any command deemed invalid (it should be sufficient for anyone to understand his error).

Conclusion

I’m probably stretching the experience somewhat too far, but this little funny experience made me think about genericity in UX by confronting me as a user to a situation where it was clearly misused.

We’ve all heard, talked and tried to apply as much genericity to our UI code as possible (creating reusable components to DRY, offering a library of standard widget in the context of enterprise applications, etc). One of my current coworkers even professes that every developer seems to follow the cycle : “dirty-do it myself code” to “code taking in account all possible evolutions (except the one that will happen)” to being somewhat more pragmatic in the approach.

Do not misunderstand me: the value of DRY and reusable components is real - it wins you time, time that you can use to deliver business value to your customer, but it cannot be done at the expense of the customer experience.