Register a Vehicle Electronically beta assessment
The report from the beta assessment for DVLA's register a vehicle electronically service on 20th November 2018.
| From: | Central Digital and Data Office |
|---|---|
| Assessment date: | 20 November 2018 |
| Stage: | Beta |
| Result: | Met |
| Service Provider | Driver and Vehicle Licensing Agency |
The service met the Standard because:
- there is a sufficiently resourced, multi-disciplinary team that is empowered to make product decisions and iterate the service based on user needs
- since Alpha, the team has tested with a variety of users and iterated the service based on findings from this research and other quantitative data
- the service is designed and built using common patterns and reusable components where possible.
About the service
Description
The service enables approved motor vehicle manufacturers and retailers to upload vehicles to the service and register them with the DVLA. Vehicles are uploaded into the web service and assigned to motor vehicle retailers for registration. When a customer purchases a vehicle from a retailer, the retailer registers the vehicle with DVLA by providing information about the vehicle, the person responsible for the vehicle and the rate at which the customer will pay vehicle tax.
Service users
Motor vehicle manufacturers and retailers.
Detail
User needs
Since Alpha the team has continued to research with a variety of users. They’ve tested with 45 users face to face as well as acting on data gathered from surveys, feedback forms and analytics. It was good to see that team have travelled to their users to test the service in their location, allowing them to be able to see how the service would work in the user’s environment. The team has worked hard to test with users who had the most difficulties using the current service and include users who currently use the paper process in their research.
By testing the service with real data the team have uncovered new needs as well as disproving the prior need for a ‘wet signature’. Through deeper research in Private Beta the team found for smaller users this caused a problem as it required the customer to be present, the team were able to remove this by instead having a declaration in service. The team should investigate further whether there is a genuine user need for the service not to be available after 6pm.
It was a recommendation in the service’s alpha report to test with users with access need within the sector. The team have made a good effort to recruit these users through webinars and conference calls, however were not able to identify any users with these needs to test with. The team planned to have a accessibility report commissioned, it was suggested by the panel that the team could also test with a proxy user with access needs, so that the service was not excluding anyone who might be employed in the future.
The service has an existing assisted digital channel which they have tested with the new service allowing a vehicle to still be registered if the service was down. There is still a paper form alternative although the plan is to decrease it’s usage and increase digital take up. The team should continue their research with paper based users to ensure the digital service is catering for their needs also.
The team had a plan for Public Beta to migrate more users and remove barriers for 5% currently still using the paper process. Team The core team is mature and deals with the design, engagement with industry and policy, and service management. This team works with four squads that are responsible for the delivery of different technical components, which are also shared across DVLA.
The core team works closely with the squads to ensure that service priorities are featured in their backlogs. The team also participates in weekly standups across the squads and wider monthly showcases. The service team is co-located and uses collaboration tools like Slack and Confluence.
This setup has helped the service to benefit from economies of scale and use reusable components shared across DVLA.This arrangement will remain for public beta but the amount of technical work related to the service in the squads’ backlogs will decrease slightly. The assessment panel was pleased to see that the team spends 30% of sprints on continuous improvements, thereby sustainably scaling the service for public beta and live.
The team, in particular the Product Owner and Service Manager, are empowered to make decisions and set product priorities. They report to the senior management team and have monthly engagement with DVLA’s CTO. It was great to see that the service team collaborates actively with other services across DVLA and has done significant engagement with car manufacturers and dealers. Technology
The panel was pleased to see that the squad approach to building the service has allowed for them to build and use a number of shared components, to the extent that key parts of the service will eventually replace the legacy VSS system. In the Alpha assessment, there was a recommendation to consider containerising the service which the service team has done. They now deploy much of the non-prod service using Docker and wrap the containers in AMIs for the prod environment. The service team have chosen not to alter their pipeline to deploy containers in prod until a new DVLA-wide pipeline is available and should be applauded for this decision.
The service team do not publish any of their code as open source. The panel was pleased to see they share some common components but they should strongly consider sharing the majority of their code externally.
The service asks manufacturers for a .csv file containing a detailed specification of each vehicle. The panel were pleased to see that the service team have spent a lot of time working to validate these files quickly and provide feedback to users if there are errors. However, it is still possible that incorrect data could be accidentally submitted. Because much of the data requested comes from a VCA certificate, the user is being held responsible for submitting accurate data that is already known to DfT. The panel would recommend that further engagement take place between DVLA and VCA to explore how the end to end user journey could be simplified.
The panel was pleased to see a robust approach to securing the service. The service team has followed several of the recommendations from the Alpha report to improve access control and have ensured that all data within the service is encrypted at rest and in transit outside of the Cloud environment. Whilst the authentication service is robust for existing users, the process to register or deregister requires a user to call the DVLA helpdesk and fill in a paper form. The panel was pleased to see that the service team were aware that this is not a good experience for users and are planning to incorporate user management into the service.
The panel was pleased to see that the service team has a very close relationship with users (especially manufacturers) and has brought them along as the API has been built out and continue to do so as new features are released. For example, the service team deliberately hold features in UAT for longer than technically necessary to ensure manufacturers are happy with the proposed service changes.
Design
The team is aware that some users looking to access this service are contacting support after navigating to the ‘buy a vehicle’ step-by-step page on GOV.UK and are currently being directed to the existing paper form. The team should continue to improve the journey from GOV.UK.
It was good to see how the team removed the wet signature process, making the service much simpler for users. The declaration which replaces wet signatures has been iterated over several rounds of research to balance legal requirements and being understandable.
The tax code page is another good example for how the team has iterated the service. Using the information the service knows about the vehicle they now only offer relevant tax code options where before there were many.
The team are engaging with users of the paper process to make sure they’re aware of the digital service. They’ve identified barriers of entry for users and plan to address these barriers, including expanding the service to support vehicles that can’t currently register using the digital service.
Analytics
The team has a good grip on performance analysis, using data from the backend, from Google Analytics and the DVLA Contact Centre. The use of data to monitor platform performance from AWS is impressive.
Monitoring covers both the web service and the underlying APIs. The current service 95% digital - 90% of volume via the API service. The web service serves smaller manufacturers and retailers, with a further 5% using the paper channel.
Focus for user research was based on analysis of data from the existing service. Data analysis signposted proportionate segmentation of user groups and was supplemented by quantitative research with dealers regarding the existing service. Looking for data for new and improved service.
As a rebuilt service, the team has been able to bake in enhanced data collection (both granularity and frequency) that was not available in the legacy system.
The service team meets monthly to review data and customer insight from the platform, Google Analytics, the Contact Centre, the paper channel. Policy colleagues attend.
There is currently a low volume through the production environment, but a bigger volume going through test environment. There has been a lot of learning from user research, backed up from GA on the live environment.
Two important learnings, backed by data were:
- evidence that people looking for the upload template without logging in
- that one individual could be fulfilling both manufacturer and retailer role
The latter led to quite a lot of rework to solve this.
Role profiles are defined by contracts with manufacturers and retailers. A lot of analysis of current users was done to map up the user profiles and permissions.
The team identified the following critical metrics:
- completion rate
- maintaining data that goes to the Society for Motor Manufacturers and Traders. The service has contractual agreements to supply data on a regular basis, usually weekly, to SMT
- overall volumes through web channel and the whole service.
The current Performance Platform dashboard for the service is showing static data. The team should engage with the Performance Platform team to provide live data as the service volumes increase.
Recommendations
To pass the next assessment, the service team must:
- evaluate whether the request for a National Insurance Number without using it in the service is a proportionate use of personal data as described in the Data Ethics Framework
- consider how to effectively incorporate into the service backlog the data gathering requirements and reporting that come from policy team
- conduct an accessibility audit and address any issues that emerge from it.
The service team should also:
- revisit whether there is a user need to make the service available outside of the current VSS operating hours Explore ways they can work with other DfT bodies (especially DVSA) to share data and services so that users can have a coherent, less complex end-to-end journey
- make a large proportion of their code open source, and have a plan for the rest.
- explore whether they can bring the process for registering or deregistering a user into the service and away from helpdesk calls and paper forms
- continue to improve the user journey from GOV.UK
- consider removing the 9–5 service availability restriction
- make it clear to users if the service is going to share information with other departments
- engage with the Performance Platform to provide live data.
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
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.
Digital Service Standard points
| Point | Description | Result |
|---|---|---|
| 1 | Understanding user needs | Met |
| 2 | Do ongoing user research | Met |
| 3 | Have a multidisciplinary team | Met |
| 4 | Use agile methods | Met |
| 5 | Iterate and improve frequently | Met |
| 6 | Evaluate tools and systems | Met |
| 7 | Understand security and privacy issues | Met |
| 8 | Make all new source code open | Not met |
| 9 | Use open standards and common platforms | Met |
| 10 | Test the end-to-end service | Met |
| 11 | Make a plan for being offline | Met |
| 12 | Make sure users succeed first time | Met |
| 13 | Make the user experience consistent with GOV.UK | Met |
| 14 | Encourage everyone to use the digital service | Met |
| 15 | Collect performance data | Met |
| 16 | Identify performance indicators | Met |
| 17 | Report performance data on the Performance Platform | Met |
| 18 | Test with the minister | Met |