Designing the future of lounge access.
LoungeBoss is an iPad app that integrates with the LoungeBuddy platform to enable instant lounge access and reservations for travelers around the world. I worked with the Business Development and Engineering Teams to envision and create the future of lounge access using the different services and integrations we’ve built over the last two years.
The Existing System
This first version of LoungeBoss was created before I started at LoungeBuddy, and not much has changed since then — nor has it had to. LoungeBoss is a straightforward check-in system for Lounge Agents that integrates directly with the LoungeBuddy platform to enable instant lounge access and reservations for travelers around the world.
As LoungeBuddy grows, and our services and data offerings increase, we want LoungeBoss to be the gatekeeper of the lounge experience. We have so many technologies that have been built around premium airport experiences, and we want to bring those to a wider audience. For example, our Access Rules in LoungeBuddy for iPhone, which allow you to see which lounges you already have access to through your lounge memberships, elite statuses, credit cards, and premium airline tickets. We can also use this feature to inform Lounge Agents whether or not a customer has complimentary or paid access to their location, what the guest policy is, any relevant flight information they might need, etc. I think you’re starting to see where the “2.0” comes into play.
What can I expect from this case study?
When I was told we were going to be working on a new version of LoungeBoss, I assumed it was going to be a few updates to the existing system, but I couldn’t be more wrong wrong; this was the kind of project every product team dreams of; what would you design if you could start from scratch?
The following case study will introduce you to LoungeBoss, and go through some of the product decisions we made along the way. You might be wondering, “Why is this case study is so freaking long?!” I considered breaking it up into multiple posts, but felt a more cohesive write-up made the most sense given how LoungeBoss was designed. Feel free to skim or jump around, but be warned, you’ll miss out on some pretty great witticisms if you do. Enjoy!
Given the existing version of LoungeBoss is centered around the Dashboard, this felt like a good place to start. Though the initial requirements were vague, we had a feature list of what we needed to include on the Dashboard:
- Lounge Statistics
- Customer Reservations
- Flight Status
- Feedback Management
Due to a combination of ambiguous handoffs/requirements and my initial unfamiliarity with the Lounge Agent’s responsibilities, the Dashboard easily wins the award for “Most Iterations of Any Product, Ever.” I can’t count the number of sketches, artboards, pages, and conversations it took to get to this point.
A lot of my initial explorations were… for lack of a better word, “uninspired.” I was ticking feature checkboxes, but not taking these features to the next level. I kept telling myself that these mocks were “wireframes”, but if I’m being completely honest with myself, I didn’t know how to take these mocks to the next level. After some back-and-forth between me and the CTO, I decided to create a new file and say the dreaded words “Start Over.” I think it’s important point out that when you “start something over,” that’s not actually what happens. I’m convinced this is something you tell yourself to make yourself feel better, but you always retain what you’ve learned and experimented with until that point.
The act of "starting over" gives you the creative license to look at the same problem in another way, without feeling like you’ve failed.
I remember begrudgingly increasing the font-size on my artboard just to mess with the CTO during our next critique. I knew he wouldn’t like it, but for some reason that mischievous moment changed my entire perspective about the Dashboard. This was the moment changes were being made with intent. I started making major changes, and then reigning these changes in.
With each iteration (and conversation with business dev, engineering, and the lounge agents) you could see the Dashboard starting to form, and the design patterns starting to emerge. As we started formalizing elements, I set a goal for myself to start creating components that we could reuse across all screens, and challenge myself every time I wanted to create something “new.”
After a few more conversations and iterations, we solidified our plans for the Dashboard. Our requirements were simplified, and we tabled the features that were not absolutely critical for launch.
First up is the Lounge Overview, which gives the agent an idea of how crowded the lounge is, and whether or not they should consider turning off access. We put this section first, since it would serve as a screensaver when agents aren’t checking anyone in.
Along the graph, we can show things like opening and closing times, predictions of lounge capacity based on historic data, and provide estimates for how many travelers are in the lounge. This is all information agents currently keep track of manually, but is now automated with LoungeBoss.
Fun Fact: During testing, there was an early bug that did not smooth-out the graph, but instead kept compounding check-ins from the previous hour. The agents didn't realize this was a bug, and were competing to see who would make the metrics "jump."
“How are you determining how many travelers are in the lounge?” Good question! When a customer is checked-in using LoungeBoss (you’ll read all about this in the next section), the agent will scan their boarding pass as part of the check-in process. Once we have the customer’s flight information, we have a pretty good idea when they are going to leave the lounge, since they have a plane to catch. Regardless of when a customer enters the lounge, we have an idea of when they are leaving.
Second on the list is the Customers section, which allows agents to check a guest in, view and manage upcoming reservations, and view historic data (up to 48 hours) of lounge visits.
LoungeBoss 1.0 interface is centered on a one-tap check-in experience. With LoungeBoss 2.0, we didn’t want to lose that simplicity. We knew from years of interaction experience from Lounge Agents that they’ve had little to no issues with the existing interface. Since LoungeBoss 2.0 was such a major change, we didn’t want to change the UI so drastically that it would require further training for features the agents already know how to use. Isn’t there a saying, something about “what ain’t broke…”
This means we ultimately decided to reuse the existing “card” metaphor from LoungeBoss 1.0, but used the opportunity to add some enhancements including highlighting when a customer is running late, displaying the customer’s confirmation code, and the number of guests in the party.
The Flights section of the Dashboard has been an interesting project in and of itself. At this point, the design language was setting in, and creating components came naturally.
Based on input from the Lounge Agents, we created an extremely glanceable yet detailed version of upcoming Flights for the dashboard. We wanted agents to be able to quickly scan a list to see which flights were about to depart, and which flights were delayed. After all, flight information affects lounge capacity dramatically.
The first version of the Flight Dashboard we were comfortable sharing used design cues from the Customer Cards.
Visually it was clean, but functionally it was broken.
After seeking more feedback and data, we found out that the number of flights an agent could see at any given time could fluctuate from a handful (say 3-5, the original estimate were were given) to nearly 50. This of course depends on the location of the lounge and airport traffic, but having fifty flights on the roster was too common a scenario to be considered an “edge case.”
But Jony, shouldn't you be focusing on critical flight information?
You've made an inarguable point. After many conversations about “what’s most important,” we honed-in on these two questions:
- Which flight are customers traveling on? An agent does not need to know flight information that does not affect the customers in the lounge. That’s just extra information.
- What is the status of those flights? What happens if the majority of flights are delayed? How should an agent proceed if multiple flights are canceled? Does the agent have to make an announcement?
Knowing which flights affect lounge capacity empowers the agents to make critical decisions like shutting-off access to the lounge or more strictly enforcing access rules if they haven’t already.
What we came up with is a simple flight board that shows the flight status along with the accompanying airport code. When there’s a mix of flight statuses, the agent can scan the list by airport code to check a status, but when flight statuses change on an airport or airline level, it is immediately obvious thanks to the flight status symbols. This works just as well for the handful of flights scenario we originally designed for, as well as the common fifty-ish flights the busier lounges have to deal with at the drop of a hat.
The Check-in Flow
Due to the way flights are scheduled, large amounts of people tend to enter and exit lounges at the same time, which means lines happen exactly when you don’t want them to. The current Lounge Management Systems are the biggest obstacle to improving check-in times; what should take a few seconds, actually takes close to 3-5 minutes per passenger. This might not sound like a problem at first glance, but when you think about 20 people trying to access the lounge at the same time, that 3-5 minutes quickly becomes 60-100 minutes. To solve this, some lounges use multiple agents to check-in passengers which may cut the time in half or a third, but when technology is involved, more people should never be the solution.
We didn’t want our system to be the limiting factor when a customer is trying to get into the lounge. Our goal was for LoungeBoss’s check-in flow to measure in seconds, not minutes.
Fun Fact: During our beta tests, lounge agents were able to check customers in using LoungeBoss 2.0 (while using their old system) in less time it took their old system to process the same check in.
What steps are required to check-in a customer?
- Access Method (i.e. Credit Card, Lounge Membership, etc.)
- Flight Information
- Number of Guests
- Payment Information
In addition to these steps, we had a few constraints we had to work with. There would be hardware to scan QR Codes and read credit card information, we did not know whether or not we would be accepting payments through LoungeBoss, and because of the hardware chosen the iPad would be locked in portrait mode — landscape was not an option.
Access Cards, a Failed Experiment
When we first started talking about the check-in flow, I immediately thought about our recently redesigned Access Cards for our iPhone App.
Agents would swipe a customer’s card, and we would allow them to pick the correct access method. After selecting an access method, we would then display the appropriate form to fill out.
Here’s the problem — I was thinking from the perspective of “manually selecting an access item” instead of automatically selecting the access item that made the most sense for the customer. With speed being a major goal, why would we let the agent choose an access method instead of automatically selecting the one that made the most sense for the customer. After all, if one of the options shown is free lounge access, why wouldn’t you select that option? Despite my desire to share visual metaphors between platforms, the access cards just didn’t fit in this context.
We needed to regroup and look at this more from the lounge agent’s perspective.
I quickly realized I was ignoring all of the past work we had been doing, and ignoring the design patterns we had started developing on the Dashboard. Little things were important; ”How does the check-in panel appear? Where does it come from? What information does the agent need to see? What steps are actually necessary to check-in a customer? etc.”
With that in mind, we began questioning whether or not this should be a full-screen experience. Looking through Apple’s HIG, we re-read the section about modality, which changed how we saw the check-in experience.
A modal state was exactly what we were looking for. We decided to make the check-in panel a form sheet that pops-in from the center of the screen.
Prototypes & MVP
After we had the basic check-in ideas thought through, and some ideas mocked up, the engineering team built a proof-of-concept app with the ideas and interactions more formalized.
We used this prototype get feedback from lounge agents and partners to make sure we were on the right track. It was crude, but all of the requirements and basic interactions were there. After gathering the feedback and discussing it amongst the team, I took the prototype and refined the UI and interactions from there.
The Check-in Experience
Instead of having the agent tap anything on the screen, we automatically select the access item based on what’s been scanned or swiped. This means if you have a lounge membership, you can swipe or scan your membership card using the attached card reader/scanner and LoungeBoss will immediately start the check-in process from anywhere in the system.
Reservations have all of the customer’s information filled-in, so all the agent needs to do is confirm this customer’s identity and admit them in the lounge.
The Automated Check-in Flow
To initiate the check-in process, the lounge agent will swipe or scan the customer's access method to see if they have complimentary or discounted lounge access. The agent then scans the customer’s boarding pass or enters their flight number manually
If there are any guests, those will be entered manually. Finally the agent will admit the customer into the lounge, or deny entry based on the information presented.
The Detail Views
We needed a detail view that was extensible to multiple types of information, but also allows the agent to quickly drill down to the information they might need to reference. For example, if a customer that already entered the lounge wants to know when their flight is set to depart, does the agent look up the flight number or search for the customer.
We wanted to standardize the header’s design across all views in the app. We needed the obvious things like a title and a way to close the screen, but also things like pages, a way to search the content on the page, page-specific actions, etc.
Below the title, we wanted a way to quickly switch between the types of content we were displaying. We started thinking of these as “quick filters” instead of pages, since we were displaying the same content, but in a different context. Agents could switch between “Upcoming Reservations” and customers who where “Recently Checked-in,” while staying on the same screen.
We looked to iOS for inspiration on how this could look, and tried different versions of the design based on standard iOS conventions.
We ended up settling on Apple News’ always-visible and extensible page design. This was not our ideal visually due to the decreased contrast, but it served the desired functionality, and we knew it was something we could always revisit since it was a contained element.
Before designing these screens, we had a conversation about what information an agent would want to reference in order to find a specific customer, or what questions a customer might need answered regarding their itinerary.
This was quickly broken into two experiences, pre and post check-in. Before check-in, the agent needs to recognize who is in the lounge vs customers who are expected to arrive. Is that customer late, how many guests are they bringing with them, etc. Post check-in, their concerns start changing; how long have they been in the lounge, how many guests did they bring with them, and what is the status of their flight?
We knew we had to think of different views to house this information, so for the design we wanted to know what filters do agents do naturally, that we can do automagically?
Translated to lounge agent-speak: Who is coming to the lounge? Who is already in the lounge? Which customers have left the lounge?
- Reservations: Shows customers who will arrive at the lounge within the next two hours.
- In the Lounge: Shows customers who have already been checked-in, whose flights haven’t departed yet.
- Customer History: Shows all customers who have been checked-in, regardless if their flight has departed or not.
After many iterations, we came up with a table cell that housed all of the information an agent needs at a glance, and sorted by “how easy is it to reference this information when a customer approaches the front desk.”
Depending on the filter selected, agents can switch contexts quickly and easily. You’ll notice from the image above that we change certain information based on the filter. For example:
- The reservation time changes from absolute time to relative time when an agent switches from “Reservations” to the “Customer History.” Customers arriving at the lounge will reference their reservation time, whereas agents will reference a checked-in customer by how long ago they entered the lounge.
- We also replaced the Booking Number with the Flight Number. After check-in, the Booking Number isn’t as useful as the customer’s flight information, unless there was a problem with the booking (a rare occurrence).
Each cell can be tapped to view the check-in screen, where an agent can view more information about a customer, including reservation information, actual check-in times, flight details, and the customer’s check-in history.
Thanks to the Flights section on the Dashboard, we had already done a lot of the research for the Flight Details screen. It also helped that there are many examples of Departure Boards, so there was no need to reinvent the wheel.
We knew customers would approach the front desk to ask about their flight status, so we wanted it to be incredibly easy to scan a long list of flights. We also wanted it to be abundantly clear which flights were On-time, Delayed, or Canceled.
The biggest design challenge was deciding how to sort flights. We had so many options to choose from, but what would be most helpful for the agents?
A major operational concern for lounge operators is quick turnover and limiting overcrowding; the two go hand-in-hand. Flights are the most natural way of managing this, since it gives the Lounge Agents an idea of when customers might leave en masse. Knowing this, we decided to focus on the flight’s status and departure time.
Which departure time are you talking about? Such a good question; this is where the design started to become challenging. There are two "departure times" for every flight:
- Scheduled Departure Time: the time at which the flight is planned to depart.
- Expected Departure Time: the actual time a flight is scheduled to depart, including any delays.
There are so many scenarios where an agent will need to reference either numbers. For example, a customer can ask, “What’s the status of the Phoenix flight at 9:25?” In this case the agent is going to reference the Scheduled Departure Time to find the flight in the list. If a lounge manager asks an agent, “when is the next flight departing?” An agent could (in theory) scan the entire list of flights to see which ones are departing soon, but it would be much easier for the agent to sort by the Expected Departure Time.
With every scenario in mind, we knew providing both options would offer the most value. By default we are sorting by the Scheduled Departure Time. Next to the search bar, we added a toggle where agents can switch between the two sorting options.
There is a lot more to LoungeBoss — including a few micro-interactions, edge cases, and changes we’ve made to make development not only easier, but to improve the experience for both the lounge agents and customers. This case study covers most of the major features, and though it was long, I hope you enjoyed reading through some of these design decisions as much as I did sharing them.
LoungeBoss 2.0 was designed in it’s entirety (from concept to the start of development) in about three months. In this time, I was the only designer working on not only LoungeBoss, but features and enhancements for our other products along the way. I want to point out that this was a major team effort (from business dev, to engineering, and of course, design). We worked very closely together to push and pull ideas from one another in order to make the launch a success.
It takes a team to support this kind of iterative process. You can’t iterate without feedback, and you can only get yourself so far before you need a fresh pair of eyes. Every major positive change came from having a conversation with someone about what I was working on, and being unafraid to share how I was feeling about a design at any given point.
LoungeBoss has been “in the wild” for a little over 6 months now (as of publishing). Reactions from Lounge Agents and partners have been overwhelmingly positive, and we are continuing to tweak and make improvements along the way.
Completed October 2017