One Design System for 80+ Apps

Netflix Studio runs more than 80 applications that support the content production pipeline, from pitch evaluation through financial forecasting to asset delivery. Employees may move between several of these apps in a single day. Hawkins is the name of the design system built to keep that experience coherent and to avoid each team re-implementing the same UI primitives.

The system has two layers. On the design side, Figma components give designers a consistent foundation for mocks. On the engineering side, a React component library turns those assets into reusable, configurable, composable code. The components are intentionally atomic early on, so they stay small, lightweight and easy to combine into larger structures.

Cohesion and the Cost of Reinvention

Without a design system, each application develops its own patterns, tooling and component set. Users pay the price on every learning curve; engineers pay it through duplicate implementation and maintenance. A shared system addresses both problems at once.

A consistent UX shortens training. An engineer who learned to fill out forms, read data in a table or interpret notifications in one app can apply that knowledge to the next one. The system also works as a shared vocabulary between designers and engineers, and the documentation that comes with it helps new team members get up to speed faster.

The biggest engineering win is single-sourcing the shared primitives. One implementation of buttons, tables and forms means fewer bugs, better performance and broader impact from improvements. When a fix or enhancement ships in a component, every application in the organization benefits.

Build, Buy, or Both

The first decision was whether to write everything from scratch. Building internally gives full control over what goes in and what stays out, but it takes longer because the team owns everything.

Adopting an off-the-shelf system delivers a lot out of the box, but the team would inherit the health of that library, whatever it is, and customization is limited by the vendor decision.

Hawkins took a hybrid path. On the design side, the team built a custom design language, giving complete creative control over the user experience. On the engineering side, the team implemented the system on top of Material-UI. That choice provided a large set of components ready to configure and style. Key customizations are obfuscated behind Hawkins' own API to make future upgrades to the underlying library cleaner and less disruptive.

Stage One: Earning Trust

The investment in a design system is front-loaded. Research, design tokens and the component library all require sunk cost before any application consumes them. The payoff comes only after teams trust the system enough to adopt it fully.

For Hawkins, the initial build spanned two quarters. The first quarter was dedicated to the design language; the second to implementation with engineering and design working alongside each other. That resulted in a significant Figma component set and a large Material-UI-based React library. Adoption could only start after that foundation was in place.

To encourage engagement from engineering teams, the Hawkins team focused on four things:

  • Documented components — Every component has documentation and examples in Storybook.
  • On-call support — Engineers can ask questions and report issues in a Slack rotation; responsiveness was critical for building confidence.
  • Road shows — Presenting Hawkins directly to teams demonstrated value and let engineers ask questions and shape the roadmap.
  • Bootstrapped proofs of concept — Helping teams bootstrap a feature or app as a demonstration built working relationships.

Beyond the Atomic: A Parallel Library

As usage grew, teams built increasingly complex experiences on top of the atomic primitives. In-app chat, data grids and file uploaders were common patterns across multiple applications, but they were not used across the entire Studio and did not belong in the core Hawkins library.

The answer was a secondary library that sits alongside Hawkins and builds on its foundations. It is organized as a Lerna monorepo, with tooling for spinning up new packages quickly, and follows the same Storybook and support-channel conventions as Hawkins. The monorepo gives engineers a single discovery point for what is available.

Each package is versioned independently to avoid coupling between releases. Responsibilities are shared through an open-source-style model: any engineer can contribute a new component or fix issues in existing ones, meaning ownership spreads across many contributors instead of sitting with one person.

The parallel structure keeps an eye on the future. When components prove generally useful, they can be promoted into Hawkins proper. All repos follow the same development, testing and build rules to make that migration straightforward.

Next Steps

Hawkins is not finished. Planned work includes performance improvements, better developer ergonomics and making the system easier to use overall. The team is also scoping how to take Hawkins outside Netflix Studio, where the shared vocabulary can reach a wider application landscape.