Web forms done right – Form best practices
As promised in my post about bad web forms, here are some form best practices to get you started on making sure your forms don’t suck.
Credit – Rather than re-inventing the wheel, I’ve borrowed several examples from Luke Wroblewski, one of the web’s most authoritative voices on web form design. If you’re looking for a really in depth look at forms, check out his book.
Do you really need that information?
This is probably one of the most common problems out there: you want 12 pieces of information from your visitor, and they’re only willing to give you two. This comes down to having a thorough internal discussion about which fields you absolutely require and which could be removed.
Typically, once you get beyond three or four fields, conversion rates start to drop off. Of course, this is dependent on the offer – if it’s a great contest, an expensive white paper that you’ve sponsored free downloads of, or a product warranty, chances are visitors are going to be more likely to give you their information.
This is where testing comes into play. If you can make do with less data about your visitor, run a test with a shorter form and see how it does.
Another option here is progressive profiling. If you have a CRM system that ties into your web forms, it likely has some sort of progressive profiling feature built in. When a visitor comes to your site and converts multiple times (e.g., downloading several white papers), they’re presented with different fields on each form. This lets you collect, say, 10 pieces of information while only asking your visitor for 4 at any given time.
There’s been a fair amount of research looking at the optimal placement of labels within a form so that they facilitate scanning, understanding, and form completion.
When the data being collected is familiar (e.g., a contact form), labels should be stacked vertically on top of fields. This makes it quick and easy for the visitor to scan down the entire form. The disadvantage here is that it makes the form take up more vertical space.
When the data being collected is unfamiliar or complex, labels should be placed to the left of the field, and should be left-aligned. This helps visitors scan down the list of labels so that they can see exactly what they will be providing. Left-aligning the labels can create a bigger distance between the label and the field, but this is preferable to right-aligning them, which is more difficult to read.
Ensure that the length of field is appropriate for the type of data. For example, a zip code field only needs to be 5 characters wide. This can help the visitor understand what type of information you’re looking for. However, keep the visual design of the entire form in mind as well – it probably won’t help the visitor if you have 9 different fields that are all different widths scattered all over the page.
Required vs. optional fields
- Indication of required fields is most useful when there are lots of fields but few are required – use an asterisk.
- Indication of optional fields is most useful when few fields are optional – use “(optional)” beside the label.
- Neither is useful when all fields are required, although this should be noted somewhere.
- Ensure that instructions about required/optional fields are easily noticed – they should be in the visual path of the user, not in tiny little text at the bottom of the page.
Grouping related fields together gives the visitor the opportunity to scan the groups and get a high level sense of what is required; however, only use the minimum number of visual elements necessary to communicate useful relationships.
The visual presentation of the actions should match their importance. Avoid secondary actions (e.g., “Reset”) if possible, and if not, ensure a visual distinction between primary and secondary actions.
Also make sure that you’re using good calls to action.
Don’t make the visitor figure out appropriate formatting for a field (telephone numbers are especially notorious). Either provide a hint, break the field into the appropriate format, or do server-side processing to interpret the data.
It’s also nice if you can do the hard work behind the scenes. For example, if you can figure out the state based on the visitor’s zip code, that might be nice. Another great example is credit card numbers: MasterCards all start with the same set of numbers, which aren’t the same as the numbers that Visas start with. So when a visitor gives you a credit card number that starts with “5191”, you know it’s a MasterCard without the visitor having to explicitly say so.
Help and tips
- Useful when asking for unfamiliar data, when the user may question why the data is being collected, or there are recommended ways of providing the data.
- Don’t overuse them!
- If you have a lot of help/tips on a form, consider exposing them only when the visitor reaches that field (e.g., tooltips) or clicks on a help icon.
If there are field dependencies (e.g., the options in a shipping option selection menu depends on the zip code entered), ensure that they update appropriately.
Account for tabbing between fields when designing your form. Lots of web users do this now.
If you’re designing a multi-column form, make sure that the tab progression makes sense. For example, if you have first name and last name beside each other at the top of two columns, probably you want the visitor to fill in their first name, press tab, and then fill in their last name. You don’t want them to fill in their first name, press tab, and go down to the field below.
This also comes into play when a visitor is happily tabbing through a form, and then all of a sudden the three fields for the telephone number auto-advance when they fill in the required number of digits. It can then be extremely frustrating to try and get back into the previous field to try and fix any errors made.
- Provide direct feedback as data is entered – use inline validation to verify input and suggest valid input if errors are found.
- Show errors at the top of the page and at the place where the error occurred. Make sure that they are visually distinct. Provide error messages that help the visitor understand what went wrong and how to fix it.
- Use progress indicators to show that something is happening. Disable the submit button after the visitor has clicked it to avoid duplicate submissions.
Now go out there and make some awesome forms!
Not sure if your forms are working for you or not? Check out our usability services to see how we can help you with usability testing, A/B or multivariate testing, and user experience research.
Questions and comments are always welcome.
Ian Everdell is a Usability Consultant at Mediative.