Pay the Dartford Crossing (Dart Charge) beta assessment
Service Standard assessment report Pay the Dartford Crossing (Dart Charge) 09/05/2023
Service Standard assessment report
Pay the Dartford Crossing (Dart Charge)
| From: | Central Digital & Data Office (CDDO) |
| Assessment date: | 09/05/2023 |
| Stage: | Beta |
| Result: | Not met |
| Service provider: | National Highways |
Previous assessment reports
Service description
A web service which allows users of the Dartford crossing to pay for their crossing online either as a one-off payment, ‘pay as you go’ or via a top up account. There are facilities to set up and pay via business accounts, used mainly by freight transport companies.
Users are able to pay or challenge a PCN (Penalty Charge Notice- a fine for not paying the toll charge in time) within the Service.
The Service will include IVR (Interactive Voice Recognition) telephone numbers for both Payment and Enforcement (paying a PCN), and an option to call a contact centre (number supplied within the Service).
There are also ‘contact us’ flows for the Payment and Enforcement parts of the Service, along with complaint form flows.
Key charging hours and statistics for 2022
- Charging hours are 0600 – 2200 daily
- Number of crossings - 48.5 million
- Daily average – 133,000
- Daily average of crossings by vehicles with number plates not previously seen – 4,672
- Percentage of users who pay the crossing fee on time and do not receive a PCN – 94.4%
- Number of open accounts - 880,000
- Number of vehicles in these accounts – 2.9 million
Service users
- Fleet (national and international)
- Residents
- Foreign visitors
- Commuters
High level user needs this service aims to meet
As a user of the Dartcharge Service…
- Ineed…to be able to manage my payments in a way that suits me
So that…I can pay for my crossings quickly and easily without incurring a charge
- I need…to understand how the Dartford Crossing works
-
So that…I do what is needed of me and don’t incur a penalty charge
- I need…to understand how I make a payment for a penalty charge
So that…I can pay the charge on time and avoid additional costs
- I need…to understand why and how I can challenge a penalty charge
So that…I can make the decision whether to challenge the charge or not, and challenge it correctly
- I need…to contact Dartcharge to make a complaint
So that…I can resolve or report an issue
1. Understand users and their needs
Decision
The service met point 1 of the Standard.
What the team has done well
The panel was impressed that:
- the team has undertaken a lot of additional user research in Beta, e.g., 140 user sessions, 80 usability tests, and in addition analysed over 3,000 service requests with the call centre. The team undertook a variety of research methods, e.g., carried out a very comprehensive amount of user research, using a variety of methods, including both internal users and end-users. Research has covered all user groups and internal customer service representatives.
- user needs have been clearly identified, and pain points captured and prioritised. There is clear evidence this has been fed into design iteration, and into the product roadmap, and the roadmap remains user focused.
- the team had a strong research focus on accessibility and inclusion, e.g., accessibility is included in all user groups. In total there were 56 users included who had digital inclusion needs, 68 users who had accessibility needs and 36 users that were identified as having digital inclusion and accessibility needs.
What the team needs to explore
Before their next assessment, the team needs to:
- evidence they are continuing to analyse and prioritise research, e.g., drop off rates in the user journey
- provide greater clarity on how they are engaging with business stakeholders, and which decisions (if any) are being led by stakeholder need and not user need.
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 team have considered the full end-to-end user journey, including the steps before and after the digital service, and this is reflected in their designs
- they understand the constraints and the boundaries of their service (e.g., there only moderate scope to change signage) but are working closely with adjacent teams (e.g., signage) as well as other governmental departments like DVLA and local councils on either side of the bridge/ tunnel
- they have worked with third parties such as Google Maps to signpost to drivers that a toll will be part of their journey
- they have designed the service to give users the opportunity to succeed the first time and not penalise them for an initial mistake, so the first missed toll is only the price of the toll
- they have introduced a flagging that detects a local postcode so the user knows they might qualify for the discounted rate
What the team needs to explore
Before their next assessment, the team needs to:
- review the feasibility of government services, particularly GOV.UK sign in and GOV.UK pay and when they can be achieved on the roadmap. This was recommended at alpha and is still a recommendation of beta.
Ensure the journeys for locals receiving a discount- as well as locals moving from the area has been considered
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 considered solutions outside the digital service, and has worked on components such as call centre scripts, offline documentation including paper form and PCN
- designers and user researchers regularly interact with internal and external stakeholders. research data and design propositions are freely shared across teams
- the team have worked closely with the contact centre listening into calls and monitoring complaints to find opportunities to improve the service
- they have surfaced the contact details for getting help on the start page so users can call if they prefer
What the team needs to explore
Before their next assessment, the team needs to:
- ensure a plan for ongoing research of the end-to-end journey into public beta, particularly as the service switches providers
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 language and content used in the service reflects the research undertaken into the language of the users. The team have created a terminology guide used across all paths.
- The service has been designed to work on both mobile and desktop devices. It meets WCAG 2.1 AA
- They have tested the service on a variety of devices
- the team has used proven design patterns, for example the sign-in and payment patterns. Where they have deviated such as in the account management pages, they have thoroughly tested this with users
- the service allows multiple ways to pay - after a journey, pre-pay by top up or link to credit/debit card and also includes offline through Payzone outlets, call centre and postal options
What the team needs to explore
Before their next assessment, the team needs to:
- ensure a smooth transition for users moving from the old service to the new. While new users went onto the new system for private beta, existing ones primarily stayed on the old one. However, the team has indicated some existing users have come onto the new system.
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:
- varied user groups have been considered, including individual travellers, international travellers, drivers of rental vehicles and road freight
- the have worked with Digital Champion Network and Citizens online to support users with the service
- users with accessibility needs have been included in service research, and organisations representing these user groups have been consulted
What the team needs to explore
Before their next assessment, the team needs to:
- continue testing with users’ accessibility needs and ensure that changes recommended by the accessibility audit are actioned before launch.
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:
- the majority of the team have remained consistent since Alpha and that continuity continues into public Beta
- the team acted on Alpha assessment recommendations to bring in appropriate resources
- Technical decisions are collaboratively reached between the team and wider architecture community
7. Use agile ways of working
Decision
The service met point 7 of the Standard.
What the team has done well
The panel was impressed that:
- the team use many of the common agile ceremonies in order to allow collaboration, and make their work visible through show and tells
- the team is using regular user research and adapting their approach as they learn
- the team has a robust governance structure and process in place
- the team regularly gather user feedback, they have plans in place for operational readiness for the transition into public beta
8. Iterate and improve frequently
Decision
The service met point 8 of the Standard.
What the team has done well
The panel was impressed that:
- the team is taking an iterative approach to the work and demonstrated that usability testing and feedback are informing multiple iterations throughout
- the team is planning to carry out regular iterations of the service throughout the beta phase
9. Create a secure service which protects users’ privacy
Decision
The service met point 9 of the Standard.
What the team has done well
The panel was impressed that:
- the team demonstrated the care taken to minimise retention of personal data within the system
- vulnerability management systems were in place to cater to both urgent and routine patching
- the team was able to explain the threat model and for the system and how this had fed into the design
What the team needs to explore
Before their next assessment, the team needs to:
- continue to monitor vulnerability management - i.e., ensure that in real world scenarios the systems in place lead to all suppliers finding out about those vulnerabilities and patching promptly
10. Define what success looks like and publish performance data
Decision
The service met point 10 of the Standard.
What the team has done well
The panel was impressed that the team:
- outlined some success metrics for their areas of operation
- were collecting data from the back end to compensate for the loss of data due to users not accepting cookies
- complied with cookie consent models
- provided some examples where data had helped with the development of the service
What the team needs to explore
Before their next assessment, the team needs to:
- show better awareness of the service’s top-level performance indicators. The assessment and documentation shared showed that a huge amount of data was being collected, shared and reported, but it wasn’t clear that this had been evaluated or prioritised. Different areas had their own success measures but there should be more clarity and awareness of the most important performance measures for the service as a whole, and of how these relate to the overall aims of the service.
- consider how analytics tracking can be harmonised - at the moment the payments and penalties sections of the service each use different analytics software. This can make it difficult to track journeys which cross from one to the other. It also results in users being presented with two different cookie consent messages.
- given the huge volume of data that will be collected from the service we’d like to see more examples of the impact this has on the team’s decision making.
11. Choose the right tools and technology
Decision
The service met point 11 of the Standard.
What the team has done well
The panel was impressed that:
- the system is designed with appropriate interfaces and APIs
- the team was able to show that feedback from the previous assessment had been taken on board
12. Make new source code open
Decision
The service has not met point 12 of the Standard.
What the team needs to explore
Before their next assessment, the team needs to:
- open some of the codebase and provide links to the relevant repositories
13. Use and contribute to open standards, common components and patterns
Decision
The service has not met point 13 of the Standard.
What the team has done well
The panel was impressed that:
- the team has plans to integrate with GOV.UK Notify, Pay and One Login
- the team has an aspiration to provide/form part of a cohesive offering for other crossings and road charging
What the team needs to explore
Before their next assessment, the team needs to:
- progress adoption of common components
14. Operate a reliable service
Decision
The service met point 14 of the Standard.
What the team has done well
The panel was impressed that:
- the team has given substantial thought to dealing with failure conditions, including how rules can be adjusted e.g., to allow users more time to pay in the event of a system issue