The challenge

Sell your tickets
anytime, anywhere

During 3 months in the summer of 2018 I was part of the team tasked with redesigning the ticket sell experience. As the lead UX designer I did research, UX and UI design and build all prototypes for the project.

Our primary goals starting out were:

1. Increase the amount of tickets offered by improving the sell flow
2. Have a great, consistent selling experience on any platform

We were working in 2 small teams with a product manager, designer and a few developers each. In our case any platform meant

First, User Research

During user interviews we found that lots of people had a story about either having to go home to sell a ticket on their desktop computer or asking a friend who was at home to do it for them.

They either thought it wasn't possible to sell from your phone at all (it was, but only through the apps) or they had tried and failed.

When we started looking at the flow, it was easy to see why.

The quickest way we had to sell a ticket on iPhone is shown below. The red part is where you leave the app, go to your email client, download your ticket to the files app, and go back to the app to finish the flow.

Other common problems included selecting which ticket to sell in a multi page PDF, some screens getting really long on a phone, and hard to find barcodes and page numbers.

It was our first major data driven project. Hanno's experience helped us integrate data in the product development process.

Looking at the data, it was of no surprise the upload step had the highest drop off in the whole funnel by far. We had a long list of other improvements we wanted to make, but if we could solve getting the tickets uploaded, it would have a lot of impact.

Our first experiment

We did some brainstorming sessions with the whole team, and came up with a bunch of different solutions;

• Better instructions on how to upload,
• Setting up an email address you can forward your tickets to,
• Making uploading the tickets the first step, so you don't get stuck

We quickly found out we made a lot of assumptions about how people store tickets on their phone. Of course, everybody in the team assumed everybody in the world did it the way they did it.

So I proposed starting with a lightweight experiment that would both help our users and would allow us to gather some data.

We wrote detailed instructions on how to upload from all the major sources we could think of and presented users with the question, where are your tickets?

We used a single sprint to build a simple instruction flow for the web version of the sell flow and started to gather data.

From data to insight

Turns out, most people keep their tickets in their inbox. Also, the majority of our users where using either Gmail or Outlook. A quick scan of our users table in the database confirmed this.

This is great, because it allows us to start thinking about how to improve the experience for users with this specific use case.

While investigating our options on how to get tickets out of your inbox, I realized the top 2 places people stored their tickets (Gmail, Outlook) where both email providers that have an API.

Since I have enough programming skills to be dangerous, I built a quick proof of concept authenticating and talking to the Gmail API.

This is what I love about having programming skills, it allows me to think of solutions that are hard to conceive if you don't know what's possible. In this case we quickly found out we could completely integrate Gmail into our flow, cutting out steps, and avoid sending users out of our app.

Time to prototype

I thought this was a great improvement over our existing flow, but it would be quite a lot of work to implement completely, especially to get the authentication and integration working smoothly in the app. On top of that some people in the team had concerns about privacy and were worried users would be afraid to use the feature.

So we decided to build a prototype in Framer. This took me a few days, but we put it to good use by observing users go through the flow and seeing most of them weren't concerned. This convinced the team this was worth building for real.

We also realized that once people where logged in to Gmail, a lot of other possibilities to make the interaction even smoother open up.

For example, we could download the tickets directly from Gmail servers to ours, making downloads fast, even if you phone is on a slow connection, like when you're already in line for an event and you get a last minute guest list (this was mentioned in our user interviews).

Next, ticket selection

Most of the tickets sold on TicketSwap are PDFs. And in a lot of cases these have multiple pages, which in turn can contain multiple tickets. Users don't always want to sell all of them, so one important feature is splitting the tickets for you and letting the user choose which ones to sell and which ones to keep.

We did a lot of iteration on this, and decided that this was a place where we could add some visual flair and animation.

In case we are sure we detected the event and barcode of your ticket correctly, we present you with this nice, bold visual interface to pick the tickets you want to sell.

Once we where happy with the basic flow, we worked with the development team to make high fidelity mock-ups of all the possible states.

There are a lot of different ticket types, some tickets have attachments, and we had to include a way to show the original ticket so users can double check.

Having the prototypes really helped getting the animations just right.

Results

The team did a great job implementing this and the number of tickets uploaded increased by over 10% in the first month after launch. On mobile the increase was even higher, and the number of users using the Gmail integration where so high we also build Outlook at a later stage.

Considering the flow we replaced had years of iteration and optimization and was know to millions of existing users, this was a great result to start with and we managed to squeeze out more improvements in the following months

What we learned

The main thing we got wrong is that we had product and design start at the same time as the development team. This led to a unnecessary pressure on the design team at the start of the project because there was not enough work for the developers. Next project we did a kick-off with the whole team, then started the design work and blended in developers as needed.

Secondly, we should have started thinking collecting data earlier. We had trouble getting statistically relevant results and had to move based on preliminary results sometimes.

Thanks

I had a lot of fun designing and prototyping this and was happy to use some of my product management skills from previous roles and got to improve my prototyping skills in Framer.

Thanks to the whole team at TicketSwap for doing a great job building this and getting it to work so smoothly for all our users across the world.

I still enjoy seeing the work we've done in action every time I sell a ticket from my iPhone.