Design Systems: Sling - Complexity Across 27 Devices
The Challenge:
As a TV streaming product, we had to account for different device manufacturers and their different frameworks - 3 front end engineering frameworks across 27 devices. To maximize quality, consistency, and efficiency, we wanted to control all front end changes from Figma and deploy UI changes from Figma to a QA environment.
What Made It Work:
The key to any successful design system is tight alignment with engineering from the start and constant testing on devices. From a leadership perspective it’s getting stakeholder buy-in by focusing on the value and end goal, while giving progress updates and setting milestones for the team. The principles don't change when complexity increases - they become even more important.
Case Study:
From a management perspective, the most important part was the team. I assigned a manager of mine who had built design systems in previous jobs. I hired a multi-talented Senior Designer and assigned an existing Senior Designer. I assigned 50% of another designer’s time who had a background in motion graphics, like me.
Separately, I shared my strategy and goals with Engineering Leadership, got their buy-in and advocacy, and they helped identify a few strong front end developers for the team.
The team took on the daunting challenge of building a single source of truth for a global design system across 3 front end frameworks that serviced 27 different devices.
But the critical, and most challenging piece was a Figma-to-Code pipeline that ingested the tokens and variables from Figma and translated them for the three different front end frameworks.
Pulling this off meant designers could push UI changes to all platforms at once, only requiring code merges and quick QA from developers. Dish patented our solution.
In translating designs from Figma to code, the token and variable architecture became extremely complex. The team collaborated with their engineering partners almost daily, despite being in different buildings and different countries.
I organized a weekly check-in, and included Engineering leadership. These were progress check-ins, brainstorms, reviews — whatever support the team needed.
As the team iterated through tests and different solutions, the token architecture had to be rewritten several times, but each time it got a little simpler and more durable.
On the design side, we debated pixels, type scales, color values, and corner radii, as well as illustration styles and AI-generated image styles. We involved the rest of the team, setting up weekly design reviews to make sure use cases are covered and to involve the team on design decisions — a standard practice of mine.
I gave the team the air cover they needed so they could have the time and autonomy to build things right.
This involved regular status updates and demos of their progress, always reminding stakeholders of what we were building toward and why we were doing it — the big picture.
Finally, I worked with Product leadership to identify the right projects to either refactor or build using the new global design system. These were a combination of net new pages and existing pages that were getting a significant UX update (a page that needs a significant UX update usually requires enough front end changes to warrant refactoring with a new component library).
The first page to use the design system was a new Collection page template, followed by a redesigned Guide and Video Player experience.
Read about my other Design System projects: