Ticket transfers by Ticketfly

During this project, I was sole designer for all platforms related to consumer ticket transfers: iOS, desktop web, mobile web, email, consumer awareness, and help articles. I also designed backend support for clients in event settings. I collaborated on marketing, copy, BETA & wide release plans, help articles & assets, and user test sessions via Pandora's research lab.

The problems

Printing tickets

Concert-goers need a printer to print, they need to remember to bring the hard copies, and they need to coordinate with friends to meet up before the show.

Sharing digital tickets

Attendees are left checking barcodes or seat numbers during the entry process. Good luck reading those numbers and making sure you don’t double scan a friends ticket!

Friends can’t access tickets

Ticketfly does not know who your friends are when you buy tickets for them. This degrades the experience because Ticketfly or the venue can't contact them with updates or promotions.



It’s simple: type an email and send.

Sending a transfer request via iOS

Sending a transfer request via desktop web


Desktop web screens for sending a transfer request

Mobile web screens for sending a transfer request



I chose the widely adopted pattern of sending a token access through a generic link because this can also be applied to other methods of delivery like SMS, messenger, or AirDrop in the future. The transfer isn't tied to your friend’s email, but instead acts as a vehicle for delivering access to acceptance.


Transfer confirmation emails for the sender

Acceptance email & confirmation received by the transfer recipient



When they accept, Ticketfly will remove that ticket from your order and give your friend their own unique ticket. For me, this was a must have. At a music event, the last thing a concert-goer wants to do is parse through barcodes before entry.

Accepting a ticket transfer via iOS


Accepting a ticket transfer via desktop web

Accepting a ticket transfer via mobile web


Test, test, test

Being a subsidiary of Pandora from October 2015 to August 2017 has its advantages. I contacted peers I had worked with on Pandora integration projects and solicited a UX researcher's help in testing at Pandora's new research lab.

Setting up the test

  • People signed up in 2’s—some knew the person (simulating going with friends) and some didn’t know the person (simulating buying from stranger).

  • Required factor: must attend a music show yearly.

  • Testers used their own devices.

  • Some pairs were in the same room and some were in different rooms, but always in pairs. The test was broadcasted for the product team to watch live.

Outlining common tasks

  • Testers got to choose from 3 different events

  • They were instructed to purchase with a test CC

  • 4 pairs were to successfully transfer (happy path)

  • 3 pairs were instructed to transfer, then cancel

  • All pairs were to finish with a completed transfer


The two individuals were brought in the same room to give feedback together, common patterns or problems (mostly copy) were logged and fixed prior to launch, and main UX assumptions were confirmed as quality solutions.

Outlook after testing

The amount of testing in user research and in BETA, what I’ll mention later, were invaluable to the success of the product that we would not have otherwise known by keeping testing internal. The breadth of QA and perspective of feedback allowed this product to shine from all angles.

Testing allowed the team and I to talk to improvements, pivots, and design decisions made along the way in an unbiased manner to stakeholders and approvers in the company.


Educating consumers

For consumer awareness, the go-to-market team for transfers (myself included) chose to send a mass email letting consumers know transfers are live for clients who decide to turn it on for each event.

Writing code

The call-to-action in that email directed them to a page I built myself using html, css, and javascript.

Customer info page

This ticket transfer information page takes a deeper dive for a consumer to learn more about how ticket transfers work. I intentionally designed it to be a hub for all things transfers, including a link to FAQs for sender & receiver, and a link to a user’s account, where they will be prompted to sign in and see their orders.


Ticket transfer information page on web


Client adoption

BETA launch

We discovered minor bugs during the first 100 transfers with BETA clients for hand-picked events that wouldn't have otherwise been found doing controlled tests on our own.

Wide release

We ramped up to 100% on web and pushed transfers to the iOS app for wide release in just 3 short months of BETA.

Dependencies for mass adoption

For clients to enable transfers on 100% of events, it would depend on how well this initiative fights fraud. Transfers will fight fraud more successfully if consumers are educated and make smart decisions about how they obtain their tickets. There are a lot of known dependencies like this for 100% adoption by clients and consumers.


In the 3 short months since the June 2017 launch, we have seen a 34.6% conversion in transfer requests on the sender side for a total of over 1700+ transfers successfully completed. We continue to average around 40-70 transfers per week across the US. Our platforms continue to be split to approximately 95% revenue on web and roughly 5% on iOS. Transfer adoption by consumers on each platform tends to be similar, with a majority of senders on desktop web and a majority of receivers on mobile web. We also have hooks into our system to monitor health, so if transfers were to decline, we would be able to pinpoint the reason.