Entire checkout flow of a theatre event booking, with Headout PWA
A full description of my design process on how I got here🚶🏻
Attention, I don’t work for Headout, this is just a side project, an attempt to redesign the checkout flow of a theatre event booking app, essentially focusing on the seat map selection flow. Did this during my last 2 weekends.
I will now describe the design process I did to achieve this:
Requirements — what the user must be able to perform ⚠️
- Choose his desired seats
- Compare prices for various seating selections
- Select the number of guests
- Select the date & time of the show
- Add multiple guest & payment details for future references
- Apply promo codes available online
- Contact support (in between the checkout process, in case of any difficulty in booking)
- View ticket confirmation
How I tackled the project 🏋
- The problem
- The approach
- Challenges I faced
- Results
- Measure of success
- Next steps
1. The problem 🤔
From my short research on how Headout works, it sounded to me like buying experiences on Airbnb, but unlike a shared economy concept, they operate by partnering with event organizers, cruises, music shows, theatres, etc, and selling it to a broad audience of experience enthusiasts.
My findings revealed that the flow to choose a seat is of utmost importance when trying to book a theatre show. The promoter can charge based on seat instead of one price only, like any other kind of events. The most common use case for different prices per seat on a theatre is mostly based on the seat row or section. For example, front-row seats are more expensive than side panel seats.
From my experience, this problem is hard to solve due to the technology involved in getting the seat mapped for that venue. Usually, the true visual design of the seats is impossible to get, and it will lead to a list of seat numbers like: vip {[seat 32], [seat 33], [seat 34]} ; first-row {[seat 35], [seat 36], etc}.
To solve this problem, I decided to use the example of BookMyShow app, which is a combination of a list of seats represented in a graphical way. This simulates a real theatre seat map but, the problem of special seats on the sides (like a stadium) is still hard to represent here.
Right now, the flow of booking on Headout for a Musical show in London is:
- Event page
- Date selection
- Hour selection + Guest selection
- Checkout
- Payment
- Booking confirmation
This flow can lead to the following problem:
- For the selected date, only 5 seats are available for that venue, and the user is trying to book 6 seats.
When the user arrives to the screen of guest seat selection screen, realizes that he can’t book on that place for the amount of guests needed. So, I decided that it should show the number of seats available per date when the user is selecting it. Also, gives a notion to the user to see if the event is popular or not. If the place allows 200 seats and 180 are available it should be reworded as ‘Seats available’ without any specification given to the number of seats actually available. If lesser seats are available, reword to ‘Only 6 seats available, hurry up’.
The screen of Hour selection + Guest selection has, in my opinion, some problems in terms of UX, like:
- Hard to recognize and identify the hours selection area
- Less space for the user to interact with the map
- The price range selector is aligned from cheap to expensive, but the goal should be to try to sell good seats
- Each price has different color for each seat price, and for me, it looks confusing and colorful
- Clicking on prices makes the price get unselected from the map — users might not be expecting this behavior, but instead, seeing just those seats
- Icon to reset zoom is not recognized until the user clicks it
- I’m still puzzled by the orientation of this frame. The user cannot decode by this graphic as to which side they’re going to be facing when in the theatre. Thus, the selection process is becoming harder rather than user-friendly.
- The map might be too big to explore and can lead to a prolonged decision time. Expect big user drop rates at this step.
- When a seat is added, the confirmation box animates too fast and there is no clear intention by the user to choose it, maybe he just wanted to know more about that seat and confirm the price of it.
2. The approach ✍️
Inspired by John Maeda — Laws of simplicity, I decided to approach this project using thoughtful reduction. Also, based on trends of well known apps like Airbnb and Typeform, will compose simple screens with only one clear task per screen on this flow, so the user feels the process is simpler and faster. But, he will always have the possibility to turn it more complex, by using filters or expanding a feature/operation. The idea is to make it look simple to the eye, but be complex inside, for advanced users to explore and exploit it.
Also, I believe that a good user experience is not made by reducing number of screens, but reduce the number of operations instead.
After some research and paper sketches, I decided that the flow should be as follows:
- Event page
- Selection of date
- Selection of time
- Selection of seat area
- Guest seat selection
- Checkout
- Payment
- Booking confirmation
It’s a longer flow but, instead of mixed operations on the same screen, like hour selection + seat map selection screen, I decided to guide the user on a story, step by step, about his important moment of booking an event that he really wants to attend. My attempt for the project is to make it look shorter and easier for the user and try to convince him getting better seats, not the cheapest option 🤡
Wireframes — Current screen vs Proposed screen:
(1/6) Event page — solving the following problems:
- Distance between the price and the main action button, booking.
- Compelling users to click on booking button by adding user rating information next to it.
- Instead of using tags bellow the event name, use only one circular tag that describes the category of the event.
- I did a free and small screen recording (10 min), using Peek by UserTesting.com, with one user, and discovered that users give a lot of importance to the summary section of an event. So, I tried to push this information up, so users can see it before scrolling. Can be seen here.
(2/6) Date selection — solving the following problems:
- Conversational format, asking real and human questions to users.
- Show if there are seats available per day, and if there are less quantity, mention the number.
- Show price range from day to day for a better comparison. Here, I decided to not go for a calendar view, because I feel that Headout is more of a next-day booking experience, instead of a very thoughtful and planned decision that a calendar can give.
It would be great if I could get data to see what are the most booked dates for theater events. On Zomato, we did this research for people who booked tables at restaurants and the major result was ‘today’ and ‘tomorrow’. I decided to the the same here and still allowing the user to see the calendar view.
(3/6) Hour selection + Guest seat selection — solving the following problems:
- Separated this screen into 3 steps: Selection of time, Selection of seat area and Guest seat selection. This will allow the information to not be so cluttered and still using a conversational format.
- Faster decision making on the time selection screen, by using illustrations of the period of the day it represents, 🌞(day) or 🌜(night).
- Instead of visualizing the whole seat distribution on the venue, show a screen to choose seat area so it shows seats just for that selected area. Followed with a graphical representation of the venue.
- Try to push the users to get prime seats instead of the cheapest option.
- Venue Map Overview tool (fixed top left on guest seat selection screen), that shows the area visible on the screen vs total venue size of the selected seat area.
- A chair, instead of a ball, for a more human communication.
(4/6) Checkout — solving the following problems:
- Trying to fit all the content without scrolling.
- Better introduction with title and main image of the event.
- Price resumed, user clicks on ▾ if he wants to know the breakdown of the amount.
- Security, best price and support information visible on screen to generate more trust for the payment flow that comes next.
(5/6) Payment— solving the following problems:
- Let the user just focus on the act of payment here
- Booking details and trust information is already shown on the screen before
- Interactive and fun way to introduce credit card details. More human.
(6/6) Last step, the booking confirmation screen:
I couldn’t get the actual screenshot for this screen because it requires a payment! Here, I decided to use animation and provide the user a clear message of success, trying to increase his dopamine levels. Features like “add to calendar” or “tell your friends you’re going out” would be encouraging.
3. Challenges I faced 😲
The main challenges I faced during this side project was:
- Lack of information made me make some decisions that go to the business and technological level. For example, I don’t know if this is a situation that applies to all theatre venues or not, if not I should have designed a version that adapts to both flows. It should had been discussed with all the people involved in the project.
- Deciding the platform was also tricky, but since my last (live) project was the Zomato Progressive Web App, I decided to it do there. Also, I think that Headout did an amazing job with this PWA, I’m a big fan of those loadings during page transitions 😛 (Does it work offline? I didn’t had time to test that yet).
- Lack of data to justify my decisions. Understanding what is the most common date booked or how much time people are spending on the current flow, was crucial. Most of my decisions were based on my experience and not on the user. I should had got more knowledge about my target and metric goals. Still tried to know more by doing a screen recording test.
- Designing the high-fidelity mockups was hard, since I didn’t have access to the UIKit, or basic understanding on how is the design language. But, I had to adapt by taking screenshots and… a lot of jugaad.
- After designing and compiling everything on Medium there was always that feeling of “I wish I had done that thing a little differently” or “I totally forgot the login/register flow here”. Well, that is for another day…
4. Results 🍬
Passing from wireframes to high-fidelity mockups and then animation video of the whole flow, made me change some things and make different decisions. I was learning more all the time during this project.
Now, presenting my final design mockups, starting by showing the comparison from the actual seat map selection screen, to my proposed redesign:
And the high-fidelity mockups, designed on Sketch:
And again, the GIF describing the whole user flow:
5. Measure of success ⛳️
Now, to measure the success of this project, and to not just be judged on “taste”, but by the users who are the ones we design for, I feel the need to define some metrics that define if the project was a success or not, like this:
- How much time users used to spend on this flow before vs now? — do A/B test just for 30% of the users initially, or just one city that was recently launched.
- How many bookings were completed before vs now?
- How much time users are taking to select date and time vs now?
- Which screen in the flow has steeper drop rate?
- How many users who booked with this flow actually got that seat number?—if the tech side is working properly.
- The experience level increased from before? — if users are rating the experiences higher.
- Is the team happy for building it? — most important topic, because motivation leads to higher results
6. Next steps 🚴
This part is just fictitious :P but I would had planned it like this, if this was a real project.
- Discuss the proposed flow with all who are involved with the project — the ideal scenario would be one project manager, one person from content team or sales, and one lead developer. Make the necessary design changes on it based on collaborative feedback. Coordinate with the project manager for the deliverable timings.
- Send the designs on Zeplin to developers so they get all measurements needed to code. Also, send explanation GIFs showing screen transitions or small interactions. Work closer with developers on the last stage of development for design polish.
- Include new designs of the flow in the UIKit for future changes and to be re-used for other flows as well. Preferably using Abstract app or Brand.ai.
- While the developers are starting to develop this flow, do the rest of the design flow, covering all possible scenarios. Agile.
- Track the data of the current flow, before deployment, for comparison with data from the new flow. Make sure the success metrics are accomplished after 1 week of A/B testing. If bookings rate is going down, stop the project and do a proper user research, to try to understand what was the problem. Or, if the problem we were trying to solve is actually a problem. Still, celebrate for the learning acquired with this project.
- Watch the user behavior using screen recorder apps, like Hotjar. Make the necessary changes accordingly to what was observed and noticed as a problem.
- If it’s a success on the A/B testing, push it live for all users in a gradual process. If Headout retention rate is low, we can skip the gradual process and release the complete flow to all users. Tweet and share the design & development process on Medium. Celebrate, preferably with beers.
- Do small growth hacking experiments on the flow, trying to improve even more. Focused on showing discounts for particular dates, times or seats. Be persuasive, show to the user during the flow, things like “IN HIGH DEMAND! Booked 42 times in the last 24 hours”. See if incorporating the live support feature during this flow increases bookings, removing it may lead to save a lot of money and resources, if it’s not so efficient.
- Fix bugs reported by the users, or by internal observation.
- Extend this flow for other platforms, but remember that different platforms lead to different needs by the users, so a little bit of research is still needed.
Learned a lot while doing this project! Hope you guys like it or find it useful for your future projects. Feel free to reach me via twitter @imguic or check my professional path on Linkedin. Soon, you will be able to see my online portfolio at gui.world and much more active here, on Medium.
