Pay for the Dartford Crossing (Dart Charge)
The report for DfT's Pay for the Dartford Crossing (Dart Charge) alpha assessment on 20 January 2022.
Service Standard assessment report
Pay for the Dartford Crossing (Dart Charge)
| From: | Central Digital & Data Office (CDDO) |
| Assessment date: | 20/01/2021 |
| Stage: | Alpha |
| Result: | Met |
| Service provider: | National Highways |
Service description
The Dart Charge is a free flow charging service for road vehicles crossing the Thames at Dartford. This means there are no physical payments taken on the bridge or the tunnels. There are multiple ways to pay online or offline, including a digital journey from GOV.UK. Not paying a crossing can result in users receiving a penalty charge notice. This can be paid or challenged through the service.
Service users
- UK motorist unaware of the Dart Charge
- International motorist unaware of the Dart Charge
- Motorist using the Dartford Crossing without an account
- Motorist using the Dartford Crossing with an account
- Local residents
- Motorists with vehicle exemptions
- Fleet organisation
- Fleet intermediary
- Contact Centre Staff
- API users
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 carried out a very comprehensive amount of user research, using a variety of methods, including both internal users and end-users
- there are clear findings with well delineated user groups, user needs and pain points
- the team had a strong research focus on accessibility and inclusion, including going through alternative recruitment channels to access hard-to-reach participants
What the team needs to explore
Before their next assessment, the team needs to:
- review the assumption that the user is the motorist, if the user could be someone else in the car, for example, how would that change the user groups categorisation, the approach to accessibility and inclusion and the recruitment of hard-to-reach participants?
- consider looking at accessibility and inclusion also for internal users (customer service operatives and managers)
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
- constraints have been considered and documented and the service design takes these into account and works to minimise the impact for users. the team feed back their research into these constraints to relevant parties
- other free-flowing toll services have been studied and those findings have influenced this design. scalability and reuse of this service for future solutions is part of the design consideration
What the team needs to explore
Before their next assessment, the team needs to:
- review the potential to integrate with shared government services such as GOV.UK sign in and GOV.UK pay, which were not possible in alpha
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 is empowered to improve solutions outside the digital service, and has worked on things such as call centre scripts, offline documentation and GOV.UK content
- designers and user researchers regularly interact with internal and external stakeholders. research data and design propositions are freely shared, and there is evidence of collaborative working such as workshops and voting sessions
- offline channels such as phone and postal journeys are supported in the proposed service design. there are visibility challenges for these journeys, but the team are exploring how to best get this information to users
What the team needs to explore
Before their next assessment, the team needs to:
- given the importance of the PCN in the enforcement journey, the team should work with policy and legal stakeholders to try and influence the design of these notices
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. plain english principles and the GOV.UK style guide have been applied
- there are evidenced links between design decisions and user needs
- accessible design has been applied, and the service has been designed to work on both mobile and desktop devices
- frequent usability testing and design iteration has taken place
- the team has used proven design patterns, for example the sign-in and payment patterns
- the design incorporates the Post Office address finder solution to simplify the account creation and management journey
What the team needs to explore
Before their next assessment, the team needs to:
- reconsider the appropriateness and placement of ‘nudge’ content
some questions to consider:
- does positive feedback in research equal a ‘user need’?
- is there a difference between ‘user need’ and ‘user want’?
- if evidence is strong that this is needed/wanted by some users, is there another place, or a less intrusive placement, for this content?
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 service allows multiple ways to pay - pay after a journey, pre-pay by top up or link to credit/debit card
- offline payment and information channels are available through payzone outlets, call centre and postal options
- varied user groups have been considered, including individual travellers, international travellers, drivers of rental vehicles and road freight
- 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:
- identify and expand on edge-case users and scenarios and outline how the service is designed and developed in beta to cater for these
- consider how privacy concerns could exclude people, and therefore if data and privacy needs to be considered as another barrier to access the service
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 service has had a multidisciplinary team for Alpha, including the roles and skills set out in the Service Manual. This allowed a good quality of research and service design
- the makeup of the team includes a blend of civil servants and very long term contractors. The Product and Delivery part of the team are civil servants who have been working on the service for many years, ensuring continuation
- National Highways is taking considerable steps to build internal DDaT capability and is expected that starting April/May National Highways will have the UCD toolkit in wide use, with capacity to provide user research and service design to projects across NH
- the project is subject to a three-level governance structure and the governance arrangements align to existing management arrangements within National Highways
- the service team has a good system of knowledge transfer put in place. Apart from specific agile ceremonies such as stand ups and Show & Tell the service team uses NH Teams folders to store artefacts to ensure that knowledge is retained when people/companies roll-off. It also uses tools such as Click Up agile project management tool which comprises a Wiki document storage area and Miro boards where NH staff have editor rights
What the team needs to explore
Before their next assessment, the team needs to:
- this is key and long term service and it is essential to have a sustainable team with the knowledge and skills to deliver and maintain the service throughout its lifecycle. Although multidisciplinary and working well at alpha, the team is reliant on its external delivery partner to provide the digital specialists needed for delivery. The team should ensure contractual arrangements with delivery partners are sustainable for the development, maintenance and support of the service
- the team should make efforts to benefit by the positive developments in building internal DDAT capability and appoint more civil servants into key digital roles to ensure the long term sustainability of the service
7. Use agile ways of working
Decision
The service did not meet point 7 of the Standard.
What the team has done well
The panel was impressed that:
- the team has adopted agile practices with an iterative and user-centred approach. They work on 2 weeks sprints, do sprint planning and retros. The service team has regular daily stand-ups
- the service team keeps their stakeholders engaged and involved by doing regular Show & Tells, fortnightly programme MDT presentations and weekly Product Owner sessions
- they have a clear governance structure and are empowered to make decisions. The team are working effectively with their wider organisation to build support for their service
What the team needs to explore
Before their next assessment, the team needs to:
- consider their proposed ways of working at beta. While the prototyping work was done in agile and the team has learnt useful things at alpha, their waterfall delivery beta plan with very long periods of time needed to introduce any change into production is raising concerns
- work closely with CDDO to ensure ongoing alignment to the Service Standard and Technology Code of Practice
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 iterated prototypes rapidly during the Alpha Phase based on user research. This allowed them to discount ideas and correct assumptions about user needs based on feedback
- the team are improving internal practises by using retrospective meetings to constructively review their processes and improve
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 was knowledgeable regarding ways the service could be abused by fraudsters and was able to express the threats quantitatively
- The team was aware of risks of information disclosure implied by some of the designs in alpha and intended to iterate the designs to resolve these
- The tech suppliers working with the team have been through due diligence and should have robust procedures in place to secure the tech they are providing
What the team needs to explore
Before their next assessment, the team needs to:
- explore ecosystem threats - while each supplier has visibility of threats and controls within the components they provide, there is a risk that an adversary could exploit properties of the overall system to execute an attack. A desktop exercise with a wide range of stakeholders and subject matter experts would be on one way to explore this kind of threat
- validate patching mechanisms - i.e. in real world scenarios where vulnerabilities in software are disclosed, check that the systems in place lead to all suppliers finding out about those vulnerabilities and patching within hours or a day or two for high or critical vulnerabilities
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 has defined a clear set of performance indicators for the main problem they are trying to solve: increased compliance and improved customer experience
- the service team has a clear idea of what online and offline channels they will use to collect performance data and are in control of collecting and managing the data
- a new capability, the Data Hub, is being implemented by the NH as a point to centralise the data flow across the entire service
- there will be a data analyst embedded in the team throughout Beta with responsibilities including service performance analytics
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 has been designed with interfaces that should make it easier to switch supplier for parts of the system in the future
What the team needs to explore
Before their next assessment, the team needs to:
- validate that changes can be made to each part of the system in isolation, i.e. without going through a lengthy systems testing process and coordinating activity across multiple suppliers
- iterate on the deployment pipeline and process to bring down the cycle time for changes - it is important for the pace of future delivery that small changes to the frontend as well as security patches should be able to move swiftly - within hours - from inception to deployment, without elaborate process. Slower supplier release cycles for the backend services should not be emulated for the new web component
- as the web component is built, continually consider whether a smaller supplier or an in house team would be able to take on operation of the web component in the future to avoid locking it into the backend services
- during integration testing or before, the panel suggest that the team investigate the impact on user experience when parts of the system experience degraded performance - for example if there’s a lag in detecting crossings and this information is not available by the time users try to pay
-
a wider concern is the ability of Highways England to continually improve their service in response to changing user needs once the service is in the public domain. at a beta assessment, the team should demonstrate that they’re able to capture new or emergent user needs, and:
- either iterate the service, including underlying platforms, to meet those needs
- or migrate components such as the website to an alternate platform if improvements aren’t achievable
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:
- the team intends to open source all software written to extend and integrate the supplier systems as well as the code for the web component of the service
- the organisation has made provision for this in its contractual arrangements with the suppliers
What the team needs to explore
Before their next assessment, the team needs to:
- develop and release the beta service through open source repositories
13. Use and contribute to open standards, common components and patterns
Decision
The service met point 13 of the Standard.
What the team has done well
The panel was impressed that:
- the team is establishing and intends to publish interfaces for the components of the system, to make it easier to re-use and re-procure over time
- the team is exploring the use of GOV.UK notify, pay and sign in
- the team has plans to expand the service to other crossings as well as federate with other road charging schemes to reduce complexity for users
What the team needs to explore
Before their next assessment, the team needs to:
- explore the user experience and technical feasibility of federation in tandem
- determine whether GOV.UK Pay and GOV.UK Sign In are a good fit for the service and if so where they sit within the delivery plan
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:
- considered various scenarios where the system could become unavailable
- has verified minimal user impact
- has plans for comms
- has contractual protection for lost revenue where the issues sit with a supplier
What the team needs to explore
Before their next assessment, the team needs to:
- show how incremental change, including pilots and experiments can be rolled out in the context of the complex supplier landscape. there is a danger that the contractual penalties will foster a culture of “if it ain’t broke don’t fix it” - which would force the cost of change up