CMS · Content Management Platform
NDA
Every App.
Every Platform. One CMS.
An internal Content Management Platform that runs across apps, platforms, and markets. One tool doing the work of both operations and content editorial.
It powers 5 apps in production (more in the pipeline) across up to 5 platforms (iOS, Android, Meta Quest, Vision Pro, web) with independent regional and provider-access configs, merging operations (live video ingestion, multi-platform distribution) and editorial (metadata, curation, carousel placement) into one tool. It's also provisioned to partner companies to manage their own app's content, a multi-tenant, SaaS-style extension beyond internal use.
Initially built without UX guidance, the tool had grown organically, becoming unintuitive, error-prone, and difficult to use. The redesign aimed to modernize the interface, reduce operational errors, and create a scalable component foundation.
UX Researcher, Information Architect, Product Designer
Backend Engineer, QA, Operations Staff, Frontend Developer
Figma, FigJam, Jira, Confluence
An internal CMS spanning a portfolio of apps, each across multiple platforms and 12+ regional/provider configs, had grown for years with no UX owner. Non-technical Ops staff couldn't predict what a change would break, and mistakes shipped live during real sports events.
Audited every core workflow, interviewed 9 stakeholders across every role that touches the CMS, then redesigned the information architecture and the 3 highest-impact flows (event config, per-country content, live debugging) based on a prioritization matrix, not assumptions.
Operators stopped making "scared calls" to backend before publishing. Faster configuration, fewer live-event incidents, and onboarding for new Ops staff dropped from weeks to days.
Quick look at what shipped
See the full flow ↓
Discovery & Research
The Content Management Platform had grown organically over several years without dedicated UX attention. Initially built without UX guidance, the tool had become unintuitive, error-prone, and difficult to use. Operations staff, mostly non-technical users, were struggling daily.
Before designing anything, I interviewed 9 key stakeholders and users to understand the real problems with the CMS, not assume them.
Methodology
Heuristic evaluation
I conducted a self-led usability audit of the CMS, walking through every core workflow (ingestion, metadata creation, multi-country publishing) to document baseline UI inconsistencies, interaction friction, and system blind spots before engaging stakeholders.
9 Stakeholder & User Interviews
Ops Lead, Ops Engineer, Operator, App Manager, QA Engineer, Product Lead, covering every role that touches the platform daily. Sessions combined task walkthroughs, open-ended questions, and direct observation to surface pain points that wouldn't appear in a bug tracker.
What users told us
Control over app content
"I need to show different posters in Spain vs. the US. But I don't want to upload the same thumbnail 5 times."
Preview before publishing
"Last week I changed a title and it broke across all apps. I need to see what will change before I click save."
Understanding system-wide impact
"I'm always scared of breaking something. I don't know what else this change affects."
Key Findings
- Inconsistent UI across all sections
- White pages with no visual structure
- Non-consistent layout patterns
- CRUD interactions needed improvement
- Users get lost navigating the app
- Confusing save changes flow
- Unorganized notifications
- Interrupted Live Event flow
- Asset Manager with unrelated sections grouped together
Prioritization with Stakeholders
Each finding was evaluated across three axes: direct impact on Ops staff, development difficulty for the CMS team, and design effort required from UX.
The Design System roadmap was built on these priorities, not assumptions. The solutions described below directly address Highest and High priority problems first, ensuring every design decision had a measurable user impact before touching lower-priority items.
Show the full priority matrix 10 problems scored — Ops impact, dev difficulty, design effort
| Problem | Ops Impact | Dev Difficulty | Design Effort | Priority |
|---|---|---|---|---|
| Core content user flows | High | Medium | High | Highest |
| Live streaming user flows | High | Medium | High | Highest |
| UI consistency | Medium | Low | High | High |
| Navigation & information architecture | High | Low | Medium | High |
| Save & confirmation patterns | High | Low | Medium | High |
| Data import & export | Medium | High | Medium | Medium |
| Content grouping & structure | Medium | Medium | Medium | Medium |
| Notification system | Low | Medium | Low | Low |
| Visual polish & empty states | Low | Low | Medium | Low |
| User roles & permissions | Low | High | Low | Low |
| Dark mode | Low | High | Low | Lowest |
Definition & Architecture
This phase involved defining user flows, information architecture, and interaction patterns before touching high-fidelity UI.
Mapping the System Architecture
I created a system diagram to visualize how the platform is structured across three interconnected layers: ingestion, metadata management, and distribution. The diagram became our shared language: engineers, operators, and leadership could finally point to the same boxes and say "this is where the problem is."
User Flows Prioritized
Based on research, I prioritized three critical workflows: configure a new event, update a thumbnail across all countries, and debug why content isn't appearing in an app. I mapped each flow end-to-end, identifying friction points and decision moments where operators typically made mistakes.
Information Architecture Redesign
The original IA buried the three layers inside nested menus. I proposed a new structure that:
- Made the three layers visible in the main navigation
- Showed "impact preview" before destructive actions
- Grouped related settings by user task, not by technical domain
- Added search and filtering across all layers
Mapping States, Not Just Screens
A piece of content isn't just "published" or "not published." Because distribution fans out across apps, platforms, and 12+ regional/provider configurations independently, the same asset can be live in one market and stuck mid-sync in another. Mapping every state, not just the happy path, is what "why isn't this showing up in the app" flow was actually built to answer.
Access Control & Permissions
Configuring a live event across 12+ markets means several roles touch the same content at different points, some can publish live, others should only ever preview. A clear permission model is what stops an Ops Engineer from accidentally publishing to a market they don't own, without slowing down the day-to-day.
| Module | Operator | Ops Lead | QA Engineer | App Manager |
|---|---|---|---|---|
| Video Content | Edit | Full Access | View Only | View Only |
| Event Configuration | Edit | Full Access | View Only | View Only |
| Providers & Access | No Access | Edit | View Only | Full Access |
| App Settings | No Access | View Only | No Access | Full Access |
Final Design: Configuring a Live Event Across Countries
Of everything touched in this redesign, this is the flow the project hinged on: rated Highest priority in the matrix above, the source of both quotes in the research section, and the reason the lifecycle states and impact preview earlier in this case study exist at all. Rather than tour every screen that changed, here's that one flow end to end, from reusable content to the moment it goes live in a specific market.
All data, section names, and branding shown are fictitious. This mockup has been modified from the original to comply with a confidentiality agreement.
A video's Master Data: identity, scheduling, editorial metadata, per-platform imagery, technical controls, exists once. Customization layers per-locale overrides on top of it, so a new market gets its own copy without re-uploading a single asset, the direct answer to "I don't want to upload the same thumbnail 5 times."
Locale switcher: same content object, viewed for a different market (spa-ES).
"Variant" badge: this field has been explicitly overridden for this locale.
No badge: the field is left untouched, it silently inherits the Master value. Nothing to re-upload, nothing to re-enter.
App Manager Home indexes each app's configuration surfaces. Providers is where an operator maps a given config and operating system to its blocking/access provider, per market, before that config is ever tied to a live event.
Space + Operating System filter: this mapping is scoped per app, per OS.
One row per Config: a market-specific configuration, defined independently of any event.
Assigned provider: what determines blocking/access once a live event is later tied to this config.
Video Details lets an operator pick a Configuration, Language Version, and Platform, and see exactly how the master asset and its locale overrides resolve for that specific combination, the concrete answer to "does this change if I switch to another config" before anything is confirmed live.
Pick any Configuration, Language, Platform: any combination the content might resolve to.
Resolved status per card: stream, visibility, access and sync state, computed live for that exact combination.
Conflict surfaced up front: the exact reason playback will be blocked, and for whom, before anything ships.
Collaboration & Trade-offs
Still inside this same flow: once content is bound to targets and published, Ops wanted a true "undo" for anything live. Engineering constraints meant that wasn't always possible, and the design had to meet the system where it actually was.
A single "undo" button that would instantly revert any published change across every app and country, the same mental model as undoing a local edit.
Publishing fans out asynchronously per app and per country. Once a change starts propagating, some markets update before others. A true instant-wide rollback isn't something the distribution layer can guarantee, especially mid-sync during a live event.
Instead of promising an undo the system couldn't deliver, I designed the impact preview to surface consequences before publishing, plus per-market status visibility after, so operators could see exactly what state each app/country was in and reprocess selectively rather than assume a rollback that might not fully apply. That status visibility is the Video Details view shown above.
Impact
Outcomes tied to the redesigned flows and IA, based on team feedback and operational trends. (Component-level and adoption metrics live on the Design System case study.)
Partnerships & Scale
The redesigned platform now powers content operations for:
- Provisioned as a multi-tenant SaaS-style CMS to partner companies, who use it to manage their own app's content directly.
- Multiple live sports events per week
- 5 apps in production, each spanning some combination of up to 5 platforms (iOS, Android, Meta Quest, Vision Pro, web)
- 12+ regional and provider-access configurations per app/platform
Learnings
- Preview before publishing was the single most impactful feature. Operators stopped making "scared calls" to backend.
- Mapping every state, not just published/unpublished, is what finally made "why isn't this live" answerable — partial success across markets turned out to be the default case, not the exception.
- An instant, system-wide "undo" was the ask, but the distribution layer couldn't guarantee it. The honest fix was surfacing consequences before publishing and status after, not promising a rollback I couldn't build.
- The permission model only held up because it mapped to how each role actually touches content day to day, not a generic access-level template.
