Designing Cabana’s Back Office
My Role
From initial research to designs to implementation, this project took about a year. I conducted user interviews, and worked with our product manager to design the new features. As I went through design iterations, I worked with the engineering team to adapt the designs to their technical and time constraints as they implemented the changes.
About Cabana
Cabana is a Seattle-based startup in the travel and mobility space. They rent out ‘mobile hotels’: camper-vans upfitted for a hotel-like experience. In order to create the best experience for guests, Cabana has an operations team that manages bookings, vans, and guests.
The Project
Designing Cabana’s Back Office
Running operations at Cabana is complex, where a damaged van can trigger a jigsaw puzzle of moving bookings, vans, & cleaners around to accommodate a booking starting in an hour. To manage this complexity, the operations team uses a few different tools.
In this project, I worked with our engineering team and product manager to cut out a 3rd party tool and incorporate its features into our own Back Office web app.
Process
Research: Discovered how the operations & customer support teams currently use Wheelbase through user interviews
Ideation: Explored design ideas
Concept Testing: Walked through designs with operations & customer support teams and iterated based on feedback, and worked with engineering team to determine feasibility within technical & time constraints
Visual Design: Created a style guide and worked with engineering team to help them implement it effectively
The Problem
Cabana was using two systems to manage bookings & users which was complicated for both the ops team and our engineering team. In this case study, I will focus on the transaction management part of Back Office.
Research
I knew what functionality we needed, but I wanted to find out how the operations and customer support teams used transaction features in Wheelbase: what worked and what didn’t?
I talked to every person on the operations team, customer support team, and maintenance team, about 10 people in total. I asked them general questions about what they liked and disliked about the systems they used, and I asked them to share their screen and walk me through specific processes that they went through every day.
Key Findings:
The operations & customer support teams need to be able to get a sense of a booking’s transaction history at a glance.
These teams are moving fast, and are often rushing between the warehouse and the parking lot with vans. They don’t have time to deep-dive into the transaction history.
The operations & customer support teams need to explain pricing changes to customers.
Ops & CS make edits to bookings while on the phone with customers. The customers will often ask why the price of the booking has changed in a certain way, and the current system doesn’t clearly surface the reason behind the changes, which can be frustrating to our team members and to customers.
The operations and customer support team need to limit duplicative work because it takes up time and it makes it harder to onboard new team members.
This is especially relevant because these teams have a high turnover rate.
How might we enable the operations team to clearly understand, manage, and communicate guest transactions in the Cabana Back Office?
The operations and customer support teams need a lot of information, and I realized that I needed to design a system that empowered them to find and understand information quickly. The more insight into a booking I could give, the better.
Ideation
Transactions Section
The operations and customer support teams needed to see a history of transactions (essentially charges & refunds) associated with a booking. Based on my research, I came up with a few design ideas and showed them to both teams to get feedback.
The operations and customer support teams needed to see a history of transactions (essentially charges & refunds) associated with a booking. Based on my research, I came up with a few design ideas and showed them to both teams to get feedback.
Note: refunds have to come from a specific charge; in Wheelbase, users need to select a charge to refund from.
Feedback: The problem with this approach was that it was no longer in chronological order, so it was hard to ‘tell the story’ of this booking.
In the next iteration, I showed the transactions in chronological order. I removed elements from Wheelbase that weren’t being used or referenced. In this version, the product manager and I decided to add credit information. We thought that this could be useful when looking at the overall money associated with a booking.
Feedback: Credit information didn’t feel relevant to a booking, more so relevant to the guest.
In the final iteration of the screen, we ended up taking out the charge-specific refund action, and instead having a button on the top to ‘issue concession’. This way, users could give a refund for an amount larger than one charge, and the refund would be spread across charges in the backend. We also removed all of the specific credit information and kept just the total credits issued for the specific booking. This way, the Operations/CS teams wouldn’t accidentally give the customer more credit value than they actually paid for the booking.
Editing Bookings
There were a few challenges that came with designing the edit booking flow. One big challenge was determining how to show the financial impacts of an edit.
(In Wheelbase, the edit screen is a piecemeal of different charges, with no overall charge or change visibility.)
I had heard repeatedly from the Ops & CS teams that customers would ask a lot of questions about why their booking edit was more expensive, or how much of a refund they would get.
The Operations and Customer Support teams really wanted visibility into the breakdowns and totals of the charges & refunds so that they could answer these questions while they were on the phone with customers.
In trying to give CS the power to explain the reasoning behind pricing changes, I highlighted the specific charges and refunds in the edit screen.
Because of all the areas where editing was possible, the modal was becoming really long. The PM and I decided we should move the final payment screen to another step.
In order to empower CS to have more information, I also added a modal so they could see the breakdown of the pricing per day that makes up the total rental cost. This way, users can see the original rental cost, and the new rental cost (in this case they added 2 days to a booking), and the cost per night.
What I Learned
One of the main themes across this project was that we were trying not to design in a way that would force engineers to redo work (a modal with the same content that later shows up on another screen), and at the same time thinking about the ops team having to learn a lot of new processes. Because of this, I had to think about the big picture with every decision I made, how one design change would impact other screens, and how it would impact both the engineering and operations teams.