Tax Free Childcare (Parents) - Alpha Assessment
The report from the alpha assessment for HMRC's Tax Free Childcare (Providers) service on 4 October 2016.
| Assessment stage | Alpha |
| Assessment result | Met |
| Service provider | HM Revenue and Customs |
The service met the Standard because:
- Although further work is required to ensure assisted digital (AD) support is aligned to AD user needs; AD support is well provisioned and extensive.
- The service team has coverage for all agile team roles.
- The team have developed a sensible and well considered approach to running the private beta, and for rolling out the public beta service.
About the service
Service Manager: Catherine Pike
Digital Leader: Brigid McBride
The service allows parents to make payments to regulated childcare providers with a 20% government contribution through the Tax Free Childcare scheme. The service also presents users with information needed to claim Extended Entitlement for 3 and 4 year olds.
Detail of the assessment
Lead Assessor: Thomas Moore
The panel have previously assessed the childcare provider component of the tax free childcare service against the alpha standard.
The service demonstrated was at a development stage beyond that expected of an alpha service. This service is a new digital service and does not replace any existing service.
User needs
User research
User research has been conducted during the discovery and alpha stages.
The discovery involved stakeholder forums, research in Citizens Advice centres, and guerrilla testing with parents at school gates, with longer one-on-one sessions with parents to further understand user needs.
In alpha, the team has conducted research every sprint and with a range of users. Changes to the service have been tested in the subsequent sprints to ensure the service is better for the end user. The team have worked closely with policy colleagues to ensure that product iterations remain consistent with the policy objectives.
Assisted digital
The team outlined plans for supporting users with assisted digital needs. The support model follows that of the Provider component of the overall Tax Free Childcare service. Funding for AD support is incorporated into the cost of running the service, which will ensure support is sustainable. The team plan to provide support via telephone and are exploring whether childcare providers could also offer support to parents.
While the model is based on research completed during the alpha, the panel expect to hear the results of more research into assisted digital needs during the private beta. In particular, the team should ensure they’ve got a broad research sample to increase their confidence in the needs identified. The results of testing the support model with the broad user base, and any changes as a result, should be discussed at the beta assessment. The panel are also interested to hear whether the team succeed in partnering with childcare providers to help parents use the digital service.
Users with accessibility needs
Although the team has conducted some research with users with disabilities and access needs, this research has largely focused on users with visual impairments (two users in HMRC that have visual impairments, North Links Visual Impairment Team, and the RNIB were mentioned). Research with users with cognitive disabilities has been limited, with research with this group taking place more through opportunity than design.
More research with users with a range of accessibility needs must be carried out before the beta assessment. The team should also have the service tested by a specialist. See Making your service accessible in the Service Manual.
Service name
The team must develop the service name to reflect the purpose of the service. Start by making it a verb, not a noun, then conduct research to understand what actions the name needs to reflect (for example, research how first time and repeat users find the service and what they think they’re doing when using the service) and not what’s popular.
The current service name, Childcare Choices, may be liked by users, but may be confusing as the service doesn’t cover all childcare support routes and suggests the service allows users the ability to choose between options.
The service name needs to:
- be easy to communicate
- sound secure
- sound official
The team should conduct research to understand what a the service name should convey. Once this is understood, a range of names can be produced that reflect these attributes. Further research can then be conducted to establish which name works best. To do this the team can ask:
- what words to you associate with this name?
- what does it represent?
- how does it make you feel?
Other questions could be a variation of the following, for example, on a 1 to 5 scale, how does the service name make you as user feel (and why) with regards to the service being:
- secure
- official
- government
- personal
This research should ideally be done across a number of sprints. Further issues with the current service name and integration with GOV.UK are covered in the attached content review.
Team
The team working on the Parent component of the service are also working on the Provider component. The team has all the key team roles described in the Government Service Design Manual, having now recruited a performance analyst.
The service manager has oversight and control of the day-to-day running of the service, and control over when new iterations of the service are released. The service manager has to ‘refer up’ in the case of major technical changes.
The team is geographically separate, and it was confirmed at this assessment that there are no plans for the team to colocate. Whilst the panel feels this isn’t ideal, the team continue to mitigate the lack of colocation through regular meet ups (for four days out of ten in each two-week sprint) and through the use of collaborative tools. The team should ensure this commitment to regular meet ups continues and all the team attend.
Technology
The service is at a very mature stage for an alpha. Within an alpha context, developer productivity to explore the domain problem is expected to be of more importance than production ready code, indeed any development produced in alpha is expected to be disposable.
The architecture of this service is split into two distinct aspects:
- The front-end is very much aligned with the Technology Code of Practice, having made technology choices familiar from other services, such as Scala and the Play Framework.
- The back-end services that provide the NS&I integration are not so readily aligned to Technology Code of Practice. The integration pattern employed is that of an Enterprise Service Bus (JBoss Fuse) offering RESTful API adapters for the front-end to use, whilst maintaining the traditional NS&I back-end integration.
Persistence tier
The choice of Relational Database Management System (RDBMS) at the persistence tier under the front-end is problematic as it is closed source, and the use of an RDBMS for the customer journey is debatable. It is recommend the team look into alternative persistence technologies, such as MongoDB, for the technical and commercial gains they provide and, if RDBMS still has a role to play, look into whether a Polyglot Persistence strategy is worth adopting.
Enterprise Service Bus
Generally the application of an Enterprise Service Bus (ESB) pattern, as proposed in the service layer, needs careful consideration. Often ESBs create integration monoliths, misalign architecture and the organisation, and produce overly complex architectures. In this particular instance the ESB is seen as the component that allows the delivery team to leverage the NS&I service and contract. Although the choice of service providers is currently limited, it is important for the ongoing health of the service that readily switching to another supplier is possible.
Hosting
The service is currently hosted within the NS&I data centres, which does not follow the cloud first approach advocated by GDS. Current hosting arrangements may limit the ability of the service to scale in-line with increasing demand.
Persist data on every post
The ‘new applicant’ journey was a long process that may require users to find supporting documents. The team should investigate a save and resume feature on every post (a database round-trip) so that the user can continue from where they left, in instances such as searching for documents and service failover.
GOV.UK platforms
The service team should pursue the integration with GOV.UK Verify within beta and aim to have it available as soon after launch as possible. The team should also continue to explore how GOV.UK Notify and GOV.UK Pay could be used as the service currently uses functionality provided by NS&I.
The team plan to add GOV.UK Verify alongside Government Gateway during the public beta in early 2017.
Open source
It is encouraging that the team have published their front-end code on GitHub. It is noted however that the NS&I integration is not published due to the proprietary nature of the integration. The team should consider ways (eg blogging) to increase awareness of proprietary work they’ve built or used as it might be relevant to other service teams.
Design
The scope of the service during alpha has been based on identifying critical functionality allowing users to access childcare support.
User journey
The team demonstrated iterations of the registration flow, removing confusing and unnecessary questions, streamlining the flow and using the ‘one thing per page’ pattern to increase user comprehension and completion rates.
The exception to the ‘one thing per page’ pattern is the account summary for each child. From this page a user completes a number of complicated actions, namely adding money to their account, associating childcare providers with a child, and scheduling payments to the provider. The team should consider whether these actions can be organised differently to provide a clearer user journey.
Users need to be aware of where they are within the service. Presently, there’s no clear definition between the registration and application sections. Furthermore, following these steps, it’s not clear what the user is expected to do next. Current service content may add to this confusion. The team has already started to iterate the “empty state” to be more task focussed, but it is recommended that for first time users, this is treated as a step-by-step process to help guide the user through the service.
The team needs to give further consideration to how the service fits into the end-to-end user journey. The team should consider:
- discovering the scheme
- use of the calculator
- how the service relates to other tax and childcare benefits across GOV.UK
- returning users
A number of the above journeys link to each other and so there is a risk of creating a circular journey for users. For a returning user, the team should consider whether the journey on GOV.UK needs to include the guidance pages or can be shortened.
Accounts and identification
Of particular concern is the proliferation of identities based on channel, for instance:
- Government Gateway is used for the web channel
- GOV.UK Verify will be added to the web channel in early 2017
- a separate identity and password is produced at the end of the application process to enable the use of the phone channel
- assisted digital users have a further identity
The service should do the hard work to make it simple for the user to authenticate. At the beta assessment, the panel would like to hear about the work the team have done to make user identification and login consistent across channels.
Users can currently register for an account even though they are ineligible for Tax Free Childcare. The team should consider using guard questions to route out ineligible applicants early on in the process.
Messaging
The service currently offers a secure message inbox to send notifications to users. Relying on users to access the inbox specifically introduces a risk that important messages are missed. Where there is a task the user needs to complete, such as reconfirming details, the service can help the user by dynamically showing a call to action on the account overview screen. The team should look at similar functionality in other services, for example the personal and business tax accounts.
Further functionality
The team indicated functionality may be added to allow trusted helper users to access the service on behalf of someone. The team will need to establish the extent of the need for this functionality and, given the time available before launch, the panel strongly recommend the focus remains on improving the current service over developing additional functionality.
At the beta assessment the panel would like to learn more about the user journey for parents that have separated.
Analytics
In addition to the four mandatory Key Performance Indicators (KPIs), the team also plan to measure drop out and error rates, and provider sign-up rates.
For the beta assessment, the team should have a clear idea of the metrics and indicators they’ll be using to track to what extent their service is meeting the user needs they’ve identified during research.
Recommendations
To pass the next assessment, the service team must:
- Review the service name to ensure it accurately reflects the service offering.
- Conduct further user research with AD users, ensuring that research outcomes drive the design of the AD support model.
- Test with users with a range of different access needs (both physical and cognitive) over multiple sprints, and conduct a full accessibility report with an external agency.
- Continue to iterate, simplify, and streamline the user journey to ensure it is simple and clear and that users can succeed first time.
- Simplify the authentication journey for users across channels and explore options that allow users to access the service over the phone using their Government Gateway or GOV.UK Verify credentials.
- Investigate ways in which the service can move from dependence on proprietary NS&I components (such as ORACLE and ESB), as well as options for an eventual move to cloud hosting.
- Review and act on recommendations outlined in the content review.
The service team should also:
- Continue to investigate what GOV.UK platforms, specifically GOV.UK Verify and GOV.UK Notify, can offer the service.
- Investigate a save and resume function.
- Develop and test during private beta metrics and indicators that show the extent to which the service is meeting user needs.