Voter Card Alpha Reassessment
The report for the Voter Card alpha reassessment on the 31 May 2022
Service Standard reassessment report
Voter Card
| From: | Central Digital & Data Office (CDDO) |
| Assessment date: | 31/05/2022 |
| Stage: | Alpha |
| Result: | Met |
| Service provider: | DLUHC |
Previous assessment reports
Service description
Electors will be required to identify themselves by showing an approved form of photographic identification before casting their vote in a polling station at:
● UK Parliamentary general elections;
● local elections in England;
● local referendums in England; and
● Police and Crime Commissioner elections in England and Wales.
For electors in GB who do not have an accepted form of photographic identification (defined in Schedule 1 of the Elections Act 2022), EROs will be required to provide a Voter Card - a photographic identification document free of charge for the purposes of voting in polling stations.
Service users
Main user groups:
- 70+ retired
- 30-60 white, non-working
- Mod/Severe disability
- Homeless
The main user groups have been identified and supported by research done in Discovery.
Please note: Although the user research has identified specific groups of users who are most likely to need a Voter Card, the Voter Card service must be made available to every British citizen who is eligible to vote and wants to receive one, regardless of whether they own a photographic identification document or not.
2. Solve a whole problem for users
Decision
The service met point 2 of the Standard.
What the team has done well
The panel was impressed that:
- the service team clearly demonstrated their rational and other options explored in terms of the scope of the service for checking they need a voter card but also applying for a voter card all in one transaction. The service team provided evidence from user research that very few users were unclear on the scope of the service. The service team clearly articulated the live pilots that had taken place in regard to providing identification at polling stations which built towards the policy decision taken
- the service team demonstrated a clear rationale for the use of NINO for verifying identity and explained how this was supported by reusing the DWP FINDR. The service team also explained how they have worked with DWP to make tactical improvements to FINDR in order to better meet users’ needs. The panel were pleased to know the service team have already been engaging with the GDS Digital Identity team and would be considering this as a product becomes available to use
- the service team described several options in regards to reducing the need for users to double key information across related Register to Vote services
- the service team explained clearly there will be no expiry date for the voter card and demonstrated how this information was made available to users throughout the user journey and related service touchpoints
What the team needs to explore
Before their next assessment, the team needs to:
- consider monitoring the number of users who do not go on to apply for a card in order to further validate their rationale for combining ‘check and apply’ into one transaction. Journey completion rates should be monitored in terms of both the check and apply parts of the transaction
- the service team should continue to question what can be done to reduce the need for users to rekey information across related services within the constraints set by policy
- continue to test and undertake user research on those who are not registered to vote to understand how their service plays a part in the overall voting journey
3. Provide a joined-up experience across all channels
Decision
The service met point 3 of the Standard.
What the team has done well
The panel was impressed that:
- the service team has designed and tested paper prototype elements of the service. They clearly presented how design changes could improve the accessibility of the paper artefacts and have provided this advice to the Electoral Commission who have ultimate responsibility for the design of the non-digital touchpoints
- the service team explained how they have an established Business Change process for ensuring Electoral Commission and ultimately Electoral Registration Officers (EROs) are kept aware, informed and are feeding back on changes to the digital service. Areas of responsibility for training and support were clearly laid out with named point of contacts for each area. The service team also demonstrated how in line support might be also delivered within the ERO portal the team is designing, however the team needs to learn from a Beta pilot before they have a full understanding of what areas of support are required
- the service team clearly demonstrated how access to assisted digital and user support was provided across paper, or digital touchpoints. The panel were particularly pleased to see how already live support pages on GOV.UK would be updated to incorporate the new service. This is going above and beyond for an Alpha assessment
- the service team clearly articulated the different circumstances by which a replacement card will be issued. They showed their thinking in terms of business logic and as a result they have made excellent headway in understanding what flows they will need to build in Beta/Live
- the service team demonstrated how the start page signposts users with no fixed address to register to vote, and explained how once this has happened the user is eligible to apply for a Voter Registration card. They demonstrated content iterations they have made such as incorporating partial postcodes in order to make the user journey clearer to users with no fixed address
What the team needs to explore
Before their next assessment, the team needs to
- In the beta assessment the panel would be interested to hear an update on how the digital service development roadmap has been aligned to the design and roll out of the paper touch point of the service that Electoral Commission are responsible for
4. Make the service simple to use
Decision
The service met point 4 of the Standard.
What the team has done well
The panel was impressed that:
- the service team were clear to show their process for how they will collect and evaluate user feedback and how this would be a blend of quant and qual insights
- the service team demonstrate a significant amount of quant research which informed their understanding of the demographic make up of the service. The service team clearly articulated how their research to date had been representative of these groups
- the service team had done truly impressive work in regards to measuring how easy the service was to use. The team have a very clear understanding of expected completion rates and completion times, which has given them a really strong baseline for evaluating the success of their private beta
- the service team had designed and tested paper prototype elements of the service. They clearly presented how design changes could improve the accessibility of the paper artefacts and have provided this advice to the Electoral Commission who have ultimate responsibility for the design of the non-digital touchpoints
- the panel were delighted to see the team engaging with the GOV.UK content team for a 2i and were pleased to hear suggestions of breaking the guidance into sections was a useful outcome and had validated by user research
What the team needs to explore
Before their next assessment, the team needs to:
- going forward the panel would strongly advise the team to pay specific attention to the ERO’s pain points within their beta. It’s essential that the team also consider how the technology decisions impact EROs operationally. A future panel would be particularly interested to learn about the consequence of introducing another software solution for EROs to use, for example how did ERO’s prioritise their workload across both the ERO portal & the existing EMS systems
- the service team should consider how a user with no fixed address might express a preference in regards to where they will collect the Voter Card from. This is highly likely to create operational burden for EROs, impact card collection rates and ultimately presents an opportunity for automating parts of the process for EROs
5. Make sure everyone can use the service
Decision
The service met point 5 of the Standard.
What the team has done well
The panel was impressed that:
- the panel were delighted to hear how the team has done specific research in understanding the specific needs of users with access needs. The panel was pleased to hear about plans for accessibility in beta and saw the vast majority of patterns being used align to the GOV.UK Design system
- the service team had acted on the first assessments feedback and investigate the applicability of the ATAG guidelines. Whilst the ERO portal does not come under the scope of ATAG, the panel welcomed the analysis and consideration that had been made to understand how these criteria might be applied to the design of the ERO portal going forward
- the service team had a clear articulation on the groups most likely to be excluded from the service and had good explanations for strategies to meet their needs - such as ensuring the service would be available in a range of formats & languages
What the team needs to explore
Before their next assessment, the team needs to:
- although the part of the journey that focuses on adding a photo and giving identity details is based on patterns from the Blue Badge service, the team should consider comparing their users’ demographic groups with those of the Blue Badge service to ascertain whether user research is needed for those parts of the journey
- ensure that they are feeding in their research to the design system team, especially the use of check your eligibility
6. Have a multidisciplinary team
Decision
The service met point 6 of the Standard.
What the team has done well
The panel was impressed that:
- there is a clear multidisciplinary team that are working well together, and engaging with policy or across the organisation
- since the last assessment, the team have reviewed the roles suggested. There is a clear Product Manager, and the team have secured funding for beta, using a variety of methods to ensure that any recruitment gaps could be fulfilled
- there are clear plans in place to continue to invest in building the number of permanent staff and Civil Servants, as well as considering where there can be join up on other and complimentary services in the department
- the team had already considered operational support and are actively thinking about the long-term ambition of their service
- the use of contractors is sustainable, particularly with recruitment constraints and members of the team will be working on both alpha and their private beta
What the team needs to explore
Before their next assessment, the team needs to:
- continue to ensure that user research and data is actively being shared across the organisation to assist in service development
- ensure that there is an appropriate plan of knowledge transfer from suppliers, and that this is actively being considered whilst continuing to recruit. The team should continue to develop opportunities for knowledge sharing sessions, or paired activity
- develop their funding model, so that there is a continual investment in the service
- ensure that appropriate leadership is in place across disciplines as the team scales up and that areas are actively being joined up
12. Make new source code open
Decision
The service met point 12 of the Standard.
What the team has done well
The panel was impressed that:
- consideration had been given to what code can and can’t be open sourced with clear rationales given as to why
- consideration has been given to security testing of code in beta
What the team needs to explore
Before their next assessment, the team needs to:
- be able to demonstrate what code has been made open source at beta assessment, i.e. provide links to open source repositories
- ensure code repositories are migrated to DLUHC to enable continued management and ownership
- consider whether moving from a monolithic code repository could better support open source requirements