Ticket
Reservation
for INWEGO
The Problem
According to user feedback, our users didn’t know about different ticketing types or add-ons, which negatively effected non-subscription revenue, especially revenue from guest tickets, which is higher margin product.
Users also expressed that there is a difficulty in reserving popular events. There are only a limited number of tickets available and tickets end up going to the users with the fastest fingers.
Additionally, there were also 7 ticket types and each ticket type had it’s own reservation flow which further complicates the ticketing process.
The Challenge
Is there a way to prominently display add-ons or guest tickets?
Is there a way to combine or condense the various reservations flows?
How much faster and simpler can we make the entire experience of reserving a ticket?
Exploration
Initially, I went with the shopping cart approach, in which you present the user with all available ticketing types and tapping each ticket will take you into the respective flows and quantities update once done.
However, this approach still felt a little bloated. This approach still doesn’t solve the issue of time. Because the main user must first reserve their ticket using their credit before gaining the ability to purchase other ticket types, users might end up in an edge case where they return to the main view to reserve their add-on tickets and the event has sold out.
After another brainstorming session, we identified some key points:
All tickets are treated the same in the back end.
Users are only concerned with quantity, price, and reason for final price.
The Solution
Option A: One-Step Slider
This option simplifies all tickets types into one flow. To reserve 3 tickets of any type, the user only has to select a quantity and any associated cost will appear.
Option B: Multi-Step Solution
Current users are used to ‘activating’ their initial tickets before being able to add on any additional tickets. This option builds upon the shopping cart approach from earlier while also keeping a few features from the original design with the goal of not alienating current subscribers.
Validating Through User-Testing
I was very certain that Solution A was the best path forward but utilized A/B Testing to make sure I wasn’t biased. After processing the results, it ended up being too close to call. However, the open-ended questions showed a slight affinity towards Option A. This coupled with how Option A moved guest ticketing, a high margin product, to the initial step in reservation led to the consensus that Option A is the best path forward. See Raw Data Here
