The other day I was grabbing a salad and some spring rolls for lunch at an upscale grocery store in Houston. I used my debit card to pay, which is an almost daily exercise for most of us. Entering my PIN and clicking through the screens is such an ingrained habit for me that I probably perform it through pure instinct and muscle memory. Well, I ran into a snag.
Typically, the debit card screens run through the following progression:
- Swipe card.
- Enter pin.
- Do you want cash back? Yes or No. If no...
- Is this amount OK? Yes or No. If yes...
- Voila. I'm done.
This particular store's machines work differently.
- Swipe card.
- Enter PIN.
- Is this amount OK? Yes, No, or Cash Back.
Whaaaaat? I wasn't even paying attention, and I clicked "No" in step 3. Which meant that "No, this amount is not OK." What I intended to say was, "No, I don't want cash back." The machine brought me back to the beginning of the process.
Apparently the machine's GUI designers decided to combine two screens and therefore save their users a click. I didn't save a click, though. I had to start all over.
Consider, please, the Principle of Least Astonishment (POLA), which states that "when two elements of an interface conflict, or are ambiguous, the behaviour should be that which will least surprise the user." So for software GUIs, users form expectations based on their experiences with similar software.
The debit payment interface I encountered is a perfect example of why it's so important for your design to conform to your users' expectations. Saving a click is good practice -- most of the time. But if your GUI's behavior is counter-intuitive to your typical user, you're just going to cause frustration and wasted time.
Resources about POLA
Principle of Least Surprise
Principle of least astonishment
Applying the Rule of Least Surprise
Chapter 11. Interfaces
History of Interface Design on Unix
The cranky user: The Principle of Least Astonishment
Most Astonishing Violation of the Principle of Least Astonishment