Interactive prototype [Adobe XD]
An approach to flight booking experience.
Client: Student project at UX design institute, Glasgow Caledonian University.
Role: Entire product design from research to ideation, visualization, and testing
Project duration: 3 months
Tools: Adobe XD, Photoshop, Illustrator, Survey monkey, Let'sView, sceenrec.
Try out my interactive prototype!
This interactive prototype is created for a specific flow. Would you like to try it out? Use the following steps:
From: AMS Amsterdam
To: ATH Athens
Dates: 14 August-29 August
Show direct flight only.
Seat selection: 16A, the same seat for the outbound flight
Pay with saved credit card
For this project, I designed the mobile app for a startup airline, FlyuX. For this project, the emphasis was given on the ticket booking process from selecting a destination to the payment and the screen structure. I focused mainly on the research and the smooth user flow, while the UI was developed at a basic level to prioritize the elements on the screen.
In order to understand in-depth the product I was to design as well as the behaviors, pain points, and goals of the users, I had to conduct research. The research methods I used were the following:
competitive benchmarking in similar flight booking apps
online surveys to a representative group of 34 participants
usability testing on two similar flight booking apps
#1.1 Research | Competitive benchmarking
For the competitive benchmarking I chose to analyze 3 airline apps:
The main points of focus for the competitive benchmarking were the primary navigation menu, the home page, and all the screen states from the search and select flights screen until the payment screen.
This was a process that affected widely the overall strategy as I navigated thoroughly through all the steps of the booking process. I analyzed the conventions regarding the booking process and I pointed out which areas were poorly designed and could be improved.
#1.2 Research | Survey
After having a personal experience with all three apps, I wanted to hear from the existing users how is their experience with the booking process. The goal was to gain quantitative data that would help to identify the goals and pain points of the users.
The statistics came out from 34 participants. My target group was people that were flying at least 2-3 times per year so that the last scenario where they booked flights was not too long ago. Also, I tried to keep the number of questions small to manage to collect more answers.
From the survey, I could confirm that 70% of the users prefer to access an airline website from a desktop. This result reinforces the original hypothesis of the case study.
Also, the main goal of the users when accessing an airline website is to book tickets or search for flight prices in order to book in the near future. So I decided that it makes sense to define all the steps from the home page to the payment screen, later on. In this way, I could test my own approach and assess if I managed to resolve all the pain points of the users.
#1.3 Research | Moderated usability testing
The survey was not enough to investigate who the users interact with the existing airline apps. It only made sense that the next step of the research would be a usability test in the competitor's apps. I proceeded by facilitating a moderate usability test.
The user had one task, to search and select round trip flights from Amsterdam to Athens on specific dates. The apps to be tested were:
British Airways app
During the test, the user was asked to share his thoughts about the apps, what was unclear, where he was not sure how to proceed and in general all the pain points he bumped into, using the apps.
After reviewing carefully the usability test video, I summarized the finding into the following bullet points.
#2 Building Empathy
The next step was to use the quantitative and qualitative data I collected from the competitive benchmarking, the survey, and the usability test, to define my target group.
More specifically, I focused on the user goals, and the scenario of the last time the user booked flight tickets, that shaped the design goals. In this way, I would be able to empathize more with my main user group and put in priority their goals. I referred to the user persona throughout the entire product development process and mainly through the sketchy wireframes.
#3 Affinity diagram
Processing all this research data can be challenging. In order to move forward and make sure that all the valuable information is prioritized and taken into consideration, I facilitated an affinity diagram session.
I gathered a team of 5 people, I shared all my qualitative and quantitative data from the competitive benchmarking and the survey. I presented them with the usability test video and I provided them with pens, a lot of post-its, and a big whiteboard.
While presenting all my research to the team, everyone took notes on post-its of the key points that affected the user's experience.
The next step was to stick them to the wall and start putting them to groups that made sense. The result was that we ended up with the following 14 groups that defined the focus areas and the issues I needed to solve in the prototype later on.
Integration with other apps
Search & Select
#4 User journey map
In order to understand better the flight booking process, I created a user journey map. This step helped by visualizing the pain points, behaviors, mental models, and goals of the users at each step of the process.
Having all the data from my research and especially from the usability test, and the affinity diagram, I defined my high-level steps. Then, I defined on a scale of 5, how the user feels at each high-level step, based on the comments of the users and their goals, behaviors, and pain points. Visualizing where the current apps are failing the users helped to focus on finding solutions for the specific pain points.
#5 Information Architecture
Based on the insight gained from all the research, I created the information architecture diagram for the specific flow of booking flights. I defined what actions should be taken in which screen states in order to make the next steps easier.
I structured the screens in a way that is logical and matches the mental model of the users. In addition, I made sure that each screen focuses on one main action, that is highly prioritized to help the user identify the action he/she is required to take. In this step, I also made sure that the structure of this product had to be forthcoming and save steps where possible.
#6 Wireframe Sketches
After having digested all the data gathered, and with the Information Architecture as a leading structure, I moved forward to sketching the main screen states. This is the way I prefer to visualize the first screen states as I believe is the fastest and more intuitive way to share my ideas.
Having made my first sketches about each high-level step of the process I went through the customer journey map. I checked if I had solved all the problems the users pointed out, all the parts that caused uncertainty and frustration. Then I started over trying to take out all the info that was not absolutely necessary for each screen state.
After many sketches, I ensured that the priority of the elements was clear and all the destructive elements were eliminated. By adding annotations I made sure that even the information of what happens when a button is pressed or a checkbox is taped was included. In this way, the next steps would become easier.
Right after having finalized my sketchy wireframes, I created a medium-fidelity prototype for testing purposes.
I used the Adobe XD to create the hole flow from the home page to the payment confirmation page. It was an essential step to define the screens as I received precious insights from the usability testing process.
#8 Moderated usability test
In total, I made 5 testing rounds, each time improving the structure of the screens, adjusting the hierarchy of the elements, and making the flow more clear.
All 5 of the participants were meeting the background of the target group. It was really essential to start testing the interactive prototype as it had enough information to receive feedback on the flow, the hierarchy, the affordance of the different control inputs, and in general to see where the design didn't match the users' mental model.
After receiving the feedback from the five testing rounds, I adjusted the interactive prototype to resolve the users' pain points.
#9 Design System
In order to make the project less complex, I decided to set up a Design System. In this way, I had a unified set of rules that I could follow.
In this way, if the project would evolve to include more flows and features, the additional elements could follow the design system for a more uniform and consistent outcome.
The most challenging part of creating the design system was to make sure that all the elements and the colors work together to create a clear design with high visual hierarchy and good accessibility. Particularly for the readability, I made sure that the contrast ratio for titles and body text meets the WCAG AA criteria.
#10 Final Wireframes for developers.
Defining in detail all the screen states and the results of the interaction is part of the design process. In this step, I described all the actions and rules that define the interactions. This is essential to avoid any misunderstanding and to share all the necessary information with the developers.
Creating the final wireframes was particularly interesting as all the pieces were put together and nothing was left to chance. In a way all those rules were from the beginning of the design process present, forming the screen states and shaping the priority of the screens.
#11 Heuristics evaluation
1. Visibility of system status
The system always keeps users informed about what is going on, through appropriate feedback within a reasonable time.
2. Match between system and the real world
The system follows real-world conventions, making information appear in a natural and logical order.
3. User control and freedom
The user is provided with the option to go back to previous steps or edit the information before paying without losing any data.
4. Consistency and standards
The app uses the same “language” through all the screen states. The different components have the same character in each screen state.
5. Error prevention
Number chunking, suitable keyboard appearance, and hint texts, as well as inline validation, are error preventing factors
6. Recognition rather than recall
Minimize the user’s memory load by making objects, actions, and options visible. Instructions for use are visible or easily.
7. Flexibility and efficiency of use
Shortcuts are provided to enable the user to save steps if he/she wishes.
8. Aesthetic and minimalist design
Only the absolutely necessary information is displayed.
9. Help users recognize, diagnose, and recover from errors
If an error occurs the systems communicate to the user where it is detected and what action should be made.
10. Help and documentation
The search button and contact in the main menu and footer are available on every screen to ensure that the user has easy access to help.
#12 What I learned
Completing this project was for me a revealing process, where through every step I was discovering new ways to use the information, and mold them into an interactive prototype.
Research, research, research
Rock-solid research is going to take you halfway there. It is not possible to come up with great solutions if first, you haven't understood in depth the problem. And it is not possible to understand the problem if first, you don't dive into research. It is the way to create empathy for the users, to understand their mental models, and why existing products are failing to meet them.
Looking back to the affinity diagram session I learned from my mistakes. Inviting people to an affinity diagram that didn't have any similar prior experience, means I had to be crystal clear about the steps of the process. It is not enough just to explain it, I should make sure everyone was on the same page. The way to ensure that you get the most out of the session and you have great material to work on is to let the participants know exactly what they are expected to do.
Pen and paper
Before rushing to the prototyping stage, it is essential to get the pen and paper, sketch, and then sketch some more. The sketches of the first wireframes can reveal points that you haven't come across so far and is also a good way to check your information architecture. You can decide that you can optimize the flow by combining two screens, or that a screen has too much information and it must be broken down in more steps. If done thoroughly sketchy wireframes can same much time in the next steps.
What I would do differently
Test, improve, and test all over again.
Looking back I would have chosen to do the usability test in a low fidelity prototype. Testing the medium-fidelity prototype was part of the assignments for the diploma I have completed. Now that I have the experience of how valuable feedbacks one can get from a low-fidelity prototype I would not devote all the time and effort to do the first usability test on the medium-fidelity prototype.
Having completed this project I believe I should have chosen from the beginning a brighter color palette. From my usability test, I noticed some of the users liked the dark version of the app but some commented that would rather have a brighter interface. Going through the process of improving the UI interface I also chose to follow the Material guidelines about the various components to match more with the mental model of the users regarding interface components.