Online Forms: how to communicate format restrictions?

Tips to prevent errors and reduce form abandonment

“I love forms”, said no one ever¹! Everyone is familiar with online forms — they are an integral part of our digital life. However, when not designed properly they can be a source of frustration to users and result in loss of income for businesses. Good web form design should prevent user errors during data entry. However, this isn’t always possible. When errors do occur, we should aim to help users correct them as easily and quickly as possible.

Online forms can have various input types. The most common ones are checkboxes, radio buttons, drop-down menus, and textboxes. Unlike all the other formats textboxes (by default) don’t limit users to a specific input and format. The possibilities of answers a user can provide are endless. This can result in missing or inadequate data. Let’s look at two examples of this:

• a numerical input field in which the user has to enter their date of birth

There are multiple answers to this: 05/01/90, 05-01-90, 5th January 1990, 1990-05-05, and so on! So many combinations. In most cases like this one there are format restrictions but without communicating that to the user, how can they possibly know?

• a password entry field

We ask a user to create a password. They create a 4-word password and an error message appears informing them that the password isn’t strong enough. That occurs due to format restrictions not being communicated to the user in advance and can lead to frustration and abandonment. We can’t expect users to guess the rules.

How can we ensure that users enter the data in the desired format preventing errors and user frustration? Should we disclose the rules or include examples?

This was a topic Javier Bargas-Avila and colleagues explored over a decade ago. Should we communicate form restrictions and if yes, how? They recruited 166 participants and used four different ways to inform users of format restrictions:

• no visual format restriction: users didn’t see any information about the restrictions. If their answers didn’t follow the right format, they were shown an error message informing them about the restrictions.

• using format examples: the rule wasn’t explained explicitly but an example was provided (e.g., 05/01/90)

• explaining the format specifications: the researchers explained the rule to the user (e.g., “Date of birth in dd-mm-yyyy format”)

• including both format restrictions (examples and specifications): Users were presented with the rules and an example (e.g., “Date of birth in dd-mm-yyyy format (e.g. 05/01/90)”)

Results showed that providing details of any format restriction to users in advance led to significantly fewer errors suggesting that it is crucial to inform users in advance that format restrictions will be imposed. The most efficient way of providing this information was by presenting users with format specifications (i.e. explaining the rules). Using format examples alone left too much room for interpretation, which also led to errors. Providing an additional example didn’t have a positive or negative effect. Since brevity is encouraged, using the rule alone should be sufficient.

This study was published over a decade ago but there are still numerous examples of forms not explaining the rules or explaining them badly (e.g., using a placeholder that disappears once the user starts typing). I love this quote by NNG on this:

When a system doesn’t show the requirements beforehand, users are essentially being asked to play a game where the rulebook is hidden. That’s neither fun, nor fair. 

When you’re creating a form with format restrictions, ensure you:

• state the rules to the users (either show they the entire time or activate them when the user selects the field)

• make sure they can see the rules the entire time (don’t use a placeholder).

1. That’s not entirely true... Forms can be a fun challenge from a UX perspective!