Service Standard assessment report
Apply for, replace or renew a tachograph driver card/company card
The service met the Standard because:
- This is a capable and consistent team working in a collaborative and iterative fashion, led by an empowered service manager and product owner, with good relationships to the SRO as well as DVLA Policy and Legal colleagues.
- User research is thorough, with knowledge and findings shared with the whole team and stakeholders.
- The service has been tested with a broad range of users during the Alpha, with findings widely shared in the team. This has already allowed research to focus on the users who will have the greatest challenge as they proceed into Beta.
- The team have had a good technical approach during Alpha, with the gathering details about APIs to be built, integration and the testing plans.
About the service
The Tachograph Driver Card service will allow professional drivers in the haulage and passenger transport industry to:
- Apply for their first Tachograph Driver Card
- Renew an existing Tachograph Driver Card (they expire every 5yrs)
- Replace a lost, stolen or malfunctioning Tachograph Driver Card
Driver Cards are used in conjunction with a Tachograph Vehicle unit (installed in the vehicle) to record driving hours and rest periods. This helps enforce the rules on driving times and rest periods of professional drivers in order to prevent fatigue, guarantee fair competition, and improve road safety. The recording of driving hours is mandatory for certain vehicle types under law.
The Tachograph Company Card service will allow Vehicle Operators (haulage and passenger transport businesses) to:
- Apply for their first Tachograph Company Card
- Renew an existing Tachograph Company Card (they expire every 5yrs)
- Replace a lost, stolen or malfunctioning Tachograph Company Card
Company cards are used by employers to download or print driving hours from the Vehicle Unit so that they can evidence that their drivers are compliant with the law.
- Haulage Drivers
- Long-distance Bus Drivers
- Company transport managers
- Company transport administration clerks
The team has done an appropriate amount and variety of research with current users. The team has made good use of their findings to shape the service to meet user needs. The team has done some research with potential users, and plans to do more in beta.
The team has done good work to understand the support needs of different users, and have used what they have learned to develop their assisted digital support model.
The team has done little or no research to understand the potential barriers for users with disabilities. This effect of this is visible in their prototype which includes some steps that could present a barrier for some users. For example, the DVLA have textphone support lines, but the prototype has no option to indicate voice or textphone when providing a contact phone number.
The service team has effective engagement with relevant businesses, and has a good plan for recruiting larger numbers of participants and continuing to learn during beta - with both existing users and new users.
During beta the team plan to test, and have ability to iterate, all parts of their service, including their support model, and the paper forms and letters used in specific circumstances.
The team has found little variation in the needs of users in different locations and different businesses. The team should continue to look for differences among their users as they expand their numbers during beta.
The team is using an agile methodology to deliver this service. The panel was pleased with their description of the complete lifecycle of a research insight. They are using a combination of digital planning tools, including Slack for communication and Jira to track their stories, backlog and show transparent priorities.
The team appears to be a good size and mixture of appropriate skills and disciplines required to satisfy the harder potential problems on the project of Alpha, including access to other key roles required for strategic guidance and senior stakeholder support. The team have a dedicated service manager, product manager and required for Alpha, and have access to other key roles shared through the DVLA Tachonet team including, a content designer, service and interaction designers giving them the expertise required to develop a user ecentric end to end service. The team indicated that the amount of time they received from these disciplines was flexible and responsive to their needs.
The amount of senior engagement has clearly been thought out and planned by the team and wider Tachonet team and DVLA colleagues. The team is utilising pre-existing comms plans to ensure consistency and breadth of engagement.
The panel was pleased with the amount of engagement with policy stakeholders and the teams vision for how they could help shape and influence policy. The team acknowledges that engaging with their policy colleagues is not always easy but they are building up good relationships, including with industry and other depart. These relationships should help them to make the service easier for the users by changing the policy to potentially not require the mothers input.
Moving forward into Private Beta the service assessment panel highlighted the makeup of the service team would change to support the back end development required for the technical migration, with skills available from web operational engineers and supporting research and design. There is also a dedicated Service Transition Manager part of team, to manage and support the handover to operations and business as usual teams BAU, including supplying 247 DVLA support hours and GDPR compliant with the Information Assurance team.
The team is able to demonstrate that they are working in Agile environment using open source. They are using Bitbucket and Jira for management of the requirements and source code collaboration. The team is using APIs for Tachonet, Printing, DVSA, and Payment. The APIs are RESTful. The team needs to get to some level of maturity in APIs. The team plan to look into the API maturity model and adapt to it. The team is using the “Mob” approach to detailed design. All Developers participate in the proposed component design. This distributes knowledge around the team as well as being peer reviewed by two other developers. Services are built in with rules in the code for security. This provide an asset valuation and risk assessment. The more detailed security architecture is being analysed and developed and will be built during the alpha.
The team is using AWS cloud services, Ruby and Rails for presentation services. The platform services uses Active Directory, network and monitoring services using CloudWatch, Logging with ELK. The team is discussing about finalising the database to use AWS RDS or Postgres. Data migration plans and scripts are currently in discussions. The team would be using Spinnaker for the deployment process. The developers are using Cucumber tool for testing and Gatling for Load and performance testing.
Plans and technology for providing accessibility for disabled people and assisted technology were not available. It is proposed that team should be able to show the steps and development in this area in near future.
The team has made good use of the GOV.UK design patterns to present information in a clear and consistent way, giving users the confidence that this is an official DVLA service.
The team were able to demonstrate different iterations of previous approaches, for example how long the applicant had lived in the UK, start pages and the order summary.
The panel was pleased to hear the team works closely with a content designer and that they conduct regular content reviews.
Concerning content, a minor improvement to the service could include explicitly stating the reference number on the thank you page is, in fact, the tachograph card number.
The team primarily showed the happy-paths for the Driver Card and Company Card user journeys. These journeys were both clear and concise. However, the Driver Card journeys appear to be reliant on several offline processes for the unhappy paths, such as for users living in the UK for less than six months, users who do not hold a full EU/EEA Driving Licence and user’s whose driver record is out of date. The panel would like to see the service team work towards eliminating these unhappy paths where possible.
The panel was concerned with the security implications of allowing a company search in the Company Card journey without first authenticating users’ identity, as this enables malicious users to nullify cards and cause disruption to legitimate users. The team should consider ways of mitigating against the risk of the malicious activity.
The team demonstrated three paths in the users’ journey for both Driver Card and Company Card user groups: apply for a new card, replace a lost card and renew an existing card. The panel was worried that the renewal flow for Company Cards was open to error: If a company has ten cards, a user inadvertently only renews one card, the remaining nine become invalid. The team acknowledged this issue, and they are considering ways of improving the renewal journey to prevent errors occurring.
The panel was disappointed to discover little effort had been afforded to designing for users with disabilities. While it is understood drivers of vehicles subject to the tachograph system must adhere to fitness to drive rules, this does not excuse the team from designing for users with access needs.
Using google analytics as tool of choice, the service team is measuring the required 4 mandatory Key Performance Indicators (KPIs), along with a range of good benchmarks from the existing service, including user satisfaction. The service team also identified a list of KPIs they will be tracking and analysing as they move into Private Beta beyond the mandatory four, including the need to focus on operational availability and their migration from 247 support at team level, to using DVLA business operations service support in Live.
The Analytics team are already running two performance platform screens, showing real live data. The service team were able to talk about how completion rate had improved during Alpha. The team also listed out what areas they will be evaluating moving forward including, increasing general user satisfaction, completion rates, supporting assisted digital survey through DVLA data centers main pinch-points, out of hours touchpoints and need to reduce cost per transaction.
To pass the next assessment, the service team must:
- Research with current and likely users with disabilities to understand existing and potential barriers for users with disabilities. We would need to see how the service team plan to will remove or mitigate such hindrances for users with disabilities.
- The security journey around ordering and renewing the company card does appear to be clear. Any user can effectively cancel a companies card, so more research required around the impact of this and how the team will mitigate it using verification methods for companies identification (gateway, or verify).
- Team need to bring to life how, and on what frequency, they plan to continually develop and improve the end to end service.
- The security architecture needs to be clearly defined for next stage.
- The maturity of the APIs need to be defined.
- Test with the minister responsible.
The service team should also:
- The team is utilising pre-existing comms plans to ensure consistency and breadth of engagement, but a suggestion is to review the rejection letters to increase the digital update of users.
- The team should closely follow whether the new technical migration is on track. Any suspicion of delay should mean the team should create several mitigation plans to reduce the impact on delivery.
You should follow the recommendations made in this report before arranging your next assessment.
Submit feedback about your assessment.
Get advice and guidance
The team can get advice and guidance on the next stage of development by:
Digital Service Standard points