National parking platform alpha reassessment report
The report for DfT's National parking platform alpha reassessment on the 10 March 2022
Service Standard reassessment report
National Parking Platform
| From: | Central Digital & Data Office (CDDO) |
| Assessment date: | 10/03/2022 |
| Stage: | Alpha |
| Result: | Met |
| Service provider: | DfT |
Previous assessment reports
Service description
The National Parking Platform is a service that enables the exchange of standardised, reliable, up to date national parking data through a data platform. It is not a public facing service, but citizens will benefit from improved service provision: real time availability, access to more reliable and detailed parking information, and multi-vendor payment options.
The data enables interoperability with connected vehicles and other transport services, and better sustainability and traffic management decisions through strategic data reporting.
The wider service enables multiple service providers to operate in participating parking areas, opens competition leading to better services for motorists and reduces cost of procurement.
Service users
Primary users
- local authority parking operators
- private parking operators
- parking payment service providers
- parking data aggregators
- parking enforcement providers
Indirect users/beneficiaries
- motorists
- EV motorists
- disabled motorists
- motorists with low digital skills
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 a clear vision and have identified different problem statements
- the team could explain the eventual policy intent of enabling better motoring decisions through shared data, while also simplifying council procurement processes and encouraging market competition
- the alpha research has identified four problem statements, including some particular pain points relating to motorists, for example, that motorists with electric vehicles often have to use one app for parking and another to check for charge points
- the team has learned from a ‘private beta’ scale pilot in Manchester
- the team has mapped the touch points/journey for users across the service ecosystem
What the team needs to explore
Before their next assessment, the team must:
- continue to refine their understanding of the policy intent and their problem statements. For example, consistent standards and better procurement processes help councils, which then allow both motorists and eventually policy makers to make better decisions. Understanding how problem statements can be sequenced may help the team focus without losing context. In doing this, the team should continue to engage with wider policy/legislation around sustainability and transport and consider the wider impacts of this service
- look to other departments doing similar things, both within transport and beyond. There is work happening in parallel for rail data, HMRC created a developer hub which met the Service Standard, and the NHS also has a well-resolved developer ecosystem. The Data Standards Authority’s API and Data Exchange community is open to all in the public sector and may help the team learn from similar services
- articulate the problems to solve and pain points more effectively through tangible data and evidence - possibly through focussing on fewer that have greater and measurable impact
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 team has evaluated other options, such as an England-wide service provider app, peer-to-peer integration and councils creating multi-vendor contracts
- the team has learned from the Manchester pilot about some overall pain points, (ranging from merchant IDs to signage and contract processes) and has identified ways to fix them
- the team has a good understanding of take-up and timeframes, (ranging from 1 to 5 years)
- the team has an understanding of the end-to-end journey, and has visualised this in a service landscape
What the team needs to explore
Before their next assessment, the team needs to:
- test their assumption that the offline journey for end users not using the National Parking Platform will not be a lesser experience
- ensure they have the autonomy to respond to what is learned in user research and feedback to shape the service to meet user needs even if that means the project changes direction - while the panel was happy to see some more thought about alternatives, they were still concerned that the focus was on validating a concept rather than testing alternatives
- when looking to the integration of payment with this platform conduct user research around issues of trust and data security for public users as well as users of the National Parking Platform
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 team has had real use of the core user journeys out in the field through the ‘private beta’ Manchester pilot. From this, they’ve evidenced useful learning for this stage of the project, for example, from motorists using entry and exit and barrier car parks and providers bulk uploading of data
- the team has started to think about offline and online content needs and priorities including technical and contractual
- the team has considered the impact on users of non-digital channels and included this in the solution architecture
What the team needs to explore
Before their next assessment, the team must:
- do an actual service demo - while the team spoke of needs relating to guidance and onboarding, and the desire to use an off-the-shelf product for documentation, they did not show a complete journey. Even though this is a data sharing platform there are still user interfaces with patterns and content to review fraud. The team must be able to demo the most important journey to assure the panel that their work is carried out in line with GOV.UK best practice, for example API reference documentation and using GOV.UK Frontend components where possible
- ensure they follow through on plans to conduct research with business users/tech support etc that have access needs
- name the service based on user needs and best practice - ‘National Parking Platform’ does not follow GOV.UK service naming conventions and should only be used if it is too high profile to change
- continue to consider the end-user while designing the service. This may emerge from doing detailed usability testing of guidances and APIs with developers; and understanding user pain points based on the usability and accessibility of existing service provider apps
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:
- taking onboard previous feedback, they are planning on a blended team towards the end of beta
- they have looked at emerging needs and as such they are planning to bring in capability to support including data engineers
- they are looking at future capability and knowledge transfer for continuous improvement
- there is evidence that they’ve collaborated with colleagues in DFT to solve common problems
What the team needs to explore
Before their next assessment, the team needs to:
- make sure that they have the extra user-centred design capability they have specified for beta, in particular technical writing (this is distinct from content design). The team may also need ad-hoc graphic design capability for signage recommendations if this is not available through the Department for Transport
- look to create a ‘one team’ approach in beta
- speak to other API/platform teams to understand sustainable and value for money team composition within beta, for example GOV.UK Notify or NHS Digital (who have recently published a case study about their API platform).
- ensure that knowledge transfer is embedded in their team’s cadences of work so that it is not lost
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:
- through their working private beta technology, they tested their riskiest assumption around availability of parking data. They have seen that organisations on the whole have been willingly sharing their data
- the development team have joined the user research to enhance the loop for insight
- they were able to provide examples of where they have listened and iterated
- they have developed a clear roadmap for private and public beta
What the team needs to explore
Before their next assessment, the team needs to:
- follow through and expand the pilot area for private beta to include areas with different characteristics e.g. rural, seasonal variations
- ensure they use a variety of user research methods with a broad range of users that meet the characteristics of the personas as they make any further iterations - given the number of actors involved, the team may need to focus on different use cases in different rounds of research to make sure that they understand all scenarios
- ensure they design a range of qualitative and quantitative feedback mechanisms to measure whether they are meeting users’ needs and also the KPIs
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:
- they have thought about their mandatory KPIs
- the private beta working software prototype has enabled the team to learn about the data that is trackable for performance but also what will be hardest to track
- they employ feedback mechanisms and from their learning they are considering more (e.g. on data quality)
What the team needs to explore
Before their next assessment, the team must:
- baseline data as early as possible
- adequately quantify and qualify the value around uptake and adoption. There still does not appear to be adequate evidence of the likely adoption of the service that is planned
- by forecasting, and perhaps by working with an economist, create a tangible relationship with savings and cost and articulate quantifiable benefits with values that can be reviewed and monitored
- consider enabling a route to receive, and consequently benefit from, feedback and insight from motorists through their relationship with providers
- identify who will own the performance data and benefits going forward
- as there are multiple problems to solve, look at performance and success through the associated benefits e.g. carbon reduction and efficiency gains by non-EV end users
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 had recognised the need for open sourcing of the solution but had yet to develop any components
- the team understood the value that open sourcing brings
What the team needs to explore
Before their next assessment, the team must:
- discuss which licence the used API code can be released under
- publish the code under an open licence, or explain in detail to the panel if there are barriers to its publication e.g. if the API is being used under a non-open licence agreement
Before their next assessment, the team needs to:
- make the code open; ideally, the location of the open source repositories to a DfT or other public organisation repository
- documentation, including licensing and contributing guidelines should be made clear in the README file
Updates to this page
Published 23 March 2022