The Raffle

Product designer

TicketSwap is a marketplace for second hand e-tickets. Most people come to TicketSwap if the official ticket sale has been sold out. Because it is sold out, there is often a huge demand for tickets while the supply is low. People enable ticket alerts if there are no available tickets when they visit the platform. A ticket alert is a push notification that will be send as soon as a new ticket becomes available.

The tickets are sometimes in such high demand that thousands of people are waiting for a notification and immediately tap on it. Currently the first person to press the buy button will reserve the ticket in their cart, leaving the other people disappointed.

People lose trust in our system after trying many times. They think bots are getting all the tickets or that our app is broken. Another frustration is that they have to spend a lot of time on their phones being ready to tap the push notification and the buy button.

This experience is the most frustrating part of TicketSwap. A lot of users complain about it on social media, in reviews, and to our support team.


  • Reduce frustration of users when trying to get a ticket.
  • Give all users a fair chance to get a ticket.
This is the experience of most people after tapping on a notification. The ticket is already being paid for.

Understanding our current technology

We started our research by investigating how our current system exactly works. We’ve also looked at what was tried previously. We learned that the system is sending the notifications out in batches. The batches are added to a queue. It can take as much as 2 minutes before the last notification is sent out. The tickets are often already reserved within those minutes. Because of this a lot of people open the notification for nothing.

In the past we've also tried to not notify people if a ticket was already reserved. This resulted in users thinking their app wasn't working properly.

We also confirmed our assumption that older devices have a lower chance of getting a ticket. The listing page will take longer to load and so the button can only be pressed later. The same applies to people with a slower internet connection. We thought this was not fair and also wanted to solve this issue.

This part of the research added the following requirements to our solution:

  • It can take up to 2 minutes to send out all ticket alerts. This is the minimum time we should wait before making the ticket available to buy.
  • We have to sent a notification to every user that enabled ticket alerts. Even if the ticket is not available anymore. When we don't do that people will think their app is not working properly.
  • The solution must be independent on the quality of the device or network being used. This is required to make the solution fair.
High level visual representation of how ticket alerts are being send out.

What users are doing right now to get tickets

After researching our technology we started investigating what our users are doing right now. By interviewing our users and looking up data we found out three patterns:

  • They tap on the place where the notification appears and on the place of the buy button while waiting for a new ticket alert to pop up.
  • They refresh the event page and wait for a listing to appear.
  • They try to use bots, which is unfair to other users.

Except for the users that are trying to use bots, and risking a ban while doing that, we confirmed that a lot of frustration is caused by endless refreshing or tapping in the pursuit of a ticket.

We added two new requirements to our solution:

  • The solution should decrease the effort and time the users have to put into getting a ticket.
  • A nice to have is that the new solution decreaeses the problems of bots. We threaded this as a nice to have because there are also other ways to do this than by changing the system.
Currently the highest chance of getting a ticket is by tapping on the spot of the notification and where the buy button will appear.

Possible directions

Except for researching our own technology and user behavior we also did an extensive benchmark. We looked at what our competitors are doing but also at how other situations with high demand and low supply are handled. After this we went into brainstorming directions. We filtered out three viable directions.

  • A first come, first serve approach in the form of a waitlist: The first person that subscribes to the list, will get the first ticket that becomes available.
  • A lottery approach: Tickets that become available will be randomly distributed.
  • An auction: The highest bidder gets the ticket.

The first come, first serve approach could decrease the growth of our platform. This because the length of a waitlist will make it impossible for new users to get a ticket. A lottery approach is interesting but can also be very demotivating because of the lack of control and low chance of getting a ticket. The auction was quickly dismissed because at TicketSwap the selling price is capped at 120% of the original price. We do this to reduce scalping and keep prices fair. In an auction there would simply be way too much bids of the same maximum price. Based on these arguments we decided to first take a look at the lottery direction.

The concept

After a lot of brainstorming, sketching and ideation we came up with a concept called: The Raffle.

With the new concept we will hold a raffle for every listing. The raffle will be drawn within 2 minutes after the creation of a new listing. This ensures that the seller also has a quick selling experience. During the draw we will show everything that is going on to keep the process transparent.

For every ticket inside the listing a winner will be picked at random. Losers will have more chance to win the next raffle. Increasing the chance of the losers, and making this visible, is a reward for putting in effort to get a ticket.

Happy path the raffle concept

Design, Prototype, Test, Repeat

Now the next challenge is to explain the concept of a raffle in a short and clear way to our users. After sketching out different ways to do this we jumped into a few intense days of designing, prototyping and testing.

During this phase we focused mainly on creating the flow that explained how the raffle works in a non-frustrating way. We also wanted to make sure that people perceived the raffle as a fair way of distributing tickets.

We tried to explain the raffle in a lot of different ways. The conclusion of our user tests was that people understood the concept the best by experiencing it. During the experience we are giving short explanations.

A few of the different prototypes that aim to explain the concept to the user.

The biggest win in clarity was made by changing the visual representation of the chance to win. We first used a thunder icon and called it a "chance boost". Later we changed this to a four leaved clover. The clover is a symbol of luck used in many countries across the world. The four leaved clover immediately made it clear that it was about increasing luck. The thunder icon gave the impression that the user with the highest score always wins.

In the first iterations we visualised the chance of winning with a small thunder icon. After changing it to a four leaved clover the concept became much more clear.

The result

Our plan to release the feature during the festival season of 2020 fell in the water because of corona. Luckily there were a few events with tickets in high demand where we could test the feature. Below are two videos of how it looks when you win, and of how it looks when you lose.

These tests went very well and we got quite some enthusiastic responses. During these tests we collected valuable feedback that we are going to use for the launch version of the raffle. Hopefully we will launch it in 2021 when events get started again. Once it's released I will definitely add any metrics and reactions from users here.

Next case