Bus Open Data

We conducted 1:1 interviews with 7 large, medium and small operators.

Key findings were as follows:

• Large operators had their own tools and systems of how to produce timetable data. They were worried that the new platform would not integrate with their system.

• Small & Medium operators were not familiar with concept of “data”, and the tool they used was Excel.

• Publishing data on BODS would be another task for operators, and for small operators, this requires time and money.

• There are many different variations of the same bus timetable: Weekdays, school days, weekends, bank holidays, etc. The tool had to be able to capture this different information.

• Bus routes are regularly updated, and therefore the data have to be too.

• All operators had concerns on data quality.

Key findings were as follows:

• They needed to be able to find data based on location, bus number, etc.

• Some needed only one data file, while some needed everything.

• It was important to be able to access the historical data for any given route, not just the most up-to-date data.

• Data consumers wanted to be able to access data both as a raw TxC file as well as via an API query.

• The quality of the data was very important.

With the research we conducted, we were able to create personas for the different user types we identified. We held co-creation workshops and persona validation sessions with the DfT stakeholders as well as an implementation groups consisting of a group of industry professionals, all of whom joined to give input to the new policy design and to evaluate the progress of open data initiative.

Before we jump into the personas, it is important to mention that in creating personas for the public sector, we had different aspects to consider compared to usual, the most important of which was the Digital Inclusion Scale. Often as designers, we are exposed to users who are already familiar with technology. However, designing for public meant we had to understand and design for the whole population, including those are reluctant to use technology. To reflect this, each persona also has a Digital Inclusion Scale rating.

Una the Uninformed

Una is a small bus operator, who tend to operate mostly in rural areas. Una’s business is a family business, and therefore Una is both time- and resource-poor. While she has heard about the changes coming to bus operators regarding open data, she hasn’t been informed in timely manner and is unsure of the changes it might bring. This is important as she is also not the most tech savvy of individuals, and will need help around uploading data.

Cameron the Can-do

Cameron works for a medium-sized bus operator and has been in the industry for about a decade. While he is motivated to provide top-quality data to the public, his process for checking the quality is manual. He is concerned about the new policy on open data as it seems to require a change in his company’s operating model, such as hosting the data.

Warren the Wary

Warren is an influential industry expert who also works for one of the largest bus operators in the UK. He is very aware of the new policy guidelines as he was invited to be part of the BODS implementation group, where they discuss the progression of policy development.

He often works with advanced technologies, and is repulsed by the changes required by the new policies. This is because the operator already possesses mature operating models, which will need to take a step back in order to work with the slower paced public systems.

Dayna the Detail-oriented

Dayna is an experienced app developer, who has been working in the transport industry for the past 2 years. When using open data, her main concern is around the quality of the data as it will have a huge affect on the final product.

She also needs the data set to be accessible and searchable through different criteria.

Ian the Innovator

Ian is a PhD researcher studying the correlation between the climate change and transportation data. As a researcher, his interests are around the historical data which he can use for analyses and predictions. As a non-technical person, he also requires instructions on using and finding the data.

Chris the Concerned

Chris is a transport data aggregator who is highly influential in the industry. He is also a part of the BODS implementation group and his opinions are respected by the policy makers. He has concerns around the quality of the data and the direction the industry is going. Additionally, as a transport data aggregation company owner, he is concerned about how the new policies might affect his business.

Henry the Hesitant (Local Authority)

Iris the implementor (DfT Project Lead)

Tim the Techy (Tech Suppliers)

Olivia the Opportunist (Freelance Consultant)

Operators:

• Publishing data

  • Uploading bus data via file upload or API

  • Data Quality check (Feature where the tool itself provides data quality checks on different aspects such as correct stop names, times and etc)

  • Review & Publish

• Updating data sets

  • Uploading bus data via file upload or API

  • Data Quality check

  • Review & Publish

• Managing data sets

  • Ability to view status of datasets

• Managing accounts

  • Team lead accounts

  • Team member accounts

Data consumers

• Finding data

  • Browse catalog

  • Search for a specific data set

  • Download all data sets

  • Pull from API

• Subscribing to a data set

• Providing feedback on a data set

• Account management

  • See subscribed data sets

Publishing and nudging users for quality check

As mentioned above in the challenges, here it was important to design a page that nudges the operator to re-upload higher-quality data, while not forcing them or discarding the current upload. On the left is one of our original designs, where we did not have a review page. This meant that users would be shown the results of the data quality check after publishing was done, rather than before. In addition, the wording of “Passed” suggested to users that they were finished, even if there were issues flagged by the data quality check. This lead to most operators not actually reading through the data quality report.

As a result, we updated this by adding a Review & Publish step, including a check box to confirm that the data quality report has been reviewed and that the data quality was good. This was perceived better, and lead to every operator wanting to look through the data quality report.

Stepper

The left design was done during the alpha phase, prior to my involvement. The design was not only outdated, but also made it difficult for users to know where they were in the process. It did not showcase what step the user was in, or how many more steps user needed to complete. The updated design clearly showcases where they are in the process, and uses an updated style from the GDS design system.

Tab VS List

This is the page operators see when they click “View data quality report“ from their data set review page, prior to publishing. We tested 2 different designs: Tab view and List view. While both designs had pros and cons, users responded better to the list view, where they could see all of the different issues on one page rather than clicking through the tabs.

Data Quality Scroll

This page is the “data quality report detail” page, i.e. the page users land on when they click on an item/issue from the “View data quality report” page. We tested how users would like to see the list of data points (typically the bus stops and times on a given route). The users resonated better without the scroll as they could find the highlighted bits easier, even though the page could get much longer.

Communicating sample vehicle journey

Designing the right UI/UX for the sample vehicle journey is something we struggled quite a bit with. The sample vehicle journey is an example of previously uploaded data which shares the same timing pattern as the newly uploaded data, but does not exhibit the same data quality issues. These are provided for the user when examining a data quality issue as a reference for how to avoid or fix the issue in the newly uploaded data.

However, the phrasing of the first design caused significant confusion for users. The final design resulted after 3-4 iterations.

Curating pathways for different data consumers

This page was effectively a homepage for the data consumers, where they start searching for a data set. The left design was done during the alpha-phase, prior to my involvement. The old design gives only a search option for finding a journey, while we found out that there are 4 different ways for how a user might find the data set they need:

• Browse catalog

• Search for a specific data set

• Download all data sets

• Pull from API

I updated the design to allow users to navigate through the different pathways, and user-tested them with different user groups as mentioned in the persona. Different personas found each of the options useful.