0-1 Enterprise Design System
MVP Enterprise SaaS design system for internal game management tools at Riot Games, creating a safer workflow and improving developer efficiency by designing solutions informed by the needs of developers.
Company + Project Intro
Project Overview
Why would developers benefit from their own design system?
Value Proposition
Players and developers have distinct goals and needs, and Riot had a player facing system, but not one for internal tooling. A unified tooling design system could streamline development, ensure consistency across teams, reduce technical debt and reliance on external frameworks.
Objectives
Create a unified design language speaking to the needs of our specific user base
Reduce design + technical debt across silos
Standardize workflows for faster deployments
Accommodate dense information for power users
Support both technical and non-technical user personas
Scale to support future internal tooling across Riot
Maintain developer confidence (safety patterns)
Context & Goals
Riot never had a standardized internal design system, and as a bottom up org, where workflows often were silo'd, multiple teams would spin up their own resources. Maintaining multiple design systems across organizations over time becomes increasingly costly and unscalable, despite having related user needs.
Our approach was guided by four core design principles. Rather than imposing top-down standards, we researched each team's unique constraints and built components that satisfied shared needs while allowing customization where needed.
Process & Solutions
Scalability
Riot suffered from bottom up, silo'd thinking across teams, which meant there was often duplicate work created on different teams which should have been shared to reduce overhead. With this project, we had the unique chance to create a single, broadly usable design system that worked appropriately across teams.
Show me how it was done...
Delivered Work
Information Density
These components helped developers display and interact with complex data.
Component: Dense Table Purpose: Optimized for high-row-count datasets. Sticky headers, sortable columns, filterable cells, pagination. Prioritizes information over whitespace.
Component: Collapsible Section Purpose: Progressive disclosure. Show summary by default, expand on click for details. Reduces cognitive load without hiding information.
Component: Multi-Select Filter Purpose: Complex filtering for large datasets. Users select multiple criteria, see results update in real-time. State persists per user.
Component: Severity / Status Badge Purpose: 5-level severity system (Dev, SEV1-5) using color + icon + text. Makes priority obvious at a glance.
Component: Data Summary Card Purpose: Show key metrics (count, average, percentage change). Used in dashboards for quick scanning.
I want to know why this was important...
Delivered Work
Safety & Trust
How to make developers feel confident making changes?
These components helped developers feel confident and in control.
Visually distinct button styling making risk obvious.
Informative confirmation dialog/modals for destructive actions to reduce errors.
Reducing accidental deletions following Github "type to confirm" patterns.
Disabled form fields when actions aren't allowed, and descriptive tool tips.
Sortable history of actions on a resource, helpful for retracing prior actions.
Show me why this was invaluable to the goals...
Delivered Work
Key Insights
What we learned from discovery and research
Insight 1: Design systems are equal parts design and organizational alignment.
The hardest part wasn't designing components—it was getting five teams to agree on one system when they'd built five different ones. We needed stakeholder buy-in, clear value messaging, and proof of impact before anyone would adopt.
Insight 2: Customization is a feature, not a bug.
Teams wanted consistency, but they also wanted flexibility. The answer wasn't "use it exactly as shipped"—it was "use the base system, customize the tokens and theme for your team's needs." This balance made adoption possible.
Insight 3: Some developers are power users, some are new, or less familiar users.
We designed for both - Power users required granular code level customization. Less familiar users lack that same context, and would benefit from more of a guided experience.
Insight 4: Safety patterns unlock adoption.
Trust that we're building a system that lowers live incidents, confidence increases for users. Once they understand these tools despite being new to them, were built with their workflow improvements in mind, trust in a new system could be established, and built upon.
Final Outcomes
What was the result?
The launch of the design system was an initial success, but shortly after all the hard work was forced to be removed for an out of the box option.
The project started as a two team collaboration, though one quietly pulled back mid project.
Fewer resources led to inconsistent UI implementation, resulting in constant build breaks.
Despite our best efforts, by the time the problems were identified, it became less work to use an external framework than fix all the existing problems.
Despite replacing the custom UI with an external framework, we were able to retain the "How & Why" patterns that provided safety, trust, and information density required for our workflows.
