Apply for Personal Independence Payment Alpha reassessment
The report for the Apply for Personal Independence Payment alpha reassessment on the 22 May 2022
Service Standard assessment report
Apply for Personal Independence Payment
| From: | Central Digital & Data Office (CDDO) |
| Reassessment date: | 26/5/2022 |
| Stage: | Alpha |
| Result: | 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
Note on reassessment
The assessment of Met is in the context of Alpha development, with the understanding that continued development, testing and iteration would be necessary to meet beta standard.
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 the 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 is 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
At reassessment
The panel was impressed that:
- the team’s user needs were clearly presented and accurately showed people’s goals and ambitions, as well as tacit needs and needs created by using the service
- the team demonstrated strong empathy with their users and an understanding of their pain points in the current service. They knew where people might go wrong in the new service and were designing for that
- there was a strong working relationship with user researchers from other parts of the end to end service and knowledge was regularly and well shared
- the team are quickly taking action on the people who accept the invite to apply online to make the most of the opportunity to understand their experiences
Before their next assessment, the team needs to:
- carefully consider how the User Research team restructure will impact the regularity and quality of research on ‘apply’. The panel were concerned that handled poorly, the project could lose cadence and the close connection to user’s lives they’ve built up
- make every effort to return to some face to face contextual research with users. The panel understands there are still difficulties to overcome, but on a long service with such vulnerable users, it really will enhance the team’s understanding of user’s lives
- ensure their considerations around inclusivity go further than just people with access needs to deliver the equitable service they strive for. For example, the impact of health inequalities around race and in poorer communities
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
At reassessment
The panel was impressed that the programme has:
- set up a new end-to-end service design team, which has rapidly deepened the maturity of view of the whole service journey
- enabled further linking of strategy/policy to delivery
- been working to align different channels experience - covering multiple users groups across journeys
- alignment with Health Assessment Service - working with teams across PIP and HAS
- been developing service-level hypotheses, and has experimented with different approaches to delivering the overall service
Before their next assessment, the team needs to:
- ensure that the ambitions for the wider development of the end-to-end service are reflected in the detailed delivery of the Apply service
- continue to refine the guidance, to ensure that service users understand the stages in the PIP application process
- move into the next stage of improvement of the PIP2 questionnaire, which should have a significant impact on the quality of the information received, and therefore improve award decision-making
3. Provide a joined-up experience across all channels
Decision
At initial assessment on 16 December 2021 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
At reassessment
Decision
The service met point 3 of the Standard.
The panel was impressed that the team:
- have set up an additional team (Peregrine) to design and develop the digital service needed to replace phone triage
- have begun to explore the requirements, options and constraints to replace the phone triage.
Before their next assessment, the team needs to:
- continue to test and iterate the digital service, including ensuring that users understand why they might not be able to continue their journey through the main service, and have clear access to an alternative route
- have made sufficient progress in the design and delivery of the expanded digital service to show that the roll out will meet projected timescales
4. Make the service simple to use
Decision
At initial assessment on 16 December 2021 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’s so important that it needs to be unmissable)
- develop and test the journey back into the service after someone has saved and signed out
At reassessment
Decision
The service met point 4 of the Standard.
The panel was impressed that the team:
- have done significant exploration within the context of the alpha stage of potential navigation approaches for the multi-part PIP2 – the check box pattern, and assembling the relevant sections looks to be much more usable than the previous task list approach. Further testing will confirm if this is the case
- have further explored approaches for users to save and exit part way through the journey and prototyped return journeys for users who have saved and returned
Before their next assessment, the team needs to:
- continue to test the questionnaire navigation approach and iterate as necessary
- undertake the interaction and content design improvements of the questionnaire itself, as has been intended, for example, the team discussed providing different question types and answer structures that will give users a more controlled environment, compared to free text answers (which the team have had feedback that they can be stressful to complete, and don’t necessarily elicit the most useful information for case assessment). This overall design improvement work will be key to meeting a beta level of evidence of making the service simple to use
- continue to test, and potentially iterate the design approach to save and return; the panel recommend that the team talk to the GOV.UK design system community, as a number of teams across government are working to develop patterns for this user need
- continue to use peer review for interaction and content design, and consult cross-gov design community to see how others have solved similar design problems, particularly when dealing with complex content; Tory (design assessor) would be happy to meet with the team to discuss some of the points observed on the demo and other materials
5. Make sure everyone can use the service
Decision
At initial assessment on 16 December 2021 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 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
At reassessment
Decision
The service met point 5 of the Standard.
The panel was impressed that the team have:
- had an accessibility audit and are working through the recommendations
- significantly redesigned questions with nested interactions (reveals)
- have been developing design options (described in the previous point) that will make it easier to navigate through PIP2
Before their next assessment, the team needs to:
- ensure that the service as it moves into beta address all of the DAC recommendations
- continuing iterating and testing the design of the service and questionnaire, ensuring that the process and information are easy to understand
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
At reassessment
The panel was impressed that:
- greater clarity was provided on how they were working effectively with policy and operations as part of a multidisciplinary team
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
At reassessment
Point 7 was not reassessed
8. Iterate and improve frequently
Decision
At initial assessment on 16 December 2021 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
At reassessment
Decision
The service did not meet point 8 of the Standard.
The panel was impressed that the team have:
- explored new approaches within the Apply the product, and carried out wider exploration in collaboration with the end-to-end service time
Before their next assessment, the team needs to:
- continue to iterate the designs, test and learn in beta, particularly the areas mentioned above in points 3, 4 and 5
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
At reassessment
Decision
The service met point 9 of the Standard.
The panel was impressed that:
- the team were able to show how analysis of threats to the service had fed into requirements
Before their next assessment, the team needs to:
- continue to grow awareness of the threat landscape and attacker capabilities within the teams building and iterating the solution
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
At reassessment
Point 10 was not reassessed.
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
At reassessment
Point 11 was not reassessed.
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
At reassessment
Decision
The service did not meet point 12 of the Standard.
The panel was impressed that:
- the team is working through the existing codebase with the intention to open source, and has already open sourced some components
- the team has adopted a process to develop all new components in the open
Before their next assessment, the team needs to:
- complete the process of open sourcing the code for the service
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
At reassessment
Point 13 was not reassessed.
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)
At reassessment
Point 14 was not reassessed.