Case Study
Redesigning Eventbrite's organizer experience
I tried to create an event on Eventbrite. It took me 7 screens of onboarding, a survey about my company size, and a phone number request before I could type a single event name. Then I looked at how Luma does it — one page, under a minute. That gap is what this redesign addresses.
14
UX issues found
7→1
screens to create
2→1
navigation systems
3
screens redesigned
The Problem
Powerful backend, frustrating frontend
I went through Eventbrite's entire organizer flow three times, screen by screen, applying Nielsen's heuristics. I found 14 issues. Three of them kept showing up everywhere — and they're all fixable.
Language chaos
The UI mixes Spanish and English within the same screen. Onboarding tags, form labels, editor headers, and buttons all switch languages unpredictably. Non-bilingual users are left guessing.
Lost user control
Clicking "Create from scratch" redirects to the AI creation flow after a 7-screen onboarding survey. The organizer came to create an event — not to answer sales-qualifying questions with no progress indicator.
Competing navigation
The event editor has two simultaneous nav systems: an icon sidebar and a text sidebar with collapsed sections. Green checkmarks appear on content blocks with no legend explaining what they mean.
Competitive Analysis
What Luma and Partiful do better
I created the same event on all three platforms. Luma took 45 seconds. Partiful took a minute. Eventbrite took over 10 minutes — and I'm a designer who knows what I'm looking for. Here's what the comparison revealed.
| Eventbrite | Luma | Partiful | |
|---|---|---|---|
| Time to create | Weak: 7+ screens, then form | Strong: Single page, <1 min | Strong: Single page, playful |
| Language | Weak: Mixed ES/EN everywhere | Strong: Consistent per locale | Mixed: English only |
| AI integration | Mixed: Separate flow, generic output | Mixed: On roadmap | Mixed: "Party Genie" — fun, not practical |
| Editor UX | Weak: Dual nav, card blocks | Strong: Inline WYSIWYG | Strong: Single scrollable form |
| Event page | Mixed: Rigid, shows competitors | Strong: 40+ themes, customizable | Strong: Playful, personality-driven |
| Dashboard | Mixed: Exists but buried | Strong: Clean, with traffic data | Weak: RSVP list only |
| Scale | Strong: Enterprise-ready | Mixed: SMB / community | Weak: Social / casual only |
Process
Mapping the gap between current and proposed
I mapped every screen an organizer touches from "I want to create an event" to "It's live." The current flow has three separate paths that all end at the same editor — but only after making you choose which one without explaining the difference. The redesign kills the fork.
Current flow — 11+ steps to publish
Proposed flow — 3 steps to publish
What happens to the onboarding data?
Eventbrite can infer event type, audience size, and pricing model from the actual event data — title, category, ticket setup, and capacity. No need to ask upfront. The organizer's first event IS the data.
Design Decisions
Four principles for the redesign
Every change I'm proposing has a reason behind it — and a business cost I'm aware of. I'm not pretending Eventbrite's current design is arbitrary. It's the result of real constraints. Here's what I'd change and why it's worth the trade-off.
Show, don't survey
Let the organizer see their event taking shape as they fill in details. No onboarding interrogation. Eventbrite can infer event type and audience from the actual event data.
Business tradeoff: The survey likely feeds Eventbrite's sales pipeline (qualifying organizers by scale and budget). The redesign proposes deriving this data from event behavior instead — less intrusive, same signal.
One language, always
The current UI mixes Spanish and English within the same screen — onboarding tags, form labels, and buttons switch languages unpredictably. This is an i18n audit finding, not a layout problem, so the redesign mockups don't address it visually. But it's the single easiest fix Eventbrite could ship today.
Why it's not in the mockups: The root cause is technical — some strings come from a CMS, others are hardcoded, and AI-generated content defaults to English. The fix is an i18n audit across the codebase, not a UI redesign. The mockups use English consistently as a reference language.
One navigation
A single, clear nav system. Tabs instead of competing sidebars. Every section earns its place at the top level — Marketing, Analytics, and Attendees are not hidden behind collapsed menus.
Business tradeoff: The current dual-nav likely reflects organizational structure (different teams shipping different sections). A unified nav needs cross-team agreement on information hierarchy — a design ops challenge as much as a design one.
AI as copilot, not autopilot
AI assists inline — suggesting copy, images, and categories — rather than generating a full event the user didn't control. The organizer stays in the driver's seat.
Business tradeoff: Eventbrite likely invested heavily in AI-powered event generation as a differentiator. The proposal doesn't remove AI — it redistributes it into the workflow where the organizer can accept, reject, or refine each suggestion individually.
Screen 1 of 3
Event creation in one page
The current flow requires 7 onboarding screens, a choice between manual and AI, a form, and then a generated preview. The redesign collapses everything into a single page with a live preview that updates as the organizer types.
- Removed: 7-screen onboarding survey, separate AI flow, phone number / company collection
- Added: Live preview panel, inline AI helpers ("Write for me"), auto-categorization from title
- Added: Progressive disclosure — advanced options (recurring, promo codes) behind "+ Add" buttons
Tickets
Category
Summer Music Session Barcelona
Enjoy a unique in-person gathering where music and good vibes come together. Come dance, sing, and connect with fellow music lovers...
Screen 2 of 3
One dashboard, one navigation
The current editor uses two competing sidebar systems and hides key features like Marketing and Analytics behind collapsed menus. The redesign uses tabs at the top level and makes the editor WYSIWYG — you edit directly on the preview.
- Removed: Icon sidebar, text sidebar, green checkmarks, 3-step stepper
- Added: 5 clear tabs (Page, Tickets, Attendees, Marketing, Analytics)
- Added: WYSIWYG editing — click to edit directly on the event preview
- Added: Quick stats visible by default (views, registrations, conversion)
Screen 3 of 3
The organizer's page, not Eventbrite's marketplace
The current public event page shows competitor events at the bottom, has a sticky sidebar eating screen space, and buries the organizer's identity. The redesign puts the organizer's event front and center — no distractions, no competitors.
- Removed: Competitor events ("También te podría gustar..."), sticky price sidebar, "How to get there" section, "Report this event" prominence
- Added: CTA at top and bottom (no sticky needed), category badge, organizer bio with other events, compact map
Why does Eventbrite show competitor events? Eventbrite operates as a marketplace — driving traffic between events increases total ticket sales. But from the organizer's perspective, this means paying Eventbrite to promote their competitors. The redesign proposes showing only the organizer's other events instead, keeping traffic within their ecosystem while still giving Eventbrite cross-sell data.
Music · Barcelona
Summer Music Session Barcelona
Free
About
Enjoy a unique in-person gathering where music and good vibes come together to create unforgettable moments. Come dance, sing, and connect with fellow music lovers in a relaxed atmosphere full of positive energy.
Highlights
Location
Carrer de València, 12 · 08015 Barcelona
Organizer
Nicolas Marciano
Music events in Barcelona · 1 event
Expected Impact
How I'd measure if this works
I can't A/B test this redesign — it's a concept. But I can define what success looks like. If Eventbrite shipped these changes, here's what I'd watch and why.
Time to first publish
Current estimate: ~15 min (7 onboarding screens + form + editor)
Target: under 3 min (single page, no onboarding)
Why it matters: Every minute of setup cost loses first-time organizers. Luma's under-a-minute flow is the benchmark.
First-event completion rate
Current signal: The 7-screen onboarding is a classic drop-off funnel. Each screen is a chance to leave.
Target: ≥ 70% of users who start creating finish publishing
Why it matters: An organizer who publishes one event is 5x more likely to publish a second.
Organizer return rate (30-day)
What to watch: Do organizers come back to create a second event?
Target: ≥ 40% within 30 days
Why it matters: Eventbrite's revenue depends on repeat organizers, not one-time users. A faster, less frustrating creation flow should improve retention.
AI feature adoption
Current: Separate AI flow that generates a full event the user didn't control
Proposed: Inline "Write for me" / "AI suggest" at the field level
Target: ≥ 30% of organizers use at least one AI helper
Why it matters: Adoption of AI as copilot (not autopilot) validates the D4 decision.
Reflection
What I learned and what comes next
This project taught me that the hardest design problems aren't visual — they're organizational. Here's what I'd do differently and what I'd need to validate.
UX problems are often org problems
The dual navigation system, the mixed languages, the onboarding survey that feeds sales — these aren't design mistakes. They're symptoms of different teams shipping independently. Fixing the UI requires cross-team alignment, not just a new layout. That realization shaped how I framed each design decision with its business tradeoff.
Heuristic evaluation has a ceiling
I identified 14 issues, but I can't know which ones actually hurt organizers the most. A power user managing 50 events/year might have completely different pain points than a first-timer. The next step would be 6–8 interviews with organizers across experience levels to validate and prioritize.
Accessibility as a design constraint
The WYSIWYG editor pattern (contenteditable, live preview sync) introduces significant a11y challenges — proper ARIA roles, keyboard navigation, screen reader announcements for live updates. In a production implementation, accessibility would need to be a first-class constraint from the start, not an afterthought.
Validating the hypotheses
Every design decision here is an informed hypothesis. Before implementation, I'd run moderated usability tests on the prototypes — specifically measuring time-to-publish and error rate on the single-page flow vs. the current multi-step flow. The metrics would tell us whether the redesign actually works, not just whether it looks better.