Riot Games MVP Internal Tooling 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.
CLIENT
Riot Games - DevPlat
CLIENT
Riot Games - DevPlat
Company
Riot Games - DevPlat
Role
E2E Design
Role
E2E Design
Role
E2E Design
Problem Statement
Problem Statement
Problem Statement
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.
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.
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.
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.
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.
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.
Scalability
Scalability
Scalability
Focus on scalable baseline patterns and methodology
Navigation
I improved upon initial plan from another designer to view more options via hover, which would otherwise provide some UX challenges.
Accidental mouse movement could change what is being presented and cause friction. I organized a pivot to expandable elements, with nested content that went one level deep.
This improved usability, while still being scalable.
Focus on scalable baseline patterns and methodology
Navigation
I improved upon initial plan from another designer to view more options via hover, which would otherwise provide some UX challenges.
Accidental mouse movement could change what is being presented and cause friction. I organized a pivot to expandable elements, with nested content that went one level deep.
This improved usability, while still being scalable.
Before - Hover to show more options, which could cause friction.
(1 of 2)
After - Hover to view more was removed, features had clickable drop downs to improve usability.
(2 of 2)
Buttons
For the MVP, I reduced our options from the initial wider scope to simplify implementation and maximize cost efficiency.
Buttons
For the MVP, I reduced our options from the initial wider scope to simplify implementation and maximize cost efficiency.
Focus was two sizes - action-based colors (red, green), and two generic colors (blue, black). Colors were adjusted to hit an accessibility balance between AA and AAA standards, as the latter could be too restrictive.
(1 of 4)
For accessibility, users should be able to see all options, even if inactive, so adjustments were made to achieve that.
(2 of 4)
"Ghost buttons" were replaced by regular link text.
(3 of 4)
Text-only or icon-plus-text options met most of our needs, while also adding limited use of a dropdown version for controls.
(4 of 4)
Focus on scalable baseline patterns and methodology
Navigation
I improved upon initial plan from another designer to view more options via hover, which would otherwise provide some UX challenges.
Accidental mouse movement could change what is being presented and cause friction. I organized a pivot to expandable elements, with nested content that went one level deep.
This improved usability, while still being scalable.
Focus on scalable baseline patterns and methodology
Navigation
I improved upon initial plan from another designer to view more options via hover, which would otherwise provide some UX challenges.
Accidental mouse movement could change what is being presented and cause friction. I organized a pivot to expandable elements, with nested content that went one level deep.
This improved usability, while still being scalable.
Before - Hover to show more options, which could cause friction.
(1 of 2)
After - Hover to view more was removed, features had clickable drop downs to improve usability.
(2 of 2)
Buttons
For the MVP, I reduced our options from the initial wider scope to simplify implementation and maximize cost efficiency.
Buttons
For the MVP, I reduced our options from the initial wider scope to simplify implementation and maximize cost efficiency.
Focus was two sizes - action-based colors (red, green), and two generic colors (blue, black). Colors were adjusted to hit an accessibility balance between AA and AAA standards, as the latter could be too restrictive.
(1 of 4)
For accessibility, users should be able to see all options, even if inactive, so adjustments were made to achieve that.
(2 of 4)
"Ghost buttons" were replaced by regular link text.
(3 of 4)
Text-only or icon-plus-text options met most of our needs, while also adding limited use of a dropdown version for controls.
(4 of 4)
Focus on scalable baseline patterns and methodology
Navigation
I improved upon initial plan from another designer to view more options via hover, which would otherwise provide some UX challenges.
Accidental mouse movement could change what is being presented and cause friction. I organized a pivot to expandable elements, with nested content that went one level deep.
This improved usability, while still being scalable.
Before - Hover to show more options, which could cause friction.
(1 of 2)
After - Hover to view more was removed, features had clickable drop downs to improve usability.
(2 of 2)
Buttons
For the MVP, I reduced our options from the initial wider scope to simplify implementation and maximize cost efficiency.
Focus was two sizes - action-based colors (red, green), and two generic colors (blue, black). Colors were adjusted to hit an accessibility balance between AA and AAA standards, as the latter could be too restrictive.
(1 of 4)
For accessibility, users should be able to see all options, even if inactive, so adjustments were made to achieve that.
(2 of 4)
"Ghost buttons" were replaced by regular link text.
(3 of 4)
Text-only or icon-plus-text options met most of our needs, while also adding limited use of a dropdown version for controls.
(4 of 4)
Information Density
Information Density
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.
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.
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.
"Inter" provided the needed information density and clarity, but with fewer variations to improve implementation and reduce drift.
(1 of 5)
I built a grid tracking the fonts in use and their locations, helping identify what needed to be replaced or removed.
(2 of 5)
Font usage locations were identified, with additional research on other internal portals (not shown here) to lay the foundation for future alignment.
(3 of 5)
Alignment was created with the broader internal typography system overhaul that was in progress.
(4 of 5)
Options were streamlined around weights and headers, to simplify implementation and define standards.
(5 of 5)
"Inter" provided the needed information density and clarity, but with fewer variations to improve implementation and reduce drift.
(1 of 5)
I built a grid tracking the fonts in use and their locations, helping identify what needed to be replaced or removed.
(2 of 5)
Font usage locations were identified, with additional research on other internal portals (not shown here) to lay the foundation for future alignment.
(3 of 5)
Alignment was created with the broader internal typography system overhaul that was in progress.
(4 of 5)
Options were streamlined around weights and headers, to simplify implementation and define standards.
(5 of 5)
"Inter" provided the needed information density and clarity, but with fewer variations to improve implementation and reduce drift.
(1 of 5)
I built a grid tracking the fonts in use and their locations, helping identify what needed to be replaced or removed.
(2 of 5)
Font usage locations were identified, with additional research on other internal portals (not shown here) to lay the foundation for future alignment.
(3 of 5)
Alignment was created with the broader internal typography system overhaul that was in progress.
(4 of 5)
Options were streamlined around weights and headers, to simplify implementation and define standards.
(5 of 5)
Tables
Top down data organization via Tabs
The most relevant data per feature was front and center, nesting additional content inside a dropdown.
Text fields are easier to scan when left aligned.
Number fields are more readable when right aligned.
Tables
Top down data organization via Tabs
The most relevant data per feature was front and center, nesting additional content inside a dropdown.
Text fields are easier to scan when left aligned.
Number fields are more readable when right aligned.
Tables
Top down data organization via Tabs
The most relevant data per feature was front and center, nesting additional content inside a dropdown.
Text fields are easier to scan when left aligned.
Number fields are more readable when right aligned.
Safety & Trust
Safety & Trust
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.
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.
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.
More often than not, developers had no clear guidelines about features. Best practices, how features work, and the ability to find timely support was a challenge.
Providing proper context along with templated workflows following best practices, lowered the knowledge bar on complex experiences. Providing an easy path to specific feature help (via support ticket or documentation) streamlined troubleshooting on both ends, including providing a path to knowledge within our documentation.
More often than not, developers had no clear guidelines about features. Best practices, how features work, and the ability to find timely support was a challenge.
Providing proper context along with templated workflows following best practices, lowered the knowledge bar on complex experiences. Providing an easy path to specific feature help (via support ticket or documentation) streamlined troubleshooting on both ends, including providing a path to knowledge within our documentation.
More often than not, developers had no clear guidelines about features. Best practices, how features work, and the ability to find timely support was a challenge.
Providing proper context along with templated workflows following best practices, lowered the knowledge bar on complex experiences. Providing an easy path to specific feature help (via support ticket or documentation) streamlined troubleshooting on both ends, including providing a path to knowledge within our documentation.
Final Outcomes
Final Outcomes
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.
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.
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.
