Resume

Portal Design System

Design system focused on internal facing, game management software tools for game teams.

Problem Statement

Riot had a design system for players but lacked one for game management tools, despite having a strong developer culture and internal tooling.

Building and maintaining a design system demands significant time and resources, including planning, alignment, and goal-setting for scalability and long-term value.

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.

Problem to solve

Create a centralized, scalable design system that simplifies developer workflows.
A 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 maintentce costs by deprecating existing duplicate systems.

Who are we designing for?

Primary Audience

Developers

Primary users of the system for both teams.
Often viewing large amounts of information in one place, requiring a balance of density and clarity.
Elements require clarity of use and consistency to work across teams, while minimizing unnecessary customizations.
Since developers typically work in code editors and GitHub, which are prone to errors, improving the workflow when transitioning to a new environment is essential.

Secondary Audience

Non-technical Users

Our team also needed to support less technical users.
Includes product managers, QA engineers, producers, and designers.
Often less comfortable with code editors and GitHub, we needed processes and UI that guide them through tasks without relying on a developer to assist, as was the current workflow

Project Roles

Multi Team Coordination

Both teams were already in flight on their respective projects, so combining workflows and sharing resources was the best way to complete the work, and achieve wider org value.

Team 1

Product
UX Designer
5 Engineers
QA

Team 2

UI Design Contractor
2-3 Engineers

Stakeholders

Internal Tooling Teams (SDK, Commerce etc)
Game Teams
Player Platform Team Members (Designers, PM's, Developers etc)

Project scope

Goals

Combine the design workstreams for the two portals, align them, make adjustments, and deliver the final work before the last 6 months of the UI designer's contract.
Define a system of best practices and use cases for future use and implementation.
Migrate our portal's existing designs to align with the updated system.

Notable pivot

Prior to completion, broader internal pivots and team changes led our partner team to scrap their project a few months later, stepping away from both their portal and the shared design system.

Approaching the work

Riot was growing but at that time had limited design representation within the developer initiative. That meant the other had a lot to cover, and jumped into each others workflows to align.

His work had a narrow data scope for a single team, but to provide real value across initiatives, we needed broader and more flexible designs to better scale across teams.

We'd both done competitive analysis on products like AWS, Epic, Google and Firebase, which we re-assessed in light of the new joint effort needs.

Assessing the work

What was in place? Did it work as is, do we need to make tweaks or start from scratch?
Where are the gaps that need to be bridged, and how do we do that?
How do we create best practices with value and consistency to scale?

North stars guidelines

Design for information density while retaining information clarity
Improve on the code only experience in GitHub, using UI and contextual information to guide task completion.
Provide guard rails against avoidable human errors that lead to costly breakages.
And a “nice to have” that always came up, no matter who we talked to, was a design system that supported Dark Mode!

UX Patterns

Information Density

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

Tables

Top level data summary for quick scanning.
Focus on primary data with spaced to scan, and additional detailed data accessed via dropdown.
Text, links and combination data is easier scanned when left aligned.
Numeric data is easier scanned when right aligned.

Safety & Error Reduction

We used modals, colors and intentional button placement create build guard rails around destructive actions. Where possible we wanted to try reduce human errors, such as accidental clicks, and “fat finger” inputs, or general “YOLO” accidents.

Destructive Actions

Deletion might be the end goal, but can also cause a live incident, which is more problematic than taking additional pre-cautionary steps. Multiple confirmation steps are included as a method of prevention.
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.

Usability & Scalability

Menu Navigation

Some comp analysis went multiple levels deep, but we felt that didn't match our needs and could users could lose track of their where they were in content. Nesting content went one level deep to maintain future scalability.
We avoided forcing users to hover over an item to see more feature content, as that could cause frustration should the UI change with small mouse movements.

Broad project results

The launch of our portal MVP also introduced the design system, both of which received positive user feedback.
Developers noted the simplicity and consistency within the interface, and workflow error reduction.
We begain obtaining feedback, and planned to implement metrics to make additional improvements.
Partner teams could begin using our system and Figma templates, which allowed their designers to more quickly visualize designs.
More fleshed out documentation was still in flight, so we provided helpful guidance to them around patterns to follow.

My part in the process

I was managing all the design work for our portal and had insight into cross-team requirements for our systems.
My goal was to guide the process, expand the designs, and establish standards for using and implementing the UI.

To Do Goals

Expand existing UI experiences for broader use, such as making dropdowns usable in forms and standardizing data presentation to improve discoverability.
Refine the UI and experience to simplify implementation and create a scalable, standardized design for developers. This included reducing the number of fonts, buttons, and colors, and defining use cases for each element to optimize the experience.
Targeted adjustments to improve table UX, making data more scannable and establishing standards for data alignment
Rethink top navigation IA to expand from a single to a multi-portal experience with a unified access point.
Improve the menu UI and IA to be more scalable and reduce friction for users.
Collaborate with developers on implementation, creating reusable patterns with clear notes and documentation.

Refine UI Elements

Atomic Design

This was a key foundation for scaling the system, providing a solid starting point for both of us.
Adjustments were necessary to achieve greater flexibility within the Figma nested component hierarchy

Point Of View

The designs followed a "kitchen sink" model but needed a stronger point of view to improve consistency and scalability.
Implementing every option would be time-consuming and overcomplicated, making it harder to maintain best practices in the long run.
Given our broad needs, I began with existing portal designs to identify use cases that could bridge to wider requirements.

Typography

"Inter" provided the needed information density and clarity, but with fewer variations to improve implementation.
A grid tracked the fonts in use and their locations, helping identify what needed to be replaced or removed.
Font usage locations were identified, with additional research on other internal portals (not shown here) to lay the foundation for future alignment.
The designer handling the broader typography system to make adjustments was brought in to gather suggestions, and ensure alignment.
We reduced alternate weights, simplified the headers, and streamlined the design. Her recommendations helped maintain alignment, establish standards, and prevent over-implementation.

Buttons

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.
Users should be able to see all options, even if inactive, so adjustments were made to achieve that.
"Ghost buttons" were replaced by regular link text.
Text-only or icon-plus-text options met most of our needs, while also adding limited use of a dropdown version for controls.

Optimized Table UX

Much of the designs in place worked well, which was crucial for precise refactoring that added value without removing requirements from the other team.
The organizational hierarchy was defined in a top-down manner to simplify how users view related data within a feature.
Summary data and improved column alignment enhanced information discoverability.

Tables

Tabs to create clear data groupings within a feature. Ex - tournament may have a tab for upcoming/in progress/completed tournaments.
High level overview of current selection results at top of table.
Search to quickly find data.
Additional data available to view in a dropdown, when required.
Left aligned text data for easy scanning.
Right aligned number data for easy scanning.
Create CTA always consistently on the top right and accessible without deterring from focus on current data.

Top Navigation Bar

Revamping the top navigation and user settings improved clarity and enabled an access-based system for Rioters to reach all their portals from one location.

Nav Bar

The layout was initially designed for 1920+ screens, so I improved the usability by re-engineering it to align with our existing grid system, which included smaller standardized screens like laptops.
We created a hub for multiple portals, with a top navigation for access and a portal switcher on the left to change between them.
Search evolved from an MVP to a future goal as the scope expanded to include multiple portals, due to the complexity of cross-product search functionality.
Team access was included in a product dropdown, alongside account settings and a help function (the latter as a placeholder for future features).

Multi-Team Access Point

Product Access Dropdown

Transitioning from a single to a multi-portal setup required rethinking top level feature organization.

Product identification remained the same.
Team name was simplified.
Team management was moved to the main menu alongside our access management feature.
The search feature was removed as it felt redundant and potentially confusing with the larger search functionality in the top navigation.
The favorites list, requested by the other portal, was deemed a fringe use case and was removed.
The help link was removed, with the static help in the top nav now covering this use case.
Current products and access requests followed the "guide, not hide" UX pattern to enhance discoverability.

Menu Navigation

Scale with less friction

Initial plan was hover to view more options.
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.

Wide Screen Content

Content Focus on wide screens

Grid columns were used to create consistent spacing between elements allowing for readability without being cramped.
Devs often have large screens. Content unfurling infinitely to the right as screens got wider, decrease usability, so I standardized maxing out at 1920 then centering content.

Pairing with devs

Building a scalable "source of truth" documentation method was in progress across teams. As a small, fast-moving team, clear Figma instructions sufficed for the short term.

Handing off work

Detailed Figma annotations
Async Slack threads were used for quick questions, which could lead to ad-hoc sync meetings.
Standing meetings to walk through designs, and answer larger questions.
We used a test environment to review in-flight designs along with the QA lead, and developers to address any issues.

Naming Conventions

Long-term naming convention alignment was crucial to bridge Figma and code. By aligning with developers and understanding their perspective, we chose the BEM methodology which follows similar conventions as our atomic design system.

Did it work?

Following this approach allowed us to release the MVP, enabling users to discover and use the features. As it was a new process, we spent time walking users thorugh things, answering questions, and gathered feedback for improvements.

Post-project reflections

UA few months later, we faced issues that led us to abandon our custom UI in favor of an external framework. Builds began breaking due to inconsistent implementation, caused by reduced manpower and insufficient documentation.

While there was documentation in Figma, it may not have been sufficient. The company later adopted Notion, which became a better collaborative space for cross-discipline documentation.

Documentation in Figma was compounded by our decreased resources that also led to our iniability to implement the BEM naming conventions.

Fortunately, all our UX work was validated. Despite switching to an external UI framework, core UX processes like enhanced guardrails for safer development and improved data scannability remained intact.

Project Coda

Building a design system with shared resources between two teams with different priorities proved more challenging than if a single design team had handled it.

I'd like to think based on the initial launch feedback, improved communication and alignment could have changed the eventual outcome.

Ultimately, despite a valid effort to create internal value, frequent changes in broader roadmaps hindered our ability to complete continue progress on our custom design system.