Viewers: in countries Watching now:
In this course, interaction designer Luke Wroblewski shows how to create web forms that encourage visitors to enter information and covers ways to capture input without the use of forms. The course covers boosting conversion rates and customer satisfaction, organizing the structure of forms, aligning and grouping form elements, assigning the correct input field types, validating input, and handling data entry errors. The last chapter highlights alternatives to static forms, such as using dynamic inline forms, using web services, and leveraging device capabilities, which can be used to gather additional information or replace a traditional form altogether.
One of the most common types of input groups in Web forms is the address block, but even the address block has a number of variations that we need to consider, especially when we've start talking about International Addresses. As I've mentioned earlier when we were talking about input groups, there is natural structures among certain types of input fields. These natural structures can provide valuable clues about how to actually answer a question and that Visual organization can represent that structure. So when we look at how Address Blocks are generally laid out we try to mimic the structure that people are most commonly familiar with.
When we break that structure we force people to think a lot and perhaps make mistakes. As we see here on the Nintendo Wii form where the address block structure is divided across two lines and really spread out. International address block structure follows a similar format and see here in the US, French and Spanish version though the input labels are a little different the general structure stays the same. So we start thinking about International Addresses within Web forms this structure plays a big role.
Luckily, there is a fair amount of commonality between the elements that make up an address around the world, looking at the generic Address Structure here at the top, you'll see that in most countries the destination or the recipient is first and the rest of the address really progresses from most to least specific. Russia and Iran are notable exceptions. So when shipping to someone at a Corporation the individuals names come first then the Corporation name. This line structure is a pretty reliable baseline for all international address.
International address variations start with the most specific destination to whom an address actually belongs. The next series of variations falls in the Street Address, though names in Street Addresses can have many variations a single input for each usually provides an adequate amount of room, and is all that's really necessary. Street number comes before street name no problem. Street Number comes after street Name, also no problem. When it comes to the City Line of an address block we're not as lucky. In addition to a city name in postal code a City Line can also include a state, a region, a province, or a county depending on the country each of these can have different names abbreviations and locations in the address block.
There is also a slew of postal code, format variations across countries, including the use of spaces, numeric or alphabetical characters and various lengths. The order of these elements also varies quite drastically. And you can see the variations that we're talking on the City Line here, again, not as lucky as a street line China and India town, province postalcode. Brazil postalcode, town province Italy postalcode town (provincia) you start to see the challenge.
So how can we actually layout a series of input fields that captures address information knowing that we have these variance. Well there is a of couple options that we can turn to. Option one is really providing a very specific format for each country. Specific format approach works best when you can confidently either infer or ask for somebody's country. Using this approach you custom tailor the address block specifically for each country. You can see the difference in this for France and Italy. Note the variations in the line placement and labels between the two.
If you know somebody's country at the high degree of certainty, you can infer this automatically otherwise you can give people a choice. In option two, the choice people have about changing there format can be configured with a drop down. So here when you adjust your country from Australia to Canada, the rest of the form updates. Now one of the challenges with this approach is that, in a standard address block the country tends to come last. So you may fill in all the information only to realize that you can toggle between Australia and Canada and change the input fields and labels only at the end.
Luckily the entire form does not need to change. Really only two fields the State province region and the ZIP postalcode postcode areas. In the case where somebody selects Canada instead of Australia State/Territory changes to province, and postcode changes to postal code. It's important to know that if the user has filled in any information that's common across both address structures such as First name and Street address we'll preserve that information when they change countries that is we don't remove any information that they've actually entered. Removing information that people have already provided is likely to really upset people.
As a way to address some of the shortcomings to the Changing Formats approach, many people will try to capture country information upfront. Sometimes even before somebody enters a web form. If we can infer a country and we don't have a clue about where they actually are using something like IP address, we can ask them up front. Here's an example of sticking the country right at the top and then filling in the information below. What I don't like about this approach is that it breaks this common address structure. In fact, it aligns everything vertically in a way that it doesn't represent traditional address structures as most people know them.
So while we capture country upfront, we don't actually do a lot to take advantages of how people know and enter address info. Option three takes a different stance. This offers an alternative to maintaining lots of different variations that support country specific solutions. If you remember option one was giving people the specific country solution, option two was allowing them to change that format, option three is releasing the generic format and tries to support every variation possible. What you run into here is that you explicitly call out the variations and name, street address and city lines by say State/Province/ Region, Zip/Postal Code, as a way to be forgiving and inclusive of any type of variation you can have.
When you do so you have to make sure that you account for alphanumerical characters spaces and variations and lengths infield like the ZIP or postal code, otherwise something that's valid in one country might not work out in another. While this kind of Generic Format can provide a flexible set of input fields for international address, error checking can be a bit harder because several fields can have multiple valid formats. Also by virtue of its flexibility, this Generic Format isn't optimized for any country or culture, so it's likely to be functional, but it's not necessarily ideal.
One small variation that a number people have proposed is to actually create a single open block for your address information. While this seems good on the surface there are actually a number of potential problems. One of which is that different parts of the address need to go in the different fields in the database and while it's impossible to parse things out from a single box it's considerably more difficult. The other big down side is you can make certain parts of the address mandatory. For example if you're collecting Billing Information you really need the ZIP code to process someone's credit card, enforcing that within a single address field where everything is included in one area is much more challenging than having a separate ZIP code field that you can respond to when it's left empty.
Also it's challenging to allow people to leave things off such as in Australia where people sometimes leave the postcode off, if they feel it's not needed. Having a single input field that you try and parse for a valid format might have a difficult time trying to catch those types of variations. In general, when dealing with international addresses, it's good to stay focused on what a common address block looks like. Using more generic labels like Post/ Postal Code over specific country labels like ZIP Code is generally a good idea. Those postal codes are also need to support numerical, alphanumerical characters and spaces and there are some situations where country don't have codes or don't require them.
So you need to be a little bit more fault-tolerant there as well. Which option makes the most sense for you, option one of a specific format; option two of allowing people to change the format; or option three being flexible, really depends on the situation you're most comfortable with. Inferring a country with a high degree of confidence might lead you to: Option one, the fields will be specific to a country and people have no problem understanding the country that they're commonly used to providing an address for. Option two; may make a lot more sense if you don't really have any confidence about what country someone's in, allowing them to specify and pick a format, maybe the right way to go.
And option three; the flexible field's, maybe a great solution for you if you're comfortable managing all the variations you have to deal within the form to support any kind of address within a single set of input fields. Which choice is right? Depends really on the situation you're in. Last but not least there are a number of resources that you can turn to for further information on international addresses. Particularly I've written the article that explains many of the points I just made and there is a lot of places where you can get explicit data around how postal addresses are structured around the world and how to make use of them.
So if you would like to dive a little bit deeper these are the places to go. This point we have looked a lot at form organization. We talked about where replacing labels, we talked about health and tips, we talked about how we format input fields and structure their lengths, they are required indicators and even their way be group them to indicate meaningful structures. All of these things add up to a lot of great best practices for how to layout and organize our web forms, but how we structure, organize and layout web forms is only part of the solution.
The other piece is how people actually start to interact with our forms. And for that, we'll turn to the next chapter and form interactions.
There are currently no FAQs about Web Form Design Best Practices.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.