User Resarch + Service Design

From trip booking to the courthouse

Blueprint and workshop design to diminish legal claims for a flight cancellation experience.

To comply with my non-disclosure agreement, I have ommited and altered confidential information of some case studies. All information in this website is my own and does not necessarily reflect the views of the organizations I worked with.


In the span of a year, the legal claims for flight cancellations in Brazil spiked, augmenting litigations’ costs exponentially.

Even though the reason for the claims were known (passengers demanded a refund) there was no clear idea of the necessary steps the team needed to do in order to prevent the claims from happening in the first place.

I was appointed to the project as the lead UX Researcher. I decided to design a Blueprint because I concluded that this required a service-centered approach given that it involved cross-company efforts.

A very hands-on workshop.

The research and analysis lasted two weeks.


To synthesize the irregular and uneven experience of five passengers into one design artifact that could facilitate consensus amongst every business vertical into how to attack the problem.


Research patterns and conclusions, Service Blueprint, workshop design and facilitations, report for stakeholders.


The teams successfully prioritized cross-company actions involving the Shopping, Checkout and After Sale verticals.

The IT team implemented a new system that unified the policies that were displayed in every passenger’s touchpoint.

The Checkout team implemented improvements in the communication of cancellation policies.


Problem and context analysis: goals and methodology

Mapping experiences

Analogous inspiration: Structural analysis

Debriefing of patterns


Blueprint design

Final blueprint

The workshop

What I learned


Problem and content analysis

Our UX Squad worked for two years in three main Aftersale operations: rescheduling flights, change of flight and flight cancellations. This allowed us to be informed about the most pressing problems that passengers were having with their trips.

Since January, the legal claims in Brazil regarding flight cancellations had been increasing. This meant almost millions of dollars in expenses for the company.

These legal claims were tagged as “passenger doesn’t agree with cancellation policies.” From a user-centered approach, this tag made us ask the following questions:

UX Research Goals

Because this project was all about discovery and understanding it was appointed solely to me, the UX Researcher of the squad.

Notepads note from kick-off.

Before defining the project goals and its subsequent methodologies I sat down with the information we had mapped out in the problem analysis. Then, I concluded on these following goals:

  • To map and visualize the available information about 5 experiences that ended in legal claims in order to centralize it and make it consumable as a tool for decision making.
  • To put the user front and center in order to ideate solutions from the passenger’s experience and not solely from the company’s interests.


Now that we had the UX Research goals, we needed to choose the most fitting methodology by asking: what should we do to achieve what we intended?

  • Find patterns to understand which behaviors and experiences were constant in order to define a phenomenon from the available data.
  • Map out multiple dimensions in order to see the interconnections, dependencies and breakpoints in the experience from the user point of view and from the company’s efforts.
  • Design an archetype from the patterns to centralize the information in an effort to make the phenomenon tangible, workable and shareable.

For these reasons we concluded that the pertinent artifact was a Service Blueprint, adapted to the available information.

Mapping the experiences

Delineating the layers

As with any design, one starts by looking at references. For this project, I used

Notepad notes from reference analysis.

Defining the sample

The sample was defined by analyzing the legal claims data from the legal department. With it, we could understand in which period the claims increased, from which ticket condition (what policies their purchases had) and from which airlines were the majority of complaints.

Analyzed dimensions

The first step to start recollecting data was to create a sheet with all the dimensions we needed to map out in order to create the archetype.

Calls analysis

The analysis’s starting point was the passenger’s calls that are saved in the company’s database. From other projects we had already devised a matrix through which we analyzed them.

From there started an exhaustive search for the available company’s data. Looking for analytics recordings of the passenger’s entries and actions within the site, what Customer Service agents had documented about each claim and what communications we had sent the passengers.


We have a problem because of these types of practices

Because this type of practices were still not common in the Aftersale department of the company, all the data we hoped to find wasn’t recorded or wasn’t documented properly. There were huge gaps of information and all the existing data points weren’t centralized properly.

The colors highlight some of the places where there were gaps of information.

We had a very small and limited sample because the intention was to go deep and not wide. To really understand each case and map out how they fully played out.

Yes, this picture was taken with a self-timer.

Analogous inspiration

I had a conversation with my UX Lead because I didn’t know what to do. She advised me to think of the dimensions I have mapped out in a more anatomical -even cellular- manner.

Could there be patterns in the way the dimensions were constituted instead of how they played out? What type of structure did the dimensions have?

Structural analysis

Engineering and design are in constant dialog. Therefore, I resorted to the former in order to find a framework for structural analysis.

Definition of Structural Analysis*

Structural analysis comprises the set of mechanics theories that obey physical laws required to study and predict the behavior of structures. The subjects of structural analysis are engineering artifacts whose integrity is judged largely on their ability to withstand loads.

Notes I took to understand the basic concepts.

Communications System Part I


After reading and understanding, I translated the basic concepts into elements of our passenger’s experiences to conduct the analysis.

Debriefing of patterns

By looking at the data through a structural analysis lens I was able to find patterns in the experiences that got me closer to the creation of an archetype.

The documentación of the patterns for each cluster.

Main findings

There were many patterns found but there were some particularly telling and problematic.

Duration of experience

Median: 143 days.
Max. duration: 262 days.
Min. duration: 72 days.

Total amount of calls

Median: 10 calls / pax.
Max.: 20 calls / pax.
Min.: 2 calls / pax.

Satisfaction Surveys

3/5 passengers received multiple surveys while the cancellation hadn’t been solved yet.

Inflection point

In 3/5 cases, it happens when they are told that they already agreed to the conditions.


Trust easily broken

On average, legal actions are initiated with only two previous interactions with the company.

The analysis of the legal paperwork is blurred to comply with my NDA.

Paperwork analysis

Additionally, I read the official paperwork from the legal claims to understand how the plaintiff and the defense interacted.

I found out that 3 out of 5 passengers said that specific clauses pertaining to death and sickness cancellation motives were not informed in the purchase process. And they considered their situation enough reason to be reimbursed.



All of the findings could be summarize in three main insights that characterized the experiences of the five passengers

Blueprint design

With the patterns in place, there was still some thinking to do when defining the archetypical experience to be visualized.

To organize the patterns sequentially, I defined three macro moments. As layers, I defined eight dimensions according to the available data.

Then, I started prototyping the blueprint and filling the blanks. Although this is a blueprint, I adapted the format to the data (instead of adapting the data to the format).

Sketching always helps me make sense of data.


After 4 weeks of deep case by case analysis and blueprint design, we applied our learnings in an interdisciplinary workshop with the goal of solving the main business problems through collaboration. As a team, we were able to define the main causes that were motivating travelers to sue the company and localize each team’s opportunities to solve the issue. I conducted the research, designed the blueprint, designed and facilitated the workshop and documented the outcomes.

Final Blueprint

With my rough prototype, I teamed up with one of my squad’s UX Designers, Denise, to bring the blueprint to life.

The information about the legal documents is blurred to comply with my NDA.

The workshop

The analysis and blueprint design had one specific goal: to facilitate collaboration. Only through a workshop I could know whether my outcomes were succesful and served the greater purpose.

Workshop Design

When deciding who needed to attend the workshop, I wanted to work beyond the limits of the Aftersale team and include collaborators from other teams that were also involved in the passenger’s experience.

For example, collaborators from the Checkout team were key because that was the moment the passenger could visualize the policies and conditions for the first time before purchasing.


Workshop’s dynamics

Finally, I had to restore back to the project and business goals to design the dynamic. It was divided in three moments that included a lot of hand-on involvement from the participants because we learn more by doing.

Discovering needs and pain points

  • Participants were divided in pairs and given specific layers to analyze.
  • They were prompet to locate the passenger’s needs in each moment by answering: what were they needing that they didn’t have? Why? How did this affect their experience?
  • Finally, they had to write down the needs and situate them on the blueprint.
Mix and match

When pairing them, I thought beforehand who had to be with whom. I mixed people from different teams to foster a holistic approach.

Turning needs into opportunities

  • Participants were still working in the same pairs.
  • After locating the needs from a user-centered pov, now they needed to think which problem created that friction from a company-centered pov.
  • Lastly, they had to write the problem in the format of an opportunity (action-oriented) and put it in the right layer and moment of the experience.
Fast and cheap

Fast and cheap I sketched a blank blueprint with the same sections as the designed one for the participants to put the problems in.

Sharing and prioritizing

  • Each pair presented the opportunities they found explaning the needs they came from.
  • With an evaluation matrix that involved user value and technical complexity as its axis, we decided as a group where the iniciatives should be placed.
  • Hearing all voices was important because things that seemed easy for some were not for the people in charge of implementing them.
Effort vs. impact

We didn’t use frameworks like RICE because we didn’t have enough data to do so. In turn, we asked: What brings more value to the user? What’s technically more complex and harder to implement?

Beyond the scope

For design to be really strategic, it has to remain open. That is why, with my team we papered our office’s walls with maps, journeys and tools that promoted a holistic approach to problem solving.

After doing so with my blueprint design, decisions beyond the project’s scope were influenced. For example, nobody had mapped the amount of NPS surveys we were sending each passenger. One of them received more than seven.

After seeing it on the wall, the team in charge changed the IT service’s logic and fixed the bug.

All this work
deserves a bigger screen

Because of the length of the case studies, I have adapted them for mobile and tablet. If you want to read the complete case study, head over to desktop.

Thank you for reading!