Data visualisation: building and managing dashboards – Government Analysis Function

Data visualisation: building and managing dashboards – Government Analysis Function
Skip to content
Table of contents
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.
Back to top of
page
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
Back to top of
page
Lifecycle
A dashboard lifecycle should follow the lifecycle for a
government digital service produced through agile methods
, with the following stages:
Discovery
Alpha
Beta
Live
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.
Retire your dashboard if it is not being maintained or user feedback indicates that it is no longer:
useful
relevant
providing value for money
Add a banner on all pages of the service to let users know the dashboard will be retired and no longer updated.
Do this at least six months before retirement to provide time for users to:
be made aware that the page will be withdrawn
give feedback if they still require access to the statistics in a particular format
Some suggested wording is:
“This product is longer updated and will be withdrawn on [month] [year]. Please contact [contact mailbox] if you have any concerns or feedback. Once withdrawn, the webpage will remain available via [for example. the UK Government Web Archive].”
If a public facing statistics dashboard is the only route for public users to access that data, it must be retired in line with the
Code of Practice for Statistics
Point
V2.6 in the Code of Practice for Statistics
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
.”
Archive your dashboard by:
following proper procedures to preserve the original state (dashboards are often hosted on servers where updates can affect dashboard functionality)
keeping data and metadata available, with a clear note that it is no longer updated and the dates or period the data is associated with
retaining any code used for the dashboard in a public GitHub repository
marked as archived
– this will help users recreate any visualisations
If a dashboard is public facing but not the only route to access the data, you may be able to use a holding page to point to the original data and the dashboard code.
The archiving process will be easier if you developed your dashboard to be easily archivable. The National Archives have
some guidance on how to make a product technically compliant
If it is not possible to archive your dashboard in its current form,
contact The National Archives
. If users do not need access to the full dashboard, it may be sufficient to retrain only the underlying dataset. If you publish separate data tables on gov.uk, there could be an option to withdraw the dashboard and archive the data tables page through The National Archives. Alternatively, if the data tables are not available separately from your dashboard, you may be able to archive these independently through the
UK data service
The
climate change dashboard
is a good example of how a government department has retired a dashboard.
The page clearly states that the item has been archived, and links to the National Archives page.
On the archived page itself, you can see:
a version of the page
the date that it was archived
the dashboard owners clearly marked that the dashboard would be retired over a year in advance
Back to top of
page
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
Back to top of
page
Latest
A user guide to international trade statistics and trade asymmetries
10 April 2026
Adolygiad o’r safon wedi’i chysoni ar gyfer ethnigrwydd: meini prawf gwerthuso a ddefnyddir ar gyfer opsiynau ymateb ychwanegol yn y safon newydd
4 March 2026
Review of the ethnicity harmonised standard: evaluation criteria that will be used for additional response options in the new standard
4 March 2026
Data visualisation: examples of dashboards
6 February 2026
Data visualisation: dashboard software
6 February 2026