The report from the alpha assessment of the DVLA’s Fitness 2 Drive service on 5 October 2015.
Department / Agency:
DfT / DVLA
Date of Assessment:
Result of Assessment:
About the service
The Drivers Medical service is currently responsible for managing all services and channels required to enable drivers to:
tell DVLA about a relevant medical condition, or
renew their existing medical driving licence.
Drivers have a legal obligation to inform DVLA of a medical condition which could affect their ability to drive safely and a list of the relevant conditions is available on the DVLA website. GPs also have a duty of care to inform their patients of this legal obligation when they are diagnosed with a relevant condition.
DVLA is beginning the transformation of these services on a condition by condition basis, starting with those conditions which attract the highest volumes.
Outcome of service assessment
After consideration the assessment panel has concluded the Fitness 2 Drive service is on track to meet the Digital Service Standard at this early stage of development.
However, the panel notes that the service brought in for alpha assessment is limited in scope and there are some areas which the team will need to focus on in private beta development and which will need to be addressed before the service comes back for a beta assessment: At present the service only covers two relevant medical conditions; it does not allow users to be notified digitally of a revoked licence; and the service does not appear to have been considered as part of DVLA’s wider family of similar driving licence services which share a basic user need of “I need a driving license in order to drive a vehicle legally” (e.g. first time applications and renewing or updating a licence).
The Fitness 2 Drive service provides a digital way for users to tell DVLA about a medical condition which could affect their ability to drive safely; or renew an existing medical licence they hold due to having a medical condition. For alpha the digital service is only available to users with diabetes or glaucoma.
The service takes users through a series of questions designed to help DVLA understand the nature of the user’s medical condition and its potential impact upon their ability to drive safely. Once a user submits their answers, DVLA send a decision letter back to the user via post informing them of the outcome. This process can take up to 9 months. The panel noted the lack firm plans to build a way to notify users of revoked licences within the digital journey.
User needs and research
The team used a number of different sources of insight to identify user needs and develop a good understanding of the service’s users. The assessment panel was very impressed with the work the client insight team members did during discovery to explore user needs, which included carrying out 63 focus groups across 48 towns and cities as well as interviewing users and surveying people calling DVLA’s contact centre about the existing service.
The team were able to describe user needs at a granular level with a good understanding of the emotions the underlying drivers. However, as the team moves into beta, it would be good to see them revisit the insight from the focus groups to develop a high level user need for the service.
The service has worked hard to find and meet with potential users of the service who might struggle to use the service independently - including those with the lowest levels of digital skills, confidence or access. The team estimates that 42% of their users will need assisted digital support of some kind (around 250,000 support transactions per year), and that a significant amount of that support will need to be face-to-face. The team had learned that the support for this service needs to be sensitive to its potentially emotional nature (users may have their driving license revoked) and needs to appoint someone to lead the assisted digital work.
The service team had done well to look beyond just those users making direct contact with their department, working with charities to reach users who would go to them for support. More than 100 users who’d need support were included in the team’s focus groups, and 19 were met with face to face. The team believes the range of users met to be representative of the service’s broad user base. The service team talked with them specifically about their support needs, as well as testing the on-screen elements of the service.
There is a group of users identified by the team who have a condition which they need to notify the DVLA about and are aware of the service but have not used it. The team has plans to reach this group using various communication and education channels including signposting through other DVLA and government services and working with GPs and charities. However, there is a risk that the size of this group is significant, and the team continue to conduct research into these users and the best ways of addressing their needs.
The team doesn’t believe digital channels are appropriate for informing users that they no longer qualify to drive legally. This hypothesis should be validated with careful interaction and content design, and tested with users, particularly in light of the importance of giving users an outcome as quickly as possible to manage the risk of users continuing to drive when they have a condition that could affect their ability to do so safely. The outcomes of such research will be very useful to the wider design community and should be shared.
The team have not yet considered this service as part of DVLA’s wider family of similar driving licence services which share a similar high level user need related to getting a license to be able to drive legally. During beta development the team should consider how these services relate to each other.
The service has phone support options to call upon from the department, and is exploring face to face options. The team said users would rely on face-to-face support from friends and family, but as this support is neither sustainable nor measurable, alternative support options must be in place for these users.
Two of the charities that the team is working with to research user needs (Diabetes UK and the International Glaucoma Association) have agreed to provide face-to-face support for free and on an ongoing basis.
There are some instances where the team have not used GOV.UK design patterns initially, going on to implement them later after research. The team should where possible, save design and research effort by using established design patterns. If these patterns don’t work well for your users and their needs, it’s always valuable to test alternatives, and then share the findings with the government design community.
Tools and Approach
The team have taken a pragmatic approach - using technology that will be familiar to staff at DVLA from other services under development and in production. Utilising DVLA’s existing contract to provision infrastructure is reasonable though the panel would encourage the team to develop with portability in mind and evaluate other hosting options as part of the ongoing service evolution.
Privacy and Security
The team plan to take steps to minimise the personal data that will flow through the service, using features of the underlying DVLA API. There is no data stored beyond the short-lived (encrypted) session within the service as all state is held in the underlying DVLA systems. Personal data is transferred out of the system via email into another DVLA system - the network design appears to secure this transport. Care must be taken during implementation to ensure that this is achieved in practice. GOV.UK Verify will be used to check identity before giving users access to their data. The team also have a subject matter expert working with them to ensure that their non-repudiation requirements will be met.
Coding in the Open
The team are committed to open sourcing the code for the service from the outset.
Using Open Standards and Common Platform
The service makes sensible use of a number of platforms and APIs, including GOV.UK Verify, DVLA’s own API for licences and the Ordnance Survey API. Feedback is captured using the GOV.UK Feedback mechanism and performance indicators will be reported via the Performance Platform.
Testing the end to end service
The team are committed to setting up a continuous integration pipeline from the outset and will have separate environments to facilitate development, integration and testing in an environment identical to live. Statistics from other DVLA services have been used to identify common browsers and devices - these have been used in research and will be used to test the service.
Digital Take Up
The team said that the current paper service costs £30 per transaction and that their research showed that 45% of users (250,000 transactions per year) would choose the paper service ahead of the digital service.
However, the team’s two year digital take up target was just 55% and does not envisage any users who would prefer paper will switch to digital in that time. The team also has no plans to phase out the current paper service, in line with DVLA policy to retain paper channels until research shows that removing it does not exclude users. This equates to a service that meets users’ expensive preferences ahead of the user needs that the team’s own research has identified. These users are left to a more expensive and inferior service.
In preparation for beta assessment, it will be vital that the team addresses the following recommendations.
User needs and research
Revisit the insight from the focus groups to develop a high level user need for the service.
Continue to research and design for these users and explore the best ways of addressing their needs.
Carry out research with these users to understand the barriers to using the digital channel (either independently or with assisted digital support).
Carry out research to understand if any users would be excluded if required to complete the service digitally (either independently or with assisted digital support).
Continue to research with users who would seek support from friends and family to understand their needs and enable appropriate design of support.
- Identify who will be undertaking the AD Lead role.
Point 12 - Service design
Conduct research into delivering negative results or outcomes digitally to users.
Consider this service as part of DVLA’s wider family of similar driving licence services and how they relate to each other.
Ensure appropriate face to face support is available to all users who need it (i.e. potentially beyond the coverage provided by Diabetes UK and the International Glaucoma Association).
As part of delivering a good end to end service, consider what is required beyond when the user submits their medical information in the online journey (e.g. the reports pushed into the legacy case management system and the paper notifications back to users).
Use GOV.UK design patterns where appropriate and feedback on any findings relating to these patterns to GDS and the Government design community.
Point 14 - Digital take-up and measures
Refocus digital take up thinking onto users’ needs, not preferences.
Plan to encourage users who would choose non-digital channels ahead of the digital service, to help them overcome barriers (as researched by the team) and complete the service digitally (either independently or with assisted digital support).
Develop plans for increasing digital take up beyond the 55% of users who have a stated preference for digital and an appropriate plan to phase out non-digital channels in the longer term.
Move beyond measuring the web journey in isolation to measuring the end-to-end duration, accuracy and dropout for the whole service, i.e. user’s first interaction with DVLA to receiving a decision.
The service is on track to meet the digital-by-default service standard. The team have done some good work during alpha to understand user needs. The existing drivers medical service licence is paper based, very long and difficult to understand. There was clear evidence that the digital service is significantly simpler and clearer for users covered by the two conditions targeted for alpha. The alpha has been developed in an agile way and the team was able to demonstrate that improvements have been made to the design of the service to meet user needs. The team provided examples of working with policy to simplify the design of the service in response to feedback from users. The panel would encourage the team to continue this work.
Digital Service Standard criteria
Published: 23 December 2016
Assessment date: 5 October 2015