Apply online for new style employment and support allowance alpha assessment report
The report for the Department for Work and Pension's apply online for new style employment and support allowance alpha assessment on the 28th February 2019.
| From: | Government Digital Service |
| Assessment date: | 28 February 2019 |
| Stage: | Alpha |
| Result: | Not met |
| Service provider: | Department for Work and Pensions (DWP) |
Service description
This service aims to solve the problem of citizens securely submitting an application for New Style Employment and Support Allowance (ESA). This information will be used to populate the payment system JSAPs (using an automated robotic process). A DWP Agent (work coach) will interview the citizen to confirm their identity and agree a Claimant Commitment with them.
Service users
This service is for citizens who are unable to work due to illness or injury and who have paid sufficient national insurance contributions in the relevant two tax years prior to their claim.
And DWP agents will use an agent user interface with the service.
1. Understand user needs
Decision
The service did not meet point 1 of the Standard.
What the team has done well
- the team has identified pain points along the journey, and has examined the internal evaluation and adjudication journey in depth
- the team has produced long lists of user needs for a variety of different user types
- the team clearly has a deep understanding of the service from the organisational point of view
- the team is facing substantial challenges and pushbacks from policy colleagues, which at times makes it difficult to make certain changes (for example to remove certain questions) that would substantially improve the user experience
What the team needs to explore
The panel were concerned that much of the work presented as part of assessment seemed focused on administrative, organisational needs, rather than user needs. There was surprisingly little insight into the users themselves. The team did later share a set of case studies, which showed a deeper engagement with the issues faced by people when they apply for this benefit. However, the team did not appear to be using this type of insight to inform Alpha service development and iteration.
Before their next assessment, the team needs to:
- develop a set of rounded personas or case archetypes which they can use to test their initial thinking
- break their audience down in to some groups with different needs, based on data
- identify deeper service design needs of their users
- consider how to deal with the complex reality of the user journey, and what should go into MVP
- understand the user journey that precedes the first call to the contact centre and what’s needed to help users find the service. The team’s research shows users rarely find the service unless directed to it and the name ‘Employment support allowance (new style)’ is not understood. This work will help the team follow guidance on naming your service
The case studies shown after the assessment are in the right direction. The panel recommend building on this work:
- identify different important contexts of use/types of user (for example, someone who is in hospital now, someone who needs another person to make the application on their behalf, someone with a slowly improving condition)
- build greater empathy for users, by finding appropriate images of real people/user groups, rather than using simple cartoons
- develop applicant user needs that are expressed in plain English and go deeper than accurate form completion
- if necessary (for example, if fraud is a significant worry), consider developing anti-personas (people who are not targets of the service), but focus primarily on the needs of people who are applying for this benefit in good faith
- think about the extended journey across different health benefits that an individual in work might apply for, in order to develop design thinking right across the range of health-related benefits
2. Do ongoing user research
Decision
The service did not meet point 2 of the Standard.
What the team has done well
The panel were impressed that:
- the team has considered the question of awareness for this benefit, and used short interviews to explore the problem
- the team has tested with work coaches and actual applicants in a job centre
What the team needs to explore
Before their next assessment, the team needs to:
- test with more real users/likely users/past users, outside the context of a DWP Jobcentre
- avoid spending time testing with people who are not now or have never been in this situation. We realise that this can be very challenging but it will provide greater insight into the user journey
- test with third sector organisations and with friends/family who apply on someone’s behalf
- use a variety of methods to test designs, so that the results can be triangulated
- consider the flow of the application journey, and whether a more conventional question order might work better
- think about how to communicate stages and flow more overtly, to give an applicants a stronger sense of where they are
- think about how to communicate the multi-stage journey more clearly to users
- consider wider accessibility implications for this specific audience
- plot users on the digital inclusion scale, but also look at ways of summarising accessibility needs which do not fit neatly into that scale
- get support from an external user researcher, who can mentor the team and challenge design solutions
3. Have a multidisciplinary team
Decision
The service met point 3 of the Standard.
What the team has done well
The panel were impressed that:
- the team have the scope to improve the end to end journey and are working closely with others, such as the phone service and jobcentre teams
- the team have established a way of working with colleagues from the internal robotics team, who the ESA team are collaborating with and depend on in order to deliver the overall digital service
What the team needs to explore
Before their next assessment, the team needs to:
- help policy colleagues understand the importance of working with the digital team and learning from users. Research is a team sport and everyone, especially those that don’t routinely take part in research analysis should commit to attending regularly
4. Use agile methods
Decision
The service met point 4 of the Standard.
What the team needs to explore
Before their next assessment, the team needs to:
- work with the policy team to measure their time investment with the digital team to align more with agile principle 4 (business people and developers must work together daily throughout the project). For example, agree a target for the number of stand ups or show and tells they will attend and track it
5. Iterate and improve frequently
Decision
The service met point 5 of the Standard.
What the team has done well
The panel were impressed that:
- the team has worked hard to persuade policy owners to improve the paper form based on findings from user research
What the team needs to explore
Before their next assessment, the team needs to:
- focus the scope of the digital service to deliver a minimum viable product (MVP) sooner. The team demonstrated a service that covers all potential user journeys and caters for unusual circumstances. For an MVP the team should use data to identify the most common journey and build that, filtering out ineligible users at the start and direct them to the current process. Visualising the full journey and an MVP design incubation could help
- explore a range of design options through prototyping. The team shouldn’t constrain their prototyping and designs to reflect constraints as it’s important to understand and show what users really need from the service
- use metrics to support design decisions - consider measuring user comprehension as they progress through different designs and the time it takes a user to complete each design
6. Evaluate tools and systems
Decision
The service met point 6 of the Standard.
What the team has done well
The panel were impressed that:
- the team are using well known open source technologies and are reusing existing DWP libraries
- the service infrastructure is defined as Terraform code and the service is hosted with Amazon Web Services
- the service is monitored using common open source platforms and technologies (Kibana, Prometheus and ElasticSearch)
What the team needs to explore
Before their next assessment, the team needs to:
- The team may wish to consider moving to managed message queue to save costs and developer time
7. Understand security and privacy issues
Decision
The service met point 7 of the Standard.
What the team has done well
The panel were impressed that:
- the team have a good understanding of security threats to the service, and have taken steps to mitigate these
- different types of users and services are segmented using security groups and VPCs. User data is encrypted and explicitly cleared for stale sessions
- once a user has finished entering their data a copy is cryptographically signed and stored for non-repudiation purposes
8. Make all new source code open
Decision
The service met point 8 of the Standard.
What the team has done well
The panel were impressed that:
- the team have open sourced some of the libraries used in this service
What the team needs to explore
Before their next assessment, the team needs to:
- ensure that all of the source code for the service is open sourced and developed in the open
9. Use open standards and common platforms
Decision
The service met point 9 of the Standard.
What the team has done well
The panel were impressed that:
- the team chose open standards, open source solutions and common platforms throughout the service (development, continuous integration, monitoring, alerts, logging)
- the UI was prototyped using the GOV.UK Design System prototype kit, allowing quick iterations
10. Test the end-to-end service
Decision
The service met point 10 of the Standard.
What the team has done well
The panel were impressed that:
- the team is using automated testing and using Selenium grid for human quality assurance
- the team has defined their infrastructure as code allowing staging and test environments to mirror production. Micro services are behind Elastic Load Balancers to allow the application to scale to handle surges in traffic
What the team needs to explore
Before their next assessment, the team needs to:
- for the beta assessment we would like to see a plan for testing the Robotics DRS Controller and the non-digital parts of the service
11. Make a plan for being offline
Decision
The service met point 11 of the Standard.
What the team has done well
The panel were impressed that:
- the team had a good understanding of how the application would behave if various parts of it were offline, with multiple layers able to inform users that the service is unavailable. For the time being users can revert to the paper process
12: Make sure users succeed first time
Decision
The service did not meet point 12 of the Standard.
What the team has done well
The panel were impressed that:
- the team has identified an existing, paper-based, part of the employment and support allowance application process which has significant opportunity to be faster and easier for users by going online
- the team has a long-term vision for moving the burden of navigating the health benefits system from the user to the organisation
- the team has iterated wording and format of questions where user research has shown them to cause problems - in some cases they’ve been able to remove questions - as a bonus they’ve been able to remove these questions from the paper form too
What the team needs to do before their next assessment
Support users who won’t be able to provide obscure information about their pension or health insurance providers then and there
With the paper form users can pause completing it to find out necessary information, then come back to fill it in later. Or users can take the incomplete form to their appointment and get help with questions they don’t know how to answer.
Translating the form into one linear digital journey where the answer to every question is mandatory presents a barrier to these users. It also makes it difficult for users to anticipate questions and gather relevant information. Supporting these users could mean:
- letting them save their application and come back to it later; and letting them see upcoming questions
- letting them explicitly defer answering questions until their appointment
- excluding them from the private beta by routing them away from the digital service during the initial phone call
If the team choose c) then they still need to work on a), b), or a suitable equivalent by the time of their beta assessment. The team should consider the task list pattern as part of designing for a) and b).
Make it clearer what users need to do once they’ve submitted the form
There is no way of getting back to the ‘application submitted’ page once the user has left the service. The team acknowledged that people can be anxious about going to the job centre. This anxiety will be made worse if people are worried whether they’re bringing the right documents. If the list of documents is made specific to each application then this problem only gets worse.
Putting “ESA appointment what you need to bring” into a search engine brings back results about the work capability assessment, which will only confuse people further.
The team need to think about how they can help the user find this information again, probably by sending them a copy of it.
13. Make the user experience consistent with GOV.UK
Decision
The service met point 13 of the Standard.
What the team has done well
The panel were impressed that:
- the alpha prototype is using the GOV.UK Design System, and the team plan to use it for the production version of the service in private beta
- the content is generally clear and in keeping with the style guide, at the standard we’d expect for an alpha. There are some specific questions that could be improved; these are detailed in the separate content design review
What the team needs to explore
- if there is a way of structuring or grouping the questions: The team has some reasonable assumptions about why the order of questions should be different from the paper form (specifically why the health questions should be first). But they should check these assumptions in their beta. It might help users understand why they’re being asked certain questions if the themes (health, work, for example.) if the structure is made explicit. Outlining the themes on the start page or experimenting with the ‘task list’ pattern could help here
- how the planned eligibility checking part could be a small, concrete, step towards the strategic aim of one ‘health benefits’ service. For example, the eligibility checker could re-route users who should be applying for other types of ESA. Then the pages on GOV.UK could be framed as ‘Apply for ESA’, rather than promulgating the confusing ‘New Style’ nomenclature
-
consider how they can settle on one design pattern for adding another item. Currently there are two ways:
- the blue link used to add another health condition (which the panel worry is easy to miss on a page with multiple for conditions)
- the looping-back-around way of adding another job or pension. Particularly the ‘You have added details for [job name]’ text above the main heading of the subsequent pages feels a bit unresolved. Something more like a table showing the already-added items might work better. Other teams in government have probably tackled this design problem before, it’s worth asking around
14. Encourage everyone to use the digital service
Decision
The service met point 14 of the Standard.
What the team has done well
The panel were impressed that:
- the service team has worked hard to consider accessibility in the service
- the team has used research from other, similar services to inform their understanding of the needs of users with new or short term accessibility needs
- the team has given some consideration to assisted digital support
- the team has a clear plan to measure digital take up
What the team needs to explore
Before their next assessment, the team needs to:
- research directly with users with new or short term accessibility needs to validate the needs the team have inferred from similar services
- further research the needs of users that require assistance or support to complete the digital journey
- research the needs of those providing assistance or support as they could be different
15. Collect performance data
Decision
The service met point 15 of the Standard.
What the team has done well
The panel were impressed that:
- the team has a considered plan for collecting performance data in private beta
- the plan includes information from the telephony service centre, which will allow the team to understand time each stage of the end to end user journey takes
- the team intend to analyse data on both agent and citizen use of the service
What the team needs to explore
Before their next assessment, the team needs to:
- gain ongoing access to data about the current process and create metrics to cover the paper and digital process to allow comparison
- the team needs to follow advice in the service manual to expand and improve its range of metrics and the range of tools to gain more specific data that can deliver usable insight beyond that available in Google Analytics
- consider and implement measures for assisted digital support
16. Identify performance indicators
Decision
The service met point 16 of the Standard.
What the team has done well
The panel were impressed that:
- the team has identified KPI’s to reflect the success of their service, such as time to complete and fall out rate
- the plans for a performance framework in beta are detailed and incorporate using both qualitative and quantitative data
- the team have thought through data that can be collected that will enable improvement to the service in private beta and have a clearly defined plan
What the team needs to explore
Before their next assessment, the team needs to:
- performance analyst skills will be necessary to inform improvement decisions quickly as the team begins to understand real-life user behaviour and act on it
- consider embedding dedicated performance analyst expertise in the team for beta
- identify and implement metrics to track and gain insight of movement between assisted digital and non digital channels to the digital channel
17. Report performance data on the Performance Platform
Decision
The service met point 17 of the Standard.
What the team has done well
The panel were impressed that:
- the team has engaged with the Performance Platform team. The team will work with the platform to ensure a dashboard is ready for public beta, KPI’s are clearly defined
18: Test with the minister
Decision
point 18 of the Standard is not applicable at the alpha stage.