Enterprise MVP design system for game tooling at Riot Games
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.
1. Problem Statement
Why would developers benefit from their own design system?
Value Proposition
Where players expect big and bold layouts that inspire joy, internal workflows require information density and complexity, with added safety guard rails. Internal mistakes can have large scale ramifications with ripple effects around player trust, and costs associated with repairing that trust.
The goals were:
Create a centralized, scalable design system that simplifies developer workflows.
An experience that works across teams prioritizing dense and scannable data, increased build safety, with design support in place.
Forward thinking system that might allow for all internal tooling to use one system, reducing maintenance costs by deprecating existing duplicate systems.
Additionally, alignment at large companies can be a challenge. Even more so when individual teams don't always know what other teams are building, what problems are being solved, or the individual nuances involved with each solution required.
Cross-org design alignment isn't just about swapping out the color of one button for another, it involves:
Planning time on the roadmap to deprecate the old and implement the new.
Making sure the solution for one team can meet the needs of another.
Identifying individual needs, and then addressing them appropriately with one off solutions that align with the current process, or migrating teams to a shared and aligned solution.
Onboarding teams and users to the new processes.
2. Scalability
Focus on scalable baseline patterns and methodology
The initial outline from the other designer needed adjustments. So I made changes to improve the UX, usability, and streamline efforts around implementation future maintenance.
Navigation
Before | After |
|---|---|
Hover to pop out menu increased usability challenges and potential user frustration. An accidental mouse movement could removing the menu options from view, and frustrate users. | By changing interactions so the menu is accessible through clicks, we improved usability and removed potential friction. Defining the pattern of sub menus going only one level deep lowers the potential of user confusion. |
Buttons
Before | After |
|---|---|
#1 - The first pass was a "kitchen sink" of options, which would increase time and cost to implement and maintain and I also had WCAG/accessibility concerns with certain colors. | To streamline options, I reduced the options to two sizes. Colors were scaled back focusing on action-based colors (red, green), and two generic colors (blue, black), and adjusted to hit an accessibility balance between AA and AAA scores. |
#2 - Inactive buttons weren't always accessible, or clear to the user wasn't currently available. This went against our UX "guide not hide" pattern. | For accessibility, users should be able to see all options, even if inactive, so adjustments were made to improve clarity. |
#3 - Ghost buttons served the same purpose as links, and felt like overkill. | One instance of link text replaced each previous button size and color. |
#4 - Having every options include a leading icon + text + dropdown was overkill. | Text-only or icon-plus-text met most of our needs, but there would be occasional need for dropdown options. Leading icon + text were retained for clarity, along with minimal use cases of a dropdown. |
3. Information Density
Balancing density of information for easy scanning and readability
Typography
This project was key to growth of the company, so I needed to account for future features and work across products.
4. Safety & Trust
Increased safety & improved knowledge to build user confidence and reduce live incidents
Destructive Actions
Friction is often spoken about negatively, but is use protectively here, and thus beneficial in this scenario.
Deletion might be the end goal, an accidental live incident is more problematic than additional pre-cautionary steps.
Guided instructions pace the process while providing context around destructive actions.
Using an outlined button with red and an icon for a destructive action, reduces emphasis while retaining action clarity.
The "type to confirm" code is modeled after destructive action prevention in github.
Clear cause and effect and instructions provide next step guidance.
5. 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. Despite best efforts, implementation was inconsistent and incorrect across a variety of UI, which ended up causing repeated build breaks when other teams integrated their workflow.
The project started as a collaboration between my team and another internal team to pool resources, but eventually the other team quietly reallocated resources. This meant the project lacked the appropriate resources, and by the time the problems were identified, it became less work to use an external framework than fix all the problems with the current elements.
Though much of the UI was removed for templated elements, the thinking and theory behind HOW and WHY use cases remained, despite moving to an external framework. This allowed us to retain the big picture requirements within use cases, creating safety and trust, with density of information for developer workflows.