https://dataingovernment.blog.gov.uk/pensions-tracing-service-service-assessment/
Pensions Tracing Service - Service Assessment
The Pensions Tracing Service provides a trace facility for customers to contact work based and personal pensions providers using The Pensions Regulator database.
Department / Agency:
DWP
Date of Original Assessment:
27/4/2015
Date of Reassessment:
30/6/2015
Assessment Stage:
alpha
Result of Original Assessment:
Not Pass
Result of Reassessment:
Pass
Lead Assessor:
T. Scott (Original) / S. Wood (Reassessment)
Service Manager:
D. McLaughlin
Digital Leader:
K. Cunnington
Reassessment Report
30th June 2015
After consideration, the assessment panel have concluded that the Pensions Tracing Service is on track to meet the Digital Service Standard at this early stage of development.
Reasons
The Pension Tracing Service team have shown a good understanding of the needs and challenges their users face sourcing information on the pensions they may have. The development of a single overarching user need (‘As a user I need to find contact details for my pension funds so that I can contact them to gain access to my pension’) has helped to focus the hard work on building a simpler service.
The service team have developed a deeper understanding of the current pension environment and understand the technological challenges in connecting users to the different scheme administrators.
The Pension Regulator (TPR) is now fully engaged and working collaboratively with the service team to deliver a reliable and straightforward solution to share the details of pension schemes they hold.
User needs and research
The team have continued research with users, completing more testing and listening in to more calls to gain insight into their users’ needs. It is good to see more defined user needs and this has already been reflected in the name of the service ‘Find contact details of a pension’; this matches the outcome a user would expect. It was also good to see that research at this stage has not been limited to just the services themselves but those that support users in the government and beyond. These insights are key to the success and take-up of this service. Some insights, such as almost 20% of users searching for more than one pension, will help to shape the design of the service appropriately, others such as the needs of older and lower digitally skilled users will continue to be a challenge.
The focus for research in the beta development stage should be around measuring the success of users in contacting scheme regulators with follow up calls and interviews. Ideas like using diaries are good for providing detailed insights.
The team and delivery
The team is well equipped with a good balance of different skills and roles. The move to Newcastle and co-locating has clearly increased the team's confidence and helped in engaging stakeholders. The further development of the relationship with TPR has helped to influence their roadmap for technology, and ensured that information is accessible and being cleansed with feedback from the current service. This will increase the accuracy of the schemes database. All the standard roles are represented in the team, and the team is sized well for the type of service being delivered. The addition of a dedicated analyst will help to set benchmarks and give useful insights once the service is more readily available.
The approach to agile is commendable, flexing a variety of approaches (SCRUM and Kanban) dependant on the type of work at hand. The new BA is helping to bring focus to this and the team now have a better understanding of the speed of delivery. The latter part of the alpha has focused on a technical solution using a more SCRUM approach while working with TPR to understand how data is shared. The team are using JIRA to track their development and using weekly design checkpoints to ensure consistency across the service.
Technology, information and security
The digital service is a highly complex but it is good to see the recent focus around the backend of the service, this being the most technical aspect. Guidance from the DWP digital blueprint has been used to to build the service; the team is feeding back into the blueprint and challenging it where appropriate. The next technical challenge will be around integrating TPRs web services to provide live data, good progress has been made understanding in analysing the quality and scope of the data that will be available.
Legislation for this service requires that a name and e-mail address is taken from each user but not used for any purpose within the service itself; this adds unnecessary complexity to user journeys and creates additional concerns around securely storing these details. Challenging and changing this legislation will be important in simplifying the service for users and the team alike.
The information presented to users will be a subset of the data from TPR, with the addition of some business logic to fine tune the number of results, and present a clearer list to users. Where this logic sits eventually (with DWP or TPR), still needs to be decided. The data will be shared using RESTful JSON APIs, and some thought has been given towards potentially building these in a way that can be re-used by third parties.
The service is not currently business critical but some security aspects have been put in place to strengthen it; as a public register of information the level of security is appropriate. There are business continuity plans in place for increased traffic to contact centres. There are no sensitive aspects to the code, so effort should be made to code in the open and share as much as possible with the rest of DWP, government community and third parties.
Design and experience
Having both user experience and content designers on the team has ensured that the design of the service is consistent with the rest of GOV.UK. Some of the content may not follow guidelines; and while this was sufficient for the alpha prototype, this should be addressed during the beta phase.
Multiple layouts have been tested with users, leading to a simplified design that aids navigation through the service, and allows users to move back and forth between searches and results. There may be need to refine the results further. Some searches still end in users being directed to the existing service and the hand off is not very clear or smooth. The expectation of some users was to see the value of their pension at the end of the search, but work on the content has helped to realign users expectations.
Some work now needs to take place to plan with the GOV.UK content teams; having a soft landing page for the service is useful for the prototype but could be repetitive for users. It may be better to reduce the number of users entering the service by clearly stating on GOV.UK where users searching for private and public service pensions can find help.
Measuring success
Measuring the success of users through the service is vital to understanding the impact of changes to the design. The service team has a good understanding of the current service and are able to map that clearly with time to completion, dropouts and success rates. The aim for the early part of the beta is to complete follow up interviews to measure the success users have in contacting pension scheme administrators. Efforts to make the data comparable across different channels should continue to show where this digital service is impacting the current telephony service.
For the beta there needs to be a measure of when contact details are incorrect and more work to demonstrate how the service presents information to the Performance Platform rather than taking a ‘wait and see what others do’ approach.
Recommendations
During the beta development of this service the team should consider the following:
- If legislation does not change, the service should ensure that the user’s name and contact details are collected within the service, and that the user will not be required to add these details again when contacting the pension scheme administrator.
- Develop a feedback mechanism that is easy for users to advise when contact details are incorrect.
- Link up with the user research that is happening with the GOV.UK team on pensions and continue research into the end-to-end journey for users (follow up interviews, diaries etc.)
- Work with other organisations to encourage the use of the digital channel as the first place to search rather than over the telephone.
- Ensure user research extends to the complete user journey (through to users contacting scheme administrators).
- Understand the impacts of this service not being available across the rest of the business.
- Continue the open and flexible approach to technology and code in the open.
- Tracking searches that return no results will be important to understanding how real users search.
- Measure the usage levels across the different channels of the service to measure its effectiveness.
Summary
In a short period of time the service team have delivered a considerable amount of work. They are now joined up closely with The Pension Regulator and have a firmer understanding of the dependencies in their differing work streams. It’s encouraging to see that the team continues to work in an agile manner, flexing different approaches for the specific tasks at hand. By co-locating the team appear more aligned and confident. With the challenge of changing legislation ahead, which the panel supports, and delivering this service during that period, the team have a lot to deliver in the beta stage. The panel are confident that the team have made a good start to that process.
Summary of Original Report
27th April 2015
After consideration the assessment panel has concluded that the Pensions Tracing Service is not yet on track to meet the Digital Service Standard at this early stage of development.
Reasons
The Pension Tracing Service team did not show sufficient evidence of a full understanding of the issues that users face when trying to find lost pension details. The service team have completed a great deal of usability and user testing with the GOV.UK front end tool kit, mocking up potential layouts for the service.
Plans for the delivery of the service are built upon The Pension Regulator agreeing and delivering access to their database. While the assessment panel were reassured that this would happen, there was no agreement in principal on the timescales or the method of delivery.
There had been little work done in building a technical solution for the service, instead relying on the future delivery of a DWP common platform. This is a risky strategy for there may be delays to that delivery. While there have been conversations with The Pension Regulator, there is no agreed plan to deliver the data.
User Needs and the Team
The service team have completed a great deal of research with 18 users in a lab environment and pop up testing with users in a local library. All were rated against the digital inclusion scale with some showing low digital capability. The service team also listened in to calls at the contact centre to develop a greater understanding of the language of users and the operation behind the current service. Most of the users for the service will be aged 45 and above, with the users being directed to the service from many other sources. The service team were unable to articulate a defined user need this service is looking to meet, but were able to identify a number related to the service, for example “how much money will I have when I retire?” or “do I have a lost pension?”. The research so far has shown that users do not understand the difference between pension plans.
The team are well placed to deliver a service, being colocated and having the different skills needed to deliver a digital service. The panel was pleased to see that a content designer is now part of the team. Analytical support will be provided by a central department team, however it would be advisable to colocate these specialists. The leadership of the service follows the Scrum type methodology, however the panel were unsure exactly how the decision making process will work day-to-day. The team are following related ceremonies of Scrum, with daily stand-ups and show and tells for stakeholders encouraging weekly knowledge sharing among the team. Priorities are set in the sprint by the product owner with the priority of delivering the Minimum Viable Product (MVP).
Security, Privacy, Tools and Standards
The data that drives the service is not owned by the service team, but rather by The Pension Regulator, and currently there are no straightforward ways to improve the database. The plan is to use an Application Programming Interface (API) to access the data, which The Pension Regulator will design and provide to the service team. This arrangement will require the regulator to match user search data and deliver a reliable and fast connection to the API. The agreement between the organisations has yet to be made, although this is fundamental to the service and the functionality it will be able to provide.
The service will be built upon the upcoming DWP blueprint platform for digital services. This platform has yet to be delivered and the team are working ahead of the delivery. The demonstrated service was built using the GOV.UK front end tool kit using static information. The team were unable to demonstrate connecting an API for the search (even if they hosted that API themselves). The service will only be presenting information and will present a low security risk. The service plans to use open technology tools and platforms (HTML, JSON, Java and rest APIs) which will allow the team to adapt the service quickly, and use automated testing and continuous integration. There is a plan to share the code for potential reuse, and there are no expected barriers to this.
There is a Senior Information Risk Owner (SIRO), and the delivery manager is currently the information asset owner until the service goes live, at which point the service manager will assume this responsibility. There are currently no plans to store any data from the service (although the demo gave the option to ‘save’ results which will need further exploration). As such security plans are appropriate. Cookies will be kept just for the session, however there are some thoughts to sharing a reference number for searches with users who may need to follow up enquiries by telephone. If the option to improve the database exists, this information could be fed in. There is no identified need for verification of identity.
Design
The prototype has been built using the GDS prototyping kit and therefore has the correct base style for GOV.UK pages. It has also been iterated based on user research. However the prototype diverges from GOV.UK style in many places (e.g. line lengths, extensive use of togglable help and hidden information, page numbers, back buttons, multiple Next buttons per page), and the language used is that of pensions specialists and DWP rather than that of mainstream users. It is hard to design, prototype and test the main task of finding the right item in the database without real data or knowledge of how the matching algorithm will work. The team has not explored a range of ways for users to find their information.
Assisted Digital and Digital Take-up
There was some useful testing of the prototype service with users who have low digital literacy, however it was not clear from the research what the support needs were for those who have difficulty using digital, and the impact of potentially disadvantaging them by pushing them to another channel. It was encouraging to see that the team had identified some third party providers (such as Age UK and Citizens Advice Bureaux (CAB)) who also provide pension support, but there had been little or no dialogue with those providers to better understand the scope of users needs and what is currently being provided by them, nor a plan in place for Beta. This should have happened before the end of the Alpha. There was a presumption at the assessment that assisted digital would be provided centrally by DWP through the current infrastructure (Jobcentres for example). However it is not clear that users will expect or want to use those channels for support, nor was there a plan in place to test them. The potential future reliance on telephone support conflicts with the expected growth in the demand for the service, potentially making the triage of those with assisted digital needs harder.
The digital take-up of the current service is around 77% with a plan to increase that to 80%. This does appear challenging enough based on potential future demands. The team believe there is a potential limit to the use of the digital service as the searches for information become more complex or difficult to trace. It is important for the team to understand the barriers to users in the current service, and make steps to ensure that the digital service is the first place users are directed to; from there they can access other channels as needed.
Analysis and benchmarking
Currently there is no remote analytics tool in use on the mock-up service, however the lab testing environment has proven useful in identifying issues with the service, leading to subsequent iterations. The baseline Key Performance Indicators (KPIs) have been set from the prior email based service. This is a useful place to start, however one of the stated aim of the service is to reduce the dependence on the contact centre for the most straightforward searches, so more thought should be given to this in the Beta. The current measure of completion is difficult to quantify because the service can not be certain that all users make successful contact with their pension providers. This is something the service team should work on in the future. It was good to see that the service team had made contact with the Performance Platform team, and there are discussions taking place to build a dashboard.
Recommendations
The team should look more closely at a number of key areas:
- The team must make a firm agreement with The Pension Regulator to provide the data in an agreed format.
- Investigate if The Pension Regulator development team and the DWP Pensions Tracing Service team can be colocated and work together off one backlog.
- The need to start building the solution to address technical risk even if this will be replaced so that the team can demonstrate the ability to deliver the product.
- The need to rebalance the delivery team (there are currently 3 business analysts feeding in to 2 developers).
- Research should be completed with third party assisted digital providers to understand the needs of assisted digital support, not limited to testing of the on-screen elements of the service.
- User research should conclusively provide a coherent user need in which to judge the success of the service. The naming of the service should be in line with the user need and what outcome the user will have.
- Testing of the service needs to go beyond the front end tool kit and prescribed scenarios. It would be useful to have a copy of the database to search with, so real users can find real results.
- Explore other ways of presenting this information, including working with the GOV.UK team. A finder supported by a guide may be better provision for the user than a separate service.
- If a service is appropriate, look at how to help users actually find their pension i.e. contact with pension providers.
- All design and content design needs to be reviewed against GDS design patterns and content design style guide.
Summary
Encouragingly the service team has built their approach on the agile manifesto using a mixture of Scrum and kanban to deliver the prototype. The efforts to continuously test the service with users has begun to reveal the complexity of user's needs around understanding pensions.
The central issue the assessment team identified was the ability to access and improve the database the service is being built upon. If this stays the same the team will not be able to improve the quality of results for users going forward. There is a potential risk to service stability and availability from being reliant on a third party. Also, if the needs of the users or the service change, it will be very difficult to change the methods of accessing the data, and this will lead to a reduced ability to develop features. Not having control of the database could potentially lead to a higher contact rate with the telephone contact centre, something this service is looking to reduce.
Digital Service Standard criteria
| Criteria | Passed | Criteria | Passed |
| 1 | Yes | 2 | Yes |
| 3 | Yes | 4 | Yes |
| 5 | Yes | 6 | Yes |
| 7 | Yes | 8 | Yes |
| 9 | Yes | 10 | Yes |
| 11 | Yes | 12 | Yes |
| 13 | Yes | 14 | Yes |
| 15 | Yes | 16 | Yes |
| 17 | Yes | 18 | Yes |
