Case Study · UX Design

iWantTFC
Design System

A streaming platform serving the global Filipino diaspora across four surfaces — with no shared design language. This is the story of building one from the ground up.

Role
UX Designer
Platform
TV · Mobile · Web
Initiated by
Self + Stakeholders
Status
Live · Team-owned
Scroll
Background

ABS-CBN's flagship
streaming platform

The digital home of Filipino entertainment for the global diaspora. Live news, teleseryes, films, and OPM — across Smart TV, iOS, Android, and Web.

📺

Smart TV

Living room, 10-foot experience

📱

iOS & Android

Mobile — phone and tablet

🌐

Web

Desktop & mobile browser

🇵🇭

Global Diaspora

Filipinos worldwide

Building without a center

iWantTFC never made a deliberate decision to skip a design system. It simply never made a deliberate decision to build one. Features were prioritized. Teams moved fast. Design kept up with delivery — but not with coherence.

The signal came from engineering leadership — developers were repeatedly reaching out for specifications. Button sizes, icon choices, label styles — questions that should have had a single documented answer. They didn't. Every request was being resolved in the moment, by whoever was available, with no consistent reference to point to.

That signal opened the audit. And the audit revealed something bigger than anyone had initially framed — color, typography, voice, spacing, and hierarchy had each been decided independently, screen by screen, platform by platform. The product had no shared design language. It had dialects.

This wasn't neglect. It was the natural result of building fast without a foundation.

Problem

The absence ran
through everything

The audit didn't reveal a component problem. It revealed a structural one — every dimension of the experience had been shaped without a center to return to.

01

Inconsistent User Experience

Users moving across TV, mobile, and web encountered what felt like different products. Patterns shifted depending on the surface — not by design intent, but by absence of one.

02

Duplicated Effort & Wasted Resources

Every new feature started from scratch. Designers were solving the same UX problems repeatedly with no way to reference or reuse prior decisions.

03

Slow Design Velocity

Without a shared foundation, every decision had to be justified from the ground up. Updating a pattern across platforms meant touching every file individually.

04

Lack of Centralization

No single place where design decisions lived. New designers had to reverse-engineer existing screens — introducing more inconsistency with every new person.

05

Scaling Issues

Every new platform requirement, every new team member added friction instead of momentum. Without a system, growth made the problem worse — not better.

06

No Design Language

Color, typography, voice, spacing, hierarchy — each decided independently, screen by screen. The product didn't have inconsistent UI. It had no shared design language at all.

"The product wasn't inconsistent — it was unrelated to itself."

Research · Audit

Diagnosing
the full scope

Before proposing a solution, the full scope needed to be mapped. A cross-platform audit was conducted across TV, mobile, and web — cataloguing every pattern, every inconsistency, every dimension where design decisions had diverged.

3
Platforms with no shared design language
0
Documented standards before this work
∞
Decisions made without a shared reference
Finding 01

Color had no system

Brand color appeared differently across platforms. Every surface had made its own interpretation of the same palette.

The same primary action color carried different values across TV, mobile, and web.
Finding 02

Typography was decided per screen

No shared type scale existed. Sizes and hierarchy were chosen independently — making the experience feel unrelated across surfaces.

Heading sizes on TV had no relationship to heading sizes on mobile — separate decisions, separate times.
Finding 03

Voice & tone had no register

Error messages, empty states, and CTAs were written in different tones. The product spoke differently depending on where you were.

The same user moment read as transactional on web and conversational on mobile. Neither was intentional.
Finding 04

Spacing & hierarchy were improvised

Spacing and density were set per screen rather than from a shared scale. Layouts that looked considered in isolation fell apart in relation to each other.

The same platform used three different padding values for the same pattern — each an individual judgment call.
The System

One system.
Three platforms.

Built ground up across TV, Mobile, and Web — each with its own Figma library shaped around the interaction model of that surface. Grounded in Material Design, HIG, and streaming platform benchmarks.

Foundation — Colors, Spacing, Typography
Foundation Layer
Color palette · Spacing scale · Typography system — defined before any component was touched
Mobile Library
Mobile Library
Input fields · Navigation · Icons & Labels · Buttons · Movie preview cards · Video player
Web Library
Web Library
Home page · Rail tray · Onboarding · Video player · Content inner pages · Icons & Labels
TV Library
TV Library
Layout & grids · Content cards · Episode cards · Live program · Originals · Background cards

How it was built

01

Tokens — the semantic foundation

Color, typography, and spacing defined before any pattern was touched. The layer that ensures a single change propagates consistently across every surface.

02

Patterns — defined with all states

Buttons, cards, labels, inputs, and navigation — each defined with all states and variants. Composable by design, so teams could move without needing design present at every decision.

03

Platform libraries — TV, Mobile, Web

Each platform considered on its own terms. TV required a 10-foot model — large type, high-contrast focus, remote navigation. Mobile shaped around thumb zones and gestures. Web introduced hover states, keyboard accessibility, and responsive layouts.

04

Governance & documentation

Every decision documented in Confluence — not just what the pattern is, but why it exists and when to use it. Written for the team, not for the project, so the reasoning remained accessible long after the work was complete.

Documentation

Every pattern documented in Confluence with rationale, usage rules, and dos and don'ts — so the team could make decisions independently without needing design present.

confluence · iWantTFC Design System
Button — Usage Guidelines
Design System · Components · Last updated by UX Team
Button
Input Fields
Navigation
Content Cards
Icons & Labels
Typography
Color Tokens
Spacing Scale

Overview

Buttons communicate actions users can take. They are typically placed throughout the UI in forms, dialogs, and toolbars. Each variant has a specific role — use them consistently to maintain hierarchy and clarity across all platforms.

Usage Rules

DO

Use Primary buttons for the single most important action on a screen. Limit to one per view.

DO

Use Secondary buttons for supporting actions that complement the primary action.

DON'T

Use more than two button variants on the same screen — it creates visual noise and dilutes hierarchy.

DON'T

Use ghost buttons as primary actions. They lack the visual weight needed to draw attention.

Before & After

What changed

Before
  • No shared design language across platforms
  • Experience felt different on every surface
  • Same patterns redesigned per feature, per platform
  • Specifications resolved on request, not by reference
  • No documentation, no onboarding structure
  • Growth added friction, not momentum
After
  • Single token-based system across TV, mobile, and web
  • Consistent experience at every surface
  • Composable patterns — defined once, extended everywhere
  • Specifications documented and accessible without asking
  • Confluence documentation for onboarding and decisions
  • System scales with the product, not against it
Outcome

A system the
team owns.

The system is live across all three platforms and fully transitioned to team ownership. What began as a response to a single question from engineering leadership became the operational foundation for how design decisions are made at iWantTFC.

3
Platforms unified under one system
1
Source of truth across design and delivery
↓
Design decisions deferred to implementation

"The measure of a well-designed system isn't how it performs while its author is present — it's how well it holds when they're not."

Design Systems Figma Variables Token Architecture Cross-platform UX TV · 10-foot UX Confluence Documentation Material Design HIG iWantTFC · ABS-CBN