Is it ok to change the (US) address input field order in favor of a pre-fill feature?

Question

I am working on an international site that requires the user to enter his postal address. I am wondering if it makes sense to have a slightly different order of input fields in favor of a time saving pre-fill feature.

This is the common format for US address input fields:

^{download bmml source – Wireframes created with Balsamiq Mockups}

A slightly different order might improve the input form UX:

Let's assume it would be possible to detect the City and State correctly after the user entered the ZIP code (I am aware of some ZIP codes not being unique in the US). Once the user left the ZIP code input field (onblur), city and state could be almost instantly be pre-filled.

^{download bmml source}

My question is:
Would it really harm the user experience if I changed the input field order, i.e. would many users stumble or even drop off?

Answer 1

I'd rather stick with the well know format since users tend to go to "auto-pilot" in this mode, so making them think isn't recommended. It has also happened to me before that I'm typing / choosing faster then the values are auto-update, creating confusion and sometimes input of double values.

Moreover, you've mentioned it's an international site, so that means:

1. The user has to choose the country first
2. You need to have the reverse lookup service for most countries for this to make sense (and I'm not sure you can rely on that)

Lastly - is the zip code a must? If not, it's better to leave all optional fields to the end.

Answer 2

Since you brought up the idea of auto-filling (which would greatly decrease my form filling out time) How about hiding the City/State fields until the zip is filled out.

• If you can't get a good match from the auto-fill feature then you display the city/state fields and explain that you couldn't find a good match
• If you do get a match, display the city/state fields filled out correctly with messaging after the display.

Answer 3

I agree with Dan's suggestion.

Based on my experience, I've only flipped the order once, and it was for an internal application for users whose job required transcribing addresses from written documents.

It didn't work too well for call-center application, because CSR typically has to get addresses over the phone, and customers prefer to say their addresses in a certain order.

Another item to consider is, it's actually easy for some people to mix up zip code. (e.g. 14171 14711), whereas people know their cities pretty well.

Answer 4

From a heuristics point of view I recommend sticking with the most common format of "City, State, Zip + 5".

Another options is to ask for the Zip on a previous screen then on the screen with the address pre-fill the State and Zip while offering a drop-down of possible cities. One of the hurdles your example faces is that multiple cities may exist within a single postal code.

Answer 5

I was working on a recent project which required the design of a form based application which would be filled in by educational institutions which are looking for research funds. We did a lot of usability testing about the kind of layout which could perhaps be best used by an international audience and we found that having labels such as the ones mentioned below really confused people :

• Street Address - Street addresses can be mentioned in so many ways eg: house number first,street address second or street address first, apartment name second,locality third
• Zip - what do you mean by zip code,further more zip code is a US term and in countries like India,its referred as a pin code,so would you be changing your label text there too?
• Apartment number (This might seem odd but then most people were not sure if this should be populated by the house number and how applicable this would be in a educational institutional address and whether the apartment number would be the room number in the building ?)

In the end we found that the most simplest solution which worked for everyone was just having a plain textbox for the address field which users could fill up in anyway they wanted.

I know this is not the solution you are looking for but its a simple and effective solution which worked just fine in our case

Edit: I am curious how you plan to do your validation? I worked on a project during grad school in which we built a mapping application for mapping US impact information (locations of libraries and internet centers) in locations such as Chile and Bangaladesh and we found that the only way to get consistent co-ordindates was to use longitudinal and latitudinal points.I know I am not answering your question but do you really have a way to do validation which works effectively?

Answer 6

No.

There are zip codes split across states, do you plan on just ignoring them and making the UI inconsistent?

What about zip codes with multiple cities/towns? My home zip code includes a chunk of the neighboring town.

Answer 7

I would instead use the city/state as a check against the zip code to make sure they correspond with each other. It serves a similar purpose like making the user type in their email address twice - guarding against typos. I realize you're trying to save the user time but accuracy is more paramount. I would validate it after all 3 are entered and flag the boxes with a red background if they don't match.

Answer 8

Unless you need the data to be reformatted later or have a need for the data to be separated into specific inputs, I suggest using a single textarea for the address field. This solves the issue of internationalization, and also lets users takes care of any edge cases related to their address that you may not have considered.

It also speeds up the input since the users doesn't have to move between several inputs.