Open KatiePUX opened 5 months ago
KatiePUX
commented
1 month ago Discussed implementation with Naran - adding a new section after accessibility on each page called 'content design'. For the validation content design I will move this to the Validation pattern ticket.
developernm
commented
1 month ago I've done this, just need to confirm the formatting of the content after stand-up tomorrow.
Modal dialogue
Dialogue
Read More
developernm
commented
1 month ago
Is your feature request related to a problem? Please describe. Content design have provided us with updated content patterns for design system pages as follows:
Modal dialogue
Content Design: When using the modal dialogue, you must: make it clear why you are displaying the modal dialogue using plain language not assume why the modal dialogue has been triggered. For example, using language like ‘Are you sure you want to leave this page?’ when the action to exit could have been accidental help users to understand what will happen next based on their next action.
Have clear and concise content and do not use: jargon like 500 or bad request ‘We are experiencing technical difficulties’ red text to warn people.
Dialogue
Content Design: When using the dialogue component, you must: make it clear why you are displaying the dialogue using plain language help users to understand what will happen next, including timeframes if relevant. Have clear and concise content and do not use: red text to warn people.
Specifically for info dialogues, you must: have clear and concise content and do not use vague, unhelpful words like ‘maintenance’ or ‘improvements’ include contact information, if it exists and helps meet a user need include a link to another service, if they can use it to do what they came to do.
Specifically for warning dialogues, you must: help users to understand what will happen next based on their next action.
Specifically for error dialogues, you must: include information about what has happened to their answers if they are in the middle of a transaction include contact information, if it exists and helps meet a user need include a link to another service, if they can use it to do what they came to do.
Contact information should either be: a link to a specific page that includes numbers and opening times include all numbers and opening times.
Have clear and concise content and do not use: jargon like 500 or bad request ‘We are experiencing technical difficulties’.
Read more
Content Design: When using the read more component, you must: write the heading and summary line like any other button text use sentence case describe the content that will show keep it short (screen readers might find it difficult to navigate the component if the button text is too long).
Do not use the read more component if: it’s content that all users need to see. you can simplify or reduce the amount of content.
Validations
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.