On Friday, I was getting ready to fly to Monterey, CA for Internet Librarian 2014, and needed to pay for something on my flight with American Airlines. The screenshot above is the credit card payment page on American Airline’s website.
It’s weird. Instead of running your name, address, etc left to right, they run everything up to down. So my name? There are three vertical boxes for first, middle initial, and last.
That’s pretty much like no other credit card page ever.
And it forced me to think about the functionality of the page. For example, I really, really wanted to type my middle initial in the Country box, and my last name in the City box. Then, since I’m used to typing left to right, when I reached the Street address box, I couldn’t enter my city next. I had to search for the City box … because 9 times out of 10, most of us generally type address, city, state, zipcode. Except, apparently, for American Airlines.
So instead of thinking about my purchase (paying $15 extra to board in group 1), I was having to think about where to type my middle initial and my city.
My point? Don’t ever force your website visitors to have to think about your website and your poorly-done forms. Keep website visitors focused and thinking about the things they really want to do (i.e., check out a book! borrow a movie! read your cool blog post! etc).
If your website visitors have to think about how the functionality of your website works … you have failed.
You use real, immediate examples of BAD UX — truly helpful in demonstrating why it is bad, and that one is bad! I hope the flight was far better!
I’ve been spending a lot of time recently thinking about good form design – which is crazy tricky. Luke Wroblewski pretty much wrote the literal book on it, and his short videos on interfaces for Intel Software TV (yt: http://youtu.be/xAKnPtbfNfY?list=PLg-UKERBljNy2Yem3RJkYL1V70dpzkysC) are really insightful.
Filament Group created a really interesting script called PoliteSpace (http://www.filamentgroup.com/lab/politespace.html) which allows users to, say, type phone numbers in any format and then corrects it on the backend.
For publibs, I think the biggest obstacle is the library card registration form. Most libraries I’ve come across require way too much information – at least up front. I almost think it would be better to have users register with name and email, and then send a verification email requesting more info after the fact. There is a design trigger called the Zeigarnik Effect, which is basically, “Well, you’ve started typing, might as well finish the form.”
I made a simple prototype based on that here–http://codepen.io/michaelschofield/pen/hKpuq–where you basically as for name and email, only once the user his committed and writes his or her name, does the rest of the nasty form business reveal itself. (More on design triggers here: http://libux.co/designing-library-website-zurb-triggers/).
I’ve been thinking that libraries should / could consider account creation using Facebook or Google+, which could prepopulate most of the address fields and then only the next time the patron checks something out in person would the staff-member verify the ID. It seems obvious to me that daunting sign-up processes turn away certain users, especially when libraries ask fairly personal contact information.