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), each spanning some combination of up to 5 platforms (iOS, Android, Meta Quest, Vision Pro, web) with independent regional and provider-access configs. And it merges two jobs into one: operations (live video ingestion, multi-platform distribution) and editorial (metadata, thumbnails, categorization, curation like ordering and carousel placement).
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.
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.
Goal: Understand real CMS problems before designing
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.
| 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.
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."
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.
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.
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.
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:
- 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
- Designing for legacy environments requires prioritization. Not everything can be fixed at once.
- 80% of the design system's value came from governance, not components. A perfect component library with no adoption strategy is useless.
- Preview before publishing was the single most impactful feature. Operators stopped making "scared calls" to backend.
- Even small UX patterns (grouped machine states, preview thumbnails, impact warnings) dramatically improved user confidence.
- Collaborative sessions with backend engineers and operations staff were essential. The best ideas came from watching them work.
