Traveline Scotland
📅 2024
✏️ UX/UI design
👥 1 Senior UX Designer, 1 Design & Project Manager, 2 User Researchers, 1 Content Designer, 2+ Senior Developers + senior stakeholders at Transport for Scotland
Case and Brief
Traveline Scotland aims to gather all transport providers across Scotland (from trains and buses, to flights and ferries) and make them live under one roof, so that any passenger can plan a multi-modal journey having all services and timetables in one single place. Crucially, the product is able to offer real-time travel information too.
Transport for Scotland wants to redesign both the app and the website in order to have a consistent user experience across the two, with a mobile-first approach so that the desktop format is also consistent.
In addition, the project is to be certified at least AA under the WCAG accessibility standards: for this reason, strong attention was put on low digital confidence audiences and on screen-reading software users.
The challenge
Within the wider scope of the project, my responsibilities were:
To develop prototypes fit for weekly user research sessions, in partnership with the rest of the UCD team.
To preserve the components library, and to expand and maintain it into the design system.
To apply the style guide to all components and adapt it to the relevant component variants as necessary in an ever-evolving library.
To maintain the product journey map to address UI pattern inconsistencies.
To prepare detailed UI elements and screens for handover to the developers, ensuring that these are accessible for screen-readers to WCAG standards.
To translate the mobile app screens and experience into the desktop browser format.
Overall, given the rich database from all the operators in Scotland, and given the clear requirements from the previous project phase, the biggest challenge for the UCD team was
to define HOW all functionalities would present to the users in the MVP.
Research and Insights
The project stems from an earlier Discovery phase in which a list of project requirements was agreed, detailing some of the functions the product is expected to have. While that previous phase of user research detailed “how different user segments navigate travel”, weekly usability tests with Figma prototypes conducted by the User Researchers in the team tapped into the needs and expectations of each user group and behavioural archetypes. This case study shares some of the insights gathered and actioned upon throughout the project, where relevant.
“
We worked extensively with User Groups to gain real insights into the needs, preferences, and pain points of passengers. By involving them early on, we learned how different user segments navigate travel, ensuring the app meets a wide range of expectations. As such, the service lets users tailor their travel experience, prioritising what matters most—whether that’s the quickest route, the fewest transfers, step-free access, or the most eco-friendly path.
Traveline Scotland, on LinkedinBased on the Discovery insights and the client’s requirements, it was agreed early on that the product would offer 3 main functions:
a Journey Planner to plan trips with any mode of public transport, capable to connect any two points in the whole of Scotland using any available transport provider;
a Departure Board for all stops/stations and a Timetable for each service (bus, trains, etc);
a Travel Updates information board, collecting service changes, disruptions and alerts for all operators and transport services across Scotland.
The user is also able to review the list of instructions/info available (for instance, when planning a journey, or when following the line of a train service from station to station) on a map too, both on desktop and mobile.
Solution
Bottom Drawer
Making map-view and text-view coexist,
according to the latest best practices in journey-planning apps
Departures & Timetables as a template
Same data, two points of view: a location with a Departures board listing all services, or a service with a Timetable listing all connected locations.
Maintaining variants and states
Applying and expanding a style guide according to accessibility needs and consistency within affordances.
Bottom Drawer design
How the UCD team worked on the bottom drawer, from prototypes, through tests, to desktop adaptation.
R2
Participants struggled to find more detailed information about the walking portions of a journey. They wanted to see a map but could not find it.
1. List view - Map view toggle
Before I joined the project
For the first few iterations, the overall layout was very close to how the product originally was. For functions where both a list of text content and map content was to be displayed, a toggle was used to switch between list view and map view.
The first few rounds of testing deemed this an insufficient solution, particularly when a user needed to refer to the map from the text content, and viceversa, ideally without flicking between the two view modes. (For instance, there was no way to follow text instructions along the route on map having the 2 side by side.)
R3
Participants also expected that tapping on a particular station would bring up departure information for that station, not just station facilities.
R2
Departures screen confused many participants as they did not understand what the list of stops/stations was.
2. List view
Before I joined the project
Not all main functions of the app showed list vs map. For instance, in the context of a journey detail in prototypes for round 2 and 3, tapping onto a stop/station would link to the facilities at that location, and from there (albeit below the fold) to its departure board, but never allowing to see where the stop/station is located on the map.
List view - map view toggle, however, was available on the main Departures screen (here on the left), showing a number of stops for different types of transport. Once landed on the departure screen for a specific location (screen on the right), list vs map view was not offered as a use option.
R4
Almost all participants said they would use the 'where to' box when presented with the live departures task, rather than tapping on the station icon on the map or in the 'around me' box.
3. Bottom Drawer introduction
R4 prototype
Entirely put together by me, re-housing some of the existing elements and patterns in the bottom drawer and map.
For round 4, a prototype was created solely to test the bottom drawer interaction. Each of the main functions of the app were displayed on a split screen, part text content in the drawer and part map behind it. However, in the effort to simplify the UI, a lot of affordances were dropped, resulting in multiple users in testing not being able to distinguish one function from the other. The hint text chosen to prompt to plan a journey “Where to” was effectively used to answer any question the users might have had, including when they were presented with a task that did not involve planning a journey.
R4
Two participants were surprised to see trains not related to the journey they were planning.
Like the example earlier, a user could land on a station detail screen tapping on that step in the journey planner, but having no indication of what part of the app they were now exploring, some where surprised to find info relating generically to that station, as opposed to info relating only to the planned journey which was relevant to them.
R6-R8
Understanding of the departure board screen was mostly good.
4. Reintroduction of main navigation
R6-R10 prototypes: Departures
Prototypes for R6-10 were crafted by improving the bottom drawer component I created for R4, and expanding the prototype with what was needed for the focus of each of those rounds. For the last 2 rounds, my contributions focused on some aspects of the Departures interface.
From the very next round of testing, the main navigation at the bottom of the screen has then been reinstated permanently. Functions like the departure board of a stop, hosted within the bottom drawer, were now broadly understood, whilst some content that didn’t require a reference on the map, such as location services, featured on full-screen pages rather than in the bottom drawer.
R9 - R10
Multiple participants mentioned that they appreciated the map, saying they found it visually appealing.
One Participant stated that she would prefer the map instead of text on the UI.
Another Participant stated that the map was the most useful feature for her, including the journey details.
5. Journey Planner in Bottom Drawer
R6-R10 prototypes: Journey Planner
Prototypes for R6-10 were crafted by improving the bottom drawer component I created for R4, and expanding the prototype with what was needed for the focus of each of those rounds. I contributed to solidify the Journey Planning flow with filter components and rearranging the user journey steps for progressive disclosure
Rounds 6-10 of testing confirmed the advantages of the bottom drawer splitting the screen between map and text. Tests involved users from low to high digital confidence, and all these rounds collected some good feedback around the bottom drawer. Alongside these rounds, the development of the app has been carried out, with the Journey Planner being the first (and the biggest!) function to be in it.
6. MVP Bottom Drawer vs List-map toggle
Dev handover
Static mocks of the screens handed over to developers featured a lot of the components I created throughout the rounds of prototyping, borrowing them from one function to the other for consistency.
Whilst the idea is to also offer the split view of a location in Departures (and of a service in Timetables), the 1.0 version of the product will show the bottom drawer only for Journey Planner, and will offer the list view - map view toggle for the others.
Journey Planning on desktop - previous product
Departures on desktop - previous product
7. Desktop & mobile
Desktop format
Adaptation from mobile app to web desktop was lead by me, following a thorough audit of the existing web product that I carried out alongside competitive research.
At this point it’s worth noting that the idea of offering both view modes has always been partly informed by the website desktop design, where the text content is in a side panel alongside a wide map viewport.
Journey Planner for MVP
MVP 1.0
The Journey Planner built for 1.0 is the part of the product that most closely resembles the designs I curated myself. The main challenge I tackled collaborating with developers was featuring the same content in an estate that behaves differently, all while ensuring accessibility particularly for screen readers.
To demonstrate the exact correspondence between these mobile and desktop experiences, here is an example of what is being delivered in MVP 1.0 for Journey Planner. The journey results are presented and arranged the same way across mobile and desktop, and when a single journey is selected, the content updates to that journey step-by-step detail both in the bottom drawer and the side panel. The map also changes accordingly.
Next steps
Departures won’t be in the bottom drawer for the 1.0 version of the app, for development reasons. However, the Departures landing screen will offer the list-map view toggle to select a location from either view. Future development will show the departures board of a location in the bottom drawer for the 1.1 release, whilst the location info remains a full-screen page, mimicking the side panel interaction on website.
