BODS-2

I helped the UK government: transform public transport with Bus Open Data Service.

GOV.UK GDS · BUS OPEN DATA SERVICE · DEVELOPER TOOL

Designing BODS: A groundbreaking platform for nationwide bus data – a one-stop hub for timetables, fares, and real-time bus locations across England.

Accessible to app developers, mapping pros, and researchers, a key to bus data anywhere, anytime.

KPMG, UX Research & Design, 2021 - Ongoing

Display_banner

Buses bring important benefits to society, the economy, and the environment. In the UK, they are the most commonly used form of public transportation. In fact, over sixty percent of public transport journeys are on buses, yet the availability and quality of information available to passengers when planning their trips, waiting at bus stops, or travelling to their destinations varies considerably across the country.

They also help reduce traffic congestion and offer accessible transportation for many people and providing 123,000 jobs and contributing £6 billion to the economy. 

Because of these reasons, the UK's Department of Transport (DfT) wanted to make it easier for everyone in England to use buses by making details of bus services available as open data, as required by the Public Service Vehicle Open Data England Regulations.

Transformation through open data

The answer to this was the creation of Bus Open Data Service (BODS). A platform that provides open access to a wide range of data related to bus transportation in England.

It includes information such as bus timetables, locations, and fares. BODS aims to make this data easily accessible to various users, including app developers, mapping providers, researchers, and the public allowing them to quickly find timetable, fare and location detail for any bus in the country.

This will enable passengers to:

  • plan their journeys with confidence
  • spend less time waiting
  • find the best value tickets
  • encourage efficient connectivity and public transport usage

Most importantly, BODS also aligned with the government's efforts to standardize and share data collected by bus operators nationwide while adhering to strict Government Digital Service (GDS) standards. BODS indexes and provides this transport data using industry standards like TranxChange, NeTEx, and SIRI. Data users can access it through various methods such as rest APIs, front-end dashboards, and bulk downloads.

01 — Agile Methodology

During my time at BODS, I worked with a diverse team of experts in areas like data analytics, cloud technology, design, testing, civil servants and specialist technical partners. 

My tasks involved conducted thorough user research involving various stakeholders, including bus companies, local authorities, passengers, and journey planning providers. In each sprint cycle and feature release, I focused on extensive user testing through interviews, workshops, and consultations, using the feedback to continuously improve the digital service as described by the diagram below:

Agile

During the initial phases of discovery and definition, I extensively studied the problem and the materials provided. With a baseline understanding of the problem, I started by gathered evidence and data to guide my approach in addressing users' most important issues. This involved talking to users, understanding their goals, and identifying constraints or opportunities for improvement.

My research methods included user interviews, field studies, and workshops. I also combined insights from various qualitative methods to narrow down the problem's scope. This was accomplished this by:

  • Interviewing bus operators, both large and small, across England.
  • Engaging with developers and third parties to understand their needs and technical limitations.
  • Facilitating workshops, consultations, and ongoing discussions to resolve conflicting requirements and preventing scope-creep.
  • Members of the team joining the bus operators and shadowing their daily operations.

The insights gathered during these sessions were crucial in creating a comprehensive list of pain points and expectations, which played a pivotal role in the later stages of our framework used to identify opportunities.

After the discovery phase, the research and insight was evaluated, resulting in six key personas relevant to BODS, including data suppliers, bus operators, and data consumers. For each persona,I crafted user-centered problem statements and hypotheses, placing the user at the center of BODS. Furthermore, the research data was to refine these personas into sub-personas, each with their unique user needs, pain points, and motivations. 

These key stakeholders were then invited to user research and feedback sessions where I conducted workshops to tackle various challenges, build new features and develop the service in various releases. The size of a release would depend on the complexity, build velocity, resource availability and design readiness of the problem. It was common to have design workstreams running parallel to each other at various release stages.

However, a typical release would follow a process pipeline shown below:

The objective of this workshop was to capture feedback on the way users added fares data to the BODS database. Using a white-boarding tool like Miro helped me capture and map feedback in real-time while speaking to participants.
1. User research workshop and feedback session.
The objective of this workshop was to capture feedback on the way users added fares data to the BODS database. Using a white-boarding tool like Miro helped me capture and map feedback in real-time while speaking to participants.
An example of a session where I, along with a Product owner, reworked the user flow to configure bus services which are exempt from data processing. This kind of rapid prototyping was often done using screengrabs and utilising components that I designed earlier.
2. Prototyping and white-boarding
An example of a session where I, along with a Product owner, reworked the user flow to configure bus services which are exempt from data processing. This kind of rapid prototyping was often done using screengrabs and utilising components that I designed earlier.
I used a mix of Miro and Figma to test and track feedback on any new and re-worked features. It was also a great way to share thoughts, notes and brainstorm ideas with the extended team including a mix of stakeholders, engineers, analysts and SMEs
3. Incorporating feedback and reworking the user flow.
I used a mix of Miro and Figma to test and track feedback on any new and re-worked features. It was also a great way to share thoughts, notes and brainstorm ideas with the extended team including a mix of stakeholders, engineers, analysts and SMEs.
For BODS, I used a mix of Sketch and Figma to  wireframe high fidelity mock-ups. I inherited some assets and working files in Sketch, which I eventually migrated to Figma to take advantage of its collaborative features - effectively decreasing my turnaround time and greater transparency.
4. Creating wire-frames and mock-ups.
For BODS, I used a mix of Sketch and Figma to wireframe high fidelity mock-ups. I inherited some assets and working files in Sketch, which I eventually migrated to Figma to take advantage of its collaborative features - effectively decreasing my turnaround time and greater transparency.
User journeys and completed feature sets; test-ready.
5. User journeys and completed feature sets; test-ready
With the mock-ups ready, I would categorise and arrange them by distinct user journeys and completed feature sets. Once an entire journey or a feature site was complete, I'd test it with the users circling back, once again to workshops and testing sessions
Staging-website
6. Staging website and development
With the feedback incorporated and the mock-ups ready, I'd upload the developer-ready versions to a master file. In conjunction with Figma and Zeplin, this master file was used to develop a staging site, used for further testing and refining updates, ensuring a smooth deployment to the public site.

02 — Building with GDS Compliance

While creating prototypes for the Bus Open Data Service, I followed the Government Digital Service rules. This was critical because all goverment services are required to pass an accessibility audit defined by WCAG 2.1 accessibility guidelines.

Some of the WCAG 2.1 considerations that I worked with included - but were not limited to:

  • Testing compatiability with various assistive technologies such as screen-readers, magnifiers and peripherals
  • Providing text alternatives (‘alt text’) for non-text content such as pictures, video and audio
  • Using descriptive titles for pages, frames and links
  • Ability to navigate page content with a keyboard and being able to 'skip to main content'
  • Not using animated, blinking or flashing content
  • Using colour and contrast to showcase active focus states

In addition to that, I leveraged established styles and patterns across various government services websites to produce solutions that looked and felt familiar. Instead of creating every component from scratch, I utilised the Gov.uk Prototyping kit in Figma and Sketch to quickly create and re-iterate prototypes which could be deployed and tested with users rapidly.

Video: Keyboard navigation to with text links highlighted.

Video: Responsive page elements and text which can be altered without affecting the page layout / integrity.

Colour-palette-1
Crown-Copyright-2
Iconography-3
A summary list component is used to summarise information at the end of a user journry, for example, a user’s responses at the end of a form.
GDS Component: Summary List
A summary list component is used to summarise information at the end of a user journry, for example, a user’s responses at the end of a form.
Summary lists are used to display and verify data that a user provides. This is an example of a variation of the component that I used to capture and visualise bus location data.
GDS Component: Summary list
Summary lists are used to display and verify data that a user provides. This is an example of a variation of the component that I used to capture and visualise bus location data.
Radio components are used to ensure that users can only select one option from a list. In this case, their role and access level to the BODS database. Radio components are used to ensure that users can only select one option from a list. In this case, their role and access level to the BODS database.  GDS also recommends not pre-selecting radio options as this makes it more likely that users will not realise they’ve missed a question or submit a wrong answer.
GDS Component: Radio buttons
Radio components are used to ensure that users can only select one option from a list. In this case, their role and access level to the BODS database. GDS also recommends not pre-selecting radio options as this makes it more likely that users will not realise they’ve missed a question or submit a wrong answer.
Panel
GDS Component: Panel
GDS defines Panels components as visible containers used on confirmation or results pages to highlight important content. For BODS, the panel component is used to display important information when a data upload has been completed. In most cases, the panel component is used on confirmation pages, to tell the user they have successfully completed the transaction.
Error-state
GDS Component: Error summary
It is important to show error messages next to errors to ensure that users can understand and fix the problem. A red border is used to visually connect the message and the question it belongs to in addition to putting the error message in red after the question text and hint text.

03 — Test, Release and Re-iterate

BODS emphasizes rigorous Quality Assurance and Performance Testing throughout the app development process. The team used a mix of manual and automated testing methods to check the service's coverage and speed.

Based on the feedback, each release was carefully planned, with features and changes expressed as user stories based on priority and size. This ensured stability and continuous improvement.

We typically released a monthly update, notifying the industry via email, workshops, and user feedback sessions. Changes and improvements for every version were also clearly explained in the changelog on the BODS website.

In addition to regular testing and feedback sessions, the Bus Open Data Service continues to employ a dedicated team of domain experts who provide support and knowledge to the users through the Business Change and Helpdesk services. They work one-on-one with transport operators to understand their legal requirements for publishing open data to the service. Providing training on the Department for Transport’s supporting software and introductions to suppliers that can enable them to comply with the regulations. The team remains in consistent communication with key stakeholders, including suppliers, publishers, and consumers, to ensure the ecosystem is aligned with a clear vision forward. 

BODS-User-Interface-Showcase

BODS in action

Before BODS, there was no single transport data platform for the entire English bus industry, and very few had real-time data feeds. A similar project in London in 2017 estimated economic savings and benefits at £130 million. Importantly, BODS can help shift the bus industry towards an on-demand model, reducing the need for private cars and making public transport more flexible.

BODS is leading the way, setting the standard for transport data platforms not just in the UK, but globally. Poised to become the cornerstone of England's national transport data infrastructure, BODS will continue offering valuable insights and integration with other data sources in the future.

BODS-Project-Summary

BODS in the media

"Open transport data is valuable both in providing real time information to passengers and enabling a broader ecosystem of app developers and service providers that will allow future innovative solutions to the challenges of urban mobility"

Ed Parsons, Geospatial Technologist at Google

"We’re delighted to see this significant step forward. Consumers are the ultimate winners. Armed with better information, they can plan their journeys more easily and make better choices about tickets"

David Beardmore, Commercial Director at the Open Data Institute

How DfT Bus Open Data (BODS) can be used to plan an electrified bus fleet (Link)
"Thanks to the opening up of bus timetable and route data, building a public transport model has never been easier"

Laurence Chittock, Transport Modeller PTV Group

Passengers set to benefit from new digital transport strategy (Link)
"Enhancing transport data aims to give people better travel planning at their fingertips by improving the accuracy of travel planning apps and making journeys easier to plan"

Department for Transport, Gov.uk

More work

Over the course of my career, I've had the opportunity to work on a range of projects, across industries that continue shaping our digital landscape. I have collected a few case studies to illustrate my design process, the objectives and outcomes for some of the projects that I've worked on.

I also use this portfolio as a reference point for myself, to keep track of my learning and development as I continue evolving in my design career. Please feel free to reach out if you have any feedback, comments or if you'd like to know more about my work.

Kia Reviews

Designing for trust: How I designed a review system that fosters trust, provides valuable information, and enhances car buying experience for Kia customers.

Roombuilder

Efficient and elegant: How I designed a Unity based software tool that helped interior decorators create and render photorealistic room designs in 3D, with home decor and furniture, exactly to scale.

Timar

Mobile-first: Designing an application that helps users discover salons for a broad range of beauty treatments and easily manage appointments.

Thank you for visiting my website 🌍

If you'd like to know more about my work, please send me an email or get in touch on LinkedIn.