The problem
Roku’s product portfolio had grown across five independent business units, and the interfaces had drifted apart. Buttons looked different depending on which team built the screen. Typography and colour were applied inconsistently. For customers this read as an incoherent product; for engineers it meant every team solving the same problems again from scratch.
The design organisation set out to fix it with a unified design language. I led the engineering side of that effort: the system itself, known internally as RDS, and the infrastructure other teams would build on. The public face of that work is live at ilovemyroku.com, Roku’s brand guidelines site, which I helped build.
The architecture decision
The choice that shaped everything else was to build on MUI rather than from scratch, then layer Roku’s design language on top.
Building from zero would have meant re-solving accessibility behaviour, component composition, focus management, and a long tail of interaction details that mature libraries have already worked through. MUI brought those. What it could not bring was Roku, so the work concentrated on the theming layer: brand tokens for colour, typography, spacing, and motion, plus component-level overrides wherever Roku’s design language diverged from MUI’s defaults.
The layering mattered for maintenance as much as for looks. Keeping Roku’s identity in a theme rather than in forked components meant upstream MUI upgrades did not break Roku styling.
Three platforms, five business units
Component libraries had to serve web, native mobile, and TV. TV is the interesting constraint: ten-foot viewing distances, remote-control focus navigation rather than pointers, and a rendering environment with far tighter performance limits than a browser tab. A token architecture that works on all three has to express intent, not pixels, so each platform can honour the same design decision in its own idiom.
Five business units meant adoption was the real problem to solve, not components. A design system only works if teams reach for it before they reach for their own solution, so the engineering work went into the things that drive adoption:
- A theme teams could extend without forking, so product-specific needs did not fragment the system
- Composition over configuration, so components combined predictably instead of accumulating boolean props
- Types as documentation, since a system written in TypeScript teaches its own API through autocomplete
- Incremental migration paths, because a system that cannot be adopted a screen at a time does not get adopted at all
What it changed
RDS became shared infrastructure rather than a library one team maintained. Teams onboarding onto the platform started from it, including Roku’s IoT organisation, which leaned on it heavily during its own onboarding. The design organisation reported design-to-implementation timelines shortening by 30 to 40 percent, and consistency improving across product surfaces.
The durable part was less visible than the consistency: product teams stopped rebuilding the same primitives and spent that time on product instead.
The public face: Roku’s brand guidelines site
As part of the same body of work I helped build ilovemyroku.com, Roku’s public brand guidelines site. It is the outward-facing counterpart to RDS: where the design system gives engineers tokens and components, the guidelines site gives everyone else the brand itself — logo usage, the colour and gradient system with hex and Pantone values, typography, the illustration and icon libraries, photography standards, and accessibility guidance on contrast.
Building it against the same token vocabulary the design system used meant the public guidance and the internal implementation could not drift apart, which is usually where brand systems fail.
What I would do differently
Design systems fail on governance more often than on code. The next version of this work would invest earlier in the contribution model — how a product team proposes a component, who reviews it, and how a one-off need becomes a shared primitive instead of a fork. The technical foundation was the easier half.
