Rebuilding event creation for producers
Creating an event on TicketMax runs through thirteen steps. I redesigned several of them. Two are worth walking through: step 3, where producers set the venue and dates, and step 5, where they define tickets and pricing — the step where the complexity concentrated and where people got stuck.
Both had the same underlying problem, so both got the same treatment: stop making the producer think in the system's terms.
Tickets and pricing
The problem
Ticket setup means configuring ticket types, sectors, price tiers, date-based pricing and capacity limits, all of which interact with each other. The original screen exposed that structure directly.
It opened by explaining its own data model: which entities were global, which were nested, how they referenced one another. Fields carried internal vocabulary — products, modalities, price matrix, lot ref L1. Several pointed back to decisions made on other screens: "linked sector (Step 4)", "general capacity per date (Step 3)". To fill in one field, a producer had to hold two earlier screens in their head.
Every product rendered fully expanded and stacked, so an event with four ticket types became a long scroll with no visible structure.
The date selector was a multi-select dropdown requiring one click per date. For a long-running event, configuring a single price meant dozens of clicks.
Constraints
The redesign had to preserve the existing configuration model. The underlying entities and the settings producers had already saved could not change — this was a redesign of how the system is presented, not of what it does.
Events already selling added a second constraint: some settings can no longer be edited once tickets have been sold, and the interface had to handle that without producers running into dead ends.
What I changed
I replaced the system's vocabulary with the producer's.
The step went from Products, Lots and Modalities to Tickets. The explanatory paragraph about the data model disappeared, and so did the cross-references to other steps: what a producer decides here is now decided here, without needing to remember screen 3.
I turned the pricing model into a question.
This was mostly a UX writing decision. Instead of asking producers to assemble a "date group and price matrix," the screen now asks: does this ticket cost the same on every date, or does it change by day? Two options, in plain language. The system underneath is just as complex — it simply stopped being the producer's job to model it.
I made bulk date selection possible.
The dropdown became a calendar where clicking a weekday header selects every occurrence at once. This came from clients running long events, for whom the original interaction was effectively unusable.
I made state visible instead of surprising.
Price tiers became tabs rather than stacked blocks. Products collapsed into a reorderable list with a colour marker and a capacity badge, so the structure of an event reads at a glance. Advanced settings moved behind a disclosure. And where a field is locked, the screen now explains why: "this product already has sales — the type can't change."
Venue and dates
The problem
This step asked producers for latitude and longitude — as two empty text fields, positioned above the address. The address form came after, with a button to derive the coordinates from it. The screen asked for the technical output first and the human input second.
It also opened with a note defining general capacity per date in terms of the system model: which entity was the physical ceiling, how sectors in step 4 subdivided it, what happened when a producer skipped sectors. Further down, a checkbox offered to allow overbooking between sessions on this day, explained through child sessions decrementing a bucket.
At the top, where a producer would look for the event they were working on, the screen showed a draft UUID.
What I changed
I inverted the order of input.
Producers now start with the venue name and address, and the coordinates fill themselves in. The map confirms the result — location confirmed on the map — and the technical fields move behind a secondary action for the rare case where someone needs to adjust them by hand. The information did not disappear; it stopped being the first thing asked.
I replaced the draft UUID with the event's name and a save status.
Producers now see what they're editing and that their work is safe.
I turned a hidden decision into an explicit one.
How buyers pick a date — date buttons, a monthly calendar, or grouping by weekday — used to depend on configuration elsewhere. It is now a choice presented in the step, with each option explaining when it fits: few dates, many dates, recurring events. The producer makes the decision with the consequence visible.
How it was made
I designed and prototyped these screens in Claude Design, iterating on the layout and the flow there before anything was built, and handed off through Claude Code to the tech lead.
Where it stands
The redesigned step is live on the platform.
What's still not solved
Guiding a producer through the new flow, I watched them get stuck again — not on the pricing or the dates, but on the idea of a product itself.
My hypothesis is that the screen starts with a product already half-created, so it isn't obvious that you're building something from scratch. Adding a product should be a deliberate action the producer takes, and the fields inside a product should be phased rather than presented all at once. Ticket configuration is genuinely complex, so the goal isn't to make the complexity disappear — it's to keep finding better ways to walk someone through it.
That's the next revision of this screen, and it's what I'm working on now.