Universal Design Systems · Scope Expansion

Global Schedule Settings

Global Schedule Settings

A narrow brief turned into a universal scheduling system. One flow. 8+ modules. Zero future design engagements.

A narrow brief turned into a universal scheduling system. One flow. 8+ modules. Zero future design engagements.

My Role

Sole Designer · Self-expanded scope

Scope

UX Design · Systems Thinking · PM Workshop Facilitation

Brief Vs. Reality

1 module · 1 schedule type → 8+ modules · 3 schedule types

Outcome

Universal flow · 0 future design engagements

Client

Ticketmaster

Universal Schedule Settings UI - identical interaction pattern across all CMS modules

The Problem

The brief was narrow. The real problem was much bigger.

The brief was contained: let clients pick a date and time for a page to go live. One module. One scheduling type. A straightforward UI problem with an obvious solution. But the brief had no visibility into who was actually waiting on this - or why.

The brief was contained: let clients pick a date and time for a page to go live. One module. One scheduling type. A straightforward UI problem with an obvious solution. But the brief had no visibility into who was actually waiting on this - or why.

After the first slice shipped, that changed. Asking "where else does this matter?" revealed that scheduling wasn't a single-module need. It was a platform-wide gap that clients in completely different contexts had been working around in completely different ways.

After the first slice shipped, that changed. Asking "where else does this matter?" revealed that scheduling wasn't a single-module need. It was a platform-wide gap that clients in completely different contexts had been working around in completely different ways.

Before - Manual Publishing VS. After - Scheduled Publishing

What was asked Vs. What Was Discovered

Use Case 01 - Nonprofits

A fund that needs to close at exactly midnight.

Donation windows tied to fundraising campaigns. A fund that goes live a minute late loses pledges. A fund that closes a minute early loses a donor. Scheduling isn't a convenience - it's the integrity of the campaign.

Publish + Unpublish Window

Use Case 02 - Events Teams

A page live the moment ticket sales open.

Event pages need to go live exactly when ticket sales open - not before (spoilers), not after (missed revenue). Coordinating a manual publish across time zones at odd hours was the existing workaround.

Scheduled publish only

Use Case 03 - Admins

Config that's live now, gone automatically at campaign close.

Campaign modules are built and published ahead of time, but they need to disappear at a precise moment. When a sale ends, a fundraising window closes, or the next campaign kicks in. Manually unpublishing at the right moment means someone has to be awake watching the clock.

Scheduled Unpublish only

Same feature. Three completely different scheduling needs. The brief had captured one of them. A single-module, single-type solution would have solved the brief and missed the problem.

Same feature. Three completely different scheduling needs. The brief had captured one of them. A single-module, single-type solution would have solved the brief and missed the problem.

THE RESEARCH - WHAT THE PM WORKSHOP REVEALED

Three clients. Three completely different scheduling needs.

After the first slice shipped for the Pages module, I ran a PM workshop, auditing every other CMS module against three scheduling types and asking each team who their clients were and why they needed scheduling. The session surfaced use cases the original brief had no visibility into.

After the first slice shipped for the Pages module, I ran a PM workshop, auditing every other CMS module against three scheduling types and asking each team who their clients were and why they needed scheduling. The session surfaced use cases the original brief had no visibility into.

The three clients who came up weren't edge cases. They were the primary users of the feature, and each needed something slightly but meaningfully different from "pick a date and time."

The three clients who came up weren't edge cases. They were the primary users of the feature, and each needed something slightly but meaningfully different from "pick a date and time."

Key Finding

A nonprofit needs a fund to close at midnight. An events team needs a page live the moment ticket sales open. An admin needs config changes active before a campaign, without going public early. Same toggle. Same flow. Three completely different stakes. A per-module solution would have solved one of the three, and missed the other two entirely.

PM workshop artifacts - every CMS module audited against three scheduling types, client use cases surfaced

EARLY EXPLORATIONS

The easy answer vs. the right answer.

Two directions were considered before committing to the universal flow. The easy answer was to optimise scheduling per module, tailor the UI to each module's context and ship faster. The right answer was harder to establish but more durable.

Two directions were considered before committing to the universal flow. The easy answer was to optimise scheduling per module, tailor the UI to each module's context and ship faster. The right answer was harder to establish but more durable.

DIRECTION 01 - NOT CHOSEN

Per-module scheduling UI

Build a scheduling flow optimised for each module's content structure. Faster to ship the first module. But every new module would need a new design engagement. Clients switching between modules would encounter a different pattern each time. The more the platform grew, the more the inconsistency would compound.

DIRECTION 02 - SHIPPED

Universal scheduling language

One consistent flow: toggle → type → date/time → confirm summary. Identical across every module, regardless of content structure. Takes longer to establish upfront, but every subsequent module inherits it without a new design engagement. Clients recognise the pattern the second time, and every time after that.

Two directions considered - per-module (faster to ship, compounds over time) vs. universal flow (more upfront, zero cost thereafter)

The UX Decision

One universal flow, not three bespoke ones.

Different modules have different UI patterns, different content hierarchies, and different client mental models. The easy answer was to optimise scheduling per module, tailor the UI to each context and ship faster.

Different modules have different UI patterns, different content hierarchies, and different client mental models. The easy answer was to optimise scheduling per module, tailor the UI to each context and ship faster.

The right answer was the opposite: establish a consistent scheduling language across the entire CMS. So that a client who schedules a donation fund on Monday can schedule an event page on Wednesday and recognise the pattern immediately, regardless of which module they're in, regardless of which scheduling type they need.

The right answer was the opposite: establish a consistent scheduling language across the entire CMS. So that a client who schedules a donation fund on Monday can schedule an event page on Wednesday and recognise the pattern immediately, regardless of which module they're in, regardless of which scheduling type they need.

Step 01

Enable scheduling

Enable scheduling

Toggle opt-in. Default remains instant publish, primary path stays fast.

Toggle opt-in. Default remains instant publish, primary path stays fast.

Step 02

Select type

Select type

Publish only · Unpublish only · Combined publish + unpublish window.

Publish only · Unpublish only · Combined publish + unpublish window.

Step 03

Set date & time

Set date & time

Date/time picker surfaces only after intent is confirmed. Keeps the UI clean until needed.

Date/time picker surfaces only after intent is confirmed. Keeps the UI clean until needed.

Step 04

Confirm

Confirm

Schedule summary shown before saving, client sees exactly what they've set up.

Schedule summary shown before saving, client sees exactly what they've set up.

Decision 01 - The toggle

Scheduling is opt-in, not default

Instant publish remains the primary path. The schedule toggle only surfaces the date/time picker after a client explicitly indicates intent to schedule. This keeps the default interaction fast and the scheduling path deliberate, clients who don't need scheduling don't encounter it at all.

Decision 02 - The confirmation summary

Show the schedule before it's saved

A plain-English summary, "This module will publish on Fri · Aug 1, 2026 · 12:00 AM and unpublish on Wed · Aug 10, 2026 · 12:00 AM", appears before the client saves. The cost of a misconfigured schedule (a fund that closes too early, a page that goes live too late) is too high to skip a confirmation step.

"The easy answer was to optimise per module. The right answer was to build a scheduling language the whole CMS speaks."

"The easy answer was to optimise per module. The right answer was to build a scheduling language the whole CMS speaks."

The universal flow applied across three different module types - identical interaction, contextually appropriate labels

The Process

I shipped first. Then I went looking.

The first slice, scheduling for the Pages module - shipped as briefed. But shipping it created a forcing function: once the pattern existed, it was possible to audit every other CMS module against it and see exactly what was missing and why.

The first slice, scheduling for the Pages module - shipped as briefed. But shipping it created a forcing function: once the pattern existed, it was possible to audit every other CMS module against it and see exactly what was missing and why.

Every module was mapped against three scheduling types. That audit was brought to a PM workshop, and that session surfaced use cases neither party had anticipated. What started as a UI feature became a scheduling model for the entire CMS.

Every module was mapped against three scheduling types. That audit was brought to a PM workshop, and that session surfaced use cases neither party had anticipated. What started as a UI feature became a scheduling model for the entire CMS.

PM workshop artifacts - every CMS module audited against three scheduling types, use cases surfaced by client context

Reflection - What I'd do differently

If I ran this again, the PM workshop happens before the first slice ships.

  • The instinct to look beyond the brief was right. The bigger problem was real.

  • The timing was reactive. Discovering the broader scope after shipping meant the universal flow was retrofitted, not built-in from the start.

  • The PM workshop should have been the starting point.

Including this reflection is intentional. The outcome was strong, but a lead designer is accountable to process, not just results. The ability to identify what would have made the work better is the same ability that makes the next project better from day one.

Including this reflection is intentional. The outcome was strong, but a lead designer is accountable to process, not just results. The ability to identify what would have made the work better is the same ability that makes the next project better from day one.

The Result

Clients can now go to sleep before go-live.

Time-sensitive workflows no longer depend on someone being online at the right moment. Page launches, donation windows, and campaign configs can be planned days in advance and executed automatically.

Time-sensitive workflows no longer depend on someone being online at the right moment. Page launches, donation windows, and campaign configs can be planned days in advance and executed automatically.

8+

8+

CMS modules with universal scheduling built in - all inheriting the same interaction pattern

3

3

Scheduling types designed - publish, unpublish, and combined publish + unpublish window

0

0

Future modules needing a new design engagement - every new module inherits scheduling automatically

Zero future design engagements is the right metric for this kind of work. A scheduling feature built per-module would have required a new design engagement for every module that needed it. A universal flow built as a CMS-wide standard means every module that ships from here inherits scheduling capability without returning to design. The work compounds. The standard earns its value with every module that never requires a design review.

Zero future design engagements is the right metric for this kind of work. A scheduling feature built per-module would have required a new design engagement for every module that needed it. A universal flow built as a CMS-wide standard means every module that ships from here inherits scheduling capability without returning to design. The work compounds. The standard earns its value with every module that never requires a design review.

The universal pattern in production - the same flow recognised and used across every module it touches