Class project · Unofficial
Spring 2026
SYNC: An Unofficial Twitch Design System
Role
UX Designer
Team
Shasteny Maclang, Tracy Khiew, Aayushi Bharadwaj, Rex Fukuchi
Timeline
10 weeks
Platform
Web
Tools
Figma Zeroheight Google Workspace
Twitch is where millions of broadcasters and viewers gather every day around gaming, music, art, and culture. As a platform grows like that, small inconsistencies creep into its design, and every new page gets a little harder to build. Sync is my team’s answer: an unofficial design system that tackles consistency, accessibility, and scalability (with a whole lot of purple).
This is a conceptual design system created for educational purposes. Sync is not affiliated with or endorsed by Twitch Interactive, Inc. All Twitch branding, UI patterns, and visual references belong to their respective owners.
The TLDR: Ten weeks, four designers, and one very purple design system
In a 10-week class project, four of us built Sync from the ground up: we audited three Twitch pages, set the foundations (color, typography, icons, and spacing), built components with atomic design, tested the UI kit with other designers, and documented everything in Zeroheight.
I designed all of Sync’s badges, chips, and cards, built the typography styles, and wrote the documentation for typography, badges and chips, cards, and the accessibility pages.
A few pieces from the Sync UI kit
Where Twitch’s interface drifts: inconsistent type and undefined states
Before designing anything, we audited Twitch’s interface and found a few undefined elements:
Typographical inconsistencies. Certain font styles were applied inconsistently or only in single-use scenarios.
Unclear interaction states. Hover and focus states were underdefined, creating ambiguity for anyone navigating the platform.
Without a centralized system, design decisions get made in isolation, and pages drift apart visually. The audit gave us a clear mission: specific elements to fix and components to standardize.
Four steps from audit to documentation
We worked in four stages, each one building on the last.
- 01
Website audit
- UI inventory
- Catalogue inconsistencies
- 02
Foundations
- Color
- Typography
- Spacing
- 03
Components
- Buttons
- Cards
- Navigation, and more
- 04
Documentation
- Do’s and don’ts
- Accessibility guidelines
- Resources
Auditing three Twitch pages before designing anything
We inventoried the key visual elements, components, and interactions on three pages: the landing page, the livestream page, and the browse category page. Laying them out side by side, from navigation and type to buttons, forms, and color, is where the inconsistencies showed up.
Four principles that guided every decision
Before building, we sat down together and collated principles that aligned with Twitch’s own principles and our goals.
Four layers of color tokens, so one change reaches every component
Our first phase was building the core visual language: color, typography, icons, and spacing. For color, we built tokens in layers, starting from a raw hex value and building up to an alias that names the type of color, what it’s used for, and which interactive state it belongs to.
As we started building components, we realized our first palette needed more range. We added clearer hover colors so interactive states stand apart from the default, and lower-opacity colors for the overlay chips on our cards.
- Alias
bg/interactive/default - Semantic
purple/500 - Primitives
purple - Color values
#9147FF
A spacing scale everyone pulls from
We introduced a spacing scale to bring alignment across every surface, documented as tokens so a designer building a new page and a developer implementing a component use the same values.
Because we were all pulling from the same primitives, updating a rule meant our components would sync to the change. Building components also exposed a gap: we hadn’t defined radius tokens yet, so we went back and standardized them.
| Token | Value | Visual |
|---|---|---|
spacing-100 | 4px | |
spacing-200 | 8px | |
spacing-300 | 12px | |
spacing-400 | 16px | |
spacing-500 | 24px | |
spacing-600 | 32px | |
spacing-700 | 48px | |
spacing-800 | 64px |
Icons with consistent rules
Starting small: atoms, molecules, organisms
We took an atomic design approach, identifying Twitch’s smallest elements and building up to more complex components. Atoms included badges, chips, toggles, and buttons. Molecules included cards, navigation elements, and menus. Organisms were the most common component clusters on the site: the streamer side menu, the home page stream carousel, and the livestream card grid.
Starting from a common baseline helped us avoid errors and inconsistencies, and let each of us work independently while keeping the same cohesion and brand identity.
01 Atoms
02 Molecules
03 Organisms
Badges, chips, and cards that stay readable on any thumbnail
Now, the really fun part: learning Auto Layout and designing components. I personally designed all of Sync’s badges and chips, as well as the cards. The two were intrinsically tied together, so owning both gave me more control to test and fix issues as they came up. I hadn’t had much practice with Auto Layout before this project, and once it clicked, adjusting components or building new ones from existing ones was a breeze.
Badges and chips
The set covers the live badge, notification badge, viewer count, verified badge, red-dot live indicator, livestream tags, and clip information chips. They’re the building blocks of the cards, so each one needed rules for how and where to use it and how to adapt it for accessibility, which I documented in Zeroheight.
Cards
Cards are the backbone of discovery on Twitch, letting people preview livestreams or browse categories they might be interested in. I made the category and livestream preview cards as customizable and easy to drop in as possible: each one comes with set dimensions, overlay behavior, badge placement, and responsive considerations, plus Figma properties for boolean toggles and editable text.
Buttons with a focus state you can actually see
We structured buttons into a clear hierarchy: primary (default and inverse), secondary, and tertiary, each with four defined states: default, hover, focus, and disabled.
The key accessibility improvement was a clearly visible focus state, which addresses a gap in Twitch’s existing UI. We also refined the hover state to a darker grey so it separates more clearly from the default, and as we worked through more accessibility standards, we added color tokens to make sure we were meeting WCAG guidelines.
| State | What we defined | Why |
|---|---|---|
| Default | The resting style for primary (default and inverse), secondary, and tertiary buttons | One consistent baseline across the hierarchy |
| Hover | Refined to a darker grey | A more distinct separation from the default state |
| Focus | A clearly visible focus state | Addresses a gap in Twitch’s existing UI |
| Disabled | A defined disabled style for every button type | Completes the same four states for every button |
Could another designer pick it up? Testing the kit before documenting it
Before writing documentation, we shared the UI kit with three fellow designers. This round was less about Twitch’s end users and more about us: could another designer pick up the kit and use it without confusion?
Their feedback surfaced two areas to improve:
Labeling. Some component names were ambiguous and didn’t clearly communicate the component’s purpose or variant.
Categorization. Some components were grouped in ways that didn’t match how designers naturally searched for them.
It also pushed us to treat Sync as a real product we’d keep iterating on, and to start thinking about how we’d introduce it to Twitch and get stakeholders to buy in.
Writing the why, not just the what
Next step: making sure anyone could use Sync, not just the people who built it. We built the documentation in Zeroheight, covering every component with usage guidance, dos and don’ts, visual examples, and accessibility requirements. We wrote for designers, engineers, and managers, with extra resources for anyone who needs more context.
My main contributions to the documentation:
Typography: font families, size and weight scales, and accessibility guidance for contrast and spacing.
Badges and chips: usage rules, interactive behavior, and accessibility notes for every badge and chip type.
Cards: anatomy, overlay contrast requirements, keyboard navigation, screen reader behavior, and motion considerations.
Accessibility pages: dedicated sections for typography and cards, covering WCAG requirements, touch targets, and assistive technology considerations.
Rather than writing rules for their own sake, the goal was to explain the reasoning behind each decision, so designers meeting Sync for the first time understand not just what to do, but why.
Ready, set, LIVE: pitching Sync
We presented Sync to the class as a full design system pitch: the inconsistencies we found in Twitch’s UI and why they mattered, how our principles guided every decision, highlights from our tokens, typography, cards, and accessibility improvements, and who Sync is for.
This first pitch focused on the problems Sync solves and why it’s an essential tool. Next time, we’d include a live demo of the UI kit and go deeper on our roadmap and adoption plan.
Looking ahead: solidify, expand, deepen
We mapped Sync’s future in three phases: stress-test the components we built, expand the library to cover Twitch’s chat system and more pages, and deepen the accessibility and responsive guidelines as the system grows.
Solidify
Stress-test what’s built
UI kit testing
Audit components across all documented states
Q1 26Documentation review
Verify all Zeroheight pages are complete
Q1 26Accessibility audit
Verify contrast, focus, and hover states
Q1 26
Expand
Grow the component library
Chat components
Messages, emotes, moderator actions
Q2 26New page coverage
Components beyond the three core pages
Q2 26Component variants
Additional sizes, themes, and edge cases
Q3 26
Deepen
Mature the system’s foundations
Expanded accessibility
Guidelines for all new components
Q3 26Motion and animation
Tokens and reduced-motion guidelines
Q4 26Responsive guidelines
How components adapt across breakpoints
Q1 27
What we delivered
Sync was a 10-week class project, not a shipped product. In that time, we delivered:
A UI kit in Figma, built on shared color, typography, icon, spacing, and radius foundations
Documentation in Zeroheight, with usage guidance, dos and don’ts, and accessibility requirements
A pitch deck presented to our class
A three-phase roadmap for what comes next
Sync isn’t affiliated with Twitch, and it hasn’t been adopted by Twitch or tested with Twitch’s users.
What I’m taking with me
Start with the problem, not the solution
The audit was the most important thing we did. Without it, we’d have built a system on assumptions instead of evidence, and we’d have struggled to narrow our scope.
A design system is a living product
It needs to be tested, iterated on, and documented with the same care you’d give any user-facing interface. Finding gaps like our missing radius tokens mid-build is what made that click for me.
Documentation is design
The words you choose to describe a rule are as intentional as the component itself. Clear language can make or break a system.
Accessibility is structural, not supplemental
Our most meaningful accessibility improvements happened at the foundation level, not as a last-minute check. Keeping accessibility at the forefront meant it was built into every component, and we rarely had to go back and change foundational elements.
Beyond the system
Sync started at a whiteboard, with the team working through the first iteration of our color and spacing tokens together.
Shasteny Maclang