A 5-step guide to designing global addresses
Addresses are old. Like really old. The first documented use of a postal service dates to 2400 BC, when Egyptian runners delivered documents carved in stone. But, as you would expect, addresses have evolved and diverged since then, based on cultural variations.
And although these differences have existed since the early days of the Internet, they weren’t really an issue in a world where an American customer went online to purchase a book from an American publisher, to be delivered to their American house.
But in an ever-globalizing world, we need to design address forms for a Dutch-speaking customer buying a book from an American publisher, who wants it delivered to their apartment in India.
So how do we do this? How do we design address forms for everyone, everywhere?
The following is a 5-step guide for designing global addresses that I devised during my research for Shopify’s International team:
- Follow regional trends
- Mind the details
- Define field requirements
- Define field order
- Reduce friction
Diving into the world of global address forms can be daunting. There’s a lot of variation out there and a lot to consider. But fortunately, there are regional trends which offer a great place to start.
For instance, in North America, streets are defined by an alpha-numeric grid and are either named or numbered; and there are governing bodies that define addressing standards, like the Canada Post Corporation.
Whereas in the Middle East, specific addresses are less defined and instead focus mostly on blocks of buildings. However, there’s been an uptake on the use of GIS technology in some locales (with companies like Esri), which has provided some places with an addressing information infrastructure.
And in East Asia, addresses often refer to administrative areas and are commonly presented from largest entity (country) to smallest entity (apartment).
Although regional trends are a good place to start, it shouldn’t end there.
For instance, we could consider North America as one region that follows the same addressing system and pattern. But if we did that, we would overlook the fact that Canada has provinces, whereas the United States and Mexico have states.
And all of this is important when it comes to localization, because getting it right is all in the details. You can certainly create an experience that is good enough and will work for people around the world, but it won’t necessarily feel like it’s meant for them.
For instance, if you’re a Canadian, like me, and you’re filling out an address form that suddenly asks for a ZIP code, you’ll probably start thinking things like: “Do they deliver to Canada?” or “Is this service only provided in the United States?” or, at the most basic level, “I don’t think this is intended for me.”
With that in mind, let’s take a look at typical address form fields and consider how they might need to change depending on the locale.
Perhaps unsurprisingly, the way names are structured around the world varies. In some parts of the world, it’s common to have a distinct first and last name. In other parts of the world, it’s common to have a first name and multiple last names. And so on.
When it comes to an address form, the best generic way around these differences is to provide one field for Full name. Or if you want to target a specific locale, provide the fields (and order of fields) that people in that locale would expect.
Address line and apartment/suite/etc.
Commonly, address line and apartment number are broken into two fields. But that’s not always the case. For instance, in the Netherlands, the address line is broken into separate fields at a more granular level for street name and house number.
If you don’t have the option of providing a highly localized experience for these fields, consider adding help text beneath them to direct people in those locales.
This is one of the few straightforward fields that seems to work in most places.
State or province
This one is pretty straightforward as well, but we often get it wrong. What you need to know is that some locales have states/provinces/counties, and some don’t. And beyond that, some locales that have them, don’t include that level of granularity in their addresses.
So be sure that you understand the territorial divisions of the locales you’re including. And also whether they’re included in addresses.
Country or region
There are a few classifications of countries to keep in mind when designing this field:
- A country (example: Japan)
- A sovereign country (example: the United Kingdom), which includes other countries
- An autonomous region (example: Hong Kong)
These classifications should determine the field label as well. For instance, a more inclusive label like Country/region is a better than Country.
ZIP, postal, or post code
Most locales have some form of postal code, but some don’t. And beyond that, some locales technically have some form of postal code system, however, it’s not common practice to include it in an address:
- Postal code (Canada)
- Postal code (optional) (China)
- [no code] (United Arab Emirates)
When it comes to the field name, use the terminology of that locale (and of course, translate where appropriate). For example:
- ZIP code (United States)
- Postal code (Canada)
- Postcode (United Kingdom)
- Postleitzahl (Germany)
If you’re unable to provide that level of localization, use a generic name like ZIP/postal code.
Smallest geographic entity to largest
This is where it can be helpful to rely on regional trends. In general, Western addressing systems go from smallest geographic entity (street address) to largest (country). But of course, there is no one-size-fits-all address order. So, if you’re creating an address form for a specific locale, check the Universal Postal Union or that country or region’s official postal addressing guidelines.
Largest geographic entity to smallest
A trend for largest geographic entity (country) to smallest (street address) can be found in Eastern countries and regions. But again, there is no one-size-fits-all field order.
Address autocomplete, like the service provided by Google Places, can be a real usability win, especially if you’re filling out an address on a small screen, or struggling to remember the correct spelling of a street like Haðarstígur.
However, when you’re adding an address autocomplete service to your form, remember that even Google Places doesn’t have data for every address in the world. So depending on who this form is targeting, this could be incredibly useful or an exercise in frustration. In any case, always provide an easy way to override any autocomplete functionality.
Like autocomplete, geolocation gives people a helping hand when it comes to filling out forms. It also allows you to pre-populate the form with the country and present the appropriate fields based on the locale that’s detected. For instance, if you know that a person is based in France and is filling out an address form for their home in France, then you can surface the localized French address form to them automatically.
That said, geolocation can be creepy, and if you haven’t built the necessary trust with your users, it could be a signal to them that you are taking information from them that they haven’t agreed to. It can also be unnecessary or unhelpful if you’re filling out an address that’s in a different locale than the one your computer is in.
When it comes to geolocation, I err on the side of less is more. Even if you have the ability to detect which city your user is in, I don’t recommend going further than pre-filling the country field for them. It’s the difference between someone thinking “it makes sense that they know I’m in Canada” and “How do they know that I’m in Gravenhurst, Ontario? I don’t remember offering that information.”
There’s a lot to think about when it comes to designing address forms for people around the world. But like any localization work, it shouldn’t be overlooked, even if its complexity is daunting.
At the root of it all, an address form is a very tangible way to communicate who is included and who is excluded. So if the intention is to include people from multiple locales — or even everyone, everywhere — then be sure that the language, field presentation, and amount of friction that exists in your address form supports them.