The Manu Times
Shipped · 2023

Quickplay · Shipped 2023

Quickplay

Designing the global white-label OTT platform that powers Tier-1 streaming products worldwide. Pilipinas Live was one of several launches built on top of it, this case study is about the platform itself.

Quickplay cover

At a glance

RoleProduct Designer 2 · HumanX
Timeline2023 · Platform design system + multi-client rollout
DomainEnterprise OTT infrastructure · White-label platform design · Cross-client design systems
PlatformWeb · iOS · Android · Apple TV · Smart TV (across multiple client implementations)
TeamHumanX product design team in coordination with Quickplay platform engineering and four launch-client teams

The problem

Quickplay’s reference UI was dev-first and visually generic, every new client was rebuilding the same product from scratch with different brand colors, slowing time-to-launch and leaking platform-level decisions into client-specific code.

What I shipped

I designed the platform’s four-layer model (platform / system / theme / content), the shared component library, and the customization playbook, making client launches a theming exercise instead of a redesign.

What I ownedPlatform design system · Reference OTT templates · Cross-client consistency model · Theme-tokens architecture · Client customization playbook · Dev handoff for the client launches

The opportunity

Most OTT design briefs ask you to build a product. Quickplay asked the opposite: design the platform that other OTT products are built on.

Quickplay is the enterprise OTT tech stack used by broadcasters and streamers globally. They didn't want another reference client implementation. They wanted a system. A design library that any client could instantiate, for any market, with brand-specific customization but platform-level consistency. Pilipinas Live (Filipino sports), Cignal Play (Filipino general entertainment), aha 2.0 (Indian Telugu), and Struum (US subscription aggregator) were all in flight at HumanX, with more on the roadmap.

When I was promoted from Product Designer 1 to Product Designer 2 at HumanX, this was the scope expansion: stop designing products, start designing the platform beneath them.

Each of those four launches has its own story. Pilipinas Live in particular is a substantial project of its own and lives in a separate case study. This one is about the platform that makes all of them possible.

The problem

Platform design breaks most of the heuristics you learn as a product designer.

A product designer optimizes for one user, one brand, one market. A platform designer optimizes for, well, what exactly? The client's user, the client's brand, the client's market, times N clients you don't even know yet. Every decision has to travel.

Three problems I inherited the moment I stepped into the platform role:

  • Existing client work was bespoke. Sports-first flows, brand-specific overlay patterns, copy tuned for one market. Great for the first launch. Brittle for any second one.
  • Quickplay's existing platform components were dev-first. Functional, flexible, visually generic. Clients had to do too much work customizing.
  • No shared model for what's "platform" vs "client." Which parts of the experience should clients be able to brand, and which should they have to inherit?

My job was to build a system that respected the platform's technical flexibility while solving for client-launch velocity. Fewer bespoke decisions per client. Faster time-to-ship. Consistency where it mattered. Freedom where it didn't.

How I worked

1. The four-layer model

The biggest mental shift wasn't a design-tool change. It was a hierarchy of decisions I locked down before drawing a single screen:

  • Platform-level (inherited, non-negotiable): player controls, overlay positioning rules, accessibility baseline, motion choreography, device breakpoints, free-vs-premium interaction patterns
  • System-level (inherited, customizable): component library (buttons, cards, modals), typography scale, spacing system, iconography
  • Theme-level (client-customizable): brand color palette, logo treatment, hero assets, language-specific typography
  • Content-level (client-owned): content catalog, navigation taxonomy, promotional content, territorial rights

That four-layer model was the real design deliverable. Everything downstream, the component library, theming tokens, customization guidelines, flowed from it.

2. Designing for clients I'd never meet

The closest analogy isn't product design. It's API design. The "users" of the platform aren't viewers, they're client design teams who'll show up two years from now with a brand book, a market, and a six-week launch deadline.

Three rules I held the system to:

  • Defaults should ship. A client who changes nothing should still get a high-quality experience.
  • Customization should be ergonomic. The five things every client will want to change (color, logo, hero, type stack, microcopy) should be one-token swaps, not surgery.
  • Escape hatches should exist. When a market behaves differently, a Tier-1 sports client with second-screen behavior, an aggregator with services-as-content, the system should bend, not break.

3. Reference implementation as a forcing function

The first launch on the platform doubled as the reference implementation. Every pattern I designed for that client, live overlays, four-surface system, free-vs-premium distinction, second-screen behavior, got extracted into the platform library while I was shipping it.

The trade-off: extracting in parallel added roughly 30% to the design effort on that engagement. The alternative, ship bespoke, then extract later, would have cost three more months of rework on the next two clients and would have locked the first client's assumptions into the library.

4. The client customization playbook

By mid-2023 I'd documented the handoff model: a client-kickoff walkthrough of what's platform / system / theme / content, a theme-tokens starter file, a component usage guide, and a "gotchas" doc covering the five customizations that always come up and how to handle them.

Four launches in, time-to-launch had compressed from months (bespoke) to weeks (platform-driven). That's the real platform ROI.

The outcome

0M+

Quickplay MAUs across 100+ countries

today, on the platform design system shipped in 2023

11.82B

minutes streamed every month

on Quickplay-powered surfaces

0

Tier-1 OTT clients launched on the platform

Pilipinas Live, Cignal Play, aha 2.0, Struum, each their own case study

The platform shipped, scaled, and is still running.

By 2026 Quickplay operates at Tier-1 scale, 20M+ MAUs across 100+ countries, 11.82B minutes streamed per month, 99.999% stream uptime, and 20+ years of continuous operation, on the design foundation built in 2023.

Each of the four launch clients on top of the platform has its own story, with its own design challenges:

  • Pilipinas Live, first global Filipino sports OTT (a major engagement on its own; separate case study)
  • Cignal Play, Filipino general-entertainment OTT
  • aha 2.0, Indian Telugu OTT relaunch
  • Struum, US OTT subscription aggregator

The Quickplay system is what made all four possible without four ground-up redesigns.

Evolution

Quickplay kept evolving after I left. The platform-thinking baked into the 2023 design system has held up beautifully through each iteration.

By 2026 the company has matured into "The Content-to-Value Operating System", an AI-orchestrated platform spanning five engines (Stream, Enrich, Activate, Engage, Maximize) that handle content ingestion, metadata enrichment via AI, automated clip generation, personalization, and revenue optimization across Linear, OTT, FAST, and social channels. Current Tier-1 clients include Gray Media, TVNZ, and Global Streaming.

The 2023 design system, the four-layer hierarchy, the reusable component library, the client customization playbook, is what let Quickplay grow from white-label OTT infrastructure into a content-AI operating system without a ground-up redesign. The platform thinking I shipped in 2023 was the foundation every subsequent pivot stood on.

Reflection

Three things Quickplay taught me.

1. Platform design is a different job. Product design optimizes for the user you can see. Platform design optimizes for the users your clients will have, users you'll never meet, for brands that don't exist yet. The mental model is closer to API design than screen design.

2. A good design system survives abstraction leaks. The real test of the Quickplay system wasn't the first client launch. It was the third and fourth, when assumptions about "what sports OTT needs" got stress-tested by entertainment, Indian-market, and US-aggregator use cases. Each leak was a platform lesson. None of them broke the system.

3. Compressing time-to-launch is the quietest KPI. The platform's biggest win isn't a viral metric. It's that the fourth client shipped in weeks, not months. Platform design takes longer to validate, and validates more durably when it does, because every subsequent product is faster, cheaper, and more consistent.

Quickplay is the project that taught me the difference between designing a product and designing the plumbing products are built on. It's the case study I point to when someone asks what Product Designer 2 means.

✶ Thanks for reading

That’s the case study, front to back.

If you want to dig into anything I skimmed over, process, edge cases, the trade-offs that didn’t fit on the page, reply by email or send this to a teammate.

✶ Read next