Forms and form fields

The following section describes best practice for creating forms and transactional pages. A well designed form reduces the cognitive load placed on a user, increasing the likelihood they will complete the process, resulting in higher conversion.


Defining the process

Consideration needs to be given to how the process is constructed. Filling in a form should be similar to that of having a logical conversation where there is a sharing of information from one to the other.

Usability guidelines

  • Ensure the process is divided into pages of related questions presented in logical order.
    This conversation needs to make sense to the user if they are to be expected to complete it.
  • Inform users at the start what information they will need to complete the process.
    Prevents users having to interrupt the process part way through.

Common mistakes

  • Building a process that suits the developer or system yet is illogical to the user.

Progress indicators

Usability guidelines

  • Present the user with a progress indicator that states the required number of steps to complete the process.
  • Give clear visual treatment to indicate the current, completed and future steps.
    This will orientate the user within the process.
  • If the process contains steps which may not be relevant to all, consider greying out these steps until it is clear they are required.
  • Progress indicators work well for one off or annual application forms which the user is unlikely to be familiar with.

Fig. 1 – example of progress indicators.

Common mistakes

  • Misrepresenting the number of steps. Users will resent being lead to believe the process is shorter than it is.
  • Using progress indicator for frequent tasks eg transferring money within your bank account.

Form questions

Users are only likely to complete a form if they are presented with relevant questions which they can understand.

Usability guidelines

  • Only ask questions that are relevant to the process.
    Users are likely to abandon the process if asked irrelevant questions especially asked to gain marketing insight.
  • Group associated questions logically, providing a sub–title, and if appropriate an icon. Support grouping with visual treatment.
    Reduces the user‘s cognitive load when answering questions.
  • Ensure the question label is simply phrased in language that makes sense to the user.
    If the user doesn‘t understand the question they can‘t answer it correctly.
  • Ensure the tab order is set to take keyboard users logically through the question set.
    Many users will navigate a form using the keyboard rather than using the mouse.
  • Questions should be vertically presented.
    A clear vertical path will help users complete the form as efficiently as possible.

Common mistakes

  • Asking irrelevant questions. Every irrelevant question increases the risk of form abandonment.
  • Using jargon without help.

Mandatory questions

Usability guidelines

  • Annotate mandatory questions with a * at the beginning of the label text and provide a legend at the top of the page.
    Helps users understand which questions have to be completed.
  • Consider removing optional questions.
    If a question is optional it‘s likely to be irrelevant.
  • If all questions are mandatory, consider stating this at the beginning of the form instead of using the *.
    Removes clutter within the question labels.

Common mistakes

  • Not marking mandatory questions.
  • Omitting the legend.

Field labels

Usability guidelines

  • All labels should be left aligned and in regular font.
    Supports readability.
  • End label with a colon ‘:’
    Shows partially sighted users the end of the label.
  • Display format examples (dd/mm/yyyy) after the field label.
    Helps users answer the question in the required format.
  • Maximum distance from end of field label to the start of input box should be 20 characters (eg maximum space shown after the “Title* :” label.
    Supports accessibility for partially sighted users.

Fig. 2 – example of a form.

Common mistakes

  • Making labels all bold. This will reduce readability.
  • Having too much space between the end of the label and the start of the input.

Input field types and their usage

Usability guidelines

  • Select the correct input type.
    Helps users return the correct answer, minimising errors.
  • Left align all input fields.
    Provides the user with a clear path to completion, reducing the cognitive load.

Common mistakes

  • Making all input fields the same length.

Text boxes

Usability guidelines

  • Use when users are required to enter their own answers in text format.
  • Should be as long as the likely input.
    The appropriate length helps the user asses the likely input. If it is unnecessarily too long or short they will wonder if they are entering the correct information.

Common mistakes

  • Making fields all the same length.
  • Making fields too long or too short.

Usability guidelines

  • Used when one selection is required from a list of items.
  • Default should be set with either a probable answer or the value “Select [input name]”
  • Lists should be ordered in the most logical way. This could be alphabetically, in order or popularity, or grouped. Lists can include group headings that are not clickable.

Fig. 3 – example dropdown form element.

Common mistakes

  • Having too many or too few items in a single list.

Checkboxes

Usability guidelines

  • Use to select zero, one or more items from a list of options.
  • Place the selection label to the right of the checkbox.
  • The selection label should be bold and activate the checkbox when clicked.

Fig. 4 – example of checkboxes.

Common mistakes

  • Using check boxes for mutually exclusive options. Consider using radio buttons or a dropdown box.

Radio buttons

Usability guidelines

  • Use to select a mutually exclusive choice.
  • Display radio buttons horizontally to save space.
  • Ensure that clicking the label activates the button.
    Gives users a bigger area to click.
  • Place the selection label to the right of the radio button.
  • Use bold text for the selection labels.
    Usability testing shows more accurate answers are given when bold.
  • Consider the use of a default value.
    Helps reduce effort for users if a common value can be predicted. If there is no one common choice it may not be appropriate to default a value. Not having a default also forces the user to consider the question more carefully if the question is mandatory.

Fig. 5 – example of radio buttons.

Common mistakes

  • Not making the contextual label bold.
  • Using more than three options. Consider a dropdown box.

Buttons and calls to action

Usability guidelines

  • The primary call to action should appear below and left aligned with the input fields
    Supports a clear path to completion.
  • The label should clearly indicate progress to the next step, or be labelled “Next >”
    Helps the user progress. The right arrow supports a feeling of progressing.
  • The primary button should be the most visually prominent element on the page.
  • Avoid unnecessary secondary buttons. They should be visually less prominent than the primary button.
  • Include a “back” button positioned on the bottom left of the page.
    Supporting users who need to go back to a previous page.
  • Include a left facing arrow on the back button.
    Helps give the sense of going backwards.

Common mistakes

  • Making links to static pages appear as buttons.
  • Having too many buttons on a page competing for the user‘s attention.

Common questions

Date of birth

Usability guidelines

  • Input boxes allow sympathetic input. eg for Date of birth – the user is allowed to enter: 01011970, 01/01/1970, 01 01 1970, 01–10–1970 etc.
    Lets the user choose the format they prefer. The system should manage the complexity.

Fig. 6 – example of date of birth field.

Email address

Usability guidelines

  • Email address is the most common input box with user mistakes, so when the email address accuracy is important to the task (eg. registration, or subscriptions) then the user should confirm their email address.
  • Email addresses should be captured in a single text box with no breaks. Validation of the email address should occur as the cursor leaves the text box.
  • Users are also very sensitive to providing their email address or phone number because of spam so include a note under input boxes as shown in fig. 7.

Fig. 7 – example of email address input.

Future or recent dates

Usability guidelines

  • Future or recent dates should provide a date picker shown by a calendar icon.
  • The default date should be relevant to the task in hand (e.g. today or tomorrow for the start of a policy, or in 7 days time for the end of a short–term policy).

Fig. 8 – example of date input.

Common mistakes

  • Using a date picker for date of birth or distant past dates.

Currency fields

Usability guidelines

  • Show the currency symbol (eg “£”) aligned right to input box (always outside of input box).

Fig. 9 – example of currency input.

Credit cards

Usability guidelines

  • Be aware some credit card numbers can be more (or less) than the standard 16 digits (If Aviva accept these the 4 input boxes must be combined into 1 box.

Fig. 10 – example of credit card input.


Row spacing

Usability guidelines

  • Ensure there is adequate space between questions.
    Helps users differentiate each question and find its corresponding data field.

Fig. 11 – example of row striping.

For more information on form design see Luke Wroblewski‘s book Web Form Design.


Form scrolling

Usability guidelines

  • Encapsulate content within one continuous box (with keyline) to help show users more content is hidden below the screen fold.

Fig. 12 – example of a form page.


Error messages

Usability guidelines

  • Display a summary error statement at the top of the page with a red visual treatment.
  • Highlight each error message in context with the appropriate message closely above the input field.
  • Compile user friendly error messages that inform the user how to correct the error but in language that is not blaming or will make the user feel inadequate.
  • Encapsulate the question in error with a containing red visual treatment in the manner of row striping.
    To help the user understand and be able to correct the errors while not making them feel uncomfortable.

Fig. 13 – example error page.

Common mistakes

  • Using technical messages that make no sense to the user.
  • Not informing the user how to correct the situation.
  • Messages that are cold and blaming.