User notifications

Keeping the user informed is a vital aspect of forms.

The aim is to create a dialogue with the user and support them by reacting to their input. Helpful validation messaging and feedback builds trust and helps reassure the user. Getting this right relies on the user being at the heart of the form design, and can have a huge impact on the success of the form and consequently the service.

Validation messaging

There are two types of validation;

  • Instant (as the user completes each field)
  • Page reload (after submit/next)

The user does not differentiate between types of validation and so it is important to maintain a level of consistency in how this is handled on the front end.

Instant validation

Instant (client-side or inline) validation reacts immediately to user input. It is important to not prematurely indicate an error. This can distract, annoy or disengage the user. Therefore show error messages only after the field has lost focus. On correction of the error this should be corrected real time to quickly reduce the error states and reward the user for the correction.

Screen readers: Error messages should be read out when the field has lost focus.

forms_instant_validation example
If a user has tabbed or selected a mandatory field and then moves on to the next field without entering anything, an error message will trigger on ‘blur’ (de-focus).

Page reload validation

Page reload (or server-side) validation checks all the form fields are correct on submit/next. This can check inputs against databases and more sophisticated validation that isn’t usually handled by instant validation. Page reload validation works alongside instant validation and allows users to see a list of all the errors at the top of the form, linking to their corresponding fields where the error message is also displayed.

This validation is not able to react to user input, so the errors are not removed when they are corrected, only when the submit or next button is selected again. However, the field in error adopts neutral state as soon as the user interacts with the field and the associated error message turns from red to grey.

forms_reload_validation example
This example shows what might happen on 'Submit / Next’. The user is taken to the error playback box on the same page with a mixture of server-side and client-side errors. Since we are not validating the server-side errors in the browser, instead of the error state persisting even after correct input, the error state is removed on any change. The inline error message and the playback message both turn to grey. Crucially, there is no strong green tick validation, as this would be mis-leading.

Neutral, error and validated state

A neutral state is a field that has no indicators on it and uses default styling to indicate how the user interacts with it, for example hover, focus, selected state.

An error state is indicated with a red 2px border and a red text error message. Once corrected, the field will return to a neutral state. If validation can confirm that the input is correct, for example a “confirm password” field can be validated against a “new password” field, then the validated field’s border turns green and a tick is displayed within the field, aligned to the right.

As page reload validation can not be checked until the page is submitted, the page reload error will be greyed out but will still be visible. This is to show that there has been a change which might have corrected the error. Leaving it visible allows the user to cross-reference their input with the error message.

forms_validation_state_removal example
1 - Client side error message triggered on blur (de-focus) 2 - Error message and error state removed on correction

Language

It is very important to be clear and to the point but also friendly and understanding. For example it’s not helpful to say “incorrect date” instead say “Sorry, you must be aged 18 or over to use this service - please check you’ve entered the correct date of birth”.

Feedback

Success page

It is important to reassure the user that their information has been safely sent so they know they have completed the task. The Success box at the top of the page should display “Thank you” to let the user know you appreciate their effort. This is accompanied by a sentence telling the user what has happened e.g. “Your application has been submitted. An email summary has been sent to the address provided”.

The success page should not be viewed as the conclusive step of the journey. At this point you are still hand-holding. Use this page to set out the next steps. Provide the user with a reference number, and any other helpful information. If there is a logical conclusion to the journey then highlight that link e.g. Track the progress of your application.

If there is a way of users tracking or chasing up their submission, e.g. tracking code, reference number etc. then all details for this should be displayed.

Help the user once the form is complete to carry on their journey. It could be as simple as saying “Check your email for confirmation”. Always be thinking, ‘What is the user’s next question?’.

forms_success_page example
Don’t just focus on what’s wrong. Be sure to give the user a pat on the back at the end of the form. And remember, the end of the form isn’t the end of the process, so clearly communicate next steps or options