Client Portal
Overview
The process of booking a private flight has been fragmented. The purpose of the portal is to allow the operators to provide greater ease and flexibility of booking experience for their customers, which will help the operators improve their customer satisfaction.
My Role
Primary designer collaborating with a product manager and team of 8 engineers to deliver MVP. I worked closely with key stakeholders and our customer success team to understand the problem space, and develop feasible design solutions based on insights derived from user needs.
Background
Business goals & user needs
From initial discovery, we found out that the business aviation industry is highly fragmented and operates predominantly offline. There is a disconnect between flyers' high-end expectations and what they actually get.
The process of booking private jet trips involves inefficient back and forth emailing and redundancies for both the users and the operators who provide the service.
Booking a private jet is more comparable to RV rental than booking commercial flights. It always requires some human intervention behind the scenes. Typically the booking process starts with the customers requesting a quote from operators or brokers. After hearing back from them, the customers may negotiate with them until they find the aircrafts that they like.
↑ Identifying the pain points in the current booking process
A few existing solutions are more like lead generation tools for operators or brokers. So we saw an opportunity to eliminate the unnecessary emailing and streamline the booking process. Our targeted users are more tech-savvy flyers who expect private jets to be accessible and easy. The customers of this product are the operators. It was a balancing act between satisfying the end users' needs but not alienating the operators. Our long term goal is to provide instant booking. For this release, the values we aim to provide are:
- Efficiency and accuracy. The ability to provide a more accurate estimated prices with minimal effort from the users.
- The ability to white label the portal. Operators need a solution that saves time spent by their salespeople communicating and confirming trip details but they don’t normally have the resources to build their own booking applications to automate the process.
Measure Success
We believe that the successful launch of the client portal will attract more and more users booking their trips on the portal instead of using their old-fashioned ways. It will also directly help us attract more operators to sign up for our subscription.
On a lower level, to get a sense of the effectiveness of the design, I would like to know the proportion of the users who start the booking process in the portal but return to using emails or phone calls since it may indicate potential usability issues.
MVP End-End Experience
MVP booking flow
In our first release, we prioritized the ability to complete the booking and we evaluated features based on impact vs effort and their risk levels. For instance, we swapped out online payment functionality (a should-have feature) for the real-time customer account syncing between the operator’s app and the customer portal (a show-stopper feature). We learned that the operator salespeople often create customer accounts on the fly as they talk to them, so our portal needs to be able to do that.
↑ MVP Flow - from requesting a quote to reviewing booked details
1-Create a new request
As a frequent and seasoned flyer, I want to be able to find the available aircrafts that match their preferences in the shortest amount of time.
How would the users achieve that goal without feeling overwhelmed? Technical constraints also needed to be taken into consideration since returning a huge list of available aircrafts would impact the system performance significantly. Therefore, the users need to define their trip requirements as much as they could initially to get a more targeted list of results.
View the prototype
↑ We used a light-weight coded prototype to get feedback and iterate on the request form
2-Receive live quotes
Upon receiving the quote request, the operator checks their schedules and confirms they would have an available aircraft or that they could source another operator's aircraft if needed. They then send their branded quote to the client. This usually is done within an hour on the other part of our system (i.e. the quoting module, which was my main focus for the first and half years).
The user then compares the choices of jets and prices at a glance. We learned that price and aircraft are almost always the deciding factors.
3-Book one option
The user goes ahead to book one option and uses Docu-Sign to accept the quote.
The operator then asks for owner approval if the aircraft requires it. The operator then books the trip on their end if everything looks good. The user can then review the booked trip info and edit passenger information.
Unlike the airlines, private flights don't typically go by a flight number and the tail number of an aircraft is the primary method of identification. Once arriving at the departure facility - private terminal, the users will give their tail number to the front desk representative who will then connect them with their pilots or flight crew.
Refine The Details
Refine content-specific card components
When reusing the card component from a different product which is operator-facing (business users), I needed to make sure it was tailored to the end customers' goals.
For example, compared to a tail number (an identification number painted on an aircraft, frequently on the tail), it will be more useful for the end users to know how big the aircraft is and what model it is. Think of it this way: a vehicle identification number is useful for automotive factories, but what we care about as the users is that the vehicle is a Mercedes-Benz S-Class or Tesla Model S.
My original assumption was that aircraft size was more important than the aircraft model, as shown in "Client Portal Iteration 1" below. But we learned from the end users that picking a private jet for their trips is just like picking a car. There may be many full-size luxury cars, but knowing which exact model it is can be far more important during the user’s selection.
↑ How the Option card design evolved
Capture all the core scenarios
It's common that there are multiple aircrafts for a multi-stop trip, so how would the design accommodate for this scenario?
I took a step back and thought about what "multiple aircrafts" meant exactly. For example, would it mean there are multiple models of the same size category? Or are there different tail numbers but they are all the same model? It could be any of those combinations. So I broke down the card component to document those different scenarios.
Below is how I leveraged the card component guide to capture different scenarios, including unhappy paths, instead of creating thousands of screens.
↑ Card component guide acted as a framework to address the many iterations and states of a single screen
A Mobile-first Approach
We expect the majority of our users to book their trips on their mobile devices, so we started with the mobile design and repurposed it for multiple platforms.
↑ Viewing the quote details on different screen sizes
↑ Requesting a flight on different screen sizes
How Did We Get There?
I led the discovery phase
I got the project off the ground by reaching out to the VP of product and our domain experts to understand our business goals and targeted users.
Based on the high level requirements, I worked with the PM to map out the journey that the user needs to go through from signing up to paying for the final invoice. I also facilitated the working session to draft the MVP requirements.
I've found that mapping out the story using words (e.g. writing down the flow) or high-level diagraming created good discussions and helped us elicit new requirements, and discover hidden business rules.
↑ User Story Map for the end vision
I then worked on the wireframes and walked it through with the team to identity gaps as I tried to get from point A to point B to realize we have missed a field or an entire screen and overlooked an important requirement as well.
We also conducted internal usability testings for the first few iterations of the design, using light weight code-based prototypes, to confirm (or not) the major pain points and to validate (or not) the hypothesis being tested.
↑ I created wireframes for an end-to-end work-flow, leaving gaps for areas that are open to trigger discussion points.
Made sure the portal fit in our product ecosystem
In order to understand the dynamics between the client portal and the charter operator’s quoting product, I mapped out the interactions between those two systems such as the status mapping.
Sometimes the ball is in the operator's court. When trip changes occur, whether or not the user needs to review a revised quote and sign again, or whether or not the user needs to book a new trip, it depends on how significant the price difference is and how much scheduling work has been done to the original trip. I facilitated the discussions with cross-functional team members and came up with a detailed user flow to satisfy both the user and the operator's needs.
↑ Documenting specific use cases
Post Launch of MVP
Reflections
The MVP was delivered on time which directly helped us grow our customer base. We are currently working on the subsequent iterations to further streamline the process such as managing trip changes.