Hawkins: Scaling Netflix's design system to unblock growth teams on TV

Role: Senior Product Designer, Hawkins Design System

Duration: 8 months on Hawkins. Static List shipped 8 weeks after design approval

Scope: Web, iOS, Android, TV

Team: I led design with 2 feature team designers, a schema architect, and 5 engineers across TV, mobile, and web. Reported to the Design Systems manager.

Outcome: 2 growth teams unblocked. A deprecation process now used across Hawkins.

Project Overview

Two Netflix growth teams had A/B results for a pattern that lifted conversion, and Hawkins couldn't render it. I led the Static List redesign that unblocked them, shipping across web, iOS, Android, and TV in 8 weeks. When rollout hit a live dependency on the property we were retiring, I built the deprecation process Hawkins didn't have. It was used for 4 more components before my contract ended.

Static List

Team: Lead DF designer: Manuela, Feature team designers: Mete & Ash Grigas; Schema alignment: David Aragon; Developers: Fernando Nova (TV); Noah Blake & Stella Yan (Mobile), Mars & Kyle (web)

Platform: Web, mobile, TV

The Problem

Two Netflix growth teams were blocked from shipping a revenue-positive pattern. Their A/B tests had shown that emphasizing specific words in value-prop lists lifted conversion but Hawkins' Static List component couldn't support word-level color emphasis, and the smallest size broke on TV once localized text was accounted for. The teams were either duplicating the component outside the system or shipping suboptimal layouts.

I led the redesign to unblock them without bloating the system.

The Reframe

Framing the work as a systems problem, not a component request

The feature teams came with a specific ask: "add color overrides and a smaller size." My first move was to resist shipping that directly.

I audited how Static List was actually used across the codebase and found something the ticket didn't mention: an emphasis variant (bold headline + body text) existed in IMS Templates (code-level) but had never been productized in Figma. Designers were reaching for it in ways the system didn't acknowledge.

This reframed the project. The real question wasn't "how do we add features to Static List?" — it was "how has this component drifted from its original design, and what's the right consolidation that serves all three use cases without creating four variants?"

Current design:

Three decisions, and two I rejected

Three key decisions, each with a specific rationale:

Replaced the old emphasis property with a semantic emphasis: [high | low] API. The old property bundled two decisions. Turning it on bolded the headline and added body text, so any designer who wanted emphasis also had to change the structure of the list item. That broke the scannability that made Static List useful.
The new property describes intent, not appearance. Designers say whether an item is high or low emphasis, and the token and theme layer decides how that renders on each platform. The visual treatment can change for a new theme, platform, or accessibility need without touching every screen that uses the component.

On the growth team, UX writers collaborate closely with the designers. UX writers found that this semantic change allowed them to think
Added a smaller size variant calibrated for TV-plus-localization. Sized against the longest localized strings in our top five markets, not English defaults. This was the kind of decision that prevents a component from shipping cleanly in English and breaking the day a PM turns on German.
Tightened spacing to earn back vertical real estate on TV. Growth teams were already maxing out full-screen card layouts; giving them back 40px of vertical room was worth more than an additional variant.

I rejected two alternatives: a "TV-only" variant (would have split the component, violating one of Hawkins' core principles of cross-platform parity) and full per-character color control (overengineered for the actual use cases, would have created accessibility edge cases).

Mid-implementation, engineering flagged that the emphasis property we were deprecating was in active use on a growth-critical surface. Hawkins didn't have a formalized deprecation process at that point. We'd been adding components faster than we'd been retiring them.

Rather than routing around this (either by preserving the old property or forcing a rushed migration on the consuming team), I escalated to Josh and kicked off a cross-functional project to build a deprecation playbook for Hawkins.

The playbook I led covered:

How to audit current usage before deprecation
Communication templates for affected feature teams
Migration timelines and dual-support windows
Tokenized warnings in Figma and engineering surfaces
A decision framework for when to deprecate vs. extend
The Static List rollout became the first component to use the new process. In the time that I was at Netflix, it was applied to 4 other components.
This is the work I'm proudest of on this project. The component redesign was a good piece of craft. The deprecation process is infrastructure that compounds across every future Hawkins change.

The Surprise

Retiring a component that someone still depended on

The Result

Our token development structure.

Communicating the updates

Static List in the wild: On the left is a “low” emphasis list using a slightly less vibrant text color. On the right, is the “high” emphasis, which is selected in this example.

Outcomes

Shipped across web, iOS, Android, and TV within 8 weeks of design approval
Unblocked growth team experiments that had been held up on component limitations
Deprecation playbook adopted as Hawkins standard practice

Static List was one of 21 components I worked on at Hawkins. Most of that work followed two threads: building what feature teams needed that the system didn't support yet, and pulling forked patterns back into the system. Happy to walk through more of it in an interview.

What I’d do differently

Two things I'd change if I ran this project again:

Audit usage earlier. I discovered the active deprecation-blocker in implementation, not design. A usage audit at the start of scoping would have surfaced it a month earlier and shaped the design direction, not just the rollout plan.
Involve motion earlier. Danelle (senior motion designer) joined late in the process. For a component with emphasis states that animate between variants, motion should shape the design, not polish it afterward.

How I think about design systems work, post-Netflix

Design systems pull in two directions: anticipating future needs vs. shipping against current, real constraints. Netflix biased strongly toward the latter, and this project was where I saw why.

We shipped in 8 weeks because we didn't try to solve every hypothetical use case. The deprecation playbook handled the one surprise use case that emerged, cleanly, and is now reusable. Had we spent that same 8 weeks over-engineering variants we didn't need, we'd have shipped a heavier component that still would have had one surprise use case and no process to handle it.

The principle I bring to design systems work now: design the component for today's use cases, but invest in the systems and processes that handle surprise.