Check Your State Pension - Alpha Assessment
The report from the alpha assessment for DWP and HMRC's Check Your State Pension service on 22 January 2015.
Department / Agency:
DWP / HMRC
Date of Assessment:
22/1/2015
Assessment stage:
Alpha review
Result of Assessment:
Pass
Lead Assessor:
A. Lister
Service Managers:
J. Bramfitt-Wanless (DWP) & T. Chatterjee (HMRC)
Digital Leaders:
K. Cunnington (DWP) & M. Dearnley (HMRC)
About the service
The Check Your State Pension (previously Digital National Insurance & State Pension) service provides individuals with a view of their State Pension entitlement and when it can be claimed from, and will allow individuals to understand where they have missed National Insurance qualifying years, and the consequences of this. It will help individuals to understand the impact of paying additional National Insurance Contributions (NICs) on their State Pension, and will allow them to pay additional NICs to make up missed qualifying years if they so chose.
Assessment Report
The Digital National Insurance & State Pension service has been reviewed against the 26 points of the Service Standard at the end of alpha development.
Outcome of service assessment
After consideration the assessment panel has concluded that the Digital National Insurance & State Pension service is on track to meet the Digital by Default Service Standard at this early stage of development.
Reasons
The service is at a very early stage of development. The joint DWP/HMRC team showed a number of HTML/JavaScript wireframes, explained how the team worked, and outlined future plans for research and development.
User needs
The team has begun to explore very complex user needs using a range of research methods, creating a thorough body of research. The whole team appears engaged with the research process, and buys-in to driving the project forwards through contact with users.
The team
Most of the roles required to develop the digital service are present within the team. However, as the service develops, more in-depth technical knowledge will be essential. Three aspects of the team’s make-up and activity did cause concern:
-
The perceived need for two service managers - services need one leader.
-
The actual amount of development that had been achieved - the wireframes shown represented a very modest amount of work for a junior interaction designer rather than the output of a more complete agile delivery team.
-
The absence of a dedicated designer on the team to replace the designer who left in December, however assurances were given that recruitment was underway.
Security, privacy, tools and standards
It’s expected that the service will use hosting, technologies and services from HMRC’s common platform and there were no immediate concerns about the team’s approach to security, tooling or standards.
Improving the service
The service has assured funding and resource through to a public beta release.
Design
The wireframes demonstrated are largely in line with the GOV.UK toolkit and the need to work closely with the GOV.UK design team was understood.
Assisted digital and channel shift
This was a weaker area for the team. Although assisted digital (AD) was understood as a component part of the overall service, there was some suggestion that the team had a range of approaches and solutions in mind without sufficient evidence of actual user needs.
Analysis and benchmarking
This will prove extremely challenging as the effectiveness of the service is measured in terms of the action taken by users based on the information the service has provided. Most, if not all, of this activity will take place somewhere else. Potential measurements and methods of capture are being explored and the service already has use of HMRC’s Google Universal Analytics service. Engagement with the GDS Performance Platform team has also begun.
Testing with the minister
Steve Webb, Minister of State for Pensions, is actively engaged and interested in the service.
Recommendations
User needs
There was a degree of uncertainty about the ultimate purpose of the product. Possibilities included:
-
To provide information only.
-
To trigger further information gathering, decision making or action (which will happen elsewhere and could be about retirement income more generally - not just State Pension).
-
To support decision making or action within the product in relation to State Pension.
It is recommended that the research plan for beta addresses these issues, to understand, for example:
-
How users think about retirement income and retirement planning.
-
The natural sequence of actions that users might take when they start exploring and considering their retirement income.
-
How this sequence maps onto this product and the other products or services which might also be used as part of this wider journey.
This is likely to require additional research to supplement the proposed lab testing. This could include contextual research, depth interviews or other exploratory methods. In addition to end consumers, it might also usefully involve other players in this space e.g. people from the pensions industry, independent financial advisers (IFAs) etc. It may also be worthwhile to share and exchange knowledge with other GDS researchers currently involved in other pensions related projects, e.g. OiX Pensions Finder, HMT Guaranteed Guidance.
The team
The need for two service managers is questionable - this needs careful and objective consideration before the service returns for a beta assessment. The velocity and nature of the team’s production needs to be addressed - value for money is one of the core success measures in agile delivery. The service needs to complete the recruitment of a dedicated designer.
Improving the service
It’s vital not to defer complexity, especially if that complexity generates value. The team should make an objective evaluation of the backlog and consider what has been deferred and why.
Assisted digital and channel shift
It’s vital that the AD service provided is designed around real users and their needs, and that support connects the user directly to the digital service rather than to alternative phone or paper-based services. Research must include understanding what support users get from outside the department’s own offering, such as from friends, in libraries or at Age UK. At beta assessment, the team will need to:
- Evidence the needs of AD users of this specific service, how and where those needs were captured, and how the design of the AD support meets those needs.* Provide a plan for implementing the AD component(s) of the service (including on Verify), and demonstrate how user research will continue feeding back into future iterations.
Analysis and benchmarking
The service presents substantial challenges in terms of what success looks like. The team needs to explore all of the touchpoints users may have with other services that could be indicators of what happened next; how the information provided by the service provoked action.
Summary
The team demonstrated a genuine and sustained commitment to identifying and proving user needs and a good understanding of agile delivery methods. The panel looks forward to seeing the service again at the beta assessment.
Digital by Default 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 |
| 19 | Yes | 20 | Yes |
| 21 | Yes | 22 | Yes |
| 23 | Yes | 24 | Yes |
| 25 | Yes | 26 | Yes |