Seth Godin doesn't like pull-down menus for U.S. states. He got plenty of mail from people arguing in favor of pull-down menus. And he gives them a sound thrashing:
[H]ere are the reasons, if you insist, on why pull downs for states are silly:
...
5. The biggest reason of all: half or more of all shoppping carts online are abandoned. If this happened at the supermarket, they'd be bankrupt in less than a week. This is a crisis for anyone who sells online (except for Amazon, which doesn't have this problem--because people don't have to see any of this nonsense.) instead of Dilbertly defending the engineering status quo, teams should be working around the clock to test every single thing they can to fix the problem. [Emphasis added]
"Dilberly defending the engineering status quo." That's beautiful.
And it describes situations I run into all the time. Rather than respect people's own decisions about what's best for them (Every abandoned shopping cart says, "You're not worth my time, and you don't deserve my money."), engineers and their hyper-logical counterparts are constantly defending their system, whatever it may be, and criticizing people for being too stupid to appreciate its elegance or some similar ideal quality. They want to mold people to fit their particular vision, but they fail to see that in a world of expanding choice, people will just keep on moving until they find a system that fits their own vision.
4 Responses
Unfortunately, the Dilbert defense is a common problem in the software world. A lot of developers fail to understand (or care?) that the user is the CUSTOMER of the user interface. And we know what they say about the customer in business! I've always thought the drop-down box for the state choice is pointless. Common UI design rules state a drop-down should have no more than 5 options. I believe the state drop-down originated in the early 90's as way to show off the "cutting edge" possibilities of the user interface in this cool thing called The World Wide Web and the Mosaic browser. A good UI would simply prompt the user for their zip/postal code and then prompt the user for their city (if required). How many keystrokes would that save?
to State field (1 keypress)
to zip code field (1 keypress)
Old Way:
City field : Sykesville (10 keypresses)
State dropdown: Press 'M' twice to access 'MD' (2 keypresses)
Zip field: 21784 (5 keypresses and click DONE)
Total: 19 keypresses, 1 click
New Way:
Zip field: 21784 (5 keypresses and click DONE)
City listbox: Click Sykesville from list of 3 cities (1 click)
Total: 5 keypresses, 2 clicks
You're totally right, Alec (and Hi! BTW), but what DEVELOPERS say about USERS is usually quite different from what BUSINESSES say about CUSTOMERS. And that's the heart of the challenge for all marketers and advocates--for anyone who has to mediate between, on the one hand, developers and engineers and, on the other hand, their customers and users.
And Godin agrees with you on the best UI--type in the zip code, and just have it lookup the city and state for you, providing (short) menus if necessary. One challenge, though: we're all thoroughly trained to enter the zip code LAST, after the city and state. A UI that's intended to save us work by entering the zip code FIRST would have to be very carefully designed.
Hi Ed. Here in England it's common to encounter requests first for your post code and then for your house number. Since post codes here use letters as well as numbers, they can be specific down to the street without going on for nine digits, like full-on zip codes. You fine this on the phone as well as with web sites:
Customer: Hi, I'd like to order a [wheel of Stilton].
Store: Sure, that'll be [£50, plus £5 shipping]. May I have your post code?
Customer: It's [N99 2XX].
Store: And your house number?
Customer: [100].
Store: Ok, so that's 100 Churchill Lane, Sodding-on-Thames, is that correct?
Customer: Yes, that's it.
and on to payment. Same sort of thing is often found online.
One thing that annoys me to no end is U.S. websites that display information on international shipping policies, but are utterly incapable of accepting addresses outside the U.S. This can be infuriating after spending the time to select stuff to purchase, navigating through the payments, then getting dissed at the last stage because some HTML-coding genius made the post code a numeric field only and the whole transaction blows up.
It would be so helpful if we adopted that practice (postal code first)--but I don't see it happening, so it's going to be a UI challenge--not impossible, but a challenge.
And I plead guilty to failing to adequately serve international users. At N-TEN it took us *forever* to adapt our systems to non-US address fields. Not for lack of desire, but at the time, our systems just didn't make it easy. Heh, that sounds like the Dilbert Defense.