From: DHSC
Assessment date: 26/09/2024
Stage: Alpha
Service provider: DHSC
Service description
This service aims to solve the problem of…
‘Get Adult Social Care Data’, developed by the Data Access Project (DAP), is a digital solution to address the data gaps and asymmetries in the ASC sector, enabling more evidence-based decision-making. The service will bring together data from multiple sources and combine them to answer questions for several user-groups including Local Authorities, Care Providers, DHSC, and Academic Researchers. It will remove barriers and improve transparency of information within social care, helping us track progress against the Health Mission for social care and performance against National Care Service Standards. This will contribute to a data-driven decision-making culture across social care organisations.
Service users
This service is for…
Primary users
- Local Authorities (LAs)
- Analysts
- Service managers
- Care Providers (CPs)
- Directors and CEOs
- Department of Health and Social Care (DHSC)
- Analysts
- Policy leaders and advisors
- Academic Researchers
Secondary users
- Member organisations
- NHS England
- NHS Integrated Care Boards (ICBs)
- Think tanks
- Care Quality Commission (CQC)
- Housing providers
- Other government departments
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 succeeded in recruiting and speaking with 80 users, including some users that had been involved in the discovery process, despite the relatively short timeframe,
- the team has used a variety of research methods to understand the users and their needs. This included desk research review of the Discovery user research, some of which was re-done to provide more specific findings. Remote profile interviews were carried out to validate the user needs, and 6 co-creation sessions were done, based on the Jobs-To-Be Done principles with different exercises to ensure a new product was created and not just a revision of an existing one
- the team sent a survey to over 100 users but unfortunately had only a 28% response rate, the reasons for which could be explored in Beta to better reach these users
- the team showed evidence of proactive multidisciplinary participation in user research user research
- the team is ensuring usability testing lab sessions will occur in Beta
What the team needs to explore
Before their next assessment, the team needs to:
- revisit the framing of the core user needs which underpin the service. Having the core user needs clearly articulated, socialised and accessible by the entire service team will help to keep decision making and iterations of the service aligned to the needs of its users where possible. This will be especially important as the service scales and the team learn more about their users
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 is co-designing the proposed solution with a wide range of users
- the team has identified the risks and constraints in developing this service
- the team has done a lot of business analysis and exploration of the problem space to understand how this service can bring value to a wide range of users
- the team has clearly articulated and identified the scope and where the scope ends for this service
What the team needs to explore
Before their next assessment, the team needs to:
- continue the co-creation sessions with users, including those who have English as a second language and accessibility needs
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 tested and iterated numerous versions of the prototype, noting this is an alpha prototype,
- the team has ensured people are already accessing the data they need access to
What the team needs to explore
Before their next assessment, the team needs to:
- map the different pathways into the service and incorporate them into a service blueprint appropriate for the service team. This will help to ensure the different channels are captured and considered as the service scales, providing the service team with visibility on potential service design pathways and creating a platform to identify and then solve the challenges users will face when accessing the data tool from different departments or organisations
- continue work to understand how this service be communicated to its potential users and cohorts throughout the Private Beta phase; this is not a mandated service so while it is ostensibly providing value people may not know where to find it on their own especially considering the diverse groups and departments it could be available to
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 facilitated co-design workshops with a range of user groups. This has led to interesting design ideation and helped the team to tailor the interface to the emerging needs of the users
- the team has utilised a hypothesis led and considered trial implementation of AI (artificial intelligence) using a large language model to provide users with simple summaries of what the data they have searched for shows in a given use case. This will help to meet some of the user needs identified by the team where users want to quickly understand what data is telling them
- the team has developed frequent iterations of the home page with candid and clear acknowledgements of user feedback at each stage of the design ideation. It is evident that care have been taken to rapidly iterate the metrics pages as these were identified as high importance areas of the service for users; there have been considerations to allow users to download data based on user testing and research
What the team needs to explore
Before their next assessment, the team needs to:
- acknowledge that the current design of the primary data dashboard is trying to achieve a lot, allowing a user to perform multiple tasks and actions. Explore through iterative content, interaction and service design how the structure of the page could be changed and what could be potentially moved elsewhere in the service, to ensure that user needs are being met in the simplest way possible. Support from a technical architect and a content designer would be useful to explore these activities
- understand that while initial work has been done to form a navigation system based on user language, is it important to continue to improve this. Continue to iterate the navigation categories and information architecture of the service as you keep learning more about your users. Consider what categories may apply to all users and how you might solve more specific challenges, such as users with specific needs or interest from a particular group as identified by the service team
- explore adjacent or similar spaces which aim to provide users with a range of data types in accessible formats. Good work was done to take design ideations from systems like Local Government Association’s Data Benchmarking tooling; there may be more design systems and patterns which could help the team to simplify the interface while still meeting user and business needs
- share AI learnings and take learnings from across government or adjacent services doing similar work. The team outlined that they also met with the Head of Information Security Standards at DHSC as well as the AI board
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 tested with several user groups and iterated a lot during the alpha phase
- the team is mindful of WCAG 2.2 considerations and are working to meet those criteria during the Alpha phase
- the team has a plan for recruiting participants with accessibility needs, Though these may not be actual users of the service, so outsourcing for an accessibility audit at the end of Beta is a possibility for ensuring it works for everyone. Although no accessibility testing or research has been conducted during Alpha, it will be prioritised in Beta
What the team needs to explore
Before their next assessment, the team needs to:
- acknowledge that no accessibility testing or research was conducted during the alpha. While users of this service are anticipated to have high levels of data and digital literacy it is critical that the team prioritise access research as early as is possible for them during Private Beta. The longer that access research and usability testing remains a gap the harder it will be for the team to identify, unpick and iterate embedded design decisions should the research surface challenges for users with different needs
- be confident that any findings from research is transferrable to users of this specific service
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 is well-resourced for user research resource with 2 part-time senior user researchers
- the other team members are actively participating throughout the user research process in planning, observing & analysis
What the team needs to explore
Before their next assessment, the team needs to:
- create additional guidance for users to help them use the service
- build and iteratively refine a GOV.UK hosted service to let people find and access the data tooling
- consider bringing a dedicated content designer into the service team to support these activities during private beta
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 team has a regular cadence of ceremonies in their sprint cycle
- the team has representatives from all teams involved in each others stand ups, despite having function related stand ups
- the team is having regular show and tells, and retrospectives
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 facilitated co-creation sessions with a wide variety of users
- the team's feedback sessions and research sessions are gaining feedback on the prototypes and changing the service
- the team has identified future metrics to improve the service
What the team needs to explore
Before their next assessment, the team needs to:
- continue co-design sessions to gain feedback in Private Beta
- ensure that the improvements identified from the feedback are evidences and prioritised
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 a good understanding of collecting minimum personal data in line with GDPR policies
- the service, although only as a proof of concept at Alpha stage, shows pages loaded with data under secure login protection
- the team has demonstrated a strong understanding of securing the infrastructure, and minimising public facing endpoints
What the team needs to explore
Before their next assessment, the team needs to:
- implement secure login mechanism, using GOV.UK integrations wherever possible, to allow authentication for wide variety of users along with strong role-based access control and multi-factor authentication (MFA)
- ensure a robust registration process is built with easy-to-understand guidance and signposting on the authentication pages following GOV.UK’s frontend framework, wherever possible
- use pseudonymised values wherever possible, store personal data in encrypted formats and have appropriate guidance in place for onboarding and offboarding processes
- implement proper vulnerability and penetration test coverage with regular frequencies to identify potential threats, weaknesses to the service and mitigate the risks early on
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 what metrics they will be using to define success
- the team has identified how they will use the metrics to improve the service
What the team needs to explore
Before their next assessment, the team needs to:
- create and socialise clear definitions of what each KPI means in their service including the mandatory GOV.UK KPIS
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 using GOV.UK Prototype kit for the front-end design and service build, where possible
- the team's use of graphs that can be made to viewed as text covered accessibility needs well
- the team, although only built a proof of concept for Alpha, have a good understanding of infrastructure, framework and tooling choices required for Private Beta
What the team needs to explore
Before their next assessment, the team needs to:
- secure a robust, cost-effective and scalable hosting option to host the infrastructure and the service app keeping future maintenance, budget and resources in mind
- use common platforms for front-end, registration, login, data-source integrations and infrastructure, wherever possible
- use back-end data tools that are in line with the rest of the infrastructure and build stack and is cost-effective, scalable and supports user and business needs
- make sure that any third-party integrations are secure, cost-effective and resource-efficient to not cause ongoing cost burden to maintain them in future
- ensure that the service has user-led documentation and guidance built in and uses already built-in components, third-party integrations wherever possible, in line with service standards, rather than re-inventing the wheel
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 the Alpha proof-of-concept is built using GOV.UK front-end framework and intends to use GOV.UK One Login to implement authentication in future
- the team has ensured that secure keys, secrets required for continuous deployments are rightly not stored in public repositories and have appropriate security mechanisms over them
What the team needs to explore
Before their next assessment, the team needs to:
- move all open-source code, both app and infrastructure, made during Alpha proof-of-concept to appropriate department’s public GitHub repositories. Build using open-source code, storing future code in publicly available repositories and common components, wherever possible
- move any publicly sensitive information such as department policies, secrets, credentials to DHSC owned private repositories or private forks of their public repositories
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 looked across government and relevant bodies to leverage and take inspiration from styles and components used in this area of work such as the Local Government Association (data benchmarking)
- the team has written most of the code, service app, infrastructure, package libraries using open standards
- the team presented a proposed service start part hosted on GOV.UK which followed the recommended conventions
What the team needs to explore
Before their next assessment, the team needs to:
- collaborate and contribute this work across government more broadly so other teams working in a similar space can benefit when solving similar challenges where the team have found or iterated a component which has a novel or potentially complicated use case
- use of package libraries, tools, infrastructure, data reporting options to be as much open-sourced and written sing open-standards as possible for Private Beta
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 a decent deployment strategy with appropriate roll-back mechanisms for their Alpha proof-of-concept
- the team has a good understanding and have a solid plan in place to implement scalability, reliability and monitoring of the service that will be crucial to assess in Private Beta
What the team needs to explore
Before their next assessment, the team needs to:
- ensure there is a strong continuous development-deployment approach in Private Beta with automated monitoring, scanning and reporting of vulnerabilities along with solid triage process to fix and patch those vulnerabilities
- ensure solid backup and disaster recovery plans in place with appropriate testing coverage, wherever possible
- have appropriate auto-scaling mechanisms in place and ensure maximum uptime and availability of the service
Leave a comment