Adult Social Care jobs
The report for DHSC's Adult Social Care Jobs service alpha assessment on the 25th of May 2021
Service Standard assessment report
Adult Social Care jobs
| From: | Central Digital & Data Office (CDDO) |
| Assessment date: | 25/05/2021 |
| Stage: | Alpha |
| Result: | Met |
| Service provider: | DHSC |
Service description
This service provides jobseekers with a single place to search for Adult Social Care (ASC) jobs and care providers with a single place to list ASC jobs.
Our mission for jobseekers:
To be the obvious central, dedicated, intuitive, easy-to-use, accessible, jobs board in England for job seekers in local areas that don’t have jobs support to find and apply for ASC jobs giving a tailored sector-specific experience.
Our mission for providers:
To provide employers with an efficient and cost-effective place to manage recruitment online and reach a wider relevant audience, working well with any existing jobs boards in the same local area and giving a tailored sector-specific experience.
Service users
For MVP, our service users are:
- care workers - over 60% of the ASC workforce
- care workers with accessibility needs
- care workers with assisted digital needs
- small care providers (employers) - 85% of ASC providers
- small care providers (employers) with accessibility needs
- small care providers (employers) with assisted digital needs
We are not excluding the following service users
- other care roles, ancillary roles, management roles
- large care providers
Post MVP, we will research and design for these additional service users:
- individual employers, user-led organisations
- personal assistants, live-in carers
We are excluding the following users
- recruitment agencies
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 user needs’ documentation and assumption log was very detailed
- the impact that the user research and testing had on prototype and features was explicitly highlighted as part of the demo
- the team thought about accessibility and assisted digital needs before beta
What the team needs to explore
Before starting beta, the team needs to:
- articulate better how the service meets job seekers’ users needs. The user needs have been articulated more explicitly and confidently for the job advertisers (employers) than the job seekers (employees). While it is quite clear why small to medium companies would welcome a means to recruit more easily into their vacancies (for example by using values), I would like to see articulated why this solution would be needed by job seekers (and which sub-types of job seekers would find it more useful). Thinking of ‘extreme’ user types (for example the one looking for a stable, value rich position, versus a user seeking very quick and informal job opportunities) could more explicitly tease out which is your core (primary/initial) user sub-group and why.
- create a proposed and detailed user research plan for beta as part of the assets to be left for the next team, including for example with methods and hypotheses to be tested
Before their next (beta) assessment, the team needs to:
- research and test more with job seekers. More focus is needed on testing with job seekers. We understand the difficulties and restrictions during mourning and elections. However, the portion of work that needs more confidence is on the side of the job seeker (rather than the job advertiser) so it is important the concept is tested with a variety of users. The panel recommends you think of your users as types (see first recommendation) or maturity within their professional journeys (for example entry point, flexible, established) as drivers for your participants selection. We also recommend that you test various options to build confidence on your hypothesis (for example testing values with entry-job-seekers against other means of encouragement, such as ‘no experience needed’ box)
- pay more attention to thinking and testing for inclusivity. This implies special attention not only to accessibility and assisted digital needs (which are fundamental) but also to other inclusion (and exclusion) potential issues specific to this workforce segment (for example gender, ethnicity, first-language not-english, caring duties) to decrease the chances that those people who are more vulnerable, or traditionally more likely to be excluded, continue to be so
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 trying to reduce user burden and avoid duplication. For example the option of a link to the employer’s website means an employer does not have to manage two different application processes and means a candidate in these circumstances will not inadvertently apply for the same job twice
- by looking into sharing vacancies (for example with local authority websites), the ASC website (everydayisdifferent.com) does not add an extra place for employers to add vacancies or for jobseekers to search
What the team needs to explore
Before their next assessment, the team needs to:
- keep reviewing with ASC employers whether the new service is likely to mean employers advertise in more places than they do now, and whether jobseekers end up searching in more places. Consider whether this service results in placing a job advert or helping users find a job in this sector easier overall
- explore further which analytics it will be collating to monitor how successful the service is end-to-end for the user
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 content design alpha report recommends following style guides and a service-specific style guide for more service specific terms
- the team during discovery conducted surveys with over 200 ASC providers to determine which methods they use to advertise vacancies and which were the most successful channels
- the team throughout alpha and for future beta development have clear plans to promote ASC using social media channels
What the team needs to explore
Before entering private beta, the team needs to:
- design and test with users the content that will appear in emails sent from the service
- the EDID site’s .com domain has the look and feel of a short-term campaign website rather than an established Government branded jobs board. The team should continue to explore how the website can continue to provide a joined-up channel between social media and the website’s jobs board, whilst also maintaining the trust and officialness of a Government funded platform
- the discovery report noted that “providers use a wide range of channels to find job candidates, often spending large amounts of money on job boards - money that could be better spent on employee remuneration and benefits.” With a performance analyst and an economist, the team needs to succinctly show how the ASC job board has saved providers money to provide care in the community compared to advertising for care positions through commercial providers such as Indeed
Before their next assessment, the team needs to:
- show that the user has a consistent and joined-up experience through the service, service-generated emails, emails/messaging with the Adult Social Care Jobs team, and phone calls with the Adult Social Care Jobs team
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 moved away from a common pattern where it was not working well for their users - the panel would encourage the team to share the research findings with the GOV.UK and NHS design system communities
- the team has proven the need for certain design elements by removing them for testing - the panel would encourage the team to try this method with other elements
- the team understands the acronym ASC Jobs to be suitable only for internal use as a shorthand, not for public consumption
- the content design alpha report makes clear that supporting guidance for users should only be created where user pain points genuinely cannot be solved in the design
What the team needs to explore
Before entering private beta, the team needs to:
- get a second content designer to do a full 2i (including proofreading, style check – GOV.UK / NHS - and plain English) of the prototype - although there is some very well designed content in the prototype, the panel saw some things that indicate that a 2i had not yet been done, for example, negative contractions, passive voice and some complicated vocabulary
- have an arrangement in place for regular design crits and for 2i-ing any content changes in the beta service on an ongoing basis, before the change goes into development or gets released (this might be a crit/2i buddy for the team’s designers, or the NHSBSA design community might operate a crit and 2i rotas)
- explore more service name options, using evidence to decide which to test with users. Service manual - naming your service
Before their next assessment, the team needs to:
- validate and clearly articulate the employer and jobseeker need that the ‘values’ feature is thought to be meeting, then design and test alternative solutions - for example, if job seekers need to know that no experience is needed, the team could try showing the ‘experience required’ information upfront
- check whether ‘values’ is the right label for this feature – the items seem to be personal characteristics or strengths rather than values
- confirm whether having a backlink is meeting the jobseeker’s need to modify their application before sending
- add sort functionality or improve filtering on search results
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 focussed on designing a very accessible and simple job seekers page and search tool based on job distance range which is easy to navigate and use.
What the team needs to explore
Before entering private beta, the team needs to:
- do more usability research with a wider range of people with different accessibility needs
- do comprehensive usability testing on a high fidelity prototype or production-ready build, including features that could not be tested in the alpha prototype such as saving to favourites, uploading a document and receiving emails
- do comprehensive accessibility testing on a production-ready build
Before their next assessment, the team needs to:
- discover where users drop out of the service and why
- show that users in a range of contexts, and with a range of accessibility needs, can get effective communications from the service, and can contact the Adult Social Care Jobs teams when they need to - for example, will the service be available 24 hours a day, and will there be video relay service or similar for deaf users who need to contact the team
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 alpha development team recommended in the discovery report was largely realised
- the team presented clear plans in the alpha assessment for which key roles the beta development team needs to cover to fulfil their proposed development roadmap
What the team needs to explore
Before entering private beta, the team needs to:
- re-examine the planned balance of resources to ensure that the team’s content designer(s) will be able to have as full an understanding of the work as everyone else. This will enable the service team to work with the other user-centred design team members to better design and iterate user journeys and interfaces
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 been using two-week alpha sprint cycles and have been iterating against a defined MVP
- the team has used Agile project management tools such as Confluence and Miro to capture key lessons learned and manage ongoing tasks
What the team needs to explore
Before their next assessment, the team needs to:
- the team needs to explore alpha options 2 and 3 from the discovery report recommendations in more detail to look at other existing platforms and investigate better integration of existing services
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 user research plan demonstrated to the panel how the service would be iterated based on user experience and feedback
- the teams target operating model shows a clear understanding of how they will and have to date used an iterative approach to help grow the service
- the team has successfully developed a custom ASC front-end based on user needs that can be continually iterated through to the beta phase including the screen design, content and interaction design
What the team needs to explore
At their next assessment, the team needs to:
- present more prototypes showing how User Research has influenced design. It would have been good to see some more of the prototypes the team tested and iterated with users during the alpha phase. At the beta assessment, a closer look at how UR has influenced the design would be good to see
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 is aware of the range of security risks to their service and are working well with security and data protection within their organisation
What the team needs to explore
Before their next assessment, the team needs to:
- conduct the DPIA for the service
- define a data retention policy
- produce and publish relevant notices for the site
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 confidently presented key metrics to measure the success of the service against
What the team needs to explore
Before their next assessment, the team needs to:
- consider performance metrics for how the service is providing added value compared to other similar offerings, particularly on the quality of applications
- explore further options on how the service can better reach out to those who are less digitally enabled
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 intends to build using a modern, well-supported tech stack, in a public cloud, using a departmental platform and support wrap
- the team is collaborating with other teams, intending to re-use some low level components and microservices
What the team needs to explore
In private beta and beyond, the team needs to:
- look for higher-level components, products and services that could be used to help deliver the functionality required on the site. The team explained that they would build and maintain most of the software required for the jobs board. The panel acknowledges this decision was based on the experience of other teams across government who have worked in the same area, and that this also allows the team more freedom to get a tailored product in front of users to test hypotheses faster. However, this will also create a substantial burden of support and maintenance that will ultimately slow the team down. As the shape of the service becomes clearer, the panel urges the team to continually look for opportunities to replace parts of the service with well-supported higher-level components, products and services freeing up the team to focus on the unique challenges they face
12. Make new source code open
Decision
The service did not meet point 12 of the Standard.
What the team has done well
The panel was impressed that:
- the team plans to open all code developed in private beta open
- the team is working with other teams to open dependencies that will be needed in private beta
What the team needs to explore
Before their next assessment, the team needs to:
- publish the code used for their investigations into the use of elastic search and cognito
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 intends to use shared components such as GOV.UK Notify within their service
- the team has identified a standard microformat to use for job postings
- the team is using departmental components and platforms in their work
What the team needs to explore
Before their next assessment, the team needs to:
- explore how to implement save and return with minimal overhead for users - ideally without creating an additional throwaway email and password
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 plans to capture service optimisation metrics
- the team has checked that there is no dependency between the user interface and back end microservices, meaning that they can design and maintain the service to meet their users’ needs
What the team needs to explore
Before their next assessment, the team needs to:
- look at how further integration with other available ASC job sites could impact the reliability and user experience of the current service offering
Updates to this page
Published 7 September 2021