Improving MaxMilhas baggage allowance communication

How we used UX methods, rapid research and prototyping to help users understand and navigate through the messy environment of baggage allowance policies for flight tickets in Brazil.

Back at final end of 2017, a legislation review created a big change in the Brazil’s travel market. All of sudden baggage allowance stopped been free (as it had been for a long time), and became incumbent to airlines to decide whether or not to charge for clients to ship luggage.

The 4 airlines that operate in the country started applying 4 different baggage allowance policies. With baggage shipping fares ranging from free to R$80 a piece, customers more often than not were left guessing about what to do.

MaxMilhas mission is to “help people to travel more”, and because the company main value proposition of selling cheaper fight tickets, most of the MaxMilhas’ users are very price sensitive.

No wonder why this new scenario of unclear information made the users either confused or sometimes even angry. It was was clear to everybody in the tech/product team that, at some point, our product would need to adjust to reflect and clarify this changes. But, how to communicate messy policies without overloading users?

The assignment

Doesn't matter how small, big or innovative a company are, hallway assignments are always a thing. This one started as one as well.

One sunny day the company’s CTO asked me for a study for a new functionality to help the users to understand if they needed to pay an extra fare for baggage allowance or not. In his mid it should be fast and simple as picking an icon and snapping it into card result component.

When confronted with a hallway assignment like that, is the Designer’s job to take a step back and understand what is the root cause for this assignment. Only by finding the root cause, the team (and the designer) will be able to solve the real problem.

To search for the problem root cause I used a very simple, but very effective tool: the 5 whys.

The 5 whys technique consists simply in asking “why?” right after any given motivation statement, and keep asking “why?” after each answer until you find the problem’s root cause.

In our case, we started from a business standpoint that had motivated the task assignment: “too many customers are calling our lines to ask about baggage allowance”. After talking to stakeholders, hearing their motivations and asking why a couple times, we were able to dig from the pure business concern through the operational concern, finally getting to the real user need:

Our users weren’t able to know what baggage allowance policy would be applied for each ticket.

Research

After finding the real problem that was affecting our users, it was time to do some research in order to better understand what and how this was affecting our users lives.

I’m a strong believer in lean UX research. When you work at a startup you have to use all the tools available to gain the most understanding about users in the least time possible. So, my research process had three main steps:

1. Mapping the use cases
2. Collecting and analyzing qualitative data obtained from customer help center
3. Interviewing costumer support experts to understand how they were already solving this problem

By end of the research we were able to find a few interesting things:

1. After analyzing all the baggage allowance policies we were able to narrow down to 3 different use cases and solutions. It was tricky to know what baggage allowance were applied to what type of ticket, but once you knew it the rules were quite similar.
2. From January to March 5.700 clients contacted customer support to ask about baggage allowance policies. That about 10% of contacts made to customer support in that period. So, it was indeed a main pain point for our users.
3. After running a sample analysis from the contact support conversations we were able to find something surprising: 40% of the contacts were made AFTER the client had completed the purchase. That made clear that communicating the baggage allowance policies only in the shopping flow would ineffective. It was essential to show this information to users in the “My tickets” and confirmation emails flow as well.
4. The most frequent asked question were related to “what the baggage allowance policy applied to MaxMilhas flight tickets?” followed by “how do I pay for additional baggage allowance fares?”. That told us that we needed not only to tell users what was the ticket’s baggage allowance policy, but, in the case the user needed to pay for additional baggage allowance, how they could pay for it.
5. Interesting enough, the costumer support experts used to study the baggage allowance policies in order to help users, but in most of the cases they would just direct the users to find the policy at the airline website. And a good percentage of users were satisfied with this approach.

Hiphotesys

IF we modified key components in the user journey to tell what was the baggage allowance policy enforced for each ticket and how the user could pay for additional baggage allowance, the users would be able to make better decisions and wouldn’t need to call customer support (about this issue) anymore.

User journey analysis

The next step was to look into the user journey in order to understand in what were the key points where the users were having more doubts on.

We looked into the user journey from finding a flight ticket, through buying it up until the user fulfill their trip. While doing so, we fall back to the research mapped the steps in which the user was when contacting customer support.

By going through this analysis we were able to map 6 points that needed to be improved to clear communicate the user what was the ticket’s baggage allowance policy:

1. Search results page should display the baggage allowance policy for each ticket.
2. The pre-checkout page should display a reduced version with key information (amount to be paid or not) clearly displayed at the price details component.
3. The passenger’s information form should make clear which passenger would have free baggage allowance and which wouldn’t.
4. Similar to the pre-checkout page, the payment page should display whether or not the ticket included baggage allowance, if the user paid something for it and how much.
5. One big problem in the post-purchase flow was that there wasn’t clear information about baggage allowance. We included the baggage allowance policy into the confirmation email, inside the ticket component, and what they would need to do in order pay for additional baggage allowance as well.
6. For the purchase details page, we redesigned it in a way that clearly displayed what the user paid for, how much was, and what they would need to do in order pay for additional baggage allowance.

Improvements

After understanding the problem, what were pains and doubts of our users and map the main points of improvement in the shopping flow, we proceeded to wireframe the interface and craft our messages.

There were two main points we needed to balance:

1. We needed to clearly tell the user what policy was applied to each ticket and how they should proceed.
2. We shouldn’t bring the weight of responsibility for the enforcing or not the policy on us. Instead we should point the user in the right direction to find specific and extensive information at the airline channels after he had finished the ticket purchase.

(Yep, the screens are in Portuguese, after all MaxMilhas is a Brazilian startup. Sorry for that.)

Search Results

At the bottom of the flight ticket component, we added an element that clearly informed the baggage allowance policy applied to that ticket.

If the user decided to interact with the element, by hovering on it, a tooltip would pop, displaying additional information about that specific policy for that ticket and telling the user how she should/could proceed to to ship luggage in this flight.

Pre checkout

At the Pre Checkout we modified the main component on the page to include the baggage allowance policy status (baggage allowance: included, not included, paid). In this step we replicated the previously the flight ticket component behavior, with a tooltip explaining the policy to appear if the user hovered the element.

Passenger’s information form

At the passengers information form we had 3different use cases:

1. The user could have free baggage allowance;
2. The user should pay a fare for baggage allowance, and could pay it now, to MaxMilhas that would after pay the company;
3. The user should pay a fare for baggage allowance, and only would be able to do so after he brought the flight ticket, and should pay the fare directly to the airline.

Confirmation Email

In the purchase confirmation email, we modified the ticket component to include the baggage allowance policy. In this point of the user journey we needed to make 2 things very clear:

• if they had the right to ship luggage and how many pieces they could bring without additional fares (on the top of the ones the may had already paid during the ticket purchase);
• how the user should proceed to buy additional baggage allowance, and that they would need to deal directly with the airline in this case (at this point, the user couldn’t pay the fare to MaxMilhas anymore)

Purchase Details

In this point we needed to completely redesign the purchase details modal. The main goal here was to make clear and easy to understand what the user had paid in each price component, how much luggage she could ship in each flight stretch and how much she had paid for it. We made sure to insert a link to airline website, so the user could search for more details about the baggage allowance policy there.

Measuring success

We worked to scope it out the right problem, did user research, created a simple but effective solution that balanced well the user’s and the business needs. And we did all this while managing to work lean, delivering value fast. Great! But all this wouldm’t really matter if we didn’t measure success (or fail). How would we know if we had really solved the problem?

This problem didn’t related directly to happiness, engagement, acquisition, retention. And at the beginning doesn’t look so much as task success, but after a while we settled to it. After all, it’s just a label.

In order to define our metric (that was quite obvious from the beginning to be true), we run the Goal-Signals-Metrics framework.

After we implemented this functionality our users wouldn’t buy faster by knowing what baggage allowance policy were applied to each ticket. But they would buy smarter, choosing the tickets that better fulfilled their needs, and would have less doubts.

So, we had our Goal:

Help users to buy tickets that best matched their needs, empowering them with enough information to do so by themselves.

What could signal this? For starters the very thing that raised this issue to our management team:

The number of contacts made to customer support asking about baggage allowance.

And what then we needed to accomplish in order to be successful in this project? What would finally be our metric?

Reduce the number of contacts to customer support related to baggage allowance policies.

I think it was a great metric because it covered both the user aspect, the operational aspect and the initial motivation as well. But, more important, it was a great metric because it allowed us to measure if we had had success, and if we don’t, we could gather qualitative data learn what we are missing. And that’s the most important part, in my point of view as a UX Designer, and I think it relates well to the lean philosophy:

A metric is just as good as the amount of LEARNING you can gather from it.

Conclusion

By taking a step back and going through the user research phase, we were able understand much better the user’s problem and pains, and therefore design a solution that helped users all the way through their journey from choosing the right flight ticket to bringing the right amount of luggage to the airport.