Case study: Bookings on Highspace
Designing the customer-side ‘Bookings’ page for a stealth startup (similar to “Your Orders” page on Amazon.in).
--
The key goal for this project was to design a ‘Bookings’ page for the Highspace website, where all bookings can be found and tracked by the Customer (similar to “Your Orders” page on Amazon.in, or “Your Trips” on Uber).
In this case study, I lay out the process on how I defined the ‘Booking’ entity, and thereby designing the ‘Bookings’ page.
This is one among several projects that I single-handedly took on the responsibility to design from start to finish, during my stint at Highspace (of course, in collaboration with the product manager and developers).
As of me editing this case study in Jan 2021, the final website is still in its development stage and yet to go live.
Alright, let’s begin!
About the company
Highspace is an online C2C platform where users can rent or list on-demand high quality studios (similar to Airbnb, except here instead of renting homes, it’s studios.)
Who are the users?
There are primarily two types of Highspace users, namely:
1. Customers:– These users would include photographers, filmmakers, workshop conductors, dance instructors, or anyone who seeks to rent studios for their work or projects (Fig 1).
2. Hosts:– These users would include anyone who owns a studio which is underused, and thereby desire a side income by listing it for rental (Fig 2).
Understanding the context
When a Customer decides to rent a studio on Highspace, they send something known as a “Booking Request” to the Host, which the Host either accepts (Booking gets confirmed), or declines (Booking gets cancelled). With this in mind, I knew my design had to satisfy the following Customer needs:
Customer Needs:
1. To track the status of Booking Requests
2. To find past Bookings
Preliminary research
Before jumping into the design process, I studied how companies like Amazon, Uber, Airbnb designed their ‘Bookings’ page for their customers. I noticed a couple of things:
1. The page is logically categorised.
Airbnb categorises their ‘Trips’ page into: “Active trips”, “Confirmed trips”, “Completed trips”, and “Needs attention”, which makes it convenient for the customer to find what they’re looking for (Fig 3).
Similarly, Amazon categorises the ‘Your Orders’ page into: “Orders”, “Buy Again”, “Open Orders”, and “Cancelled Orders”.
2. The nomenclature used is easy to remember.
Amazon uses the word “Order”, while Uber and Airbnb use “Trip” to denote bookings. This way all stakeholders can easily understand and get used to the nomenclature of the booking entity.
Design process
1. Defining “Booking”
I first set on the define a simple and appropriately named entity called “Booking.”
Booking:– A Booking is an entity that is created when a Customer requests to book a studio on Highspace (Fig 4).
2. Defining states of a Booking
After defining the basic meaning of a Booking, I set on the define the various states of a Booking.
1. Pending State:– This is the initialised state of the Booking wherein the customer has requested to book a studio and awaits Host confirmation (Fig 5). The CTA to book again is disabled because the Customer isn’t allowed to book the studio before the current Booking gets confirmed.
2. Confirmed State:– This is the state of the Booking as soon as Host confirms the Customer’s Booking Request (Fig 4).
3. Cancelled State:– This is the state of the Booking as soon as the Booking is cancelled either by the Host or by the Customer (Fig 6).
4. Active State:– This is the state of the Booking wherein the customer has checked into the studio but yet to checkout — still ongoing (Fig 7). Cancellation date is set to null because the Customer has already checked-in.
5. Completed State:– This is the state of the Booking wherein the customer has checked out of the studio. The design for this state is same as that of “Active” state (Fig 7).
3. Designing the “Bookings” page
Finally, after completely defining the ‘Booking’ entity, it was time to design the “Bookings” page.
As we’ve seen, all Bookings will fall into either of the following 5 categories which I represented as tabs in the layout of the page (Fig 8):
- Upcoming
- Pending
- Active
- Completed
- Cancelled
The following Customers needs are met through the proposed design:
• to easily find the Bookings they are looking for by clicking on the tabs
• to track the status of their Booking Request in the “Pending” tab
4. Iterating the ‘Bookings’ page design
A design review was held to uncover any obvious shortcomings of the design. From the feedback I received, the two pressing concerns were:
- For an upcoming Booking “Check-in date” was missing. It was an important detail the Customer would glance at.
- “Booking” was misleading copy to denote the date of Booking Request inside a Booking.
After ideating a few possibilities, I iterated from the previous design (Fig 8) to the following final design (Fig 9):
The reason I placed the “Check-in” date and time out of the Booking was because it wasn’t an inherent part of the Booking’s design. Moreover, placing it outside made it easy to glance at, which was exactly the Customer’s goal.
Reflection
This project taught me about the importance of design documentation as it involved a lot of nuances like the various states of a Booking. Had I not documented those little details and jumped straight to design, I would have added a lot of fuel to the fire for all the stakeholders. I’m eternally grateful for my time at Highspace as it enabled me to learn stuff by doing.
🔥 Thank you for reading this case study! Hope you like it. I would love to hear any feedback you have! Leave your comments here, or hit me up 👇🏻
