Direct debit online payment service alpha assessment
The report from the alpha assessment for HMRC's direct debit online payment service on 26 June 2018.
| From: | Central Digital and Data Office |
| Assessment date: | 26 June 2018 |
| Stage: | Alpha |
| Result: | Met |
| Service provider: | HMRC |
The service met the Standard because:
- The team are working well with other HMRC services, ensuring that they think about how the user enters their service and influencing change on related services
- The team have built on the research of other related HMRC services and have done a significant amount of additional research with appropriate users, including those with low digital skills. Testing shows that users can succeed first time and the new service is a significant improvement on HMRC’s legacy Direct Debit solution
- The team has shown good plans for the technology and managing the development using open standards. The team is planning to use and adhere to the existing HMRC security patterns and frameworks.
About the service
Description
The service allows business users to set up and manage a Direct Debit payment of their VAT (value-added tax).
Service users
The users of this service are individuals who run businesses and use accounting software to manage their finances.
Detail
This new service takes variable Direct Debit payments, which is functionality available in the common government platform GOV.UK Pay. In the discovery phase of this project, HMRC investigated the possibility of using GOV.UK Pay before deciding to develop this new service.
Although it is positive that patterns developed and tested in GOV.UK Pay are being re-used by this new service, it is disappointing that HMRC did not make use of the existing platform. The panel were unconvinced by the rationale presented for this decision - specifically that GOV.UK Pay might not be able to deliver the necessary functionality for HMRC’s legislative deadline (April 2019), and that GOV.UK Pay might not respond to support issues of the high-profile VAT service quickly enough for HMRC stakeholders. GOV.UK Pay is several months ahead of this new service in its development of variable Direct Debit payments and is supported 24/7 by an experienced team.
The panel were impressed by the Debit Debit for VAT service team and the work that they had delivered, but extremely disappointed that HMRC felt it was necessary to replicate an existing government platform they could have made use of.
User needs
The team were well prepared and have carried out research with 44 users across discovery and alpha. The team have also started to do research with users who have access needs, and mentioned doing research with 5 visually impaired users.
With a very high volume of users expected to pay via Direct Debit, the team should try and test with as many users as possible in beta (35-40 over three months would be ideal), both contextually and in usability research.
The team has been working in sprints and feeding back research findings every fortnight. The lead user researcher carried out a varied range of appropriate research methods, such as card sorting activities, usability research, observations and qualitative analysis. Team members are observing research to ensure that empathy with the users is developed. This has enabled the team to understand the needs of most of their users and represent what they have learned in a set of personas.
The team has also been collaborating and sharing research with other teams at HMRC such as the Time to Pay team, Business Tax Account (BTA) and View and Change team to improve the content for service users.
The team should keep evolving and updating needs for their identified and likely user groups as they go into beta. The new user researcher joining the team in beta should continue to effectively feed findings back to the team so they can keep making improvements to the service and meet user needs. The other members of the team should keep observing research sessions and take part in group analysis when possible.
The team have a focused plan to continue to learn more about their users and keep improving the service in private beta.
Team
The panel were impressed by the VAT service team’s efforts to work with the other HMRC agile teams involved in taking payments. The teams are co-located and have regular shared ceremonies and a shared Service Manager, which helps with knowledge transfer and allows this team to influence the upstream elements of the journey.
The team are also working hard to share knowledge with the waterfall projects that are providing their APIs. The panel heard that when individuals from these back-end teams visited the agile teams they were able to easily resolve several issues, which is really positive. This engagement is planned to increase in beta. However, the differences in methodologies (ratified in the contracts) and the fact that these teams are not co-located is proving challenging. Although the Service Standard doesn’t currently require internal-facing services to be built using agile methods, the panel strongly recommends that HMRC consider reconciling these methods of delivery. It would be beneficial if each ‘slice’ of functionality (from front- to back-end) was owned by one team that had complete control of that slice.
The panel also identified that the service was already locked into technical decisions (such as not using GOV.UK Pay) because work had already started on the back-end in a waterfall environment. This should not be possible at alpha stage.
HMRC has significant governance processes surrounding the building and deployment of its digital services. The agile team seem to largely be shielded from these processes and the Service Manager was extremely satisfied with the high level of engagement from senior stakeholders and felt it would be quick to remove blockers. But as some of these processes could slow down delivery, it’s recommended that these processes be reviewed and minimised if possible. It shouldn’t be necessary to have multiple project managers to deal with HMRC’s own governance.
Although the team is largely made up of contractors, it’s encouraging that there are civil servants shadowing two of the important roles. The team expects their civil servant user researcher will be able to take the lead on this service in beta.
Technology
The team demonstrated that they are working in agile environment using open source. They are using Confluence, Jira and GitHub for the project management, requirements gathering and source code collaboration. The team is propsosing to use Restful APIs and plan to look into the API maturity model and adapt to it. The team is using the collaborative team approach for the detailed design and peer review of the design and code. The team using SCALA for the development. All developers participate in the proposed component design. This distributes knowledge around the team as well as being peer reviewed by other developers. The team confirms that they are working to ensure that documentation (readme files, etc.) are being brought up to date, in line with current developments.
The service seems to use HMRC-wide appropriate security rules in the code and development. The more detailed security architecture is being analysed and developed with the use of existing HMRC security architecture, patterns and framework. Since this service cannot distribute money back to users there is a very less opportunity for fraud.
The team is using AWS cloud services through the existing HMRC infrastructure team, which will manage the whole environment for the team. The team plans to have agreements in place for the running and management of the system.
Being a standard MDTP (Multi-Channel Digital Tax Platform) application, there is adequate provision to deal with short and long-term service outage. The team are building monitoring dashboards using SPLUNK and Google Analytics, to allow speedy recognition of problems (during office hours, at least). The team is planning to adhere to standard SLAs and runbook of HMRC.
Design
The panel were pleased to see that the service team tested the journey from the start, even though those parts of the service sit in different teams in HMRC. It is recommended that the service team continue explore and test the entire journey for the user, particularly the unhappy paths and routing through other ways to pay. In particular, it is not clear what the user should do if their Direct Debit fails, or if they are not authorised to set up a mandate.
The full service journey must be included and designed as part of the service development. Users must know what the next steps are and be clear what to do when things go wrong.
Although the team are working well with the others involved, the panel is concerned the journey is spread across multiple teams. In particular, attention should be given to the Business Tax Account dashboard and starting pages in the journey. There are multiple links and buttons on the dashboard page and it’s unclear what the next step should be for users. The team is aware of these pain-points for their users and have already begun liasing with the different teams across MTD.
The team has designed a service that is largely consistent with GOV.UK patterns and styles. It was good to hear the team were working closely with their Direct Debit provider to improve the email content required by the Direct Debit scheme.
Analytics
The legacy payment service has no analytics, but the team are baselining length of time to complete a transaction (11 minutes) through usability testing. Bringing this transaction time down is one of the key success metrics.
A Performance Analyst will be available to the team in beta. They are looking to monitor the four mandatory KPIs, as well as other sensible metrics, including proactive vs incidental set-up rates, failure rate, sign-up rate and the total number of active Direct Debits.
Although there are already existing HMRC payments dashboards on the Performance Platform, the team believe that the high volumes of Direct Debits merits its own dashboard. They have already engaged with the GDS Performance Platform team.
Recommendations
To pass the next assessment, the service team must:
- Come up with the plan how they can will be able to migrate and manage the load from few users to 800K to 900K users.detail.
- Agree with GDS how point 9 of the Service Standard (Use open standards and common platforms) applies in this case, outside of the next assessment. There should be no need to cover this ground in the beta assessment unless the position has significantly changed
- Do further research to explore and design unhappy paths and connect end to end journeys, and test with more users to ensure users are able to set up, amend and cancel Direct Debit payments
- Test with more users who have low digital skills to ensure the service works for people who score lower on the digital inclusion scale
- Do further research with users that have different types of access needs and users with assisted digital needs who currently make VAT payments, ideally via Direct Debit or similar types of online payments
The service team should also:
- Continue the good work they’ve been doing linking up service teams. If possible, look at ‘slices’ of functionality (from front- to back-end) being owned by one team that has complete control of that slice
- Recruit additional civil servants into service team roles. It would be good at beta if the ratio could be closer to 50/50 civil servant to contractor
- Challenge the heavy governance processes and attempt to slim these down before they impact delivery
-
Calculate the Carbon footprint of the service and adhere to the Green ICT strategy of the UK government
- Research the needs of agents who submit on behalf of others. Explore and understand their end to end journey(s) too
- Do further research with contact centres and any other support touchpoints that service users may have to understand their needs too, to ensure a seamless journey for both service users and staff alike
Next Steps
To get your service ready to launch on GOV.UK you need to:
- get a GOV.UK service domain name
- work with the GOV.UK content team on any changes required to GOV.UK content
Before arranging your next assessment you’ll need to follow the recommendations made in this report.
Get advice and guidance
The team can get advice and guidance on the next stage of development by:
- searching the Government Service Design Manual
- asking the cross-government slack community
- contacting the Service Assessment team