Data visualisation: building and managing dashboards

Deciding whether you should build a dashboard

What we mean by ‘dashboard’

A dashboard is a valuable visual tool that:

• is updated regularly with minimal effort
• is interactive and visualises data
• immediately presents data to the user without lots of commentary or analysis

Dashboards rarely meet full accessibility requirements. This means you should:

• not publish a dashboard without the data being available in another form
• consider a statistical bulletin to accompany your dashboard

Alternative formats may better address user needs or be a better use of resource, so you must have clear justifications for any proposed dashboard. Only consider using a dashboard when:

• there is an identified user need
• data updates are frequent and can be automated, with users likely to revisit the dashboard
• users need flexibility of data combinations and the ability to interact with data
• you have sufficient resource to support the dashboard

Advantages of dashboards

Dashboards can have several benefits, including:

• exploration of data
• allowing users to get specific outputs (such as tables or charts) without going to statistics teams
• improving users’ understanding of the data by quickly generating bespoke visualisations, including for additional breakdowns

Disadvantages of dashboards

Dashboards are not good at explaining what’s happening in the data and users may have to discover insights for themselves.

Only create a dashboard if you have a clear justification, as dashboards:

• put the burden of understanding data and important messages onto the users
• are not suitable for data that requires a large amount of explanation
• can quickly become obsolete if findings and user needs change
• require resource to maintain and improve
• require additional knowledge of maintaining a digital service
• can overwhelm users
• can risk the misuse of statistics

Non-dashboard alternatives

Users may ask for a dashboard, but a simpler, less resource-intensive alternative may be more appropriate.

A significant advantage of dashboards is the ease of updating the data. If the data in the dashboard is unlikely to update regularly, it is unlikely that it will be worth the large amount of work associated with creating and maintaining a dashboard.

Discuss with your users why they think they need a dashboard. If you do not think a dashboard is needed, explain to your users that their request can be more quickly met with alternatives which can still feature interactive elements. Alternatives could be:

• official statistics releases
• standalone data releases
• slide packs
• visual infographics

There are risks associated with dashboards as self-serve products. For example, as dashboards do not allow for commentary there is a risk that users may be lead to the wrong conclusions about data. You should make these risks clear to users. A report could give the ability for analysts to provide commentary, which could be more useful if the subject area is sensitive or changeable.

Finally, work with your user to establish which alternative to a dashboard would meet their needs.

Before you start

Staffing

Dashboards often require more resource than initially identified due to their complexity. They are not an appropriate project for a single person or for temporary staff. They should be created and maintained by multidisciplinary teams.

A dashboard is a digital service, which means you must have the skills and resource to continually manage:

• user comments and questions
• the flow of data going into the dashboard
• the accuracy and suitability of visualisations
• relevance of the dashboard over time
• secure publication and hosting

This will require input from a variety of skillsets, ideally including from:

• analysts
• user researchers
• content designers
• web service and interaction designers
• accessibility experts
• data architects

Ensure succession plans and suitable documentation to keep your live service running when people move roles or are not in work. This is especially important for the dissemination of official statistics.

User needs

You must be confident about how a dashboard meets the needs of your users.

Always get feedback from your users before you make any changes to data dissemination. Create a good relationship with your users, so you can change or discontinue your dashboard based on their needs.

Questions to ask your users include:

• How are users going to interact with the dashboard and its data?
• What trends do they need to understand?
• What will users do with the data?
• Do users want visualisations?
• What decisions will users make based on the dashboard?
• Do they need the story told to them through written commentary?
• Will users have the time to get insight out of dashboards?
• What kind of guidance or instructions do we need to give users to understand how to correctly use the data and the dashboard?

Speak to people

Never create a dashboard in isolation. Speak to people before and during the creation of a dashboard to ensure consistency across government. This may include, for example:

• researching current dashboards and their owners in your organisation, as duplication can be confusing for users
• checking if your organisation has its own digital product guidance and working with its owners

Lifecycle

A dashboard lifecycle should follow the lifecycle for a government digital service produced through agile methods, with the following stages:

1. Discovery
2. Alpha
3. Beta
4. Live
5. Retirement

Your dashboard may need to pass Central Digital and Data Office (CDDO) service assessments. Work with digital specialists in your department to agree the process for this.

Stage 0: Discovery

Before you build anything, use the discovery phase to engage with your users to ensure the dashboard is the right option to meet their needs.

Aim to understand:

• whether a dashboard is the right resource
• who your intended users are and what they are trying to achieve
• what others services your users use and their limitations
• if the data is already published in another format

Your dashboard must meet the Code of Practice for Statistics, especially in respect to trustworthiness, quality and value. Talk to your Statistics Head of Profession about how you can best achieve this.

Move to the next phase when you are confident that you understand your users and the use cases for your dashboard.

Stage 1: Alpha

The alpha phase involves building prototypes to share and test dashboard designs. It is a perfect time to explore new approaches.

In this stage, consider:

• the right software choice for your user needs and resources, including hosting and licence fees (which require consideration from early on)
• how you will meet accessibility requirements (to avoid making bigger changes later)
• your dashboard archiving process and how the product will be easily archivable (the National Archives have some guidance on how to make a product technically compliant)

Get prototypes in front of users quickly, so you can iterate on the design. Then, begin conversations about moving into the beta phases.

Stage 2: Beta

Government digital services have two beta phases:

• private beta – where the service is tested with a closed group of invited users
• public beta – where the service is fully open to all, whilst still regularly iterated on through user feedback

You may go straight to a public beta to get feedback from users, but this will depend on your knowledge of your users and how well your product meets their needs.

Include testing and tracking how users find the dashboard during your private beta, considering if it:

• appears as a search result on internet search engines
• is linked to from a GOV.UK page

During public beta:

• regularly get feedback through user research to understand how your service is meeting user needs
• actively monitor usage analytics and success metrics to assess the service and its future
• keep improving the service based on what you learn

You can end public beta if you have enough evidence that the service is providing value for money and is successfully meeting the needs of users. If you are finding this difficult, consider retiring your dashboard.

To move to the live phase, work with digital specialists in your department to assess when your service is ready.

Stage 3: Live

During the live phase, you should continually gather feedback and adapt the service to meet evolving user needs. This should continue even when the service is likely to be well established.

When updating the data in your dashboard, add a change note explaining the change and when it happened. Always make it clear which dates or period your dashboard is relevant to. Clearly link to any data no longer used in the dashboard, which should remain available either inside or outside the dashboard.

Stage 4: Retirement

This guidance applies to all public facing dashboards. Organisations may have their own processes to follow for retiring internal dashboards.

Helpful links

The Analysis Function Central Team has published several data visualisation resources.

You may find the following links useful:

• Andy Cotgreave’s video on dashboards
• Dundas Data Visualisation comparison between reports and dashboards

If you have any further questions or want to discuss updates to this page, 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
• join the #design Channel on UK Government Digital Slack
• join the #content Channel on UK Government Digital Slack
• join the #chat-data-vis channel on Gov Data Science Slack