From: NHSBSA on behalf of NHS England
Assessment date: 15th December 2022
Stage: Alpha
Result: Met
Service provider: DHSC
Service description
The service provides a central place to find and apply for volunteering opportunities within the NHS.
It is designed for people who recruit volunteers within the NHS or from Voluntary Community and Social Enterprises (VCSEs) to promote their NHS related opportunities.
They can choose to receive applications within the service or through other existing forms.
Volunteers can browse and filter the opportunities available, save their favourites to view later and apply using an NHS Volunteering account or as a guest.
Service users
Volunteers – prospective and current volunteers differentiated by their motivation to volunteer.
- Entertainer
- Volunteer to career
- Reactor
- Off the radar
Recruiters – people responsible for recruiting volunteers within the NHS or from
Voluntary, Community and Social Enterprises (VCSEs) differentiated by their level of
establishment of a volunteer service.
- Established Recruiter
- Aspiring Recruiter
- Unaware Recruiter
Table of 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 undertaken extensive user research. They use different methods to gather user input, such as surveying and interviewing
- the team has an inclusive research recruitment approach, including participants with varied accessibility needs and digital skills. We recommend that this continues
- the team identifies and tests their riskiest assumptions
- the team shows deep knowledge of their users, their needs and their pain points
- the team has developed a comprehensive list of user needs categorised appropriately to aid their design thinking. They mapped them against specific design decisions and prioritised features
- the team has created worksheet packs as an alternative method to reach volunteers with low digital skills
What the team needs to explore
Before their next assessment, the team needs to:
- involve more users who have access needs and who use assistive technology. The team is aware that they need to target a broader range of users with vision and hearing needs
- develop a plan to conduct additional research and testing with specific user groups, including diverse community members, users with english as a second language, local faith groups, pharmacists, and other hard-to-reach audiences identified as lacking representation in previous research
- carry out end-to-end user testing across all the journey touchpoints. For example from the volunteer looking to find an opportunity, through finding the service, navigating between channels, submitting an application, and receiving a response about the role
- carry out research and user testing on a mix of mobile and desktop devices. Currently the user testing was mostly focused on desktop devices
- prototype, test, and iterate an assisted digital support model to accommodate these needs. This is based on research findings showing that non-digital application channels are nearly as popular as online methods
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 used user research to understand the current constraints and user needs and developed design ideas to meet those needs
- the team has a good understanding of where it fits in the broader context of volunteering and has engaged with some of the existing services
- the team has aimed to reduce some of the barriers to entry for users by testing paper worksheet packs
- the team has considered and documented their riskiest assumptions, seeking to validate them by conducting user research
- the team has designed the service to unite all volunteering opportunities under one roof
- the team has mapped legislative requirements that apply to volunteers to ensure compliance
What the team needs to explore
Before their next assessment, the team needs to:
- ensure that they are solving the right problem for users, especially the recruiters, and that they are creating a service which is genuinely needed
- work with other teams to solve a whole problem for recruiters that address the difficulties of managing and supporting volunteers. During the discovery phase, it was discovered that recruiters had no problem attracting these volunteers,
- consider alternatives to creating a service - for example running a campaign or partnering with another service or using third parties
- think further about how the service fits into the ecosystem of different services and systems making up the wider user journey for both volunteers and recruiters
- continue to work in the open and connect with both internal and external teams to increase the potential for teamwork and avoid duplicating efforts. For example, the team can share their findings in NHS user research huddles and on Slack with the research community
- identify and test ways to integrate with existing tools and registration methods in order to reduce the number of times users have to enter the same information. For example, many NHS workers report having to remember too many login credentials
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 mapped other services and tools to integrate this service into the broader user journeys
- the team has considered how users will find the service
- the team has created and tested paper worksheet packs to reach non-digital users and considered other offline entry points such as phone line or in person support.
- the team uses data and user research about the online part of the service to inform and improve the offline offering
What the team needs to explore
Before their next assessment, the team needs to:
- explore the technical feasibility of passing details from the service to third-party services that are handling external volunteer applications so that users do not need to enter their details twice or sign up for more than one service to complete their journey
- plan the required roles and responsibilities for maintaining the service and ensuring a user centred design approach moving forward
- work closely with other services and tools to integrate this service into the broader journeys
- continue to test and iterate users’ experience of both online and offline channels
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 was able to demonstrate how they iterated prototypes based on user research findings and usability testing
- the team has made good use of the NHS design system and the NHS content style guide
- the team has made significant improvements, addressing a number of pain points in the existing service, and directly responding to user needs. For example they simplified the process to create a role to avoid duplication of effort
- the team has a content design plan for the Beta phase. For example they plan to test guidance for volunteers and recruiters, how to create a library of role templates, and legal pages
What the team needs to explore
Before their next assessment, the team needs to:
- demonstrate how they considered alternatives to creating a service before they created high fidelity prototypes. Alpha is a chance to explore new approaches and try out different solutions to the problems you learnt about during discovery. Explore how they can simplify sometimes lengthy content
- continue developing their service in alignment with NHS and gov.uk design patterns
- keep clearly documented evidence for any deviation from the NHS and gov.uk design system, and share findings with the research and design communities
- maintain and build on the relationships they established with the teams of relevant services
- continue to work across organisational boundaries to understand how to create a simple, streamlined service with minimal duplication
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 applied the NHS design system and has already carried out some testing with users that have accessibility needs
- the team has already tested paper worksheet packs with some users and has plans to prototype and test an offline support model for users with low digital skills
- the team has really good awareness of the standards they need to meet
- the team is considering the entry points for their service, both online and offline
What the team needs to explore
Before their next assessment, the team needs to:
- carry out user research with assistive technology users and users with accessibility needs, as already planned, including users with visual and hearing impairments. Ideally include some users with access needs in every round of research
- commission a full accessibility audit, as already planned
- have a clearer understanding of which users risk being excluded and why, and how to address their needs
- continue their access needs research for both the online and offline journeys. It’s worth considering that many NHS users work in challenging contexts and environments, potentially with slower connections or not using the latest hardware or software
- continue to follow Gov.uk and NHS standards for content design guidance. Incorporate a process for testing that language continues to be accessible
- share learnings across the content design profession through the slack channels and design huddles
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 appropriately large and well resourced, for the size and complexity of the service
- the team work closely with the service owner and, despite there being a large governance board overseeing the service development, the ways of working are clear and don’t hinder agility or decision making
- the team has a knowledge transfer plan in development and all alpha handover documentation is already written even though the majority of the team are contractors
What the team needs to explore
Before their next assessment, the team needs to:
- ensure that they have enough product management resource assigned to the development of the service (current Project Manager is part time)
- plan carefully how such a contractor-heavy team will hand over their work to a permanent team and how continuity can be preserved if and when suppliers change
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 is working in an agile way and making good use of the standard ceremonies including daily standups, refinment sessions, internal playbacks and fortnightly show and tells
- the team is using tools like Jira and Miro to plan and track work
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 places a focus on iterating both what they are delivering and how they deliver it
- the team iterates their designs based on user research and were able to show how research informed the evolution of designs
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’s proposed Identity and Access Management (IAM) solution is to use Amazon Web Services (AWS) Cognito, which provides full identity and permissions management enforced by the AWS ecosystem
- the team’s choice of IAM solution has been discussed with enterprise architects at NHS BSA and care has been taken to ensure it can be swapped out for an alternative authentication provider as required
- the team’s choice of AWS as the cloud provider carries a high level of security assurance, for example, ISO 27001, along with technical resources and guides for implementing secure solutions using AWS components
- the team’s architecture has a separate volunteer portal and admin portal, avoiding the risk that ordinary users could elevate rights and perform user administration functions
- the team’s choice of APIs will be exposed securely through the AWS API Gateway
What the team needs to explore
Before their next assessment, the team needs to:
- explore the potential for a shared IAM solution for the volunteer portal and the NHS jobs site, given the overlap between users of both sites, this would avoid the need for users to create two separate user accounts, and promote re-use of components
- identify the PII the service will record, ensuring this is only that neccessary for purposes of delivering the service, and is retained for the shortest amount time possible
- plan to undertake a Data Protection Impact Assessment (DPIA) before the service goes live
- carry out a penetration test of the service and fix all critcal and high severity issues identified, with a plan to address medium severity issues also, and perfom on-going regular penetration testing
- seek review and approval from relevant technical governance authorities, for example the NHS BSA cyber security team
- consider adopting a formal set of security controls for the service, for example, the Open Web Application Security Project (OWASP) Application Security Verification Standard (ASVS)
- seek and implement best practice guidance from the National Cyber Security Centre (NCSC), for example, by developing a security incident response plan (SIRP)
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 a range of approproate KPIs outside of the mandatory metrics
- the team has a plan on how they will measure these KPIs
What the team needs to explore
Before their next assessment, the team needs to:
- explore what backend performance metrics are required to ensure a stable and safe service
- plan how they will publish their performance data
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 has made an evaluation of the existing NHS jobs site architecture to see if this could be re-used to deliver the volunteer portal, and a decision made that the existing system architecture was too tightly coupled to easily re-use
- the team has indicated service will be hosted in the AWS cloud, and will follow a microservice architecture with APIs for vacancies, advertisers and volunteers, implemented using serverless AWS lambda functions, this is a proven architectural approach and allows for easier scaling, testing and development
- the team has chosen Node.js as the back-end technology, this is well supported and widely adopted, is currently being used by other projects in the NHS BSA, and has a large pool of developer resources readily available to maintain and support the service
- the team is adopting progressive enhancement as a principle of the front-end architecture, meaning users with older technology and limited bandwidth will still be able to use the service
What the team needs to explore
Before their next assessment, the team needs to:
- evidence that they have considered other third party off the shelf (OTS) products that could deliver the service, and why they have discounted these and decided to build their own solution
- explore simpler alternatives to using isomorphic rendering , or re-hydration, of the front-end as a means of delivering a progressively enhanced interface, and either adopt a simpler approach or evidence why the alternatives have been rejected
- plan for how to manage increasing complexity of business rules in the service, for example, changing the questions based on the type of volunteering role
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 plan to work in the open from the start, and publish their code in an open source repository
- the team will be taking advice and following best practice from the NHS BSA around how to safely and securely publish code in the open
What the team needs to explore
Before their next assessment, the team needs to:
- make all source code created in private beta open, and if not opening all source code, provide a convincing explanation of why this cannot be done for specific subsets of the source code, see: When code should be open or closed - GOV.UK (www.gov.uk)
- explore how they can include accompanying documentation alongside the open source code to explain the aim and function of solution, for example architectural designs and wider business context
- have a plan to ensure their open source dependency chain is secure and they are able to automatically detect and apply security updates to vulnerable dependencies
- explore options for maintaining a formal software bill of materials
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 will be using components from the NHS design system for the front-end, via the NHSD react component library
- the team plan to re-use the NHS jobs site’s newly redeveloped jobs search feature, which can be adapted to work with the volunteers service back-end
- the team has made sure that Gov.UK Notify will be used to send notifications from the service
- the team has made sure that OS Places will be used to provide address lookup functionality
- the team has made sure that a shared BSA service for file management will be used if needed
- the team has made sure that all APIs will be developed with OpenID compliance for authentication
What the team needs to explore
Before their next assessment, the team needs to:
- use open standards for the APIs they are building, for example, the Open API Specifcation v3 (formerly Swagger) and publish documentation following best practice see: Documenting APIs - GOV.UK (www.gov.uk)
- feedback any custom UI components developed for the service into the NHS design system as appropriate
- adopt common data standards and schemas for well known entities, for example users, addresses, dates when developing the data model for the service. See: API technical and data standards - GOV.UK (www.gov.uk)
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 plan to use an automated deployment process to enable regular updates to be pushed to production
- the team has ensured a non-production environment will be maintained, and updates will be pushed there for manual user acceptance testing before being published to the production environment
- the team will use AWS CloudWatch for application logging, and performance and load monitoring, with the ability to send automated alerts to DevOps when services are underperforming
What the team needs to explore
Before their next assessment, the team needs to:
- understand the number of users and transactions the service will have to support under low, typical and high load
- develop a disaster recovery plan
- have sufficient automated testing in place to ensure the quality of the service
Leave a comment