Developer Informed MVP Design System

Enterprise SaaS design system for Riot's internal game management tools, creating a safer workflow and improving developer efficiency.

CLIENT

Riot Games - Developer Platform

CLIENT

Riot Games - Developer Platform

CLIENT

Riot Games - Developer Platform

Role

Lead Designer

Role

Lead Designer

Role

Lead Designer

Gamer V Developer
Gamer V Developer
Gamer V Developer

Problem Statement

Why do we need another design system?

Value Proposition

Players and developers have distinct goals and needs, a unified tooling design system could streamline development, ensure consistency across teams, reduce technical debt and reliance on external frameworks.

Our 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.

Developr UI Elements

Scalability

Focus on scalable baseline patterns and methodology

Tables

These are data intensive workflows we were building towards, and needed to present lots of discernible content, which was also scannable.

  1. Helpful feature context telling users what they're looking at, with high level instructional context.

  2. Clear overview of current selection results at top of table.

  3. Simple search for relevant data in an organized fashion, at the top level, with some features also using tabs to separate relevant data into their own silo's for added granular context (ex - active vs inactive).

  4. Information is aligned and optimized to scan - text + mixed data left aligned, numerical (not shown) right aligned.

  5. Patchlines & Releases are UUID/unique, so to improve information discovery we show the unique name as a direct link to the full dataset.

  6. Focus on top level data to reduce information overload, with additional data available to view in a dropdown, which is also able to be interacted with.

  7. Create CTA always consistently on the top right and accessible without deterring from focus on current data, and when the functionality is unavailable the UI presents as inactive.


Feature With Table + Data

Navigation

I improved upon initial plan to view more options via hover, which could provide some UX challenges.

  • Accidental mouse movement could change what is being presented and cause friction. So we we pivoted to expandable, nested content that went one level deep.

  • This improved usability, while still being scalable.

Old Vs New Navigation

Buttons

  1. For the MVP, we settled on two sizes, action-based colors (red, green), and two generic colors (blue, black). Colors were adjusted for accessibility, aiming for a balance between AA and AAA standards, as the latter could be too restrictive.

  2. Users should be able to see all options, even if inactive, so adjustments were made to achieve that.

  3. "Ghost buttons" were replaced by regular link text.

  4. Text-only or icon-plus-text options met most of our needs, while also adding limited use of a dropdown version for controls.

Buttons

Top Menu

Problem Statement

Problem Statement

Why do we need another design system?

Value Proposition

Players and developers have distinct goals and needs, a unified tooling design system could streamline development, ensure consistency across teams, reduce technical debt and reliance on external frameworks.

Our 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.

Gamer V Developer

Why do we need another design system?

Value Proposition

Players and developers have distinct goals and needs, a unified tooling design system could streamline development, ensure consistency across teams, reduce technical debt and reliance on external frameworks.

Our 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.

Developr UI Elements

Scalability

Scalability

Focus on scalable baseline patterns and methodology

Tables

These are data intensive workflows we were building towards, and needed to present lots of discernible content, which was also scannable.

  1. Helpful feature context telling users what they're looking at, with high level instructional context.

  2. Clear overview of current selection results at top of table.

  3. Simple search for relevant data in an organized fashion, at the top level, with some features also using tabs to separate relevant data into their own silo's for added granular context (ex - active vs inactive).

  4. Information is aligned and optimized to scan - text + mixed data left aligned, numerical (not shown) right aligned.

  5. Patchlines & Releases are UUID/unique, so to improve information discovery we show the unique name as a direct link to the full dataset.

  6. Focus on top level data to reduce information overload, with additional data available to view in a dropdown, which is also able to be interacted with.

  7. Create CTA always consistently on the top right and accessible without deterring from focus on current data, and when the functionality is unavailable the UI presents as inactive.


Feature With Table + Data

Focus on scalable baseline patterns and methodology

Tables

These are data intensive workflows we were building towards, and needed to present lots of discernible content, which was also scannable.

  1. Helpful feature context telling users what they're looking at, with high level instructional context.

  2. Clear overview of current selection results at top of table.

  3. Simple search for relevant data in an organized fashion, at the top level, with some features also using tabs to separate relevant data into their own silo's for added granular context (ex - active vs inactive).

  4. Information is aligned and optimized to scan - text + mixed data left aligned, numerical (not shown) right aligned.

  5. Patchlines & Releases are UUID/unique, so to improve information discovery we show the unique name as a direct link to the full dataset.

  6. Focus on top level data to reduce information overload, with additional data available to view in a dropdown, which is also able to be interacted with.

  7. Create CTA always consistently on the top right and accessible without deterring from focus on current data, and when the functionality is unavailable the UI presents as inactive.


Feature With Table + Data

Navigation

I improved upon initial plan to view more options via hover, which could provide some UX challenges.

  • Accidental mouse movement could change what is being presented and cause friction. So we we pivoted to expandable, nested content that went one level deep.

  • This improved usability, while still being scalable.

Old Vs New Navigation

Navigation

I improved upon initial plan to view more options via hover, which could provide some UX challenges.

  • Accidental mouse movement could change what is being presented and cause friction. So we we pivoted to expandable, nested content that went one level deep.

  • This improved usability, while still being scalable.

Old Vs New Navigation

Buttons

  1. For the MVP, we settled on two sizes, action-based colors (red, green), and two generic colors (blue, black). Colors were adjusted for accessibility, aiming for a balance between AA and AAA standards, as the latter could be too restrictive.

  2. Users should be able to see all options, even if inactive, so adjustments were made to achieve that.

  3. "Ghost buttons" were replaced by regular link text.

  4. Text-only or icon-plus-text options met most of our needs, while also adding limited use of a dropdown version for controls.

Buttons

Buttons

  1. For the MVP, we settled on two sizes, action-based colors (red, green), and two generic colors (blue, black). Colors were adjusted for accessibility, aiming for a balance between AA and AAA standards, as the latter could be too restrictive.

  2. Users should be able to see all options, even if inactive, so adjustments were made to achieve that.

  3. "Ghost buttons" were replaced by regular link text.

  4. Text-only or icon-plus-text options met most of our needs, while also adding limited use of a dropdown version for controls.

Buttons

Top Menu

Top Menu

Information Density

Information Density

Information Density

Typography

This project was key to growth of the company, so we we needed to build a framework accounting for future features.

  1. "Inter" provided the needed information density and clarity, but with fewer variations to improve implementation.

  2. A grid tracked the fonts in use and their locations, helping identify what needed to be replaced or removed.

  3. Font usage locations were identified, with additional research on other internal portals (not shown here) to lay the foundation for future alignment.

  4. Alignment was created with the broader internal typography system overhaul that was in progress.

  5. Options were streamlined around weights and headers, to simplify implementation and define standards.

Typography

This project was key to growth of the company, so we we needed to build a framework accounting for future features.

  1. "Inter" provided the needed information density and clarity, but with fewer variations to improve implementation.

  2. A grid tracked the fonts in use and their locations, helping identify what needed to be replaced or removed.

  3. Font usage locations were identified, with additional research on other internal portals (not shown here) to lay the foundation for future alignment.

  4. Alignment was created with the broader internal typography system overhaul that was in progress.

  5. Options were streamlined around weights and headers, to simplify implementation and define standards.

Balancing density of information for easy scanning & readability

Typography

This project was key to growth of the company, so we we needed to build a framework accounting for future features.

  1. "Inter" provided the needed information density and clarity, but with fewer variations to improve implementation.

  2. A grid tracked the fonts in use and their locations, helping identify what needed to be replaced or removed.

  3. Font usage locations were identified, with additional research on other internal portals (not shown here) to lay the foundation for future alignment.

  4. Alignment was created with the broader internal typography system overhaul that was in progress.

  5. Options were streamlined around weights and headers, to simplify implementation and define standards.

Balancing density of information for easy scanning & readability

Typography

This project was key to growth of the company, so we we needed to build a framework accounting for future features.

  1. "Inter" provided the needed information density and clarity, but with fewer variations to improve implementation.

  2. A grid tracked the fonts in use and their locations, helping identify what needed to be replaced or removed.

  3. Font usage locations were identified, with additional research on other internal portals (not shown here) to lay the foundation for future alignment.

  4. Alignment was created with the broader internal typography system overhaul that was in progress.

  5. Options were streamlined around weights and headers, to simplify implementation and define standards.

Outcomes

Outcomes

Outcomes

+11%

New Users

+13%

Retention

+18%

Revenue