Apply for Personal Independence Payment
The report for the Apply for Personal Independence Payment alpha assessment on the 16 December 2021
Service Standard assessment report
Apply for Personal Independence Payment
| From: | Central Digital & Data Office (CDDO) |
| Assessment date: | 16/12/2021 |
| Stage: | Alpha |
| Result: | Not Met |
| Service provider: | Department for Work and Pensions |
Service description
Personal Independence Payment (PIP) is a benefit to support citizens with a long-term health condition or disability who need help with extra costs because they have difficulties with daily living or getting around (or both).
Within this benefit, there is an application, which allows users to register for the benefit, to provide further information about their circumstances and functional ability, and upload supporting evidence.
Service users
Primary users
- Potentially any citizen
- Citizens with a long-term health condition and/or disability
- Mental and physical health conditions (sometimes both)
Secondary users
- Third party organisations who provide support to citizens
- Those who become involved in direct support in relation to PIP
- Other individuals (friends/family) providing support to the citizen the benefit is aimed for
Internal users
- DWP staff or orgs connected to DWP
- Decision makers, Case managers, Healthcare practitioners
- SERCO staff, contact centres & call handlers
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 conducted solid research in the Alpha phase, with a representative mix of users, including primary users such as PIP claimants living with a disability or health condition, and third party users who also play an important and supportive role to the primary users
- the approach taken to conducting the research aims to be varied, inquiring, with a mix of methodologies, aimed at refining and iterating the design offering, as well as learning more about the lives and experiences of the users themselves, which is crucial for a service of this nature, dealing with potentially sensitive user scenarios, with 80% of the users testing having multiple conditions and comorbidity. This overall approach is also helping to inform the aim of continuous learning and iterative improvements, while also delving deeper into the citizens’ experiential and contextual needs in and around the service as well
- the team create and use evidence based personas, with the two primary personas having their tacit needs around support for their conditions, being made primary drivers for the design approach. The team shared examples of these research insights being used to action design iterations, especially for the Stage 1. Again, it is encouraging that the team are also utilising the existing personas from the PIP research, and informing the PIP research with the personas created for this Alpha phase
- the team is taking an inclusive design approach, by continuing to work on identifying and addressing the needs of users with assisted digital and accessibility needs, and the type of support that they would need
- examples of the above point were shown through the actioning of research recommendations and design iterations that highlighted aspects of the support and affordances that should be made available to users in this segment, which also would of course, benefit all users, with one notable example being around the work being done to help users to take a break and return, and future design considerations to help users transition mid session from the online to another channel if necessary
- there is ongoing work to assess and ensure that the design proposition is mobile friendly, given the preference of a large proportion of users to access the service via their smartphones, with Stage 1 of the journey currently being investigated and improved to reflect this, and Stage 2 in scope next
- the team supports a healthy diffusion of research findings, insights, and recommendations between the epic level work (PIP end-to-end) and the specific Alpha phase (Apply) of the project, while also identifying further research needs. This is set out in the comprehensive research plan and roadmap for the forthcoming phases, showing different levels of project granularity and methodology, including depth interviews, user testing, and longitudinal studies, and social media analysis
What the team needs to explore
Before their next assessment, the team needs to:
- carry on with the work being done, as discussed above, and expand the scope to address Stage 2 of the journey, using the positive steps for Stage 1, and then address the entire experience holistically, with the full spectrum of users. While the team has shown a true awareness and appreciation of the need for this, success will need support from all levels of the organisation in order to enable and achieve the commendable aims for PIP and its end users, such as succeeding first time, minimising stress and anxiety
- following on from the above point, while it’s understood that the project has its phases, and this is one of them, ensuring the usability and usefulness of the overall end-to-end holistic experience for all users is key, and the team should be encouraged and supported to carry out the activities set out in the roadmap, with active participation and support, from all key decision makers across the organisation
- continue the current work into understanding the rejected Claimants, and build up the needed research evidence to understand their needs, and where possible, develop personas that could be utilised across other phases of PIP
- continue and expand on the work done to validate parts of Stage 1 of the application for mobile users, to include Stage 2, and of course, the holistic experience, end-to-end, and user further research to identify further design affordances for this large group in this project
- consider conducting regular participatory design workshops, with the key focus on involving and including non-project, but responsible staff in the process, so that they also build empathy and awareness of the actual project and user needs, as this might help to achieve faster actioning of some of the recommendations elsewhere in the report too. There was one example of this given in the assessment involving non-project organisational Content Sign Off SROs in the project work, in order to help speed up the process, and this is commended, and indeed to be replicated and widened to other areas as well. As always, these initiatives require the buy-in and support from senior levels of the organisation, in order to achieve meaningful results
- the User Centred Design team are keen to test out other suitable and agile research approaches. So, where possible, help the team to experiment with, and apply other appropriate research approaches and methodologies, especially those that are now de rigueur in other HMG digital project environments. Guidance, case studies, and support for these is always available across Cross Government Channels
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:
- within the stage of Alpha development, the Apply touchpoint is viewed in the context of the end-to-end service, and the team are aware of the complexity of developing a fully integrated end-to-end Personal Independence Payment service
- the team are actively engaged with teams across the end-to-end journey, so are aware of the work in other stages of the whole problem and the potential impact between stages
- the team have done significant research to understand the range of journeys and channels that service users will take, as well as the pain points of experiencing a lengthy and complex journey across multiple channels and touchpoints
What the team needs to explore
Before their next assessment, the team needs to:
- prove that the work being conducted across the end-to-end service is achieving the delivery of an integrated and understandable journey that supports success for users who qualify for PIP. This will require giving the team time and space to explore and co-create more radical / holistic design ideas that they can test with users. It will also require having the vision for the service owned by all stakeholders, acknowledging that digital are taking a whole service view and that the programme needs to have a good understanding of whole service taxonomy if they are to transform PIP
- prove and improve the flow of information through stages of the application process. Although user research has shown that users have a mental model of the difference between stages of the application process, the fact that information that is gathered in one stage is not passed to the next stage has the potential to confuse and worry service users
- ensure that the health assessment is sufficiently integrated into the service design of the end to end service. Currently it’s associated with “DWP decides” and the user need of “Keep me informed”, however this seems insufficient for the importance of this stage in the journey. While this is not strictly part of the Apply journey, it seems that the overall PIP team needs to own and elevate focus on this area
- be a leader in assuring that unhappy paths across the journey have a clear way back into the process, including people who have been rejected who should reapply. There are many possibilities for a user’s journey to become complex, be denied or not run as smoothly as it should; the Apply team can support the overall service in ensuring this development, which can start with mapping these journeys across the service at a more granular level
3. Provide a joined-up experience across all channels
Decision
The service did not meet point 3 of the Standard.
What the team has done well
The panel was impressed that:
- the team have a substantive understanding of what is required to be able to move all user groups to a fully digital journey such as not requiring the initial phone call
- the team have worked with call centre staff within contractual limits to understand user experience from the initial call
- the team are engaged with the case management work researching the benefit of a variety of channels at different stages in the journey, including using calls in PIP2
What the team needs to explore
Before their next assessment, the team needs to:
- ensure that the needs of the wide range of users who can’t be served by the current alpha/private beta service are met, so that phone triage can be phased out. This is a major piece of work and it is important that stakeholders understand what is required in order to realistically scale the service
- use iterative design and research to prove the success of users as they continue a journey (happy and unhappy paths) across channels
- prove that the design and implementation of the service works for users in the channels and devices they would normally use and have access to
4. Make the service simple to use
Decision
The service did not meet point 4 of the Standard.
What the team has done well
The panel was impressed that the team:
- moved paper and non-data-connected service to a digital service, resulting in initial time savings
- tried a number of approaches in the Alpha prototype to find the best breadth of the digital touchpoint for the first stage of the application
- developed an approach to let users save part way through and return to their input later
- explore the use of the task list pattern to help users understand what information they would need to share
- are exploring future use of data pre-population to make it easier for users to complete the application
What the team needs to explore
Before their next assessment, the team needs to:
- improve the content and flow of the health questionnaire (PIP2). This will require support and collaboration with policy, health and data colleagues and stakeholders to make the service as streamlined and understandable as possible. This work is expected to lead to higher success rates for users getting through the service, as well as increasing accuracy in their answers, which in turn will support an increase in accuracy of service decisions
- test and improve the interaction of the task list pattern. As discussed in the design system, the pattern is still “experimental” and there is not an established view as to whether it’s better to return users to the task list after each task or take them straight to the next task in the sequence. In our view, a heuristic reading of the current implementation in PIP Apply health questionnaire is that returning users to the list after every sub-task requires excessive non-productive navigation, and increases the cognitive load
- further develop “Save and sign out”. This includes ensuring that the positioning of the CTA is visible to all users (the deck indicates it’s more successful than previous options, but it is so important that it needs to be unmissable)
- develop and test the journey back into the service after someone has saved and signed out
5. Make sure everyone can use the service
Decision
The service did not meet point 5 of the Standard.
What the team has done well
The panel was impressed that the team have:
- developed an understanding of accessibility needs through conducting substantive user research in the Alpha phase – with primary users with a disability or health condition, and 3rd party users who provide support to primary users
- iterated some of the content design, specifically in the first stage of the application, where the language was particularly far from plain English
- conducted research with user who have low digital confidence
- planned to improve cognitive accessibility in the iteration of the health questionnaire
What the team needs to explore
Before their next assessment, the team needs to:
- continue testing and iterating of content and design of the service, in particular the health questionnaire. Ensure that the design doesn’t present cognitive or other accessibility barriers. We recommend looking at the service using the universal barriers framework, see the #universal-barriers-community on cross-gov Slack, or contact the CDDO design team
- see comments in previous point about the implementation of the task list pattern and cognitive load. The point about excessive non-productive navigation is particularly important for users with hand/arm mobility needs, as well as potentially requiring extra work for screen magnifier users
- ensure that all questions and selections are easy to understand, and use the design pattern for complex questions, where there is a long explanation separating the question and answer selections - https://design-system.service.gov.uk/patterns/question-pages/ (see subhead Asking complex questions without using hint text)
- carry out an independent accessibility audit of the service and address any resulting recommendations before public beta
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 service had a skilled multidisciplinary team with all the relevant Digital, Data and Technology roles, and largely permanent staff
- the service maintain the necessary working relationship with policy and operational staff, given operational pressures of the pandemic
What the team needs to explore
Before their next assessment, the team needs to:
- deepen that working relationship with policy and operations with a greater sense that operations, policy and digital are one team enabling the service to citizens. It would be beneficial if these roles are fully embedded in the team, but at the very least there needs to be a strong sense that the vision for the digital service is collectively owned across policy, operations and digital. The digital team contributing to work on the green and white papers is promising, and operational involvement will be critical to rapid iteration of the service from what it will be at the official start of the private beta service, to the service expected at the point of transition into public beta and beyond
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 established agile practices and ceremonies that have been given careful consideration, especially with regards working across multiple squads
What the team needs to explore
Before their next assessment, the team needs to:
- consider how paying down both technical and product debt will be accelerated
- show that technical (and other) governance is supportive of a CI/CD pipeline that can enable far more frequent iteration in the service
- consider how multivariate testing can be implemented both across the end-to-end, and in very small aspects of the service to learn faster
8. Iterate and improve frequently
Decision
The service did not meet point 8 of the Standard.
What the team has done well
The panel was impressed that:
- the proposed private beta service has iterated and made improvements on the interaction and content of the application, based on an understanding of users’ needs, and sees the private opportunity as an opportunity to learn with real data
- the team is aware of the need to substantively address the design of the health questionnaire and plan to do that in the private beta phase
What the team needs to explore
Before alpha reassessment, the team needs to:
-
demonstrate that they now have the space and enabling environment for ongoing ‘alpha’ experimentation, to co-create (with operations and policy as part of the team) more radical designs that could move the service closer to providing decisions in days, rather than months, and improve the quality of decisions. The approaches to developing such radical designs may include, but not be limited to:
- substantive collaboration to develop more effective and integrated health assessment
- asking only necessary information, to lessen the load for users who are applying
- exploring ways to facilitate users to give the most useful information in their circumstance without leaving less prepared or informed users to potentially be wrongly turned down
- developing supported and efficient ways back into the service for users who have been wrongly turned down
Before beta assessment, the team needs to:
- create space for ongoing ‘alpha’ experimentation, including more radical end to end service design (for example testing whether we can help the claimants pull together evidence that already exists elsewhere; whether we can give claimants an opportunity to expand after initial responses in the PIP2 following a triage, or build up better prompts for the claimant, by analysing past applications)
- continue testing and iterating of content and design of the service, in particular the health questionnaire, as well as the design patterns mentioned above in points 4 and 5
- continue to use peer review to get substantive feedback on design development
- as recommended in point 1, consider conducting regular participatory design workshops, with the key focus on involving and including non-project, but responsible staff in the process
9. Create a secure service which protects users’ privacy
Decision
The service did not meet point 9 of the Standard.
What the team has done well
The panel was impressed that:
- the team are aware of and, with the help of departmental platforms and capabilities, defending in depth against the typical range of tech-focussed attacks such as DDoS, attacks against password mechanisms, exploits against vulnerable dependencies
What the team needs to explore
Before their next assessment, the team needs to:
- increase the level of knowledge of threat sources, threat actors and capabilities across the team, and use this within the product development process
- while it is valuable to access expertise outside the service team for security, the team and within it especially product and tech leaders need to be aware of the higher level threats such as fraud to the service, and how the end to end service design mitigates them
- the team will need to show how the threat landscape has been taken into account in designing and operating the service with more detail for this team’s piece of the end-to-end service, and a less fine grained view of the rest of the service
- some non-prescriptive, anecdotal examples of activities that have helped other teams build and share knowledge within the team are threat modelling sessions, threat briefings, adoption of “malicious” user stories and acceptance criteria into epics and stories
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 service had developed a robust performance framework, with data sources identified.
What the team needs to explore
Before their next assessment, the team needs to:
- demonstrate that data drives iteration of the service in beta, particularly with a view of the service ultimately achieving its overarching stated outcomes
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 are using a modern, well supported stack for the bulk of their development
What the team needs to explore
Before their next assessment, the team needs to:
- evaluate and show that all shared platforms and capabilities in use are working well for the service. It seemed that some existing platforms such as the “tactical HTML service” in use within DWP were hampering efforts to provide an intuitive design
-
challenge the limitations imposed by older, harder-to-change backend technology. A number of current issues with the service were attributed to limited capabilities at the backend. Two opportunities here would potentially be:
- prioritising refreshing the tech at the backend. Vital work that is underway refreshing the tech currently is likely to have a longer lead time
- decoupling and insulating this service from the backend components. It appears that there’s potential to have a data model that’s better aligned with the service, which could then be mapped onto the existing backend
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 has committed to open sourcing the code for the service
What the team needs to explore
Before their next assessment, the team needs to:
-
open source the code written to date for the service
- the team said they intended to open a repository, https://gitlab.com/dwp/health/pip-apply
- the panel were unable to examine the scope of this repository as it is not yet open, however based on the architecture diagrams the panel would expect the code for the frontend of the service and all the micro-services to be open source. All fixtures and code used for testing would usually be expected to be open too
- establish a process so that all future development on the service is open sourced in a timely manner by default
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 is using shared platforms including GOV.UK Notify
- the team is engaged with the Digital Identity programme at GDS in multiple areas, with potential to use GOV.UK Accounts for authentication as well identity assurance
- the team is also engaged with DWP and NHSX in the area of identity and trust
- the team are exploring experimental design patterns from the GOV.UK design system
What the team needs to explore
Before their next assessment, the team needs to:
- within the wider programme it’s important to look at how to make the system open for integration - this has the potential to reduce the demand on applicants to collate documents and put together prose supporting their application - APIs, standardised data formats and data sharing mechanisms could enable this
- continue to explore GOV.UK Accounts
- continue to test their implementation of the task list and complex questions pattern and contribute their findings to the GOV.UK design system community. The service also need to use research to gain solid assurance that the ‘Save and Sign Out’ solution is seen by all users, and the reentry journey makes sense to users
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 is operating on an established platform, with all code in gitlab, with good test coverage and an automated CI/CD pipeline
What the team needs to explore
Before their next assessment, the team needs to:
- explore more frequent deployments
- complete the work to enable zero downtime deployment
-
the stack has many layers, with some components shared with other services and others not. The panel suggests the team track to what extent the complexity:
- gives rise to service incidents
- slows down the team (where changes to the service require changes or testing of components that the team does not control)
Updates to this page
Published 26 August 2022