MoneyBowl x Systems Design

This case study emphasizes the importance of incorporating design systems from the beginning of a project to avoid the complexities and challenges involved in retroactively standardizing the design.
labeled with "MoneyBowl by Bowlero'" logo on the top left. A macbook pro showcasing my organization of the design system
General Info
Client
Bowlero
Time-frame
2 Months
Deliverable
Design System
SErvices
systems design
users
intenal product & Engineering teams
stakeholders
product manager
About
The Problem
A small bit of context here before we jump into the problem. At a glance, the mobile application is called Moneybowl - a skills-based gaming app where you can bet real money against your very own bowling skills. The app uses your initial challenges to "learn" your skill level so that the challenges you receive are tailored to you.

The problem the team faced was a lack of design consistency within Moneybowl. This was mainly due to the fast-paced design & development process that didn't prioritize the implementation of a cohesive design system from the start.

The project originally had two other designers working very fast & dirty for the speediest handoff, which resulted in inconsistencies, inaccessible color combinations, nearly 100 different colors within the app (30 of those just being different greys), a messy typography approach, and non-uniform icons. On top of this, assets were not componentized, requiring manual updates of what felt like never-ending screens when changes were made.
Typography
As you can see in the image below, there were no defined typography styles when I first joined the team. The initial designers eye-balled the typography when it was implemented.

Additionally, the style guide for If you look closely, you can see that some of the font sizes are as small as 10px, which is unreadable and inaccessible in many cases. Especially when you consider that this application is being used in low-lit bowling alleys.

The original designers started a style guide, however it was incomplete as well as being quite unconventional. Further, the naming conventions were based on very specific use-cases. This was maybe very beneficial in the very beginning of the process, but as the application scaled up and more features were added, it added a layer of confusion for developers and future designers alike.
Image of problematic text styles
Colors
Despite the long list of color names, there were many colors being used in the file that were not set up as a style. The colors were also not tested for accessibility, resulting in many color combinations failing the most basic of WCAG AA guidelines during accessibility checks. The developers were not thrilled with all of the color variations, as this added complications for them as well. These issues made the development process extremely frustrating for our engineers. That's where I came in.
Image of problematic color styles
Icons
The collection of icons was disappointing to say the least. Upon opening the "design system" page in Figma, it was clear to see that nothing was made as a component. Additionally, the text and the buttons weren't grouped together.

The icons that were being used also lacked consistency, as though they were taken from different collections. There's more on this below in the "Solutions" section.
An example of the problems the icons posed
The Solution
Actions Taken
To address this problem, I set forth to establish a design system based on the existing screens of the product. However, convincing the Product Manager of the importance of this endeavor was quite challenging. Despite initial doubts, I managed to make a strong case for the project.

Initially, I was the only designer assigned to create the design system. But realizing the scale of the task and the looming delivery date, it was decided to bring in Szani, a senior designer, to assist with the project.

My main focus was on creating a comprehensive style guide that included colors, typography, and icons. Szani, on the other hand, was responsible for implementing those styles across different elements like buttons and navigation. It's worth mentioning again that there was minimal componentization done at the beginning of the project, which added complexity to the task. Organizing and implementing design consistency after the MVP launch was indeed a tough challenge.

The Color System
So how did I start addressing this? Well, I first tracked down every single color being used across the entire application - again there were nearly 100 (!) colors - and put them in on one Figma page. It was a complete mess. I then compared all the use cases for the colors and consolidated where I could.

While I was able to take the 30 different shades of grey down to only 5, you can see below that the gradients are still, well... monstrous. These gradients were actively implemented in the live mobile app. Due to the similarity between several of the pink and purple gradients, I requested that these be consolidated in the next app update.
The Typography System
I followed this same process with the text styles. Remember, there were many more font sizes than shown in the "styles" images above.

The biggest issue with the typography was that sometimes, the line height was set to a percentage and other times it was set to a pixel amount. As I would be moving on from the project after completing my portion of this work, I left it up to the two designers who'd be working in these files. They opted to stick with the percentage-based line height.
The Icons
After tracking down every icon within the application, I went about setting them up as components and oraganizing them accordingly.

You can see that the "Custom Icons for Buttons" don't match the rounded visuals of the app. Additionally, there are multiple "Close" and "X" icons.

In the "proposed icons" section, I have included variants of directions icons, plus/add icons, and close/X icons to replace the inconsistent icons that are in the current designs.
The Conclusion
Roadblocks
Despite our best efforts, I faced several challenges while implementing the design system. One major obstacle that I've already touched on already was the inability to immediately implement the system due to the extensive development work required for a product that was already completed. As a result, some aspects of the design system had to be deferred to future updates as new features and updated screens were rolled out.

Additionally, the project became more complicated with concurrent design initiatives. While I was working on establishing the design system, Joe, another senior designer, was tasked with launching a significant "free-to-play" feature. This required the introduction of new colors based on stakeholder requests, as well as new icons, illustrations, and other components.
Outcomes
Although I couldn't implement the consolidated type & colors created within the design system right away due to development resources, this project paved the way for future improvements in product consistency and design coherence. The style guide, with standardized colors, typography, and icons, became a reference point for future design efforts.

Despite the challenges posed by the rapid development and the introduction of new design elements, my collaborative efforts here led to a clearer path towards design consistency. The decision to create a design system laid the foundation for a more organized and cohesive approach to design in subsequent product updates. This ensured that issues related to inconsistent design were systematically addressed. And best of all, not only did I give my team the tools to iterate more quickly, but I also made the lives of the developers easier as they made further updates.
Countless
working hours saved
1,800+
components impacted
84,000+
users impacted
(and counting!)