Enabling Scalable Scheduling Across 1,400+ McDonald Stores
Designing a global scheduling system that enables component-level control, faster campaign execution, and predictable layouts at scale.
Enable flexible, component-level scheduling and layout changes at global scale without breaking existing workflows or predictability.
Before this work, even minor campaign changes required rebuilding and rescheduling entire assemblies. This increased effort, risk, and inconsistency especially across complex markets. Without a more flexible scheduling model, the platform wouldn’t scale to support richer campaigns, faster iteration, or future automation.
- A base layout with three promotions needed to temporarily switch to a full-screen takeover
- Achieving this required creating a new assembly purely for layout reasons
How might we allow flexible, time-bound content and layout changes without forcing teams to rebuild or reapprove entire assemblies?


- Marketers plan in campaign moments, but existing tools forced them to think in rigid system structures. This mismatch drove assembly duplication and workarounds.
- Different markets operate at very different levels of complexity. Some rely heavily on assembly-based approvals, making it risky to introduce a single ‘one-size-fits-all’ scheduling model.
- Teams needed high confidence in what would play, where, and when. Over-flexible placement increased the risk of errors and reduced trust in the system.
- Scheduling is often done under time pressure. Reducing cognitive load and decision fatigue was more valuable than offering maximum configuration options.
- Any new model had to extend existing mental and system models, not replace them, to ensure adoption at global scale.
These insights ruled out solutions that fundamentally changed how teams planned and approved content.

Option 1
- High flexibility and reuse
- Rejected due to major changes required to client approval workflows


Option 2
- Preserved simpler markets
- Allow for a hierarchy in type of scheduling allowing user to predict more accurately what content would take precedence.
- Rejected due to not aligning with needs for having two types of scheduling.


Option 3 (Chosen)
The chosen solution schedules components and layout changes within a single flow, while keeping assemblies as the default structure.
A key design decision was to adapt the existing layout logic already used across the platform. Layouts are constructed on a structured grid system (typically 3×3 or 3×4), and component scheduling aligns directly to this grid rather than allowing free placement.
- Components can be scheduled independently without overlap or collision
- Layout changes remain predictable and visually consistent
- Existing mental models for both users and engineers are preserved
This approach enabled component-level flexibility without introducing a second placement model or increasing system complexity, making it viable to scale across markets and use cases.


- Reduced long-range visibility into overlapping schedules
- Higher responsibility on users to fully define layout changes
- Guardrails prioritised over automation in early phases
These decisions avoided multiple scheduling systems and created room for future iteration without over-engineering.
The goal was to establish a stronger UX foundation, not inherit outdated patterns by:
- Designed a reusable scheduling layout that supports component, layout, and multi-layer scheduling, now used consistently across all scheduling flows and user types.
- Established interaction and visual patterns within this feature that are now being adopted across the wider platform, improving consistency and reducing design debt.
- Ensured all high-fidelity UI aligned with existing design system tokens, spacing, and state logic, while evolving patterns where legacy approaches limited clarity.
- Balanced flexibility with guardrails through consistent component sizing, placement rules, and hierarchy to maintain predictable outcomes at scale.

- Aligned on a single scheduling model to ensure scalability and reduce long-term backend complexity.
- Worked continuously with engineering to validate feasibility and avoid late-stage rework.
- Used targeted prototypes to clarify key flows and edge cases, reducing back-and-forth.
- Repurposed existing backend structures rather than introducing new systems.
- Worked with product/delivery to scope designs into delivery slices to support phased rollout and faster shipping of key functionalities.
This enabled faster delivery while maintaining long-term system maintainability.



- Core component scheduling successfully shipped
- Follow-up work identified around previews, backups, and bulk scheduling
- The feature is now treated as a foundational platform capability