I’m not sure if it was the shape of the handle, the side of the door it was on or some other kind of standardization issue described perhaps in a Chicago building code somewhere. But when anyone got off the elevator and walked down the hall toward my employer’s office and neglected to read the little sign above the handle, they invariably tried to pull the door open instead of push it open, as the sign suggested. Problem was, you couldn’t pull it open, you could only push it open. My desk was very near this door and every day I’d see frustrated faces wincing outside this mostly glass door. Faces that were attached to heads that had almost certainly learned to read at some point and that suddenly filled up with self reproach when they realized their error. What I and other UX professionals of course realize is that quite literally, these heads weren’t wrong, the door was. Indeed the only wrong-headedness to blame in this case was the engineer who thought he could solve this problem with a little sign instead of re-installing the door.
Why?
Because while primitive, the simple doorknob is a user interface. People use it to interface with the door. And like all UI’s, its success must be judged by the soundness of the user experience principles that guided its creation. And in effective UX, user expectation trumps labeling every day of the week and twice on Sunday.
No disrespect to all you copywriters out there, but in many situations what you write just plain doesn’t matter. If a motorist encounters a red octagonal sign at the next intersection, she is going to stop even if the sign says speed up.
The same goes for software. When users repeatedly encounter the same flow of experiences on multiple Web-sites, that paradigm becomes enshrined in their minds as one that will always unfold in more-or-less the same way. Which is why you wouldn’t just charge someone’s credit card to complete the purchase on an e-commerce site if all he did was add an item to his shopping cart. Even if you labeled it, your help desk would still be fielding calls every day from angry customers who accidentally bought something and wanted their money back.
No one in charge of your interface is going to make a mistake this obvious. But if you think you can just let the one Photoshop enthusiast on your development team create your interface and hope you can label your way out of any resulting usability issue, consider this recent lesson in the power of user expectation:
Just last month Coca-Cola decided it might be a good idea to ring in the holiday season by temporarily changing the color of their regular Coke cans from red to white, effectively reversing the color scheme from white lettering on red to red lettering on white. Only problem is they’d already done this for Diet Coke a long time ago. When consumers started complaining they’d bought regular Coke in the new packaging thinking they were buying Diet Coke, Coca-Cola ended up having to scramble to address the outcry. Even though it said ‘Coca-Cola’ right on the can, the color-scheme trumped conscious, deliberate thought. Again, the labeling was moot.
The real-life examples in your development cycle will never be this obvious, they’ll be subtle and they’ll seem trifling or worse, invisible. And that’s really the point. You won’t see them coming. An experienced UX professional will, though, and when he or she suggests re-working the flow and your lead developer complains the problem can be resolved with a little verbiage, be very, very careful whose counsel you heed.
