Designing usable forms

When collecting data from users, there are a number of things you can do to make the process easier, and also a few things to avoid that might present obstacles to user or cause them unnecessary work.

In a nutshell, you should:

• structure your form appropriately
• be forgiving and helpful when handling user errors
• use form elements correctly
• tell users what information you're asking for and why
• provide clear feedback on user actions, use appropriate logic to guide the user and avoid asking for information you don't need
• ensure that all interactive elements can be used by all users
• ensure your language is appropriate to your audience

For more information, read on...

Structure and Layout

Maintain one column

• Easy to scan, improved readability
• Having multiple columns means fields can be missed
• Fewer user errors
• Higher completion success

Multi-stepped forms

• Large forms can give the impression of complexity and cause a negative emotional response
• Organise form fields into logical groups e.g. personal information, Application details etc

Presentation

• Provide visual clues - the sections you want to users to pay attention to should be the most prominent in terms of order, size etc.
• Use call to actions - provide big buttons for users to press.

Error Handling

• Give user feedback as soon as possible.
• Describes the issue as accurately as possible using non-technical language.
• Ensure that the feedback is actionable: where possible provide guidance on how to resolve the issue.

Needs to be meaningful, descriptive and constructive

• Don’t blame the user
• Don’t validate or display an error until the user has been in and out of the field
• Don’t use exclamation marks
• Don’t display error messages before the user has entered a field
• Show errors inline - don’t group them all together at the bottom/top of the page on submissions
• Provide feedback for successful actions, so users know it’s worked

Specific error messages for common form fields

Form elements

Avoid reset and clear buttons

They can increase the risk of accidentally clearing form data.

Inputs

It is important to select the right form element for the right type of information, in order align with user expectations, reduce errors and improve efficiency.

Checkboxes:

• Choosing only one item for a selection: of 2 -10 options
• Ensure labelling shows whether users can select one or multiple options

Radio Buttons:

• Choosing only one item for a selection: of 0 -10 options
• For more than 2 options the buttons should be stacked
• Larger radio buttons are easier to select with a mouse or touch device

Dropdown box:

• To be used if screen space is limited and there are more than 10 options
• They can be difficult to navigate so avoid where possible.
• Add a meaningful default if applicable e.g. United Kingdom for a UX based user
• List options alphabetically to make scanning easier
• Consider a searchable dropdown where possible

Single line text fields:

• Use for short, single line data that only requires basic validation
• If used for email capture ensure validation is in place to only accept email in the correct format

Multi line text fields:

• For longer, free-form text input that could span multiple lines e.g. comments, descriptions etc
• Height can be adjustable

Number fields:

• Use when the input should only be a number e.g. age, quantity etc

Date and time input fields:

• Use a date/calendar picker when selecting a specific date
• Context is important but often best to provide a visual calendar that allows easy navigation between months and years
• Include a visible text field that shows the selected date
• Expected date format should be DD/MM/YYYY
• Restrict available dates if there are valid ranges e.g. no past dates if booking a venue

Time picker:

Use for selecting a specific time e.g. an appointment

Specify whether using a 12 hour (am/pm) or 24 hour format

File upload:

• Tell users what file they are being asked to upload e.g. Upload your results, Photo of your dog
• Make it clear what file types are supported e.g. pdf, jpg, png etc
• State maximum file size
• Confirm that the upload has been successful
• Ensure any error messages clearly state the problem e.g. file type not supported
• Provide visual feedback such as a progress indicator during the upload process
• Allow drag and drop functionality

Labels

• Don’t place labels in the field as this increases user error - places unnecessary burden on short term memory i.e. if user starts to complete the field, deletes the label in the process and then forgets what they are writing
• Use text labels above the field, hint text within
• All form fields should have a label
• Label text should be short, clear and in sentence case
• Clearly communicate any character limits

Buttons

• User verbs on buttons - Sign up. Log in. Save.
• Avoid reset and clear buttons - they can increase the risk of accidentally clearing form data

Field sizing

• Make field widths proportional to the input they take e.g. a postcode field doesn’t need to be as long as comments field
• Form fields should be 100% width for smaller screen sizes
• Field height should be proportional to the amount of text to be entered e.g. a comments field will be higher than a postcode field

Guidance

Provide users with as much information as possible about what you are asking for and why.

Indicate which fields are mandatory or optional

• This will reduce unnecessary error messaging
• Only ask for the information you absolutely need
• Ensure mandatory fields are also flagged as required in the code to support accessibility
• If most fields are mandatory, it's more efficient to only mark optional fields. 
• If there’s a mixture of mandatory and optional field types the asterisk (*) should be used to indicate mandatory.

Feedback

Provide clear and immediate feedback for user actions, such as successful completion of a task, error notifications, and loading indicators.

• Provide confirmation of completion for actions such as saving, adding uploading, etc.
• Let users know when they need to take action and what that action is
• Let users know when the system is processing an action and they need to wait – for example use a progress bar to show processing time
• Ensure assistive technology is able to keep users informed of dynamic content changes in the page (e.g. an error message) by using Aria live regions.
• User colour to reinforce messaging (e.g. red for errors, green for success)

Logic

Enable autofill and autocorrect

• Reduces friction
• Reduces errors
• Makes the user journey quicker
• Can reduce drop off- e.g. if payment details don’t autocomplete the user may go elsewhere as they may not have their payment details to hand

Use tools (APIs) to support location information where possible

Autocomplete

As someone starts typing in their address such as 1^st line of address or postcode, the form suggests, full, verified addresses making it quicker and reducing errors.

Tools such as ‘Google Places API, Postcode anywhere etc’ can be used depending on product it needs to integrate with.

Always allow users to manually enter their address if the auto complete doesn’t work

Geolocation

When the form’s primary purpose is related to the user’s physical presence the form asks for permission to know their location. When granted it can provide the location details or show on a map. Useful in situations where users need to find nearby services e.g. find bookable space near me

Avoid captchas

• Many are inaccessible and cause frustration
• Their use can decrease completion rates
• Other technical solutions can be used to prevent bots such as:
  • Honeypot fields
  • Client side/Javascript challenges
  • Server side validation and logic
  • Third party anti-spam services

A layered approach should be taken as no single method is 100% fool proof.

Interactivity

Keyboard navigation

All functionality must be operable through keyboard input alone, supporting users who rely on screen readers or have motor impairments.

• Test the interface using a keyboard to navigate.
• Provide strong visual indication of element focus.
• Consider logical structure of elements.
• Ensure all interactive elements are accessible via keyboard.

Language and Vocabulary

The language used in the system to describe roles, processes, statuses etc. should conform to any pre-existing vocabulary relating to the tasks at hand.

Know your audience, and only use language you’re confident they’ll understand.

• Use active voice, e.g. say: “please complete all fields” not “all fields must be filled in" - this places the emphasis on the action rather than the object.
• Use pronouns - “you” for the user, “we” to represent the organisation.

Ensure that cultural norms and expectations are considered in the design to make the software accessible and user-friendly for users of any cultural background.

• Proofread content to ensure language is clear and appropriate for a diverse global audience.
• Avoid acronyms that are University specific.
• Use plain language, avoid jargon.
• Avoid gendering in theoretical examples (use ‘they’ rather than ‘he’ or ‘she’).
• Be mindful of terms related to race, ethnicity, nationality and culture.
• Be mindful of medical conditions and ability terms.
• Use person first language. For example, people with disabilities as opposed to disabled people or the disabled.