https://dataingovernment.blog.gov.uk/personalised-registration-service-assessment/
Personalised Registration - Service Assessment
The Personalised Registration service will allow consumer and commercial customers to
- retain a personalised registration from a vehicle;
- assign a personalised registration to a vehicle
It will be a real time service to ‘take off’ and ‘put on’ a personalised registration number, simplified to be done instantly online. The service is currently delivered offline through a paper channel.
https://www.gov.uk/transformation/personalised-number-plates.html
Department / Agency:
DFT / DVLA
Date of Assessment:
08/12/2014
Assessment stage:
Beta
Result of Assessment:
Pass
Lead Assessor:
M. O'Neil
Service Manager:
R. Gye
Digital Leader:
B. Etheridge
Assessment Report
The Personalised Registration service is seeking permission to launch on a service.gov.uk domain as a Beta service.
Outcome of service assessment
After consideration we have concluded the Personalised Registration service has shown sufficient progress and evidence of meeting the Digital by Default Service Standard criteria and should proceed to launch as a Beta service on a service.gov.uk domain.
Reasons
The team were able to clearly set out how the service was built in response to user need and were able to evidence how the service was iterated in response to feedback.The assessment team was persuaded that the service was built in response to user need. The volume of user engagement was sufficient to ensure that the product satisfactorily met the broad needs of its audience.
The team were proactive in engaging with their user community and could bring to life the high level needs and challenges of their user communities.The Service Manager set out how the team was structured and was able to provide clear evidence of their ability to iterate and improve the service.The service does not hold any data at rest and the team were able to explain the role of the SIRO in the sign off of the service.The technology stack is the same as that for Vehicle Management and the team were able to explain their build and deployment process with clear examples and evidence.The team were very experienced and able to contextualise their service with respect to the range of other DVLA services.
The design is in keeping with the style-guide, uses the correct header and footer and has consistency with other services on GOV.UK. There have been noticeable improvements since the alpha with design changes coming directly as a result of user research.The team have carried out good research to understand users’ assisted digital support needs. They included users at the lowest end of the digital inclusion scale, and have used learnings both to design and test the digital service, and to consider what assisted digital support will need to be put in place.
Recommendations
Assisted digital:
- User testing: The service team must test all assisted digital support channels with assisted digital users of this specific service during the beta, and be able to then evidence that users’ needs of assisted digital support are being met. User testing must include the full end-to-end support (from when the user realises they want to use the service, through to transaction completion) and must include users at the lowest end of the digital inclusion scale. The team must carry out testing to understand what users will need in the absence of unsustainable assisted digital support from family and friends.
- Awareness: The service should note that the live assessment requires evidence that users are aware the assisted digital support they need. The team should look to properly signpost users to assisted digital support, rather than to non-digital services.
- Volumes: The team must revisit the estimate that 17% of their users will require assisted digital support, as this was based in part on online surveys (users inherently far less likely to need AD support). The team must ensure that judgments of assisted digital user needs and decisions about assisted digital support are taken from talking directly to assisted digital users of this service.
- Costs: The team must specify the cost per minute of all channels of assisted digital support for their service, including face to face.
- Assisted digital ownership must be clearly stated in the team’s organogram, as an area in its own right.
User Needs and User Research
- The service team should ensure that the user needs that exist in the audience and the user needs that are being met by the product are both capable of being clearly articulated (based on user research data). There should be clarity about the relationship (if any) between sets of personas that have been developed and the behaviour and features of the product.
- If research supports the position that the disparate set of user types represented by the team’s personas only have one simple user need that the product must meet (i.e. replacement of the old paper process with the new online process) it is recommended that the personas are adapted to reflect this.
- If the different personas have more nuanced needs from the product, it is recommended that appropriate product behaviour and features are considered for each persona and that this decision-making is capable of being clearly communicated.
- The personas suggest that the respondents from the motor industry with whom the research was conducted may not in all instances be the end users of the product.
- It is recommended that the needs of these admin and helper end-users are assessed through research, that the features and behaviour of the product are considered in the light of this work, and that this information is capable of being clearly communicated to stakeholders.
User research
- The service team should ensure that information about the usability issues that are uncovered during iterative development, and the solutions that are developed to resolve these issues, are clearly understood and documented for internal and external consumption, and can be communicated to stakeholders.
- The user research documents that were shared indicate some needs that were uncovered in user testing of early prototypes that the current beta product does not meet. For example: dealerships would prefer to pay via a pre-funded account rather than by credit/debit card; contact details and a live chat feature present in early prototypes (and welcomed by respondents) were missing from the beta design. It is recommended that the status of these user needs/requirements is available in a form that can be clearly communicated to stakeholders.
- Remote A/B preference testing was conducted, and decisions about the product were made, on the basis of the preferences that were expressed in the exercise for different versions of certain pages. It is recommended that this kind of evidence is in the future supplemented by observational user research where users’ ability to successfully use different versions of the page to achieve their objectives is also assessed alongside stated preference (if understanding stated preference remains of interest).
Design
- The design is in keeping with the style-guide, uses the correct header and footer and has consistency with other services on GOV.UK. There have been noticeable improvements since the alpha with design changes coming directly as a result of user research.
- Support for web clients (browsers and the devices they operate on) has been well planned, based on the surveyed user-base, but now needs to be supported by data from analytics. This should be possible during the public beta and the team should monitor this, making the relevant changes to their support strategy.
Team
- Emphasis placed on ensuring operations roles are being filled within DVLA for time of live assessment. The team should ensure there is a plan in place to address any possible skills shortage should suppliers change / leave.
Privacy & Infrastructure
- Concern about single leased line. For live we would probably want to see some durability here - either leased line into both data centres or reduced dependency on leased lines.
Open Source
- Only a small proportion of code has been open-sourced. One reason for this was the presence of elements of configuration, which are deemed private. Steps should be taken to minimise the impact of these files and other such resources. Either by extracting these elements to private repositories and opening the main functional code or by open sourcing these configuration files if possible. Files describing interactions between services should not be deemed closed by default.
Digital by Default Service Standard criteria
| Criteria | Passed | Criteria | Passed |
| 1 | Yes | 2 | Yes |
| 3 | Yes | 4 | Yes |
| 5 | Yes | 6 | Yes |
| 7 | Yes | 8 | Yes |
| 9 | Yes | 10 | Yes |
| 11 | Yes | 12 | Yes |
| 13 | Yes | 14 | Yes |
| 15 | Yes | 16 | Yes |
| 17 | Yes | 18 | Yes |
| 19 | Yes | 20 | Yes |
| 21 | Yes | 22 | Yes |
| 23 | Yes | 24 | Yes |
| 25 | Yes | 26 | Yes |
