We’ve written previously about the role of open data in organisational transparency and the Department for Transport’s (DfT) ambition to bring data providers together, making data more accessible to solve road-based challenges through a National Access Point (NAP).
We’ve been supporting the Department of Transport (DfT) to recognise what could be improved and introduced to provide the right digital infrastructure and enable easier access to the UK’s road transport data.
Meeting the different needs of potential users
Those in the transport community that would most immediately benefit from a new NAP work in central government, local authorities, the commercial sector and research. All of whom have a broad set of needs for a NAP and various levels of data literacy. It was clear that creating a data catalogue that effectively met the needs of all of these different types of users was going to be a challenge.
To help us understand each of these users, their challenges and how they would use and publish transport data, we looked at what each of them needed most from a NAP.
We spoke with a broad range of participants to grow our understanding of data publisher user journeys and how we might be able to improve data discoverability and metadata. Learning from users from over twenty organisations, we developed four personas to represent the full spectrum of potential users. These personas included varied levels of technical expertise with different goals, data tasks, motivations and challenges.
This helped us focus on four areas that the current NAP is lacking which includes the visualisation of data, use case examples and user-friendly feedback and engagement mechanism. Whilst looking at improving the search feature and the inclusion of commercial data to provide a complete view of data sources.
During the Alpha phase, we developed multiple prototypes which included a dataset page mock-up, feedback and analytics pages mock-up and a customised CKAN search engine.
Prototype 1: dataset page mock-up
This focused on confirming which metadata is more useful than others, while allowing users to look for information on data standards, explanations of technical terms and guidance on metadata.
Prototype 2: feedback and analytics pages mock-up
We also created a feedback and analytics pages mock-up, which includes an optional registration function with added benefits to facilitate feedback submission. Through our conversations, we found that feedback is rarely provided directly, but openly shared and discussed on public forums like Twitter. Data users suggested including an optional registration function to facilitate feedback submission, as well as a more personalised experience with the NAP. This new feature creates a more personalised experience for the user, with elements such as browser history and push notifications.
“It’s very useful for us to get feedback on how our data has been used and the amount of engagement people have had with it. It helps justify the resource needed.” — A public data publisher
Prototype 3: customised search engine
Our final prototype was a customised CKAN site, which incorporates different groupings of datasets by mode of transport or publisher. It included different filters including dataset format, by dates, tags and licensing or access rights. Going forward we’ve made recommendations to continue to improve data discoverability by focusing on search engine optimisation and automating the inclusion of new data sources to the NAP where possible.
Passing the Alpha service assessment
The NAP recently passed an Alpha service assessment which means our prototypes meet crucial standards that cover being simple to use, meeting user needs, solving a whole problem and using open-source technology.
As the Service Standard is a blanket approach to evaluate all public services, some of its points were more applicable to NAP than others. Where points were less relevant, we gathered evidence for possible equivalents. For example, the NAP metadata catalogue is a fully-digital service, because it focuses on data discoverability across multiple different digital sources. We established that people without access to the internet wouldn’t be able to access the data the NAP signposts to on other websites and digital services. To meet the service requirement to “make sure everyone can use the service”, it was more relevant to talk about data users with low data comprehension and how the NAP could support them more effectively.
We also considered users with accessibility requirements. While providing visualisations of data meets a key user need, there is also a risk that we won’t be able to make that feature fully accessible. We’ve recommended rigorous accessibility testing during Beta, hopefully ensuring suggested features like data visualisation have the same or similar fidelity for users who use screen readers or other assistive technologies.
Looking forward, we hope that Beta will test scalability, as Alpha only focused on a portion of UK road data. Post-launch, the live service is expected to grow to cover all transport data with the added possibilities for data publishers and users to adapt the NAP model, contributing to a more efficient use of data by even more users in different industries.