05 / Design system
SlingTV Design System.
The problem
Sling TV ships on a lot of surfaces. There is the streaming app on televisions, apps for phones and tablets, a public website and several internal platforms. Each had its own design files, built at different times, in different tools. A button on one platform did not always match the button on the next, and nobody could say which file was current.
That cost time in two places. Designers rebuilt the same pieces from scratch for every new feature. Engineers received mockups that looked right but were not made of anything they could reuse, so they rebuilt them too. The company wanted consistency and efficiency across every platform, and a faster route from an idea to production code.
What I built
I came in as a freelance architect, so the first job was to learn what each team needed before drawing a single component.
- 01
Auditing the existing files
I talked with stakeholders on each platform, then audited what they already had. The audits went platform by platform: Android tablet settings and video player, browser screens, in-app purchase. Each became a task with an effort estimate and a link to its source file. By the end I knew what to keep, merge or retire.
Planning the library update, task by task. - 02
Running it as a backlog
I set up an Airtable base so the work had a visible process. Every template and component became a card, moving from backlog to in progress to reviewing to done, filterable by platform. The reviewing column was the review system: nothing counted as finished until a second person had looked at it.
The design system task board. - 03
Color and type foundations
I began the library with tokens. Interface colors, brand and UI gradients and neutrals went into named swatches, and older colors stayed visible but marked retired so nobody picked them by accident. Type styles got a scale with size, line height and tracking noted. Every component after this built on those values.
Color tokens. - 04
Components with variants
I rebuilt imported Sketch components as nested Figma components with variants and properties. A button, for example, has type, state and icon options in one component instead of a dozen separate drawings. Retired styles sat in the same menu, labelled, so older designs could still be opened and migrated.
A button with its variants and properties. - 05
Kits for every platform
I organized the work into libraries, one per platform: the 10-foot interface, Android, iOS, mobile, tablet, web browser and the website. Alongside them went a style guide, spec tools, a developer handoff template, device templates and sample art. A designer could open one kit and have what that platform needed.
The kit library, one tile per platform. - 06
Documentation that builds itself
Last, I built a documentation site that generates itself from the system. Tokens, colors, buttons and the message bar each get a page with a status, examples at desktop and mobile breakpoints, and code. Because it is generated, the docs do not drift away from the design files.
Documentation for tokens and components.
The solution
The finished system is a set of connected libraries in Figma with a generated documentation site on top. It holds 300 shipped components, plus page templates, platform kits, prototyping kits and spec tools. Designers assemble screens from real components, and engineers read the same names and values in the docs and in Figma's code panel.
The idea that made it work was designing the process as carefully as the pieces. Every component came from the same token foundations, passed through the same review column and landed in the same documentation. Prototypes for features like picture-in-picture and Apple TV remote interactions used the real components, so tested designs were already close to build.
What I delivered
- Figma libraries for TV, mobile, tablet, browser and website
- Color, type and spacing tokens with retired styles marked
- Page templates, starters and responsive navigation component
- Prototyping kits, spec tools and developer handoff template
- Self-building documentation site
- Airtable-based development and review process
Value added
For people using it
Viewers got interfaces that behaved the same way from the television to the phone to the website. Navigation, buttons and focus states followed shared rules, so what they learned on one screen carried to the next.
For the business
Features reached production in real components faster, across the apps, website and more. Reuse meant one fix could reach every platform, and new work stopped starting from a blank file.
For the team
Designers stopped redrawing the same pieces. Engineers got specs, code and a handoff template that matched the files. A visible backlog and review step meant everyone could see what was ready and what was not.
The result
300 components shipped, and design reached production 500% faster, in real components across the apps, website and more. The system now covers the streaming app, mobile and tablet apps, the website and internal platforms.
Results
- 300components shipped
- 500%increase in the speed from design to production, in real components across the apps, website and more
What I took from it
The audit and the backlog did as much for adoption as the components did. People trusted the system because they could see where their own screens were in the queue. I would show that queue to stakeholders earlier on my next system.