Have you ever filled out a form and froze on the address field? A research study found that users come to a confusing stop when they encounter the “address line 2” field.
Not only that, but the second address field also caused them to split their input incorrectly in the address fields. This led to confusion and frustration among users.
Labeling the second address field “Apartment/Suite/Other” did not resolve the issue. Users still came to a confusing stop and wondered whether the field was relevant for them.
Familiarity Principle
Having two address fields violates the principle of Familiarity that states the system should match the user’s real world expectations. When there’s a match, users can interpret the interface based on conventions they’re already familiar with.
The second address field forces the user to type their address in the system’s preferred format, not the user’s. In the real world, users think of addresses as a single entity. Two text fields causes them to perceive their address as separate entities. Users don’t expect to see this which is why they get confused.
Use a Text Area
By using a single text area instead of two text fields, you’ll help users fill out the address field quicker. This allows them to think about their address as a single entity instead of two separate entities when they see the field.
Text areas allow users to press ‘enter’ to skip to a new line so they can type their address in the real world format they’re used to seeing. Text areas also don’t limit addresses to two lines, allowing it to support international formats.
City, State and Zip Code
Use separate fields for city, state and zip code because these input need to be parsed to ensure a unique geographic location. There’s a tool called Parserator that allow you to parse an entire address from a text area, but it doesn’t have perfect accuracy and only works for U.S. addresses. It’s a novel solution worth trying and testing if you have the time.
Real World Expectations
It’s important to design your form based on the user’s real world expectations. If you force users to rethink conventions in order to match the system, you’ll confuse and frustrate them. Don’t force the user to follow the system, force the system to follow the user.
Book
Affiliate
This is an interesting split between data sanity and real world expectations. The burden here is on the system to recognize, or be able to parse, the more useful and less useful address information here. For example, map coordinates do not care about apartment 312, or suite 301a, and this additional information may prevent them or limit them in finding the legitimate address. But to the user, that information is absolutely critical and necessary to finding them correctly. If the user types the information in reverse, i.e. Suite 912a, 100 Commerce St, the logic on the system is even greater, as the system not only has to correctly parse the separation but also interpret correctly which is the street address.
Meeting real world expectations in this case expects that the user will input data to meet system expectations, or that the data the user inputs is easily parsable into system sane data.
So, allowing for the scenario above, the user can potentially enter:
100 Commerce St.
Suite 912a
|| or ||
Suite 912a 100 Commerce St.
|| or ||
100 Commerce St. Suite 912a
|| or ||
Suite 912a
100 Commerce St.
Add to this the fact that, last time I was in a business supporting address fields, the 2nd line of street address information was considered ‘informational’ and ‘not necessary to print’ on an envelope for successful delivery. At the time we were advising consumers to include necessary delivery information on the 1st address line so it wouldn’t get lost.
All this to say, I don’t know the right answer, but this isn’t simply a problem of “the customer is always right”.
Typing the input in the correct order applies to any other field not just addresses. Saying users might type the suite number before the street address is like saying users might type the area code last in a phone number. Most know what the common convention is.
There’s no reason for the system to parse the suite/apartment number. The suite/apartment number alone is unusable without the street address.
As an Australian, I would type the suite first.
Sometimes it can be difficult to know how *all* of your users will complete a form – especially when they have the freedom of a textarea. That’s why I think a textarea is a bad way to handle addresses.
Why not just provide a clearly-labelled individual input for each of the necessary fields? And hide the usually-unnecessary fields (eg: 2nd line of street address) behind a link which will be found by those who need it. For example, the anchor text could say, ‘Need a 2nd line?’ just below the first line. This will be easily discovered & understood by the people who need it, but it won’t confuse the people who don’t need it. And the data you receive will generally be much easier to work with.
What about the city, state, zip?
If I saw a single TextArea for address, I’d naturally type in my city, state and zip.
This may be correct in the USA but in most cities of Germany it would be no point. The only exception may be Berlin. Same is with “First Name” and “Second First Name” which may be a thing in the US but not outside. And there is an outside world, you know? 🙂
I just had to comment… born and raised in the US but I’ve never heard of a “Second First Name.” Have I been missing part of my name my entire life?
I do agree with what you’re getting at here, though.
Interesting approach. I imagine in this case the “Address” would be just for street / number / complement, right? So would you first ask the other data like country and city? I’ve seen users getting confusing with the label “Address” and inputting everything there and only seeing the other fields after, but maybe a placeholder would be enough in this case. I’ll definitely user test this thing. Thanks for sharing!
City, state and zip need to be separate fields. If you place those fields before the address text area, users will fill them out first and won’t make that mistake.
It’s an interesting approach.
My immediate reaction was: “this will hurt my data quality”. Then again: we are living in an AI world, nowadays we should just be able to fill out a text area, and the system should find out what data belongs to what..
Then you stated “City, state and zip need to be separate fields. If you place those fields before the address text area, users will fill them out first and won’t make that mistake.” Isn’t this “against” the natural flow of users? Shouldn’t the rule be to follow as much as possible the order as the user is familiar with?
Generally speaking I would state that labeled fields are pro usability, so maybe just the label is wrong? Or a different label applies for different geographical areas?
The general rule is to present fields that are easiest to fill out first to decrease form abandonment. City and state are easier to fill out than addresses.
City, state and zip do NOT need to be separate fields. Some Company’s applications may prefer (or require) to have all the address components entered separately, and some don’t care. It depends upon the reason for gathering the address information, what the Company is allowed to do with the address, and what the Company is willing to do with the address. There is a cost for each solution (time/money), just depends upon the needs.
i agree with Jshell. the whole point of using 2 input fields is for data integrity. if you open up a text field to the user, you’re most likely to get crap data that is hard if not impossible to query.
Another issue with using a textarea is that I have seen exactly zero website forms that ask for addresses as a textarea. So assuming this is not a person’s first form they’ve ever filled out (the vast majority of people nowadays will have completed at least a few online forms) they will likely be more confused by a textarea. If people are slowed down by “Address 2” how much will they be slowed down by a generic “Address” textarea where the contents are ambiguous? Also as people have noted, people may not enter all of the necessary information in the box which may result in more work for the customer and the company in the future to collect the info or deal with the problems that may occur.
Definitely an interesting and thought-provoking read. But IMO providing exactly one field per chunk of data to be entered by the user is the least confusing approach. If you consider an address to be a single entity, then perhaps capture the whole thing in a single textarea. If you consider it to be a number of discrete elements, then expecting the user to enter two elements in one field, then one element in the other fields is likely to lead to more confusion.
Have you tested this? What were the results?
Having dealt with addresses in systems in the past, i’m thinking in future of this exact approach – just a textarea for an address so that the individual quirks across countries are just taken care of. Typing an address in a textarea is a lot quicker for the user too. I think we can take some burden off the users just by thinking things through pragmatically. To address some concerns about data integrity:
Validation: This is possible by splitting the rows of the textarea and validating the last one against a specific postal code regex, the penultimate line against a regional list and the first you throw at an address validation API. Just because it’s inputted as a block of text, it doesn’t mean you have to store it in a text field in the database – a JSON type would naturally lend itself to an unknown number of lines.
Some typical use cases:
For mapping purposes – the postal code is the valuable bit of data, but you can just throw the entire address text at the Google Maps API and it’ll parse and find the location itself
For printing labels – the address has been typed in exactly as required by the user, so just print as is
To visit the location IRL – you navigate to the postal code geographic location and use the rest of the text to find the street and building name/number, as you would with any address stored in a database…
I think the main problem is with the numbers recognition in one input field. People can input them interchangeably, depending on the country.
In my country for example the street name might or might not contain numbers. Then we have the building number and sometimes apartment number. Which all can be from 1 number up to 3 numbers. People might or might not use punctuation to distinguish them. There is just too much risk for address getting mixed up. Couple of times it happened to me, because they taken the apartment number as building number.
For me, it just look bad, I wouldn’t use it. Two separate fields with only 1 label is a poor option.