Hacker News new | ask | show | jobs
by jackseviltwin 4847 days ago
That's funny, we came to the same conclusions and implemented them for our checkout flow. Here's an example:

http://crop.to/fW

Combining first/last name into a name field and auto-detecting card type were easy wins for the shopper, but in user testing, we found that detecting city/state from a zip code had some potential issues.

First, the format of the form without city/state surprised some users. One user said something like "where do I put my city and state?" They ended up appending it to the street name. Then they filled in the zip code and saw that it fetched the city/state and then realized how it worked then went back to delete it from the street name field.

Also, in the U.S., some zip codes can return multiple cities and states. Our solution was to populate a pull down of the possible values for both fields.

It turns out there are small towns/cities that we didn't return from a zip lookup, so city had to be editable for these users. We added a "Let me type it in" option on the bottom of the city pulldown for those users, who are hopefully the minority.

3 comments

For Australia we have the user enter a postcode which then allows them to pick a suburb from a drop down. We have some text next to the postcode field to explain this.
I really like your checkout process. It's very pretty and unobtrusive. One note: your dropdown fields don't update when I have focus and type in a value until after I've left the field (unlike the native control which updates as I type) which makes keyboard-only navigation a bit tricky.
Perhaps having the user enter their location information in the order country, zip, city, state, street would provide a better experience. It's not what they would be used to, but it's at least consistant (information is entered from less precise to more precise).

Having to build an additional "let me type it in" option seems like it increases the complexity and confusion. One of the banks I use asks for the zip first and then populates the city and state text fields on the lines below. This also has the benefit of working if Javascript is disabled.

What do you do if there are multiple options for the city/state? What if your city happens to not be one of the options you provide? That's why we needed to add an option for the user to fill it in.
In that case the user can type it in themselves. The textfields are fully editable after all. I would expect that it is faster for user to type in the correct city if you get it wrong than for them to have to move their mouse to the keyboard and select it from a drop down list, and if it isn't in the drop down then this method is faster.