From: DHSC
Assessment date: 29 April 2023
Stage: Alpha
Result: Met
Service provider: UKHSA
Service description
The winter viruses dashboard is a cost-effective, sustainable and scalable solution for an enduring public dashboard, which will act as a one-stop shop for priority UKHSA data and trends – starting with coronavirus and other respiratory viruses. This will enable us to proactively share relevant and useful data, trends and information, in a timely, user-centred and transparent fashion. It will meet the needs of multiple users through different features, namely a curated and accessible front-end interface for the public, as well as more granular data download functionality through APIs for professional users, such as academics, media and industry.
Service users
This service is for:
- general public
- vulnerable, elderly and carers
- media and journalists
- epidemiologist, academics and researchers
- local authorities (higher tier)
- local community volunteers
- senior public health officers
- regional ambulance data reporters
- internal UKHSA employees, including data scientists
Report contents
- Understand users and their needs
- Solve a whole problem for users
- Provide a joined-up experience across all channels
- Make the service simple to use
- Make sure everyone can use the service
- Have a multidisciplinary team
- Use agile ways of working
- Iterate and improve frequently
- Create a secure service which protects users’ privacy
- Define what success looks like and publish performance data
- Choose the right tools and technology
- Make new source code open
- Use and contribute to open standards, common components and patterns
- Operate a reliable service
1. Understand users and their needs
Decision
The service met point 1 of the Standard.
What the team has done well
The panel was impressed that:
- the team has extensively and continuously engaged the users of the current COVID dashboard through monitoring analytics, social media scanning, and conducting quantitative and qualitative research activities
What the team needs to explore
Before their next assessment, the team needs to:
- conduct additional research with members of the public who are currently not users of the COVID dashboard to test their riskiest hypothesis for this user group, namely whether members of public need to access population health data outside of the COVID-pandemic and why. This should be tested rigorously to avoid what was usual and relevant only during the COVID pandemic. This should be used to inform a possible greater focus for the service for different user groups, for example professional users, vulnerable users and their carers, and the public during a local or national emergency
- conduct additional research with professional users testing the specific journey that they are more likely to use to interact with the service, such as the main dashboard, data download via dashboard and data download through the API
- continue testing and challenging the name of the service with user research techniques that are more generative, such as open card sorting and natural key-word searches, to truly propose a name that is driven by the users’ mental model and matching what they think they are doing when interacting with this service
- conduct substantial additional research for accessibility, inclusion and digital and data maturity. This is needs to be extensive if their core user group for the service ends up being the public
- continue to work to clearly distinguish and never conflate user needs, meaning an individual’s need to access information to take an action, with business needs, meaning the organisation’s need to educate and influence or prevent actions with information
2. Solve a whole problem for users
Decision
The service met point 2 of the Standard.
What the team has done well
The panel was impressed that:
- the team has identified a wide range of personas and user needs
What the team needs to explore
Before their next assessment, the team needs to:
- create journey maps, or similar, to illustrate the most common user journeys or tasks. For example, viewing data on the dashboard, downloading data on the dashboard, accessing data through the API. As well as to help explore the end-to-end user journey in more depth
- understand user needs of potential service users who are not already using the coronavirus data dashboard
- consider focusing on a narrower group of users, such as the professional users, in private beta and broadening this over time
3. Provide a joined-up experience across all channels
Decision
The service met point 3 of the Standard.
What the team has done well
The panel was impressed that:
- the team has considered multiple ways to access and view data: dashboard, download, API
- there are rigorous quality assurance (QA) processes for the data, with acknowledgement that the team plans to make these more efficient
What the team needs to explore
Before their next assessment, the team needs to:
- consider whether some user needs, for example vulnerable users making an informed decision about which supermarket to go to, might require different or additional channels
- consider and document how different users might enter the service and how this could affect their experience aligning to user needs where possible
- explore what a non-digital journey looks like and what signposting can be provided for those users with low digital literacy or confidence
4. Make the service simple to use
Decision
The service met point 4 of the Standard.
What the team has done well
The panel was impressed that:
- the team has used known patterns and iterated intelligently on the existing COVID - dashboard where appropriate
- the team has a view of what devices users are accessing the service with and have begun to reflect this in their designs
- the team has iterated the prototype a lot during alpha and reflected this in an easily accessible view which also considers version control
What the team needs to explore
Before their next assessment, the team needs to:
- carry out more robust usability testing to ensure that the different users of the service – especially those with access needs or low digital confidence – can effectively use it as the usability testing numbers during alpha and discovery were relatively low
- consider how the navigation bar and information architecture of the service can scale over time based on different users and their needs to help them find what they need easily. This is especially important if the service has a view of one day becoming multipurposed
- continue to ensure that the usage of all device types is considered and, where possible, link this to performance data to help inform design decisions as the service scales
5. Make sure everyone can use the service
Decision
The service met point 5 of the Standard.
What the team has done well
The panel was impressed that:
- the team has ensured that a content designer has been involved in the alpha and has worked collaboratively with interaction and other disciplines to iterate and champion design principles like the use of plain English
- the team has taken a lot of useful existing research from the COVID-Dashboard to help inform design choices and not look to fix problems with known solutions
- the team were involved in attempting to name the service including internal stakeholders
What the team needs to explore
Before their next assessment, the team needs to:
- conduct a full external accessibility audit and publish an accessibility statement
- explore what an assisted digital journey could look like for users and what additional signposting can be included into the design to support those with low digital literacy
- explore and aim to define what success looks like for a user of this service. This may be reflected in the designs and supported by data as well as the use of a performance framework to better understand if users got what they needed or not
- continue to test and iterate content with potentially vulnerable users as the service scales to ensure that marginalised groups or people with access needs are not presented with alarming or possibly harmful language
6. Have a multidisciplinary team
Decision
The service met point 6 of the Standard.
What the team has done well
The panel was impressed that:
- the team will remain stable as they move into private beta
- the team has an open vacancy they can use at their discretion to fill whatever gap they need
- the team was able to fill in for the missing delivery manager and product manager while they were being recruited
What the team needs to explore
Before their next assessment, the team needs to:
- consider what roles might be needed for public beta and plan for how to fill these
7. Use agile ways of working
Decision
The service met point 7 of the Standard.
What the team has done well
The panel was impressed that:
- the two teams have a good mix of ceremonies and regular meetings that enable collaboration without requiring everyone to attend everything
- the team has good collaboration between designer and developers, especially through the designer attending the development team stand up
- the teams’ decisions are all being documented properly alongside other important information
8. Iterate and improve frequently
Decision
The service met point 8 of the Standard.
What the team has done well
The panel was impressed that:
- the team has produced and tested multiple versions of the new service
- the team has good access to channels for version control as the interaction designer has created good channels
What the team needs to explore
Before their next assessment, the team needs to:
- explore whether the current service name really is the best option. It breaks most of the guidelines in the Service Manual so your evidence for continuing with it needs to be robust
- challenge some of the internal restrictions on the service name, for example, the term ‘public health’ should not be off the table when it comes to deciding the service name. Similarly, including ‘UKHSA’ should not be mandated if other service names which do not include this acronym test better with users and meet the broader needs of the service
- consider how a performance framework might inform design decisions and how these changes could be reliably measured to support how iterations to the service are improving it
9. Create a secure service which protects users’ privacy
Decision
The service met point 9 of the Standard.
What the team has done well
The panel was impressed that:
- the team has ensured that only aggregated data is made available for public use, and that sample data size is at lower tier local authority. It is not at a post code level, therefore impossible to accidently reveal information that could identify an individual
- the team is testing for various threat models to ensure service is secure
- the team is aware of potential internal bad actors and has alerts in place to spot and stop bad acts
What the team needs to explore
Before their next assessment, the team needs to:
- consider how to handle personal identifiable information (PII) data provided by users of the service through feedback route
10. Define what success looks like and publish performance data
Decision
The service met point 10 of the Standard.
What the team has done well
The panel was impressed that:
- the team has identified sensible metrics to track, although it’s unclear which goals these relate to
What the team needs to explore
Before their next assessment, the team needs to:
- be clearer about the goals of the product. This includes overall service goals, such as reducing the cost of the current coronavirus dashboard, as well as goals relating to specific user groups for example number of API calls
- create a measurement framework that demonstrates how metrics map to key performance indicators (KPIs) and goals
- start implementing analytics that will track all of the metrics required to demonstrate whether the service is meeting its goals
11. Choose the right tools and technology
Decision
The service met point 11 of the Standard.
What the team has done well
The panel was impressed that:
- the team is reusing existing on-prem solution to manage data pipelines
- the team is using cloud-based solution to surface aggregated data through dashboard and API’s
- the team has used a combination of on-prem and cloud as the most cost-effective solution
- the teams use of a non-functional requirement of 99.99% availability (4x9’s) is justified as it simplifies the design at minimal additional cost, though this is not a critical service
What the team needs to explore
Before their next assessment, the team needs to:
- create a detailed data and technology journey map from as-is to to-be. This will provide context and justification for the choices made
12. Make new source code open
Decision
The service met point 12 of the Standard.
What the team has done well
The panel was impressed that:
- the team has ensured that for alpha, code is kept closed, however the code and supporting artifacts like design, design decision and help guide will made open as part of beta
- the team has made the data models and schema a part of the code and will be in the open as part of beta
What the team needs to explore
Before their next assessment, the team needs to:
- create a software bill of material (SBOM)
13. Use and contribute to open standards, common components and patterns
Decision
The service met point 13 of the Standard.
What the team has done well
The panel was impressed that:
- the team has ensured that the dashboard is designed in such a way that it can be white labelled and made available to other use cases
What the team needs to explore
Before their next assessment, the team needs to:
- work with the GOV design system team to identify where you might be able to contribute to reusable component and patterns
14. Operate a reliable service
Decision
The service met point 14 of the Standard.
What the team has done well
The panel was impressed that:
- the team has ensured that API design is hierarchical making it efficient and only retrieving data requested
- the team has made use of CloudFront to cache in data for frequently used queries
- the team has monitoring in place for unusual and complicated queries that may impact the performance of the application
- the team has made sure cloud-based dashboard has reliance baked in from the onset
What the team needs to explore
Before their next assessment, the team needs to:
- provide information on how potential down time of an on-prem data pipeline may impact the dashboard to provide accurate information to end users
- design sustainable data management and QA processes, automating wherever possible, to replace the current ones.
- start considering the resources and roles required to run the service in public beta and live
Leave a comment