Improving TicketSwap's sell flow across platforms
I owned TicketSwap's sell flow, designing across four surfaces: web desktop, web mobile, iOS, and Android. Over that period, ticket listing completion went from 48% to 60%, alongside a 25% increase in ticket sales.
Results
- 48%60%
- Ticket listing completion
- 25%
- Increase in ticket sales
Context
The sell flow performed very differently across platforms. Web converted at 54%, compared with 27% on iOS, even though iOS generated approximately 44% of listings. Around 69% of sellers in one observed month were selling for the first time, so the experience needed to support people who were unfamiliar with the process.

Publishing also involved requirements beyond usability, including ticket verification, payments, identity checks, and fraud prevention. The challenge was not simply to shorten the flow, but to help more legitimate sellers complete it without compromising marketplace safety.

My role
As the product designer who owned the sell flow, I worked with product, engineering, data, fraud prevention, and support. I investigated funnel performance, connected quantitative and qualitative evidence, and designed changes across the seller journey, which let the team decide which problems to solve first.
Constraints
The flow had different implementations and performance across web, iOS, and Android. Upload behavior varied by platform, while several verification, payment, and fraud-prevention requirements could not simply be removed.
We used two analytics tools that didn't show the same results, so we had conflicting explanations for the same drop-off. We needed a more reliable understanding of the funnel before committing to major changes.
How we diagnosed it
Together with data and engineering, we clarified how critical funnel events were measured. Combining that with support's knowledge and usability sessions, we had a more complete view of where sellers struggled and why.
This allowed us to challenge one of the team's main assumptions. KYC had been introduced around the time overall completion declined, making it a convenient explanation. But data showed 98% completion at that step, indicating that KYC added complexity but was not the primary bottleneck.

Uploading was a stronger opportunity. Only 69% of sellers completed it on iOS, compared with 87% on web, and upload verification was the largest source of sell-flow related support contacts. Sellers could experience long processing times, technical failures, unclear messages, and automated reminders that returned them to listings they still could not complete.
Where I put the effort
I focused on helping sellers understand and recover from upload problems rather than treating every failure as a reason to redesign the entire flow. Together with the support team, we integrated Intercom into the upload-error experience, initially on web. This gave sellers access to assistance when the problem occurred instead of requiring them to leave the flow and find support independently.
I also worked on making system states and error messages more actionable. Usability sessions showed that “can't be sold” sounded like permanent rejection, while “for sale” could make sellers believe their ticket was already live. The experience needed to communicate what happened, whether the issue was recoverable, and what the seller should do next.

We also identified that automated reminders were encouraging sellers with unresolved errors to return to the same blocked listing. By connecting product behavior with support evidence, we treated recovery as part of the experience rather than something that happened outside the product.
Outcome
Over the period, the team took completion from 48% to 60%, contributing to a 25% increase in ticket sales. That came from many small releases across several quarters on four platforms, not from one redesign, most of them invisible on their own.
We addressed the two worst problems in the funnel: upload failure and error recovery. We didn't get to everything. Listing creation time stayed at 13.5 minutes against a target of 10.
What I'd do differently
My contribution was helping the team move from assumptions and isolated signals toward evidence-based prioritization, then focusing the product experience on upload failure and recovery.
If I approached the work today, I would establish consistent cross-platform instrumentation earlier and define success metrics for each intervention before development, so we'd have a better understanding of which change had which impact.