Warwick Gavaghan
Product Designer
Roller - Venue managment CRM

Booking calendar

Manage guest availability and create new bookings through the booking calendar.
Overview
ROLLER's core product contains many powerful features that help parks log and manage bookings.The booking engine is supported by daily and weekly representations, helping venues see availability, organise staff and provide additional customer service for those bookings with special needs.Many of our venues take bookings weeks or months ahead of time, commonly for parties or groups.

They found it difficult to view their available capacity when making these bookings and often resorted to inefficient workarounds.Our clients requested that we investigate a calendar view, as a potential solution, that would give them a high level overview of their venues availability.
Research & insights
We started by interviewing venues to understand their process and what information they needed to make creating and managing their group/party bookings easier.

We needed to understand;
  • Why they believed a calendar view was the ideal solution?
  • What booking information was important for venues?
  • How would the calendar inform their decisions?
Our research identified two use cases;
1. Create bookings
When it came to creating a new booking for parties or groups these were typically performed over the phone. This was the core issue for venues, while they sold party products in the online checkout many guests still called to make a booking.

Venues indicated that a screen that gave them a quick overview of availability, over a 4 week period, would make taking new bookings smoother. They would be able to suggest alternative dates if the requested date wasn't available and then create a new booking from this screen.We learnt that our daily and weekly views were not sufficient in carrying out this process.
2. Managing bookings
Managing bookings presented many logistical challenges, such as assigning the right number of staff during a busier period, purchasing enough food and beverage, catering to particular dietary requirements and hiring specialist staff for guests with special needs care.

Our interviews highlighted that venues required more than just a list of bookings but the particular details of those bookings; information such as remaining payments, dietary requirements, and overbooked guests, etc. Being able to access this information while within same would help them make more informed decisions in managing bookings.
Concepts
It was determined that a calendar was the ideal starting point, it was a familiar concept to our users and would flow well with our daily and weekly views.I began by taking inventory of the key actions and views that were required to design this solution.
Calendar view
  • Display bookings
  • Highlight availability
  • Select the period of time to view
  • Start a new booking
Daily view
  • List bookings with guest total and start times
  • Booking holder name is shown
  • Show available products and guest slots
  • Start a new booking
Products and categories
  • Selecting products or categories reveals bookings with those items
  • Differentiate with colour coding
New bookings
  • Start from any date with available slots
  • List available products, hide unavailable ones
  • Redirect to booking flow
Date selector
  • Select a start date
  • Display a 4 week period
  • Redirect to booking flow
After sketching out some initial ideas I moved into designs concepts. Since we work from a Sketch Library it is quite easy for us to jump straight into hi-fidelity work. I experimented with both a traditional calendar view and a more unconventional, vertical style.
While I could have followed existing patterns for the calendar view, I find it is necessary to explore ideas broadly first. I believe in avoiding designing a solution too early, and that doing so is usually a sign that we're not looking at the issue critically. By taking the time to experiment you're seeking the opportunity to solve problems in new ways.
Fig 01. Initial concepts and experimentation
Solution
Eventually I settled on the traditional calendar view. Our users familiarity with digital calendars and their capacity for displaying snippets of data over a period of time made this the ideal solution.

The use of real venue data aided many of the decisions in crafting this design. It guided the process on what data to show on the calendar, whether there were reusable patterns we applied elsewhere in platform and what was deemed unnecessary.
Using real data removes a lot of ambiguity around your users, how they use your product, and what data they're viewing. It ensures we're not designing towards the bias ‘ideal’ you imagine, but real use cases.
This led to the application of the bookings and availability panel that we use in bookings but re-purposing it for the calendar.
Fig 02. Availability is revealed by displaying what dates and times are currently booked
Solution
Eventually I settled on the traditional calendar view. Our users familiarity with digital calendars and their capacity for displaying snippets of data over a period of time made this the ideal solution.

The use of real venue data aided many of the decisions in crafting this design. It guided the process on what data to show on the calendar, whether there were reusable patterns we applied elsewhere in platform and what was deemed unnecessary.
Fig 03. Bookings are shown on the calendar with their start time
Availability
Dates with bookings may still contain available slots. Selecting a date will open a panel, listing the bookings and the products available for purchase under the availability tab.

A new booking can be launched on any date simply by hovering over it and clicking the plus symbol or from a product under the availability tab.

Earlier iterations highlighted the number of available slots on each date, this led to a lot of visual noise on the calendar.
Fig 04. Products available for purchase are under the Availability tab
Management
Eventually I settled on the traditional calendar view. Our users familiarity with digital calendars and their capacity for displaying snippets of data over a period of time made this the ideal solution.

The use of real venue data aided many of the decisions in crafting this design. It guided the process on what data to show on the calendar, whether there were reusable patterns we applied elsewhere in platform and what was deemed unnecessary.
Fig 05. Booking details are accessed via the booking list
Overview
1. Use real data
Using real data removes a lot of ambiguity around your users and ensures that you’re designing for how your customer’s use your product, rather than the bias ‘ideal’ you imagine.
2. Explore
While I did end up following an established UI for the calendar view, my earlier experiments informed many of the subsequent decisions and the presentation of booking data. The colour coding and use of products/categories to surface the relevant bookings were born from these experiments.
3. Focus on the core outcome
In designing this feature I found it was easier to start with all the booking data being present on the calendar. It meant that my decisions to remove or move things were based around their importance to the user rather than simplifying the UI because it looked nicer.