THE ROKU OS DESIGN SYSTEM

As Director of Design Systems at Roku I was responsible for the design systems that powered TV, Web, Accessibility, and UX writing initiatives across the company. This write up gives insight to the effort that went into standing up the Roku OS design system. Since Roku does not publicly share the working files, the best way to see what we built is through this onboarding video I created for new team members:

0-1 Design System for Roku OS

Used by 135+
UX Designers

200+ Figma
Components

150+ Pages of
Documentation

INTRO

The Roku OS Design System is not typical by any means. Since our platfom a custom built embedded software (NOT iOS, Android, Web, Windows, or OS X) there was no precedent on how to build the design system, which introduced unique challenges.
‍
To guide us on this journey, I use the maturity model created by Ben Callahan (linked below) as a guide to what we created. Ben is able to break down the stages of design system evolution with an uncanny resemblance to my experience at Roku.

MY ROLE

Director | Evangelist | Creator | Designer

I was one of the original designers to create Roku OS. The design system is a culmination of my work over the several years I spent at Roku. Most of the work seen here (iconography, component design, color choices, typography, etc) was designed by me.

I was responsible for the overall organization of the Roku Design System.

Design System Maturity

Stage 1

Leading up to v 1.0

Stage 2

Adoption

Stage 3

Teenage Years

Stage 4

Happy Healthy Product

STAGE 1: LEADING UP TO  V1.0

The journey began back in 2018 when I was UX Creative Director for a rapidly growing UX team. The design artifacts I created for the original Roku OS back in 2012 were mostly in photoshop and powerpoint. I quickly realized that we needed a more scalable workflow to support the team.
‍
A similar issue was happening on the engineering side. There was little documentation or guidance when developing for Roku OS, and the team was growing at an incredible rate. My engineering counterpart and I proposed to the larger organization the need for a centralized “Design Integrity” team.

I created goals for this team. I outlined projects and features that the team would be responsible for, as well as a roadmap with timelines dependent on the amount of resources available to the team. I began to evangelize at every product and engineering event that would have me to speak to the value that this team would bring.

Persistence paid off. I transitioned to Director of Design Systems at the beginning of 2020, and formed the UXDS (UX Design Systems) Team, which included myself and my engineering partner. The two of us tackled a few obvious problems that were defined in my roadmap, and began to build a case for more resources. The organization saw the value in our work, and grew the team to include 3 additional designers and 2 additional engineers.

We now had resources to start creating artifacts for the design system. The UX team had largely moved to Sketch by this time, and were passing around a Sketch file that had a few out of date screens, components, and icons. We surveyed the team about their pain points with the current design process as well as requests for the Design System. The talented UXDS team took their responses and crafted the first ever Roku Design System in Sketch.


‍

STAGE 2: ADOPTION

The UX team was delighted to have access to an up-to-date and accurate Sketch Library. But in order to address the team’s concerns about having the latest and greatest, we needed to adopt Abstract for version control. There was hesitation with learning Abstract and we knew right away that adopting this workflow would be an uphill battle.

We surveyed the team again asking how they would you feel if we moved the Design Library to Figma. While the majority of the team would have to learn this new tool, overall sentiment was positive. The UXDS team went to work and was able to rebuild the design library in Figma in just a couple of months. We relaunched the Design Library alongside an internal Figma Week event, where UXDS made ourselves available to give demos and onboard the team to Figma. Within weeks, the entire UX team had adopted Figma as their primary design tool.

STAGE 3: THE TEENAGE YEARS

Everything was on track and the teams were happy with Roku • TV Design System. As a parallel effort we also developed a design system for Roku Web. And as product features became more complex, they often required users to jump between web and TV experiences to complete tasks. Designers would link both web and TV Figma libraries to the same file for these projects.
‍
At the same time, TV OS engineering teams were investing in additional technologies that allowed software to releases more frequently. These new technologies were on different timelines than the Firmware, where all the UI information was stored. This led to elements such as color, artwork, and components being duplicated in multiple areas of the code.
‍
New designers would join the UX team, often paired with new engineers to work on a project developed using a new technology. Since it was common to have both web and TV libraries linked to a project, web-like components started to appear in the TV interface. And Once UI shows up in shipping product, the team assumes they can use the component for their feature. Inconsistency was spreading like wildfire.

This was an issue that we never had to worry about when there was only a single UI repository in the software. UXDS design and engineering resources we’re being consumed by tech-debt projects to untangle the mess.
‍
In the meantime, Roku was aligning all product initiatives to a handful of KPI’s, one of which was velocity. Having a fine-tuned design system that is fully embraced by the org would greatly increase the speed at which product is developed. But the UXDS team would need more resources to make that happen. Ultimately, the company shifted all resources to revenue generating projects, leaving the Roku Design System stuck in the awkward teenage years for the time being.


‍

STAGE 4: A HAPPY HEALTHY PRODUCT

There is still bright future ahead for the Roku TV Design System. Figma has become central to product development at Roku, and many of the engineering teams are realizing the benefit of working directly in Figma. As the TV software stack is also in this awkward teenage state, there is opportunity for the next generation technologies to rely on Figma as the source of truth.
‍
The Roku Web Design System is already reaping the benefits of a streamlined workflow. The engineering and design teams are working directly in Figma and have built a tight integration with Storybook. The only credit I can take for this work is staying out of the way and giving room for the talented designers and engineers to do their best work. My focus was to replicate this success in the TV design system.
‍
In attempt to get there, the UXDS team started work on design token system to generalize the UI information stored in Firmware. We brainstormed with our engineering partners the idea of Figma plugin that would export these tokens directly into our Git software repository. The export would live in a location where all software frameworks had access to it. I named this repository Common UI Library.
‍
Since the Common UI Library could be updated at anytime outside of a software release, it would be the easiest way to retrieve and store UI properties. The different technologies could format the JSON exported from Figma without the need to duplicate the information locally. The source of truth would be maintained in Figma and accessible to everyone. Next step would be to built it!

The Common UI Library would be the fastest, most frictionless way to obtain UI information, while maintaining consistency between the Figma Library and the Software. Consistency = Quality. And if you can build quality products quickly, you have a happy healthy product. And most likely, you also have a proven design system powering it all.

‍

FINAL THOUGHTS

In my experience, building a design system is a messy business. It requires full commitment from across the product organization. It requires dedicated resources to maintain and evolve the system to meet the needs of the ever changing product. It requires governance and looking at new ways the teams can contribute back to the design system, while maintaining parity with the product. I’d love to understand the unique challenges your team is facing, and craft a design system that can scale and be successful in your organization.
‍

Design Maturity Presentation

I highly recommend checking out Ben Callahan's video that talks about the design system maturity model mentioned at the top of the page.
CHECK IT OUT

Next Steps

Thanks for making it this far. If you have any feedback or questions about this case study, please send me a note. If you'd like to learn more about my experiences, check out another case study below.

Roku Themes

Learn how the Roku OS Theme capability transformed from a dev tool to a multi million dollar business
View Case Study

Yahoo! Livestand iPad App

Learn how Yahoo! attempted to magazine-ize the web through the Livestand iPad App
View Case Study

Yahoo! Entertainment iPad App

Learn about how my team and I were given the opportunity to seed the iOS App Store with this top 10 iPad App
View Case Study
Powered by Webflow
© Jeff Anderson 2024