Seatmaps | iOS and Android
Choosing a specific seat on a train has been a key feature for Trainline since 2018. Near the end of 2020, seatmaps was prioritised as part of an initiative to boost sales and perception in French and Italian markets, and I lead the end-to-end design for iOS and Android.
Why Seatmaps?
The push for seatmaps began in 2018, when our research team highlighted the customer opportunity in the EU, UK and US markets. The ability to choose a specific seat or sit with travel companions was a top user need and already offered from various operators in each of the countries. Adding this feature was key to competing with key players, and would also help improve conversion, retention and Trainline’s perception in the market.
We prioritised the feature in 2020 to support a new initiative focused on growing Trainline’s market share in Italy and France. Choosing a specific seat was frequently requested by Italian users and was an existing feature of the local train operators (Trenitalia and Italo). In addition, Trainline acquired an Italian app and its users, who were familiar with being able to choose a seat when they purchased.
Italy was the first market for launch, but we knew this was a key needs for customers in all markets. Our design goal was always to build a global and scalable solution that could easily be enabled for multiple countries and train operators.
Our approach
We started with a discovery to evaluate the customer needs and competitor landscape. We knew that choosing a specific seat was important to users, but it didn’t necessarily mean seatmaps. We explored different solutions, and came up with a few hypotheses to take into user testing.
The first round proved the need for seatmaps and confirmed many of our assumptions about the feature. Following this test, we defined an initial set of features and mapped out how these fit with the three major carriers in France, Italy and the UK. We also decided where we wanted seatmaps to live in the app flow.
The MVP feature set of seatmaps included the ability to view, choose and change a seat on high speed Trenitalia trains. Because seatmaps was a conversion driver, we decided that the first launch should be within the booking flow, although post-booking was also important to us.
With the finalised set of features and scope, we moved into our second round of testing focused on the entry point of seatmaps.
Creating the entry point
During our first round of testing, we placed seatmaps in various places in the booking flow to understand customer perception. This, along with the existing architecture of the app, proved that the entry point to seatmaps worked best in our existing “Seating and Options” page. But there was a catch. We were currently skipping this screen for Italian journeys, as seats were automatically assigned.
This created a dilemma. We knew the importance of this feature for Italian users, but adding another screen could result in lost sales. We hypothesised that by creating an entry point that was clearly skippable, we could ensure the benefit to users, while still allowing them to simply continue if they weren’t interested.
We explored several options, but decided to show the options as radio buttons, with an auto-allocated seat selected by default. We felt this showed a clear distinction and choice between the two, adhered to the existing UI of the app and allowed users to easily skip the screen
In 2 rounds of testing with 14 users, our designs were validated. Users clearly understood that they could skip the screen, but also were able to use it to select a seat if they were interested. With this problem solved, we moved on to the actual seatmaps design.
A dynamic modal
Creating a global, dynamic and scalable modal remained a looming challenge of the project. We began by looking into train layouts of the major operators in the EU and UK, trying to find the similarities. After all, we needed our solution to easily scale as we added more markets to the mix, so we had to get the basics right.
Our comparison revealed that although there were a few outliers, most train layouts were similar and included 3 to 4 columns of seats, and 1 to 2 columns of aisles. This led us to the idea of a 6 column grid, in which seats, tables, aisles and other facilities could be placed on one or more cells depending on what was returned back to us from the carrier API.
The grid with dynamic elements allowed us to maintain control over the look and feel of the container and present the inside items based on what was returned to us. It was a lot of work upfront, but it stopped us from having to create and maintain a specific seatmap for every train carrier. And by placing it within a modal, we could access it from anywhere in the app.
We put this through another 2 rounds of user testing to validate the UI, interaction and elements on the page. With a few tweaks, we felt confident to begin passing the design off for implementation.
Delivery
The first version of seatmaps is for Trenitalia trains only, but the need for a global solution was prevalent in all conversations. We worked closely with engineering to ensure that we were building something that could scale to other markets and that wouldn’t back us into a corner.
We accomplished this through collaboration, across our team but also with teams across the company. Regular checkins, refinement sessions, one-off workshops and more were required throughout the process. We also kept the first slice as simple as possible, giving key functionality but realising that more complexity would be harder to manage as we added more operators.
Beyond Italy
That complexity came sooner than expected with a new directive to add seatmaps to a low-cost French carrier, Ouigo. The company had overhauled its business model, and in order to continue selling tickets, we needed to provide the ability for customers to choose a seat in the booking flow.
Luckily, our solution was scalable and simple enough to take on additional complexity, of which there was plenty. For one, French trains often have carriages with 2 floors (upstairs and downstairs), and we needed to fit this into the UI. We also had to look into unique Ouigo-based features, including variable prices for seat types and passenger types. Ouigo is an example of a carrier where the tickets are really cheap, but you have to pay for everything, even a seat with a power plug.
We created new prototypes, and took them in for a further 2 rounds of testing, which helped finalise the UI and interactions and gave us a solid list of items to improve for the future.
Launching Seatmaps
At the end of May, we launched seatmaps to 5% and then 50% of Italian users, to ensure the feature worked as expected and didn’t cause a sharp dip to conversion. Luckily, early results showed conversion as flat, and we were given the go ahead to ramp up to 100%.
Of course, no feature is perfect right out of the door. We tested and validated as much as we could before launch, but the real excitement starts now, when we see the feature in the wild and how customers respond to it. We already have a list of improvements and AB tests, and that list will only grow in the coming weeks.