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
Key Responsibilities + Outcomes
Riot never standardized an internal design system, but instead multiple teams with overlapping goals and needs supported their own individual design system.
My approach was guided by design principles and rather than imposing top-down standards, we researched each team's unique constraints, refining components that satisfied shared needs while allowing customization where needed.
Define repeatable patterns to create a system of best practices across teams
Reduce costs due to redundancies across teams
Simplify implementation by scaling down unnecessary UI instances
Implement best practices for text, colors, and data management
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
Dark Mode Buttons
Light Mode Buttons
Severity Colors
Text Colors
Icons
Information Modals
Selection Fields
Slimmed Down Font Selection
Information Density
Components that eased the ability for engineers to view 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
Header & Form Fields
Scannable Table Fields
Multiple Data Search Options
Primary & Secondary Data
Data Heavy Fields
Additional Table Data In Dropdown
Table Data
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 was 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.
To promote a culture of learning I did post-mortem with my engineering partners, to understand what happened. What surfaced was poor implementation practices, mainly a result of poor communication and documentation around implementation practices.
On previous work I had more hands on oversight during implementation to maintain quality. This clarified my desire to stay more closely connected with my cross-collaborative partners, to help complete delivery on our planned outcomes.
