Skip to content

Build user-centred products for the Federated Data Platform

How to use this guide

By using this guide, you can help ensure that the user of your product sees a familiar and easy-to-use user-interface, and will find it similar to other products they use at work.

It’s important to ensure that all products can be used as intended and that end-users understand the interface and can get the outcome they need easily.

These guidelines come from tested NHS designs and alongside any other security and other requirements, will help you deliver products that are easier and safer to use.

Top five things to consider

1. Colours

Use this for logos, straps #005EB8
White Use this for labels on buttons, NHS logo, headings on NHS blue #FFFFFF

Users think that when colour is used it is trying to convey information, so make sure the use of colour is intentional and consistent. Don't use colour just for decoration:

  • see the section on Use of colour - to ensure consistent experience for users across all products
  • a proportion of users cannot differentiate different colours. To communicate with people who cannot see well or distinguish colours, you may need to:
    • ensure that the contrast between colours is high enough using a colour tool
    • word things differently
    • use more than one visual cue, for example, text and an icon as well as colour

2. Type sizes

  • the Workshop tool uses type sizes Small, Medium and Large. We believe that the “small” size is unreadable for many users.
  • if specifying text in points or pixels, the optimal default font size for maximum readability for most users is 19px on large screens and 16px on small screens. Font size should not be smaller than size 10px.

3. Accessibility

  • in the UK, almost 1 in 5 people have a disability of some kind. Many more have temporary or situational disabilities, like an illness or injury. When you're working on NHS internal services, think about how people with different needs might use what you're making.

4. Headings

  • make headings meaningful, let readers know where they are and what they are looking at
  • use “sentence case” for headings (capital letter at the start of sentences, and for proper names)
  • make proper use of a semantic page structure (see more detail below) to make your product readable by screen-readers
  • links should open in the same window
  • when a link will open a new tab, add the words “opens in new tab” (or window)
  • make links meaningful, do not say “click here”. Provide context where it will take the user

General guidance

Use of colour

Users find colours indicative of meaning, therefore, we need to use colour intentionally and consistently. Don't use colour just for decoration.

Core colours

NHS Blue #005EB8 White #FFFFFF

When to use a core colours

Use for branding, and main page header bar

Buttons

Primary button

Button colour #007F3B Button font colour #FFFFFF

When to use a primary button

A primary button is for the user’s main action on a page. There may not be a main action and in that case use the secondary or tertiary buttons.

Secondary button

Secondary button colour #4C6272 Button font colour #FFFFFF

When to use a secondary button

Use a secondary button on pages that have more than 1 action or when users aren't noticing standard link text.

White button on solid background colour (reverse button)

Button labels #FFFFFF Button font colour #212B32

When to use a white button on solid background colour

White buttons on solid background colour are good on components where link text, primary and secondary buttons would be lost.

On busy screens with many KPI widgets, and where there is no main action, use the white buttons and ensure to write clear and concise button labels

Text colours

Primary text colour #000000
Secondary text colour #4C6272
Use secondary text colour instead of hover-help text where there is evidence of a need for an explanation of the heading or label.

NHS blue-grey background

Page background colour #F0F4F5
This grey is better for many users – particularly when using the screens for long periods.

Error state

Error state colour #D5281B
An error state arises when a field in a form has not been filled, or has been filled incorrectly. Use to tell users if they need to make a change on the page or if there is a problem with the platform

Border

Border colour #D8DDE0
Form border colour #4C6272

Announcement panel

Warning colour #FFF9C4

Written Content

Use plain language. Research has shown that most people prefer to read plain English, and that the more specialist a person's knowledge is, the greater their preference.

Our content is factual, neutral and unambiguous. We do not use metaphors - we say what we mean.

Readability

  • use plain language and simple explanations
  • spell out abbreviations and acronyms when first used (Example: A body mass index (BMI) above the healthy weight range can increase your risk of serious health problems)
  • don’t use jargon, rather than saying ‘free text’ say ‘notes’
  • use short sentences - up to 20 words, and short paragraphs - up to 3 sentences
  • write descriptive headings and subheadings
  • do not assume our audience will be familiar with the topic

Aligning text

  • left-align text in English
  • some people with cognitive differences have difficulty with blocks of text that are justified (aligned to left and right margins)
  • also people who use screen magnifiers may miss text that is not left-aligned
  • for translations into languages that run right to left (like Arabic), right-align instead

When to use Capital letters

  • we do not use block capitals as they're difficult for people to read.
  • we always use sentence case, including page titles. The exception is proper nouns and examples in the GOV.UK style guide capitalisation list.
  • generic drug names start lower case. Brand names get an initial capital letter, except where the brand uses lower case itself, for example:
    • Codeine comes mixed with paracetamol (co-codamol) or with aspirin (co-codaprin) or with ibuprofen (Nurofen Plus).
  • conditions are lower case except where they start with a proper name. For example:
    • Alzheimer's disease
    • cancer of the colon
    • Down's syndrome
    • multiple sclerosis
    • Parkinson's disease
    • type 1 diabetes
    • But note: caesarean section.

    Tone of voice

    • use the active voice - "Book an operating theatre" rather than "an operating theatre can be booked"
    • there’s usually no need to say "please" or "please note" or "thank you"

    Numbers, dates and time

    • we use numerals for numbers (including 1 and 2)
    • for numbers over 999, use a comma for clarity (for example, 1,000)
    • always start with zero for values less than 1 (for example: 0.75 not .75)
    • ensure negative values are indicated by a minus sign (for example: -65)
    • we spell out "one" when it means "a" or to avoid repeating a word

    Dates

    • always use UK format for dates, do not use American format
    • use this format for dates except when a short date is needed (see below): 6 August 2018
    • if you need to include the day of the week, use this format: Wednesday 6 August 2018
    • short dates should be formatted DD-Mmm-YYYY(example: 06-Aug-2018)

    Time

    • Use the 24 hour clock, formatted 00:00, for ALL times in the products. The reason is that it makes it difficult to mistake a morning for an evening time. (Example: 6 in the morning is 06:00, 4.30 in the afternoon is 16:30)
    • "6 hours 30 minutes", not "6.5hrs"

    Information hierarchy (Semantic page structure)

    • any user with special needs (for example impaired vision) who uses a screen-reader, will rely on the HTML to read the page
    • headings and sub-headings should follow a logical hierarchy
    • only one H1 header (always page title). Make sure headers and sub-headers are labelled correctly for screen readers
    • The second heading on a page should be a H2, any subheadings to this section a h3. You can have more than one H2
    • heading levels can never be skipped on the way down (H1, H2, H3, H4, H5 and H6) but can be on the way up (H4, H2)
    • when placing links in body text, hyperlink the title of the content only, and don’t show the Url in the text
    • do not hyperlink headings or subheadings
    • If links do go to a new window, warn the user by adding: "(opens in a new window)" after the link title

    Do use buttons to start or save transactional journeys.

    Don't use buttons as links:

    • to pages which aren't part of your user journey
    • from 1 flat content page to another
    • to external websites

    Only use as main buttons as a user needs to do their work. Do some usability testing with a range of real users to check that their function is understood.

    Tool Tips

    • use tool-tips sparingly. Where possible add a second line after a heading or label, using colour "secondary text colour" (#4C6272) where an explanation is needed
    • the tool-tip must be usable by users who only use a keyboard, and screen readers must be able to shift focus to and from the tool-tip
    • where possible, ensure that the tool tip does not obscure what the user is focused on

    Data Visualisations

    • every chart or other visualization must have a title. This benefits all users, and particularly those using a screen-reader. [type size medium]
    • keep axis titles as short as possible [type size medium]
    • category names on a chart axis or in a legend should be clear and concise [type size medium]
    • for data from two or more time periods, put the older values before the newer values
    • always include some written explanation for the chart and an accompanying table for those who cannot use the data visualisation
    • include a source for the data, for example the names of datasets that have been combined - so that a user can track back to the original data

    Chart colours

    We recommend using no more than 6 different variables (colours or tints) on a graph or other chart type, otherwise your visualisation will be confusing. If you need to plot more than 6 variables, you should consider alternative ways to visualise this information.

    Use the colours listed below, which have been tested for accessibility, in this order:

    Dark Blue #12436D
    Turquoise #28A197
    Dark Pink #801650
    Orange #F46A25
    Dark Grey #3D3D3D
    Light Purple #A285D1

    Gridlines

    • most chart types should have gridlines on at least one axis
    • all numeric axes, except for those showing time or bands of values, should have gridlines
    • time axes should have tick marks, but not gridlines
    • axes showing discrete categories should not have tick marks or gridlines
    • the line at the zero point on your axis should have more emphasis than standard gridlines
    • gridlines should be at sensible, round-number, intervals
    • gridlines should always be labelled with the value they represent

    Tables

    • whenever possible, ensure that table width does not cause the user to have to scroll horizontally
    • ensure that cell height can expand to accommodate its content - Do not let text be obscured or clipped by a cell that is too shallow

    Images

    Informative images

    • do not use text in images
    • provide alt-text when images convey meaning or information.
    • keep alt-text to around 125 characters or 2 sentences
    • if there's important information that you cannot fit in 125 characters (for example, you're describing a complex chart), include this information in the alt-text or consider linking to more information for screen reader users.

    Decorative images

    • avoid them in data products unless they convey useful information
    • if an image is decorative, give it a null text alternative like this: (alt="")

    Product tiles and other large buttons

    • If there is a need to add an image to a product tile, ensure that it is a copyright free image that is meaningful to users, and not a screen-grab of a product page because these are not helpful when visually searching for a product

    Templates and Widgets

    In future versions of this guide, there will be guidance here on use of widgets and templates in Workshop, and where possible, direct links to the templates. We will also include annotated images of available templates to make them easier to work with.

    The templates, widgets and code will be accessed in Foundry as usual

    Further information

    Accessibility

    Data visualisation

    Content design