A Module Design for Class Booking

Project Initiative

As everybody knows, Groupon is a uniques marketplace for various types of deals. Massages, gym passes, cooking classes, tours, auto services, electronics, and more can all be found here in one portal. To meet the company goal of making Groupon a bookable marketplace, we need to customize the online booking experience for each category of deals.

Therefore, this case study shows how I designed a module on top of the original booking experience to make Class Deals bookable for Groupon customers.

This project has been implemented and published. It is steadily running and serving Groupon's customers around the world. And it has increased Groupon's bookable inventory by 13%.

What is a Class Deal?

A Class Deal is not equal to a class.

"Class Deal" is a term used by the Engineer Team at first. It is describing a category of events that repeatedly happens for a group of participants. Together with the PM, we collected examples and map those out. It gave us a clear picture of Class Deals' range- what we are solving for in this project.

We need to bring booking capability to Yoga Classes, Baking Courses, Painting Workshops, Bus Tours, Makeup Classes, and more deals like that.

A Class Module is necessary for Class Deal Booking

The old booking experience only allows customers to choose a date and time for an appointment. With that, if a customer wants to buy a voucher for a cooking class, this person will not be able to choose between "8 pm Dim Sum Class" and "8 pm Dumpling Class" when making an appointment.

Identify problems. Outstanding ones and hidden ones.

Project Goal

By chatting with the PM and the rest of the team, the project objective is pretty straightforward and clear. And there's not much ambiguity around the project goal itself.

Design the MVP version of Class Module to:
A. Display class information
B. Enable customers to choose a class

The capability to foresee some problems

After that, I also took a step back and tried to uncover some potential concerns from the design point of view. I shared them with the team, provided the team with my proposals, and tried to decide if we would address those concerns in MVP.

Concern 1: Does page structure need to be updated?

Currently, the Booking Page is a one-pager with multiples show-hide modules. This page structure has potential risks for modules with certain complexity (like Class Module) and scenarios with too many modules.

I did some quick prototypes to evaluate the risks and possibilities of using some alternatives. I shared it with the team, so everyone is aware of this issue. And we have a good starting point for our discussions.

After a brief discussion with the design team and PM team, we agreed that this page needs an update to accommodate more complex booking needs and an up-to-date digital experience. However, in consideration of the timeline, we decide to keep this outside of the scope.

We decided to continue using this show-hide structure for our core booking experience. We will update the page structure at a later point.

Concern 2: What's the future state of Class Booking?

Currently, the only identifier for class deals is the Class Name and End time. But in the future, we will have instructor name, instructor description, capacity, and price information adding in, which will also play important roles when booking for a Class.

Although this project targets MVP, the team agrees that we need to deliver something sustainable and compatible for future add-ons. So we will consider how the solution accounts for future updates throughout the process.

What makes Class Booking challenging on Groupon?

Studying Groupon's Class offerings and also our competitor's Class offerings.

To accelerate the ideation process, I've studies some Class Booking Experience provided by some of our competitors. Learn about commonly-used patterns and collect insights. Besides that, I also made some comparisons on Classes Offerings provided by Groupon and by competitors.

Class variety x frequency map

According to the scoping, we need to take care of bookings for fitness classes, which have numerous class types (Hot yoga, cycling, HIIT, etc.) and happens 10+ times a day. We also need to cover for makeup courses booking, which only has one or two class types, and only occurs several times a month.

A one-size-fits-all solution is needed here for classes that expand across different variety and frequency.

Anatomy of a Class

At this step, I'm trying to understand the composition of a class – how is a class booking different from ordinary bookings from different perspectives.

Classes for Engineer Team

Since Engineer Team defined the class category and supported the class booking, it's crucial to understand how the class booking works in the backend. Based on what I learned from the PM and the Engineer Team, a bookable class means an available spot with more constraints than just date and time.

In backend, an ordinary booking is consist of
- Date
- Start Time
- Capacity (optional)

In backend, Class is consist of
- Class Name
- Date & Recurrence
- Start Time & End Time
- Capacity
- Instructor Information (optional)
- Detailed Description (optional)

And for MVP, the team hopes to surface Class Name, Date, Start Time ,and End Time Information. Capacity, instructor, and detailed description will be available at a later point as an add-on.

Classes for End Users

For our end-users, which is our dear customers, classes have different meanings, of course. Here is a good example:

When book a Massage Deal, 6:00 pm and 7:00 pm are equivalent for customers and can be alternatives as long as the availability works.

When book a Class Deal like a Cooking Class, 6:00 pm Dim Sum Class and 7:00 pm Dumpling Making Class are entirely different for customers.

Combining that with the initial research, we made some assumptions that Date, Start Time, and Class Name are the most critical factor when a customer decides to book for a class. And Class Name and Start Time are always considered together. Those helped me breakdown my design goal.

Goal Breakdown:
B. Enable customers to choose a class
- Surface Date, Start Time, and Class Name information as the critical information.
- Allow customers to select Start Time and Class Name together as an integral.

Date selection with monthly, weekly, daily calendars.

When should date selection kicks in?

For ordinary bookings, users will be required to choose a date first and then choose a time. For Class booking, it is an open question for me to decide if date selection should come first, come second, or come together.

To provide a better experience for as many customers as possible, we decide to use the last model - Expose Date & Class selection at the same time.

Choose a calendar style for Date Selection

For an ordinary booking experience, users will choose a date on a monthly calendar. It works OK when the task is as simple as selecting a date and time. It might be trickier when users try to book a class - it's a complicated task. So I need to evaluate if the monthly calendar is still the best choice here.

Overall, I find that the cons outweigh the pros for using a new calendar (Week or Day) in this MVP. So we decided to continue using the old Month Calendar for date selection. But the team does agree that the Week Calendar will be promising for a more user-friendly interface if we can invest more time in it in the future.

A component that allows users to choose Class and Time as an integral.

Debating between 3 solution of class selector

I was able to ideate wildly based on my previous discoveries. And I narrowed them down to 3 solutions to easily share with the team and solicit feedback.

At first, I shared this with the entire design team, asking for feedback from a design perspective. The discussion is challenging, though. Everyone has distinct opinions. Every point made is valid. At the same time, these three solutions all have their pros and cons. And we can not nominate a clear winner.

So I just continued working on those three solutions. Try to address the cons of each of the solutions. And also apply those solutions to different scenarios and test their compatibility.

I've shared these three styles with different teams – the Product Team, the Booking Team, and some other non-designer coworkers. I've used static prototypes and clickable prototypes to introduce my design proposal and allow people to feel and experience the entire user flow. I've put this on mobile screen and on desktop screen to showcasing different styles on different devices. I've prototyped scenarios with only 1 class option vs. numerous class options.

Balance between user experience and Design System guidelines

At last, the Design System is leaning towards the Button Style. And the rest of my direct teammates are leaning towards the Card Style.

My direct teammates come from a user's point of view. The Card Style is the most intuitive one for them. And it helps elevate the overall user experience comparing to other solutions. The Design System team believes that creating a new component should always be avoided if there are alternatives available to use in the library.

In respect of the Design System Team's opinions, I spent some extra time together with them, iterating the Button Style selector. After a reasonable amount of attempts without seeing promising outcomes, we made a call to use the Card Style instead. It will provide a better user experience, which should always be our top priority when possible.

What's the best way to display Class Info.

Since we have decided on the selector style, it's time to think about information display, which is also a significant part of the project goal.

Goal Breakdown:
A. Display Class information
- Display basic info ONLY for MVP
- Display info clearly so users can easily find the one they need
- The solution should also accommodate for advanced info that might add in later on.

Before selection: Module Expanded

When the module is expanded, users will see a list of class options and relative information of each class to make a choice. I think there are two layout styles. Both look promising and worth trying.

1 column vs 2 column style

Easy maintenance for responsive screens and different languages.

Information clustered into bigger chunks. Might not be good for browsing.

Information, especially time information is sectioned out, which makes it easier to browse.

Need some extra effort on responsiveness and multi-language.

In the end, we chose the one-column style just because it's a more basic, versatile, sustainable layout. It will be a better choice for an MVP and all kinds of future updates.

Duration display

For classes, the backend will provide Start Time and End Time information. After some research and thinking, we decided to surface Duration instead of End Time for a better user experience. Then the question came - where to put this duration information?

Start Time is all by itself which is easier to browse.

It's intuitive to put Duration and Class Name together

I did some ideations myself. And I've also consulted a Content Strategist for this question. One of the proposals he brought up makes a lot of sense and is agreed by most of the team, which is to put duration in front of Class Name.

Use font weight to elaborate information architecture

Previously I chose to use regular type weight for every piece of information. The research showed us that either Time or Class Name could be the most critical info under different scenarios. We can not say one is more important than the other for every single user visiting this page.

The list has rhythm and is easier for browsing.

Later on, after hearing some teammates' feedback, I decided to bold Time. It's not because Time is the first thing we want to draw people's attention to, but because it adds more rhythm to the text-heavy list. The bolded typography serves as anchor points and makes a list much more digestible from a visual perspective.

After Selection: Module Collapsed

Till now, I have accomplished the heavy-lifting part. Simultaneously, there is still one more thing that needs to be studied and figured out - the information display for the module in the collapsed state.

Although this little module looks simple, there are still lots of possibilities around that. I approached it in a systematically by thinking about how much space to take and how much information to surface. And present to the team and solicit quick feedbacks.

In this process, I tried to account for consistency - how this compares with the ordinary booking flow. I've also tried to account for sustainability - how that info plays out in post-booking scenarios and future versions. In the end, we were able to land on a solution everybody is satisfied with.

Final Outcome

I completed this project successfully, and soon it got implemented and published. With this effort, customers can choose a class to book and edit their selections all in this booking experience.