I led the design process of this project from the initial kick-off to final delivery for desktop, including responsive experience. I worked with a big team of engineers (data automation, backend and frontend), my peer product manager and business managers. The design process included constant feedback loop not only from other departments but most importantly, from my fellow design ops, ux design & research colleagues to whom I have to thank for helping me and challenging the proposed ideas, solutions.
During the time of working on this project as a contributor, I have also been supporting the design team from a partial leadership position, being responsible for team objectives, planning and prioritisation. Constant combination of two different mindsets challenged me and gladly showed me new perspectives.
How offering of a seat helps to negotiate with airlines?
The company is growing fast. The footstep in the travel industry is starting to be visible. A crucial part of being able to provide an excellent experience and continue growing is to build official partnerships with airlines and data providers. It is especially hard to talk to low-cost airlines. Their business models focus on selling additional services, not the tickets themselves. A lot of them refuse to cooperate with us since it would not be beneficial for them. Mainly because of our still low ability to offer "something more" than just travel tickets during the booking process. Providing the ability to sell seating options would get us closer to new partnership opportunities.
The myths of specific seats in a plane
When we started defining this project, one of the first stops was to go and talk with our customer support department. Chatting with agents who are in close connection with our customers daily started to help me build empathy for what might be the issues we will need to be tackling. We specifically asked about seating arrangements and what are the various requests the customers make. We received a wide variety of different stories and myths. People who contact us because of a specific seating arrangement a lot of the times have some prejudice that seating in the front (or back) is safer than vice-versa. There are stories about busy people who need to be the first ones out of the plane. Or people who want or don't want to sit next to the toilet. Altogether there have been just too much variety to get into some specific problem, yet.
Scrubbing through the complaints customers left on various sources, we quickly realised that one of the most significant misunderstandings has always been the expectation of seating together. A lot of the customers were expecting when booking, that they would be seated next to each other. Especially low-cost airlines seat passengers randomly unless they pay for specific seating allocation. We did not communicate any information about the seating arrangements before receiving the boarding passes, and that confused customers and mostly resulted in a negative surprise.
A few examples of complaints extracted from our internal tracking tool.
We do regular usability testing sessions, and our research team also works on explorative projects with our users. As designers, we are trying to be involved as much as possible, and during the last couple of months, we observed some interesting general takeaways. One of the principles we are trying to hold is to make our experience fast and very straightforward. The speed is something we see numerous users enjoy, especially during the booking process. As the service is growing, naturally, we are implementing more options, and it gets harder to make the process simple, fast and straightforward. I took this as one of the essential values to hold onto when implementing the seating feature during booking.
Does the above make sense? Travellers seating patterns
When working on this problem, our product has already offered to select a seat on a different touchpoint. Users could purchase it in the "Manage My Booking" section for specific airlines. A great way to gather more insights into and very quickly validate some first ideas. It could narrow down the focus of our ideation a little and tell us whether we are approaching the right problem statements. It was also essential to keep in mind that the behavioural patterns of the users might be a little different, since the "Manage My booking" seat offering is in later part of the product's customer journey.
Since we needed an anchor point, we chose the most widely used aircraft (and the only aircraft used by Ryanair) the Boeing 737. We assumed that if the users select a seat, they don't want to sit in the middle (in between strangers). After visualising the data of the seat patterns, it looked like this:
Bubble graph visualisation of our passengers seat patterns.
This evidence seemed to crush the hypothesis we had. As it is easily noticeable, there is no pattern in the data. We moved on to continue on other ideas. It took a couple of days to realise that most of our customers travel in pairs. To explain this thought further, imagine you are flying as a pair. If you are not in a fight situation with your peer, one of you probably sits by the window the other in the middle. Or differently, one traveller is in the aisle and the other in the middle. Either way, all the data equalises this way, and there is no pattern visible. So the next step for us was to check people who travel on their own. In this case, it sort of confirmed the idea. People do prefer to sit in the aisle (maybe people who want to get out fast) and by window (have the view).
Bubble graph visualisation of solo passengers seat patterns. Middle seat is not a popular option.
It also returned our focus to our qualitative (complaints) feedback, that it is essential for multiple travellers travelling together to sit close to each other. Just to be sure we checked how probable it is that two passengers would choose to sit next to each other in our "manage my booking" seating feature. The probability was 97.97%.
Process goal:
Combine qualitative comments, complaints & support insights with our quantitative data from seating feature we already had offered.
We considered the above insights and started ideating around two main problems:
If multiple people travel together, sitting together is their number one priority.
If a solo traveller pays for a specific seat. He/she doesn't want to sit between strangers.
We tried to keep the selection straightforward. On the other hand, we were faced with the fact, that there might be users who want to have full control around their choice and be very specific on where they sit. Especially people who want to assure themselves where the seat is.
In the first version of our seating, we decided to create something we called "quick options". In case of being a solo traveller, you would have the option to select from sitting in the aisle, by the window or with extra legroom. If multiple people were travelling together, we wanted to give the possibility to first and foremost sitting next to each other. Why these choices? We simply thought that those are the major ones, and everything else can be considered as an advanced option and could be further selected maybe on a seat-map.
Prototyping a quick idea with Will and a snapshot of some of our early brainstormings.
Building a scalable seat-map is complex
Together with the engineering team, we started grooming around the ideas. It helps dramatically to get the point of view from devs early in the process as this can show what kind of experiments we can do fast. It is particularly important as we are trying to focus on the outcome (introduce a straightforward & easy seat offering) rather than a specific output (seat-map selection). It wasn't a big surprise, but since we offer flights from 700 airlines implementing scalable seat selection was quite some challenge. Also, a specific seat might get sold out while finishing the booking. These were great arguments to use when getting buy-in for our "quick options" idea.
Being abstract rather than to overpromise
We went with ideas to the support team to get a different design unbiased feedback. The purpose of "quick options" was met with another interesting view. When the automation technology fails (it happens this complex automation infrastructure) then a task arrives for our booking agents to process the request for seating manually. Some time passes by between the booking, failure and the actual agent booking the seat. If a customer selects a specific place, there is a high probability that someone else has reserved the same place on the airline in the meantime. It requires our support to get in touch with the customer and discuss other options. However, in the case of our "quick options" the user selects just a type of seat, not a specific one. Meaning, the agent still has multiple options to choose from if something fails on automation. This insight would result in lowering the business costs as well as keeping the experience without any disruption.
A couple of photos of initial sketches from my notebook. We used these to convey the ideas.
Selecting travel segments
Aligned on the high-level concept and having a variety of arguments to back it up, we faced a more specific challenge. How should the actual product work? Taking inspiration in our meals selection process or baggage selection, we explored a variety of solutions in wireframes. However, since our design system is quite mature and enables us to explore & prototype with real parts of the UI quite fast, we quickly switched to trying stuff out with the components themselves. Especially since we felt we wouldn't need to completely reinvent the wheel with the UI. as well as using some of our design system components. Keeping in mind our core "straightforward" principle while reviews, step by step, these concepts felt less & less cumbersome.
Select the passenger or the segment first?
Using the "quick options" idea answered for us the first significant question: Should the user select first the passenger and then select seating on each segment? Or should the first selection be the segment? As we wanted to put the seat selection decisions on our system (quick options), it was clear that the user needs to select only the segment. Also, one additional finding from previous research: People are willing to invest in comfort on longer flights. Hence we wanted to put the first decision regarding seating on the segment selection. One idea for further improvement would also be to show the flight time of particular segments, which we didn't scope for the first iteration.
Iterations on the seating preference selections.
We did the first concepts with a modal flow in mind. A pop-up opening when clicked on the seating segment. We started with this flow because we use modals for most of our advanced ancillary selections during the booking. The perception of opening a modal, making selections, closing and then opening a new modal for next segment felt slow. After a couple of tries, we knew, that the seating selection needs to be more embedded into the actual booking process.
The first try to bring the seat selection into the booking UI.
Selection of a segment using the expandable card component.
Thanks to great feedback from our design system designers, we ended up using an expandable card component. It was by far the best flow, and it felt just right.
We had the segment selection done, and now it was time to iterate on the actual "quick options" choices. We introduced a new component later named "choice tile" which we ideated with the feedback from other UX designers. It was completely new and not a part of the design system yet. We had other projects which might benefit from it(e.g. selecting insurance), so we decided to create it. In collaboration with Orbit (Kiwi.com Design System) members, we went through rigorous testing and tweaking to make sure this component is going to be scalable, aligned & accessible for use in other parts of the product. This part was crucial for this project as well as for further use of the component elsewhere, so we iterated based on usability testings & design reviews.
In the first version, the affordance of the CTA's - only a grey border and accessibility of the selected option - a green border were first mani problems pointed out. We needed a more unambiguous indication of what is clickable and what is selected. Also, the label "no reservation" sounded like there is no seat for you on the plane.
We got rid of the repeating word "seat" to make it easier for localisation & devs to scale globally into multiple languages. We changed the "no reservation" into "random" and adjusted the icon.
In another iteration, we introduced a new icon design aligned with the rest of our icons in other features. Big thanks to our UI designers. We also tried to make the interaction clearer with an easy to recognise the pattern as "radio button" and together with that introduced a clear CTA "Add for $ XX".
The problem we found out during testing was that it was hard to compare the price for the users when they already selected something even though they had the amount shown in the price summary on the left page. Technical scoping brought to us the need to introduce unavailable - sold-out options.
The length and constant change and reformatting of the price & text when selecting different options was disruptive, so we ended up with a more basic version in the end. This version also worked the best on responsive layouts.
On our mobile APP I built the interaction following our native patterns.
First production tests, first real problems
Early experiments on small traffic (10% of Americans & Brits) revealed interesting findings. The overall booking conversion rate went down, and other ancillaries started to get cannibalised. The cannibalisation of ancillaries is something we have been observing for a while. With adding features into the booking process, it is more and more evident. We decided to tackle this in a separate project properly throughout the entire domain. The overall conversion rate was still a problem. Together with our UX researchers, we went to ask why is this happening. Observing people using the feature, we narrowed it down to 2 issues.
First one was connected to this message on some of the segments: "Unavailable to purchase a seat at Kiwi.com". Since that seat might still be available to book somewhere else, we didn't want to mislead from ethical & legal concerns. Instead of being politically correct, we just created a problem. Some of the users thought that there are no seats, and they have to book elsewhere. With our UX writers, we changed the sentence to a positive one: "The carrier will assign seating for you".
The initial negative unavailable message
The new positive unavailable message
The second issue was simply that until this point, we hadn't mentioned anything about seating during the booking process. Suddenly we were showing people, that if they don't pay for specific seats they might not sit together. Naturally, this might drive the conversion down but results in almost no surprises when receiving the boarding passes. One of our core values is being transparent with the customer, so in the end, we decided this was the way to go.
We also had a small tracking issue during the first tests. Our engineers were able to fix that coming to the next analyses. Overall the conversion rate of booking stabilised, loading times were good so we slowly scaled. And then our CEO came with some thoughts...
CEO taking the idea further
I remember one particular situation from this project. Towards the release of our first experiment, the company CEO himself was interested in this feature. He challenged the notion of quick options and why didn't we simply create a seat-map. We had a few great discussions together mainly on the technical feasibility, automation failures & the general feeling of the feature in the context of a long booking process. Although at first he wasn't completely sold on this idea later he came with a thought on how to move this further. Thanks to some other product releases, we were able to lower our contacts & manual processing in general. We suddenly had the workforce to help elsewhere. Thanks to having the "broad" quick options solution we could offer seating on airlines where we had no automation at all. We simply researched the price variety on 60 top booked airlines and very quickly allowed users to book also seat types on these carriers. We could bring extra revenue, but most importantly, more people got value from the seating feature.
From the beginning, we knew, that we are not going to ditch seat-maps altogether. We want to use them for more advanced selection. Not for a quick & easy general use. That's why on many of the concepts above, you could see a button leading to a specific seat selection. I can't wait to see the behaviours & insights into how people will react as we scale this feature further. But that is a story for another day.
A sneak peek into the responsive and desktop seat selection designs.
Currently, the seating feature is performing at a stable attachment rate which improved based on the initial tests & small optimisations. Multiple low-cost carriers are automated, and a lot of the airlines run manually. Thanks to the quick options offering rather than the seat-maps. I questioned many times the decisions we made during this process. Looking back, I think that we chose the right strategy for this feature. We were able to release experiments fast, have a scalable idea & users tend to continue having a fast experience when booking with Kiwi.com.
