[Feature] Design new validation component

[KatiePUX]

Is your feature request related to a problem? Please describe. The current presentation of validation is causing issues with spacing and is not in live with gov standards

Describe the solution you'd like Design spike to explore the best possible presentation of validation, collaboration with team to design a new design for validation

[KatiePUX]

Katie to add examples of before and after - total revision of validation (including the exclamation mark)

[KatiePUX]

Validation Content Design to be included on Validation Pattern page:

Content design Validation messages should include the same language as the question or fieldset label. This helps users to match up the error message with the relevant form field. Here are some examples of label and error message pairs.

Example 1: Label: ‘Is a full report of the survey included?’ Error message: ‘Enter if a full report if the survey is included.’

Example 2: Label: ‘Organisation name’ Error message: ‘Enter your organisation’s name.’

Be clear and concise

Describe what has happened and tell them how to fix it. The message must be in plain English, use positive language and get to the point.

Do not use: technical jargon like ‘form post error’, ‘unspecified error’ and ‘error 0x0000000643’ words like ‘forbidden’, ‘illegal’, ‘you forgot’ and ‘prohibited’ ‘please’ because it implies a choice ‘sorry’ because it does not help fix the problem ‘valid’ and ‘invalid’ because they do not add anything to the message humorous, informal language like ‘oops’. Do not give an example in the error message if there is an example on the screen.

For example, if you are asking for a National Insurance number and include ‘QQ 12 34 56 C’ as hint text, do not include an example in the error message.

Be consistent

Use the same message next to the field and in the error summary so they: look, sound and mean the same make sense out of context reduce the cognitive effort needed to understand what has happened don’t rely on the user needing to remember what has happened or return to an earlier part of the journey to check what has happened.

Be specific

General errors are not helpful to everyone. They do not make sense out of context. Avoid messages like:

‘An error occurred’ ‘Answer the question’ ‘Select an option’ ‘Fill in the field’ ‘This field is required’

Different errors need different messages. For example, text fields may be:

empty too long too short using characters that are not allowed in the wrong format.

An error for a specific situation is more helpful. It will tell someone what has happened and how to fix it.

Use instructions and descriptions

Some errors work better as instructions and some work better as descriptions. For example: ‘Enter your first name’ is clearer, more direct and natural than ‘First name must have an entry’ ‘Enter a first name that is 35 characters or less’ is wordier, less direct and natural than ‘First name must be 35 characters or less’ ‘Enter a date after 31 August 2017 for when you started the course’ is wordier, less direct and natural than ‘Date you started the course must be after 31 August 2017’.

Use both instructions and descriptions, but use them consistently.

For example, use an instruction for empty fields like ‘Enter your name’, but a description like ‘Name must be 35 characters or less’ for entries that are too long.