Data visualisation: dashboards

Introduction

This guidance is for people working in government who want to create a data dashboard.

Dashboards can be a powerful way of allowing access to large amounts of data, which can help people make decisions.

However, poorly designed dashboards:

• make data harder to understand
• risk misuse of statistics
• may fail legal standards for content on public sector websites
• cause reputational damage

Before you start

What is a dashboard?

To some, the term ‘dashboard’ may imply a frequently updated service that allows near real-time decisions to be made about things such as operational support. But this is not necessarily the case. The dashboard in question may just be an online reporting system.

Be clear about what you are building before you start.

Make it clear to your users if your content goes live.

User needs

Dashboards have become something that is easy to ask for, partly because it is a broad request. But they are not necessarily what people need. When people ask for dashboards, we need to find out more.

We need answers to questions such as:

• What will users do with the data?
• What decisions will users make based on the dashboard?
• How will they interact with the data?
• Do they want to explore the data?
• Do they need the story told to them?
• What trends do they need to understand?
• What background information do they need to understand the data?
• Will users have the time to get insight out of dashboards?

After getting the answers to these questions, you may find you do not need a dashboard. A less complex product may meet user needs.

Lifecycle

You will need to plan to support the lifecycle of the dashboard. Do not make the mistake of thinking a dashboard is something that can be created quickly and then left to update itself.

The lifecycle should follow these steps:

1. Prototype
2. Private beta – where you do testing with invited users
3. Public beta – where you carry on testing with anyone who needs the dashboard
4. Live
5. Retirement

Retirement

Take care when organising retirement of your dashboard. Dashboards of statistics, available to the public should be published and retired in line with the Code of Practice for Statistics.

Point V2.6 in the code states:

“Statistics, data and metadata should continue to be publicly available, including when organisational websites are changed, and be archived as required in line with relevant legislation.”

Your dashboard should remain available, but if it is no longer updated this should be made clear. Relevant dates for data within the dashboard should also be clear.

Speak to people

Avoid duplication

Your organisation may already be publishing a dashboard that meets other user needs. Those needs may overlap with yours. Research the scope of your current dashboards to avoid duplication. Duplication can be confusing for users.

Check your organisation’s standards and guidance

Your organisation may have their own standards and guidance for who designs and builds digital products. Make sure you find out before you start, and work with those teams.

Involve people with a wide range of skills

A dashboard should be considered a digital service.

As with most digital services building a good dashboard needs input from people with a variety of different skills.

Dashboards should be built with input from:

• analysts
• user researchers
• web content designers
• web service designers
• interaction designers
• communication professionals
• accessibility experts
• data visualisation designers
• data architects

Without the input from all these colleagues it is easy to create bad dashboards.

Accessibility

In the UK, all content on public sector external websites and intranets must legally meet the level A and AA success criteria in the Web Content Accessibility Guidelines 2.2.

Many of these criteria will apply to dashboards. At a high level it means that dashboards must be perceivable, operable, understandable, and robust.

More information:

• Our guidance on the accessibility legislation. 
• Understanding accessibility requirements for public sector bodies (guidance from the Central Digital and Data Office)

Consequences for inaccessible content

Inaccessible content can get complaints related to the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 and/or the Equality Act 2010. This could cause reputational damage and loss of public trust.

Make sure whoever is responsible for the content you publish is aware of this and the possible risks involved.

Accessibility statement

If you publish a dashboard you should test its accessibility and be aware of any issues it has. Any issues should be mentioned on an accessibility statement, ideally alongside plans to fix them. This can be a dashboard specific accessibility statement or part of a departmental one. The GOV.UK Coronavirus (COVID-19) dashboard has a good example of an accessibility statement for a dashboard.

Off-the-shelf packages

Dashboards built using off-the-shelf software packages like PowerBi, Tableau and RShiny are difficult to make accessible. You will not have much control over the User Interface (UI) elements, or how the content is ordered and created behind the scenes. This can make it hard for keyboards and screen reader software to navigate.

You should be aware that some software packages may claim to be fully accessible, but this does not mean they meet the legal UK requirement.

Testing

Your organisation may have a team of accessibility experts. Make sure you talk to them about the best way forward.

You should organise accessibility testing. The government accessibility community  and the Basecamp for the government content community are good places to go for help with doing this.

Improving dashboard accessibility

Dashboard content

Follow our guidance for charts, tables, colours, spreadsheets and analytical publications to make sure the content within your dashboard is accessible.

Plain text alternative

Accessibility of dashboard content can be improved if you provide the data presented in an accessible format. For example, an accessible spreadsheet document. You should make sure this format communicates other elements of the dashboard, for example, metadata, commentary, and information on how datasets are related to each other.

You can find more information on making accessible spreadsheet documents in our ‘Releasing statistics in spreadsheets’ guidance.

Providing the data behind your dashboard is also important for transparency and open data.

HTML dashboards

Dashboards built using HTML code are generally more accessible if the code is used properly.

For example, you can use the code behind SVG images of charts to allow users to access the data as if it were a table. Note this example is not perfect, but you should be able to use tab and arrow keys to navigate through the values on the lines.

Similarly, if Highcharts are coded properly, users can tab through the data presented and have it read out to them. There are also new developments like sonifcation that ‘read’ charts using sound to communicate the values. See the Highcharts accessibility module for more information.

Building data visualisations using D3 (a JavaScript library for manipulating documents based on data) can also be made more accessible.

If you want help with dashboard accessibility join the accessibility community for government.

Dashboards as an accompaniment

If the data and commentary in the dashboard are available somewhere in an accessible format, the dashboard itself does not necessarily need to be accessible. Although work should be done to make it as accessible as possible.

This can be achieved by using dashboards as an accompaniment to a statistical or analytical publication.

Design

Explanatory or exploratory

Dashboards are great for data exploration. But because they tend to be frequently updated, they’re not as good at explaining what’s happening in the data.

Depending on the structure of your dashboard, you may not be able to add commentary each time the data is updated. Users may have to discover insights for themselves.

Software has made exploring data easier. But it means that rather than critically thinking about how information can be concisely presented, dashboard creators often add additional worksheets or filters. Sometimes this might be necessary, but this change means the user must sift through more information. You should think carefully about whether it is appropriate to add extra features.

Remember: information is only valuable when used, too much information can be a barrier.

Best practice data visualisation

All charts and tables in your dashboard should follow our data visualisation guidance:

• Data visualisation: charts
• Data visualisation: tables
• Data visualisation: colours

In summary, remember:

• to choose the right data visualisation for the relationship you are trying to show
• not to use 3D charts
• to be consistent with scales when you want users to compare data
• to make sure charts and tables include clear titles, axis labels, legends, and information on time period and geographical coverage
• to think about how to tell the statistical story – it may be appropriate to add a policy target or average
• to follow our guidance on colour palettes
• to make sure that your use of colour is consistent – if you have a series of charts, use the same colour to mean the same thing throughout
• to give information about sources
• to provide accessible data downloads for all charts and tables

Look, feel, navigation and structure

Inconsistent designs

Different dashboards are being made across government. The look, feel, and navigation of them is not consistent. The problems with this are:

• users need to learn how to navigate different interfaces – this can be unclear and frustrating
• the design can be confusing if it looks too different from other government content

Research what dashboards already exist. Talk to teams who have developed other dashboards.

Structure and navigation

Structure and navigation is also important. Think about how users will interact with your dashboard. Put the headlines in the top part of the dashboard, trends in the middle, and granular details at the bottom.

Test how users will move around the dashboard. Are all the buttons and links to categories in the right place?

A format with chart title, chart and short commentary allows for more context to be given. Dashboards can often fail to explain why particular data are important, or what they show. This is crucial for users. Try to answer the question “Why is this important?” with your content.

Group related data next to each other so that information flows.

Concentrate on the important insights.

Visual clutter

The look and feel can also be damaged by visual clutter. Think about what you need to show and remove what is unnecessary. Use appropriate spacing. Test your dashboard with users and speak to other specialists such as service designers.

Do not be afraid of it looking simple. Simple designs are the best! 

Scrolling

Avoid too much scrolling. Especially avoid horizontal scrolling as this can cause users to become lost or confused by the content. Remember to think about how a dashboard looks on different devices like phones and tablets.

Software packages

Dashboards usually need software packages to be built. Different packages come with different drawbacks.

RShiny requires particular infrastructure and will limit the number of people using the dashboard at the same time. While this may be OK in some situations, it can be highly unsuitable in others.

Packages such as Tableau and PowerBi have high license costs. They are relatively easy tools to use, but there is also some cost in becoming familiar with them.

RShiny, Tableau and PowerBi dashboards will all struggle to meet the accessibility requirements set out in the Web Content Accessibility Guidelines. There may also be issues with how easily they adapt for different screen sizes or different internet browsers.

There are benefits to open-source options such as ‘D3.js’. For example:

• they have no license costs
• hosting is simpler
• they are often more accessible
• there are no limits on the number of users accessing the dashboard at one time

But building dashboards using open-source tools requires higher level skills, which means that there are higher development costs.

Responsive design

Responsive design relates to how website content adapts to people viewing it on different types of device or internet browser.

We need to make sure that our content works on a range of common devices and commonly used internet browsers.

You can read guidance on designing for different browsers and devices from the Government Digital Service (GDS). Be aware that many dashboard building software options such as RShiny, Tableau, and PowerBi do not easily adapt for different screen sizes, and do not always work in different internet browsers.

Metadata – information about the data

When building a dashboard you need to think about where the data is coming from. You should also think about what the data can and cannot be used for.

You must make sure the data displayed on your dashboard cannot be combined to tell misleading or incorrect stories.

Information about quality can be difficult to display on dashboards. For example, on a chart you might use annotation to explain a discontinuity in the data, but this is much harder to do when people are creating their own charts using data from a dashboard.

Analysts need to work closely with interaction designers to create information architecture that allows:

• data to be central
• metadata, or information about the data, to be clear
• statements about quality to be obvious

You should include:

• the date the dashboard was last updated and information about what was updated
• the date of the next update so that users know when to expect new data
• a clear, appropriate and searchable title
• the time periods the data refer to
• links to definitions, guidance, and methodology
• appropriate quality information
• links to other related information
• commentary or links to commentary
• important contextual details
• contact details for the statistician or team

Open data, hosting and security

Open data

You will need to openly share your data with users, in a way that follows open data standards.

If your dashboard is powered by a database, the best practice way of doing this is through an API onto the database. You will need to make sure this data is suitably anonymised and the schema is designed to optimise data retrieval. You may need to involve a data architect for this.

If you have a simpler dashboard, supplying the data through an accessible spreadsheet document is a good idea.

If users cannot get to the data behind the dashboard, they may get frustrated as seen in this tweet.

Hosting and security

You will need to securely host your data and the dashboard. Your organisation is likely to have favoured suppliers and partners for this, and may even block you from using certain providers. Hosting is a complex business that needs commercial agreements, live service support, and performance monitoring.

Promotion and management

Finding the dashboard

You need to understand how users will find the dashboard.

Does it appear as a search result on internet search engines? Is it on GOV.UK, or is it linked to from a GOV.UK page?

Test how users will find the dashboard.

Sharing the dashboard

Dashboards are harder to share across social media or news outlets. A well-designed chart with a good title is much more likely to be embedded and shared than a dashboard. Think about what is needed to get the messages across.

Data updates

Data that can be updated daily or weekly suits a dashboard. Data that are refreshed monthly might not warrant the large amount of work associated with designing, creating, and maintaining a dashboard.

Staffing

Staff time

Dashboards should only be created for an ongoing user need. While they may be quick to set up, updates and maintenance can be a full-time job for a lot of people.

You will need to continually manage:

• differences in data sources, data structures, production timescales, and definitions
• secure publication
• comments and questions related to the dashboard

Staff cover

You must also have succession plans and full documentation with up-to-date desk instructions. You must not rely on one or two individuals to run the whole system. This is crucial to ensure your live service keeps running even when people move roles or are not in work.

Successful dashboards are usually created and maintained by large multidisciplinary teams. They are not an appropriate project for a summer internship.

Assessment and development

Your dashboard, as a digital service, may need to pass Central Digital and Data Office (CDDO) service assessments. These were formerly known as Government Digital Service (GDS) assessments.

Once your dashboard is live and has been assessed, you should continually gather feedback and act on it. You will need to iterate what you present and how you present it to make sure you continue to meet user needs.

Remember to evaluate your choice of charts over time. A chart which was appropriate at one time, may not be the best option when data is updated.

User needs, available data and the policy landscape may change over time. For your dashboard to remain relevant, frequent changes are likely to be needed.

You will also need to consider when to retire parts of the dashboard or even the whole thing. You should look at how the dashboard is being used. Evidence and analytics will help you make decisions about changes.

Because of governance around the release of official statistics, the dates and times of updates are important. We cannot release data early.

Think about who will have access to the dashboard staging service, or the version of the dashboard that gets updated before the publicly available one does.

Think about how to manage the updates in a timely manner. Automate some, or all, of the process if possible, and include an automated error checking step. Make sure the underlying data is appropriately and consistently formatted. You will need to work with data suppliers to achieve this.

Think about how dates will be interpreted. Data referring to different time periods is often the cause of misunderstandings and incorrect stories about trends.

Finally think about loading times. File sizes can often be large and when all the data is updated at the same time it causes slow load times for users. Consider if this will affect your dashboard and how you will deal with it.

Examples

Good dashboards can be created when all the considerations are taken into account.

Example 1

An example of a current dashboard is the UK coronavirus dashboard.

There are several good things about this dashboard. For example, it:

• is based on user need
• adapts to add new measures
• provides clear notes about quality
• has a known, frequent updating schedule

However, there are areas where this dashboard could be improved. For example:

• accessibility – several accessibility issues are outlined on the dashboard’s accessibility statement
• navigation – some pages refer to England data when a user might expect UK level data

You can find our more about the UK coronavirus dashboard in the following UK Health Security Agency blog posts:

• The COVID-19 dashboard: bringing together data and statistics in one place
• Behind the scenes: Expanding the COVID-19 dashboard
• The COVID-19 dashboard moves to weekly updates

Example 2

Climate change dashboard.

This is a prototype dashboard with a clean interface.

It is a product in development, which still needs to consider accessibility, data downloads and communicating information on updates in more detail.

Example 3 and 4

Understanding the UK economy dashboard.

This is a simple dashboard-style webpage from the Office for National Statistics (ONS), with tiles about different areas of the economy.

Coronavirus (COVID-19) latest insights.

This successful insights tool describes itself as “a live roundup of the latest data and trends about the coronavirus (COVID-19) pandemic from the ONS and other sources.”

Things to consider about the insights tool:

They are not traditional dashboards, they are a group of small articles tied together with navigation.

Navigation includes simple buttons and within each page, a “what’s on this page” table of contents. These are simple interaction patterns lifted from other product types like articles. ONS knows from user research these patterns will be used.

The content is prioritised and edited. Content is regularly assessed and re-ordered. Any older content is removed if it’s no longer newsworthy or interesting.

Every entry across all the pages has a journalistic heading or chart title along with a small amount of commentary. This allows the insights tool to read like a short, interesting article rather than am unchanging technical readout of data.

Examples 5 and 6

The vital signs monitor used in hospitals are a great example of a simple dashboard of vital information that can be digested quickly.

Similarly, the information about lines on the London Underground.

Related links

Any questions?

If you have any further questions you can:

• email Analysis.Function@ons.gov.uk
• join our Basecamp project for accessibility for statistics and analysis or presentation and dissemination of statistics and analysis – if you are not on the Cross Government Basecamp, email Analysis.Function@ons.gov.uk for an invite link
• contact your departmental presentation or web dissemination champion
• contact us through Twitter @gov_analysis
• Join the #design Channel on UK Government Digital Slack
• Join the #content Channel on UK Government Digital Slack