What if a user with 100 tickets could assign them in several clicks instead of hours of manual work?

Slush is a tech event that brings together startups, investors, and large corporations under one roof. Its in-house platform provides attendees with tools for event planning and preparation.

My work focused on redesigning the Ticket Management feature and turning it into a dynamic flow that would serve both the users with 1-5 tickets and users who are managing 50+ tickets.

key outcomes overview

Research-led redesign based on analytics, interviews, and testing.

Fully re-designed main flow with a table view.

Bulk ticket management through a CSV upload.

New features: Platform profile checker, ticket print status and assigning history.

PROJECT
CHALLENGES

Challenge 01

Years of accumulated demand

Challenge 02

Support inbox as a symptom

Challenge 03

A design system still finding its shape

Challenge 04

One interface, vastly different users

What the existing data already told us

Stakeholders agreed the ticket management tool needed a redesign, but not on which features specifically. I relied on secondary research to validate that; post-event feedback surveys, user interviews, and the support inbox already held enough signal to scope the problem without running new primary research.

From support inbox patterns to a shipped redesign.

Stakeholders agreed the tool needed a redesign, but not on which features. The first step was scoping the problem against a user base with vastly different literacy levels, ticket volumes, and workflows.

Research & Validation

Research

& Validation

Concept Validation & Prototyping

Concept Validation

& Prototyping

Design System Components

UI Design Across 60+ Screens

Handoff

Research & validation

Post-event surveys, user interviews, and the support inbox provided enough signal to scope the problem without new primary research. Competitor research extended beyond ticketing tools into CRMs and general data-management patterns to account for that variance in user literacy.

Eploration & testing

Initial concepts were validated before moving to full-fidelity prototypes. Cursor accelerated the exploration stage, allowing faster iteration across the two core patterns: editable tables and CSV import.

Design system & handoff

A custom table component built with slots gave the young design system a scalable foundation; it's already used across three other projects. Handoff included both a standard and animated prototype alongside a Notion file covering priorities, edge cases, and access specifications.

Dynamic solution for very different kinds of users.

The ticket overview moved from a static widget on the Home page to a dedicated dynamic page. The default view adapts based on how many tickets the user holds, so an organizer managing fifty sees a different layout than a first-timer with one; no content is hidden, just reordered.

Bulk ticket assigning through CSV

Bulk-purchase customers manage upwards of 100 tickets, often assigning them to people outside their own organization. Their primary mode of operation is CSV files, so the solution had to meet them there.

Catching errors before they cost support tickets.

Before the user commits to assigning the batch, the system flags every error in the upload. Rows can fail for reasons within the user's control (a malformed email) or outside it (the recipient already holds a ticket). The user reviews the errors and either fixes them or proceeds with only the rows that passed. This turns an automated action into a user-controlled one; no ticket moves without the user knowing exactly what happened and why.

How do you track all the bulk assigns?

Managing tickets in bulk can be stressful. Assign History lets the user return to a specific batch, track it directly, or make changes if something went wrong.