This is the sole case study in the Professional Diploma in UX Design. The brief to redesign the flight booking process on the web for a start-up airline originally called Fly UX.
Role & Responsibility
I was the lead and only designer for this project, with the guidance and feedback from the UX Design Institute mentors. I took the initiative to develop both the UX and UI in tandem, as well as developing a brand system and identity.
The brief from the fictitious startup was to design a new airline website that would have a fast, easy and intuitive booking process.
“How may we design a calm and accessible space so anyone can book a flight without feeling overwhelmed”
Through a series of interviews and usability tests, I found most comments fall into one of the two camps: Distrust or anxiety. The fact is that the flight booking process is unnecessarily complicated. This manifests in either the user vocalizing cynicism (outwards frustration) OR they internalize it and fall into a cycle of anxiety.
The outward cynicism starts the user journey with lowered goodwill, and thus the person booking is less tolerant of obstacles, no matter how small. The internalized anxiety is even worse, with 3 of the 5 people interviewed avoiding the act as much as they can. One user even asks others to do it for him as the process is too overwhelming.
Goals beyond metrics
Taking these key questions and suppressing the gnawing feeling that design can't solve a broken economy, I framed the case study around three goals:
- Design with accessibility at the core
In this case, accessibility refers not to the visual impairments but rather tackling the flow and interaction to minimize anxiety for the users. People shouldn't feel incompetent when booking a flight
- Design with transparency to rebuild trust
This should be reflected in everything from the brand, layout, copy, error handling to flow. Information and feedback should be at the finger tips of the users.
- Design for the user and not only the business
This relates to the issue of bloat and confusing industry jargon. The process should be straightforward, inclusive and empathetic.
Users & Target audiences
Keeping in mind that the fictitious client is a start up, I excluded first class luxury travelers. Via an online survey (sample size: 32), when asked what their main goals were when visiting an airline website:
- 82% of respondents want to actually book a flight
- 46% use the websites to search for prices and availability
Based on this, I decided to frame users by the tasks to be done rather than demography or income levels. This resulted in three groups - Buyers, Browsers and Visitors.
Clear idea of when and where they want to travel, pending final decision based on availability, price and times.
Has a slight idea, searching either alone or in groups; conversion potential is high and in the immediate term
Individuals with no clear itinerary; conversion potential is low and over a long term
Scope & Constraints
The original brief had little to no constraints, other than to design for the flight booking process. You can have a peek at the document here↗.
Please note that the project was titled Fly UX but we were free to rebrand so long as the UX was put first.
How can design alleviate the stress of travel in a pandemic?
Then there's the COVID-19 pandemic. From Hopper's failings in customer service to customers being left in limbo on their refunds from Thai Airways, the problems go beyond the flight booking process and the pandemic has only served to highlight the industry's flaws.
Research Block: To find out what the norm is and learn from their wins and mistakes
- Competitive benchmarking 10+ airline sites, aggregator sites and mobile app
- Distributed online surveys that targeted a wide range of backgrounds: income, location, situation (LDR, student abroad, immigrant, work expat etc
- Facilitated 3 x usability tests
- Conducted 5 x depth interviews
- and funnily enough 👉Learned how to take good notes 👈
I benchmarked over 10 airlines and chose to conduct a screen by screen study of three websites: Transavia, KLM and Hopper. Hopper is only available as a mobile app but was chosen because it was cited in an online survey response as 'a good place to book flights'. In trying to Write A Good Survey, I found myself constantly referring to Norman Nielsen's articles↗. So in the end, even the survey itself was user tested 😂
Why design a website instead of a native mobile booking app?
Accessibility and reach (I'm talking to you Clubhouse 🙄). Survey results showed 77% of respondents book via the web and 5 of 5 users interviews revealed the same, even the ones that have the app on their phones.
Analysis Block: To work within a team to gain better insights
- Facilitated affinity diagramming sessions on Miro
- Introduced dot voting exercise to further filter the insights
- Created a service blueprint to understand the touch points and relevant back end requirements
- Mapped out customer journey based from when the user gets the idea to fly all the way to pre-flight
Team work makes the dream work
I teamed with two other students - Mark and Vaishali to work on the affinity diagram. This was a lesson in remote working and facilitating workshops. The process of sifting, sorting and discussing took just over a month and was a tough but rewarding process. 10/10 would recommend
Concept Block: To iterate and test ideas quickly
- Designed the Happy Path flow introducing new touchpoints
- Sketched out interactions and conceptual layout according to previous flow
- Created paper prototypes for quick lo-fi usability tests
- Repeated these tasks for multiple iterations
Addition of an Overview Page as a decision point
Up until this page, I found that most use cases are performed similarly. The Overview page then acts as a branching node where users can easily save prices or send details to their travel partners which increases the likelihood that they will purchase with Hummingbird. This addition also serves as a checkpoint for serious buyers to check their selection before proceeding.
Example use case 1 - 'Just Browsing'
Goal: Checks prices/availability
Enters dream destination > Chooses placeholder dates > Selects random flights
Example use case 2 - 'Ready to Purchase'
Goal: Buy flights
Enters known destination > Chooses exact dates > Selects flights to buy
Design Block: To build quickly and test often
- Created multiple prototypes on Figma (before interactive components!!)
- Facilitated usability tests on prototype
- Conducted remote usability tests using Maze to collect analytics
- Iterated multiple times based on feedback loop
- Conducted A/B tests for sequencing and date selection process
- Created polling study for feedback on brand assets
- Documented wireframes for handover
This was a good analogy of being data informed and not data driven. Maze is a testing platform that records click paths and the average time a user spends on any particular screen. You can manually set the paths to success and the software measures any deviation to the path and returns it in percentages and numbers.
After the Xth iteration of the prototype, it became unsustainable to do a user test each time. In this regard, remote testing was a blessing as you could reach a far wider audience without having a large time commitment. However, this means unmoderated tests with some users clicking into the prototype just to look, and then leave.
This is in many sense quite indicative of a real life situation as not everyone that comes to the website will buy a ticket.
"It felt strange that I couldn't choose the number of passengers until entering passenger details. Not that I needed it, but it was weird."
This was an eternal internal debate for me - in my studies it was shown that most users go through multiple browsing phases before finally going through the flow for the final booking. In these booking phases, 72% perform the flight search for one passenger so they have a better idea of the price per person. By integrating the browsing and booking into the same flow, I was hoping to simplify the starting pages to only focus on one topic at a time - place and date.
7% of users flagged the passenger count as being too late in the booking process.
I'm not happy with this portion yet as it feels like something is missing. Of the 32 remote tests (maze) and more than 10 usability tests, only three users flagged this as an issue.
- Always test assumptions! I had a hunch in the beginning that the seat selection process was unnecessary and did not have to be part of the core booking process, but the results were the opposite! Factors like anxiety, claustrophobia and just general worry of proximity brought on by the pandemic made the act of selecting your seats one of agency. This was a great lesson.
- Doing the same thing twice requires a strong reason. I conducted the affinity diagramming twice, once with fellow students and others with external collaborators who had no knowledge of the project or industry. The resulting diagram was quite similar, the differences marked by my own biases as the external collaborators did not have their own research to challenge me.
- Design a mobile app for the same fictitious client with updated goals, focusing on the less linear process after flight booking
- Create a MVP on webflow to test if it is a viable prototyping tool
- Learn how to further improve accessibility beyond WCAG Guidelines (flows, decision branches, information to show)