Efficiency in Announcements

3 Days to Under 5 Minutes: Simplifying Announcement Banners

Overview

Announcement banners are in-app promotional and informational banners shown to guests across Compass Digital's ordering apps (Boost and Thrive). Operators and marketing teams use them for a range of purposes — same-day promotions, sector-wide campaigns, service outage notices, loyalty program pushes, and seasonal or closure announcements. Because they sit at the top of the guest experience, they're one of the most visible and frequently used communication tools in the platform.

This case study covers a discovery-to-design effort to rebuild how these banners are created and published within Centric, Compass Digital's in-house operations platform. I led the design work, partnering with Phoebe, Claire (Marketing) and Compass Digital's dev team, across discovery, wireframing, and the eventual pivot that shaped the final direction.

The problem

Announcement banners were originally created directly by operators, but giving them free rein over the images led to inconsistent, off-brand creative — incorrect sizing, watermarked or "googled" images, no text overlay, and accessibility issues like illegible embedded text. To fix this, marketing introduced Brand Folder as a gated template library, paired with a separate intake form for operators to request a banner. This solved the quality problem but created a new one: every banner now required marketing to manually re-enter the operator's request into Centric, and — if no suitable template existed — build new creative in Brand Folder themselves. Add a manual deep-linking step through a third tool, Adjust, and what started as a simple communication task had become a three-system, two-actor, multi-day process. A single banner took 2–3 business days to go live, with marketing as a mandatory bottleneck for every request, and no way to react quickly to time-sensitive needs like an outage.

Discovery and Research

To understand the full scope of the problem, I ran a discovery phase with marketing stakeholders Phoebe, Claire (Marketing) Chris, Marc, Charles (Operators) and mapped the current-state workflow end to end — from the moment an operator decides they need a banner, through to a guest seeing it in the app.

Mapping the journey made two things visible that hadn't been obvious when looking at the process piecemeal: how much of it lived outside Centric entirely, and how many of the pain points operators and marketing complained about individually were actually symptoms of the same root cause — a workflow split across three systems with no shared source of truth.

Who’s affected

Two personas carried the weight of this process:

The Operator
Wants to communicate something to guests quickly (a promotion, a closure, an outage) but has no direct way to do it. Every request means leaving Centric, working in a tool they don't own (Brand Folder), and then waiting on someone else to finish the job.

Marketing
Owns brand consistency and is the only actor who can actually publish. But that ownership comes at a cost: every single banner, regardless of how routine, requires their manual intervention — checking the request, re-creating it, sourcing a new image if needed, and adding the deep link.

What we found

The pain points clustered into four areas:

Manual Process
Banner creation had no self-serve path; marketing was a required middle-person for every request, and a single banner took 2–3 business days.

Publishing & scale
Site selection was one-by-one with no multi-select, there was no way to push an announcement to all sites at once during an outage, and there was no single place to see all live announcements or their display order.

Content governance
The very problem Brand Folder was introduced to solve (incorrect sizing, watermarked images, illegible text, accessibility gaps) still surfaced whenever operators had any direct image access.

Guest experience & linking
Deep links only worked at the brand level, not the item level, and banners were frequently missed in the guest app's carousel.

Reviewing the live interface alongside these findings surfaced additional interface-level friction that the workflow map alone didn't capture

Defining the Solution (v1)

With the pain points mapped, the first solution direction focused on giving operators a true self-serve path while keeping brand governance intact. Brand Folder would be embedded directly inside Centric via an iFrame, so operators could create and publish an announcement end-to-end without submitting a request or waiting on marketing. Image choice would still be limited to Brand Folder's pre-approved library — marketing and the Compass creative team remain the custodians of that library, curating and vetting what goes into it, but they're no longer a per-banner gatekeeper standing between an operator's request and a published announcement. Deep linking, previously a manual step in Adjust, moved into the backend, generated automatically at publish time and invisible to the operator. The result: a genuinely self-serve, single-tool experience for operators, with brand governance preserved upstream — in what's allowed into the library — rather than enforced downstream through manual review of every request.

The Pivot

The v1 direction got far enough to warrant a technical spike: could Brand Folder actually be embedded inside Centric the way the design assumed? The dev team's finding was clear — integration was technically possible, but not worth the engineering cost. Rather than force a workaround, the decision was to build template creation and management natively inside Centric, removing Brand Folder from the workflow entirely rather than just hiding it behind an iFrame.

For operators, this pivot changes nothing about their experience — they still browse and select from a library of ready-made templates, just now rendered natively in Centric instead of through an embedded Brand Folder frame. The real shift is on the marketing and creative team's side: instead of building and maintaining templates in Brand Folder, they now create them directly in Centric — defining the background creative, placing and styling text fields, and setting which fields operators are allowed to edit. Brand governance moves from "curating an external library" to "authoring templates in the same system operators publish from" — closer to the source, with no separate tool to maintain in parallel.

Updated Task Flow

With template creation moved natively into Centric, the workflow split cleanly into two roles. Marketing and the creative team create templates — uploading the flattened background creative, then placing and styling the text fields that operators will be allowed to edit. Everything outside those exposed fields stays locked: background, layout, button styling, and brand colors are fixed by design, not by convention. Operators browse the resulting template library, select one, fill in only the fields marketing has exposed — headline, body copy, CTA label — and publish. Because a template is locked by design rather than by policy, there's no way for an operator to introduce the inconsistencies that started this whole redesign in the first place.

One detail worth calling out: published announcements are snapshots. If marketing edits a template after an operator has already published from it, the live announcement doesn't retroactively change — it stays exactly as it was published. This was a deliberate scope decision, surfaced directly to marketing in the interface, to avoid unpredictable behavior on already-live banners.

Wireframes

Step 1 - Select the template for the banner

Marketing create a new template

Impact

By moving template creation and selection natively into Centric, announcement creation went from a 2–3 business day, three-system, multi-handoff process to something an operator can complete in under 5 minutes — selecting a template, filling in the exposed text fields, and publishing, with no request, no waiting on marketing, and no risk of the brand inconsistencies that made Brand Folder necessary in the first place. Marketing's role shifted from being a required checkpoint on every single banner to owning the templates themselves — a smaller, more scalable surface of control that scales with the number of templates rather than the number of banners published.