Case Study 01 · Ticket Attendant
Concourse: reimagining a complex ticket consignment platform.
We took a slow, convoluted platform and reimagined it for the brokers' unique needs: lots of data and analytics. Using information hierarchy and lots of testing and research, with the developers we made a performant, intuitive tool they love to use.
Role
UX Designer
Team
2 UX designers + 2 developers
Product
SaaS ticket consignment
Users
Professional ticket brokers
Platform
Mobile + Desktop
Timeframe
2 years
Overview
A powerful tool, but a difficult user experience.
Ticket Attendant is a SaaS company that makes and supports ticket consignment platforms used by ticket brokers to manage inventory across the entire life cycle of a ticket, from importing, pricing, and broadcasting listings, to delivering orders, and analysing the results.
The existing platform did all of that, but it was also notoriously difficult to use with unbearably long load times of up to thirty seconds. Clients found the interface outdated and confusing, and the reliability problems quietly undermined their confidence in the data itself.
Collaborating with our development team, we determined the most effective route to build a reliable, performant tool was to rebuild the experience from the ground up. The goal was a faster, more intuitive product that kept every bit of the data depth this audience depends on.
The Challenge
Three biggest pain points.
- Slow performance. Screens took twelve seconds or more to load, occasionally reaching thirty.
- Poor usability. Navigation was difficult, and users complained about the experience consistently.
- Lack of reliability. Inconsistent behaviour and frequent server outages made people question whether the data was accurate and whether the platform could be trusted at all.
Underneath the usability problem sat a business question: how do you attract and maintain a client base? Clients were leaving in favor of competitors because of friction. Solving these issues would keep the clients we had and win the ones we didn't.
I wanna know: what's my take-home pay? How do I know if something's a good buy?
Ticket Attendant superuser
Understanding the Users
Mapping the ticket lifecycle.
We interviewed stakeholders, clients and operations staff, and mapped the whole lifecycle of a ticket:
01
Import: automatic or manual
02
Pricing
03
Broadcasting
04
Sale
05
Order delivery
06
Reporting
That showed us not just which features people used, but when, why, and what information they needed at each stage.
The research revealed that Ticket Attendant users are intensely data-driven. They often are working across multiple monitors with multiple spreadsheets, stadium maps and analytics tools open at once. They are not asking for a simpler product in the traditional sense. They want any and all of the information they need to make better decisions, and they want it quickly, and reliably.
The questions they ask over and over:
- Is this inventory worth buying?
- What is the most competitive price?
- What is likely to sell How did it sell last time?
- Which way is the market moving?
- How do I respond faster than my competitors?
- What is happening across my whole inventory?
- What sold today? What is my take-home pay?
Simplicity ≠ good design. How do we give them all the data they need in a way that makes sense? What data do they need when and where?
Defining the Opportunity
Balancing three perspectives.
Business
Ticket Attendant needed to attract and retain clients with a product that felt modern, reliable and worth paying for. Profit through trust.
Technology
The platform had to handle large volumes far more efficiently. Engineering explored pagination, lazy loading and server optimisation. Fast and reliable.
User Experience
Working out what information people actually needed at each stage and designing the most efficient way to reach it. Beautiful, intuitive, and enjoyable.
The Design Challenge
How might we increase trust and adoption among ticket brokers by creating a faster, more intuitive and modern platform experience that communicates reliability and makes complex ticketing data easier to navigate?
Designing Concourse
Start small. Think big.
Prioritise
We studied which screens duplicated information, combined similar features, and shipped strong defaults with customisation behind them. The first MVP covered the two workflows brokers most needed away from their desks: pricing and broadcasting. A prioritisation matrix weighed user impact, business value, technical feasibility, effort and performance. It stopped us redesigning everything at once, and gave the whole team a shared framework for saying no.
Go mobile first
We adopted the "mobile first" strategy for managing complexity. A small screen forces the essential question: what does the user actually need right now? If we couldn't make a workflow understandable on a phone, the workflow itself needed questioning. It's much easier, and much more efficient to make small things bigger than condesnse beautifully laid out desktop screens to fit a phone.
Go desktop second
Once we had our mobile lay out, it was much simpler to take those and expand them to fit a desktop screen size. We used the same visual language and components which was part of our mobile-first strategy to make things only once.
Measure adoption, not completion
As soon as we had the mobile app out to production, we tracked daily logins per user and unique logins across the legacy platform, the old mobile app and our new mobile app. New app logins drastically outran the old app enough to sunset the legacy mobile product! But new desktop app logins were less than expected. Why? What was the barrier to adoption?
From Mobile to Desktop
What was the barrier to adoption for desktop?
Users loved the mobile app, but there was still a bit of a delay to adoption for the desktop app. Time for more research. We expected the streamlined mobile approach to translate naturally to the bigger screen, but the users were finding the interface a bit lacking. The simplicity they had appreciated on a phone felt restrictive on a desktop.
They thought more data should be displayed. They found some features and information to be hidden. That taught us something worth more than the feature it produced: responsive design isn't about making the same interface fit different screen sizes. Context matters enormously. On mobile, brokers needed to price, broadcast, and quickly check if something sold. On desktop, they wanted visibility and comparison. They wanted their old spreadsheets, more inventory compressed into more space, more attributes, more information at once so they could spot an opportunity and move. More, more, more!
Our first assumption to simplify was not what they wanted. We took their feedback and built a comprehensive grid view, showing far more at a glance. It turned out to be the single critical adoption barrier. After it shipped, adoption jumped to 70%.
They liked the new look a lot, and some of our design choices they really enjoyed — but it was really about seeing the data all in one place instead of hiding it that made the difference.
For this audience, more information wasn't the problem. Unorganised information was.
The Design Insight
Complexity can be a feature, not a bug.
One of the biggest lessons of this project was that the conventional UX instinct to simplify and minimize isn't always the right answer. It is important to consider each niche of users and their unique needs when designing. No solution is one-size-fits-all.
Ticket brokers are sophisticated, highly data-driven users. They use information to spot opportunities, assess risk, price inventory and get ahead of competitors. They don't necessarily want a product that hides complexity, or dumbs it down. They want a product that makes them feel capable of handling the large swath of information they like considering.
The solution was improving hierarchy without deleting information, creating efficient workflows, and giving them the level of detail appropriate to the context someone is working in. Action menus were streamlined to offer the right actions at the right moment, instead of the same long list on every page.
Outcome
A new foundation for Ticket Attendant.
What the team did
- Created a mobile-first product foundation
- Prioritised high-value workflows over breadth
- Simplified complex mobile workflows
- Used adoption data to steer what came next
- Worked with engineering on strategies for handling large data volumes efficiently
- Adapted the desktop experience on customer feedback
- Introduced a comprehensive grid for data-heavy desktop work
The arc, in short
- Pain points: slow, cumbersome, outdated.
- First strategy: combine pages, better defaults, a reliable back end.
- Result: noticeably faster but over-simplified.
- Revision: compress the view and add more info into it to satisfy both stakeholders and users.
- Landing: 90% adoption of the new platform, then production, feedback and KPI measurement driving continuous improvement.
Reflection
What I learned
This project changed how I think about complexity in UX. It's common to equate good UX with minimalism. General population users tend to prefer fewer screens, fewer fields, less information, and reduced cognitive load. However the Ticket Attendant work showed me that the right amount of complexity and data depends on the user and the context.
The same person wanted a streamlined experience on their phone and significantly more information on their desktop. Neither version was better, per se. The difference was what they were trying to accomplish in each context.
It also reinforced three habits I'll carry into the next thing I build: design around real workflows, validate assumptions with the people who live in them, and treat constraints as design problems rather than something to consider after the design is done.
Next case study