Enterprise CMS

Ignite Modules

Ignite Modules

Giving 80+ enterprise clients direct control over their live content, without a single engineering ticket.

Giving 80+ enterprise clients direct control over their live content, without a single engineering ticket.

My Role

Sole Designer, End-to-end Ownership

Scope

Product Design · UX Strategy · Enterprise CMS

Platform

Live Entertainment · Enterprise B2B

Outcome

80+ clients · 250+ modules · 0 support tickets

Ignite Modules - Listing Page & WYSIWYG Live Preview

The Problem

Clients couldn't touch their own content without engineering.

Ticketmaster's fan app serves 30M+ monthly active users. Every piece of client content inside that app, upsell modules, venue directions, concessions, event info, was locked behind engineering. A copy change, a CTA swap, a module reorder: all of it required a support ticket, sprint capacity, and a wait.

Ticketmaster's fan app serves 30M+ monthly active users. Every piece of client content inside that app, upsell modules, venue directions, concessions, event info, was locked behind engineering. A copy change, a CTA swap, a module reorder: all of it required a support ticket, sprint capacity, and a wait.

For event organizers with tight go-live windows, that dependency wasn't a workflow inconvenience. It was a revenue problem. Real-time upsell revenue depended on clients updating content fast, but they couldn't touch a thing without filing a ticket.

For event organizers with tight go-live windows, that dependency wasn't a workflow inconvenience. It was a revenue problem. Real-time upsell revenue depended on clients updating content fast, but they couldn't touch a thing without filing a ticket.

The workflow gap that Ignite Modules was built to close

DISCOVERY - WHAT WE HEARD

The brief said "build a CMS." Clients told us the real cost of not having one.

Before wireframes, I spoke with clients across venue types to understand how the dependency on engineering was affecting their work. Two distinct pain points emerged, not one. Speed was the obvious problem. Confidence was the hidden one: clients had no way to see what a change would look like until it was already live in front of fans.

Before wireframes, I spoke with clients across venue types to understand how the dependency on engineering was affecting their work. Two distinct pain points emerged, not one. Speed was the obvious problem. Confidence was the hidden one: clients had no way to see what a change would look like until it was already live in front of fans.

Key Insight

Two problems, not one: speed (changes took days to weeks through engineering) and confidence(no way to preview the output before publishing). A form-based CMS would solve speed. Only a live preview would solve confidence. This distinction directly drove the WYSIWYG decision.

"Every copy change, every CTA swap, I have to raise a ticket and wait for the next sprint. By the time it's done, the moment has passed."

Event Organizer, Live Venue Client

"I'm working on tight go-live windows. If I can't update content the night before, I'm leaving revenue on the table."

Client, Sports Venue

The worst part isn't the wait, it's that I have no idea what it's going to look like until it's already live for 30 million people.

Enterprise Client, Multi-Event Operator

"I need to be able to reorder modules based on what's happening at the event. Right now that's a two-week process."

Client, Ticketing & Upsell Manager

Discovery artifacts - Pain point mapping

THE UX DECISION THAT MATTERED MOST

WYSIWYG over forms.

Two configuration models were explored. The form-based model had the client filling fields: title, description, CTA, with no way to see the result until after publishing. That meant clients had to hold the final UI in their heads while configuring. They couldn't know if it looked right until it was already live.

Two configuration models were explored. The form-based model had the client filling fields: title, description, CTA, with no way to see the result until after publishing. That meant clients had to hold the final UI in their heads while configuring. They couldn't know if it looked right until it was already live.

The core insight: imagination is a tax on the user. Any interface that requires you to imagine the outcome is harder to use than one that shows it to you. WYSIWYG removes that tax entirely. Clients see the fan-facing output update in real time as they configure, no gap between input and result.

The core insight: imagination is a tax on the user. Any interface that requires you to imagine the outcome is harder to use than one that shows it to you. WYSIWYG removes that tax entirely. Clients see the fan-facing output update in real time as they configure, no gap between input and result.

"The form model asks you to imagine. WYSIWYG removes imagination from the equation."

"The form model asks you to imagine. WYSIWYG removes imagination from the equation."

TESTED - REJECTED

Form-based configuration

  • Requires clients to imagine the output

  • Cognitive gap between input fields and final result

  • No confidence check before publishing

  • Higher abandonment, clients unsure if it looks right

CHOSEN

WYSIWYG live preview

  • Clients see the fan-facing output as they configure

  • Zero gap between input and result

  • First interaction doubles as onboarding, no tutorial needed

  • Modular guardrails keep brand consistent across clients

Second decision: modular guardrails over open customisation. Giving clients complete design freedom would have produced inconsistent, off-brand experiences, and an immediate surge in support requests to fix them. Guardrails aren't constraints on the client; they're constraints on the problem space. Clients get enough control to move fast. The platform maintains consistency at scale.

Second decision: modular guardrails over open customisation. Giving clients complete design freedom would have produced inconsistent, off-brand experiences, and an immediate surge in support requests to fix them. Guardrails aren't constraints on the client; they're constraints on the problem space. Clients get enough control to move fast. The platform maintains consistency at scale.

Left: Form model (requires imagination). Right: WYSIWYG live preview (shows the output in real time)

EARLY EXPLORATIONS

Three directions we considered - and why we moved past each one.

Before landing on the WYSIWYG model, three layout and interaction directions were explored. Each solved part of the problem. None solved all of it. The explorations were critical, they made the final decision obvious rather than debated.

Before landing on the WYSIWYG model, three layout and interaction directions were explored. Each solved part of the problem. None solved all of it. The explorations were critical, they made the final decision obvious rather than debated.

Direction 01 - Dropped

Tabbed from panel

Clients had to navigate across tabs to configure a single module. Context switching increased errors and slowed down the configuration flow significantly.

DIRECTION 02 - DROPPED

Modal-based editing

Each module opened a full-screen modal. Lost context of the listing view. Clients couldn't see how one module related to others while editing. Felt disconnected.

DIRECTION 03 - SHIPPED

Inline panel + live preview

Side-by-side panel kept listing context visible. Live preview closed the confidence gap. Clients could configure and verify in a single view, no tab switching, no modals.

PHASE 2 - EXTENDING THE SYSTEM

Once clients had self-service, they immediately wanted more control.

Phase 1 shipped and worked. 83 clients onboarded. Zero support tickets. Within weeks, the feedback signal was consistent: clients wanted to target specific content to specific fans, not broadcast the same module to everyone.

Phase 1 shipped and worked. 83 clients onboarded. Zero support tickets. Within weeks, the feedback signal was consistent: clients wanted to target specific content to specific fans, not broadcast the same module to everyone.

The Phase 2 brief was audience segmentation. Three completely different use cases needed to be designed for. The architectural decision: build everything on Phase 1's component foundation, not alongside it. New capabilities would extend what clients already knew, no new mental model, no relearning.

The Phase 2 brief was audience segmentation. Three completely different use cases needed to be designed for. The architectural decision: build everything on Phase 1's component foundation, not alongside it. New capabilities would extend what clients already knew, no new mental model, no relearning.

SEGMENTATION TYPE 01

Entry-based

Show or hide modules based on whether a fan has scanned into the venue. Pre-entry and post-entry experiences can be entirely different.

SEGMENTATION TYPE 02

Location-based

Target modules by Price Code and Seating Section. A premium suite sees a different concessions module than general admission.

SEGMENTATION TYPE 03

Account Groups

Segment by fan account group, season ticket holders, partner members, each seeing content configured specifically for them.

The hardest design problem in Phase 2: make segmentation invisible when unused, instantly intuitive when needed. A client who never segments shouldn't encounter any friction. A client who wants to segment should find it immediately, understand it without documentation, and configure it without error. The same panel serves both, progressively disclosed, not hidden.

The hardest design problem in Phase 2: make segmentation invisible when unused, instantly intuitive when needed. A client who never segments shouldn't encounter any friction. A client who wants to segment should find it immediately, understand it without documentation, and configure it without error. The same panel serves both, progressively disclosed, not hidden.

Phase 2 segmentation panel: Location Based, Audience Based, Entry Based. all surfaced in the same progressive UI

THE ARCHITECTURE DECISION

Phase 2 built on Phase 1. Nothing rebuilt.

The reason Phase 2 shipped cleanly, and without touching Phase 1's component architecture, was an upfront decision made during Phase 1 design: build a modular component system, not feature-specific screens.

The reason Phase 2 shipped cleanly, and without touching Phase 1's component architecture, was an upfront decision made during Phase 1 design: build a modular component system, not feature-specific screens.

Every module type (Directions, Concessions, Upsell, Donations) inherited the same structural pattern. When Phase 2 needed to add segmentation controls, the segmentation panel slotted into the existing structure without redesigning anything that already existed. Clients encountered one familiar interface with new capabilities, not a new interface.

Every module type (Directions, Concessions, Upsell, Donations) inherited the same structural pattern. When Phase 2 needed to add segmentation controls, the segmentation panel slotted into the existing structure without redesigning anything that already existed. Clients encountered one familiar interface with new capabilities, not a new interface.

"The hardest problem: make segmentation invisible if unused, intuitive when needed."

"The hardest problem: make segmentation invisible if unused, intuitive when needed."

Left: Phase 1 (Basic Feature), Right: Phase 2 (Additional Features)

THE WORDS IN THE INTERFACE

Every label, confirmation, and empty state was a design decision.

In a self-service CMS used by non-technical clients, interface copy does the job a support team used to do. A poorly worded button causes hesitation. An unclear confirmation creates a support ticket. Every word in the Ignite interface was written intentionally, not defaulted.

In a self-service CMS used by non-technical clients, interface copy does the job a support team used to do. A poorly worded button causes hesitation. An unclear confirmation creates a support ticket. Every word in the Ignite interface was written intentionally, not defaulted.

PUBLISH FLOW - REVIEW MODAL

Review before publishing: 1) Associated events, 2)Internationalised text

Rather than a generic confirm dialog, the modal gives clients two concrete checkpoints, are the right events connected, and is the copy ready for each market? This converts a moment of uncertainty into an actionable checklist, cutting the "I published before I was ready" support ticket category.

SORT ORDER - SINGLE EVENT OVERRIDE TOOLTIP

This sort order will override the sort order set for All Events.

Switching from All Events to a single-event sort is consequential, and invisible without this tooltip. Clients don't know that a per-event sort takes precedence over the global order. The message surfaces that implication at the exact moment of the decision, before the action is taken.

EMPTY STATE - FIRST-TIME USER

Add your first module

The empty state pairs the message with a live ticket preview on the right, no modules below it yet. Clients don't see a blank screen; they see what they're building toward. The CTA echoes the primary action button so the next step is never ambiguous.

The Result

83 clients. 255 modules. Zero tickets.

Designs delivered in 10 days. Clients didn't need a tutorial, the first interaction was the onboarding. The system was recognised at VP Leadership level and featured at the Global Design Townhall.

Designs delivered in 10 days. Clients didn't need a tutorial, the first interaction was the onboarding. The system was recognised at VP Leadership level and featured at the Global Design Townhall.

The core insight: imagination is a tax on the user. Any interface that requires you to imagine the outcome is harder to use than one that shows it to you. WYSIWYG removes that tax entirely. Clients see the fan-facing output update in real time as they configure, no gap between input and result.

The core insight: imagination is a tax on the user. Any interface that requires you to imagine the outcome is harder to use than one that shows it to you. WYSIWYG removes that tax entirely. Clients see the fan-facing output update in real time as they configure, no gap between input and result.

83

83

Clients onboarded to self-service, without a single onboarding session

255

255

Modules configured independently by clients post-launch

0

0

Support tickets raised after launch, the benchmark for self-service done right

10

10

Days from design brief to shipped designs, across a B2B platform serving 30M+ users

The recognition metric that mattered most: VP Leadership called it out at the Global Design Townhall, not because it was a visual achievement, but because it removed a category of engineering dependency that had existed in the platform for years. Zero tickets isn't a UX metric. It's a systems metric. It means the design was self-evident enough that 83 different enterprise clients, across different team sizes and technical comfort levels, could operate it without help.

The recognition metric that mattered most: VP Leadership called it out at the Global Design Townhall, not because it was a visual achievement, but because it removed a category of engineering dependency that had existed in the platform for years. Zero tickets isn't a UX metric. It's a systems metric. It means the design was self-evident enough that 83 different enterprise clients, across different team sizes and technical comfort levels, could operate it without help.

Real modules published by clients in production, no engineering involvement post-handoff

THE COMPONENT SYSTEM

The system behind the modules.

Every module type in Ignite, Concessions, Directions, Upsell, Donations, Merchandise, is built on the same underlying component structure. Adding a new module type doesn't require a new design engagement. The component system absorbs it.

Every module type in Ignite, Concessions, Directions, Upsell, Donations, Merchandise, is built on the same underlying component structure. Adding a new module type doesn't require a new design engagement. The component system absorbs it.

This was the decision that made Phase 2 possible without redesigning Phase 1. And it's why 0 future design engagements were needed for subsequent module alignments.

This was the decision that made Phase 2 possible without redesigning Phase 1. And it's why 0 future design engagements were needed for subsequent module alignments.

Module Strip

Published & Unpublished states

The component spec used for dev handoff. Two variants annotated with gap, padding, fill, stroke, and component type, engineers could build both states immediately without follow-up questions.

Individual Module

10 variants, 1 Type property

Five content layout types (IMG + Title + Copy + 2 CTA down to 1 CTA) documented as Figma variants. Engineers could access any configuration directly from the component panel, no custom build per module type, no back-and-forth.