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.