Galaxy Design System

Making the case for a design system
Background
In a handful of years GoGuardian had managed to capture a significant market share of the K-12 edtech space. GoGuardian had managed to create six different products to meet customer demand. All six products were built, operated and looked like distinct products which led to a lack of cohesion between products - this was killing us on the build side. 

When I joined GoGuardian, there were only four designers supporting six different products and an ever growing product management and engineering team. Both Product Managers and Engineers wanted to engage with us, but there wasn’t enough time or enough designer to adequately give time and attention to every request. 

There was a lot of redundancies in how designers approached new projects (myself included). The design team was fascinated by the problems that we were tackling; but working in the pixel was tedious and ate into our critical thinking time - solving user problems. I started going deep into diagnosing the root cause of our issues. I interviewed each designer and our design manager to see where we could be more efficient. As I went deeper with my investigation, I discovered that we needed a more efficient process of turning out wires/mocks/prototypes  - we needed a design system.
 

The Pitch Meeting

I worked with our UX intern to audit and document each UI element that was used across all products. There was a lot of redundancies: 

My boss was blown away by our findings that he said - “This sounds great. We now need to prove this out.”
I got the green light to work on our design system but I could only apply 20% of my time; I still had to balance individual contributor work and other DesignOps initiatives. At the time I was working as the UX Lead Designer for a self service project that enabled our smallest tiered customers to trial, purchase and renew product licenses all within our Org Management product. My manager had me present my design systems pitch deck to the design team. The presentation worked. The other designers saw the value that a design system could bring. Our associate UX designer and our UX Lead designer decided to chip in and help. We began by identifying our design principles.

Here are the design system principles:

Honest + Direct


We aim to evoke feelings of trust, calmness and confidence in our products for our users.

Familiar


We aim to evoke feelings of comfort, relatability and predictability for our users in an effort to reduce product cognitive load.

Compassionate


We aim to evoke feelings of friendliness, positivity and empathy such that all users to feel cared for.


We identified that our customer base could be segmented out into three distinct user types: 

Blowback

We began working on Galaxy with the sole intention of making it for designers and then communicating our findings with Engineering. After attending the Clarity design systems conference in December 2018, I walked away with so much vigor to engage with Engineering as soon as possible, instead of solely focusing on creating the design system for the design team. When I got back to the office, reality dropped me to my knees, our engineers were tied up and unavailable. After speaking with a few of the lead front end engineers, it was clear that they liked the idea of having a design system but they didn’t have the capacity to dedicate resources to the project. It wasn’t a soft no or a dismissal but it was a direct order from the top - engineering resources were to fully focus on shipping our newest product - Beacon, a suicide detection and prevention tool. I had to accept the reality that I would have to march forward solely focusing on creating the design system for designers.

After much work we've been able to ship Galaxy. It is now part of every designer's workflow. Here are a few of the components that were created: 

Proving out the value of the design system (Galaxy)

Now that Galaxy is released, I needed to prove out the ROI of the endeavor. I had each designer do a series of design exercises to build a number of components. The goal of the exercise was to create a baseline of “how long” it would take for a designer to build components from scratch vs. pulling premade components from Galaxy. 

Each designer had to create each component from scratch. Once completed, the designer would pull the premade Galaxy component alternative. Each exercise was timed and recorded.

These were the exercises that each designer had to complete:  
Each designer was timed as they tackled each component. As expected, the designers easily ripped through the first two exercises. Once a designer got to the global navigation exercise is where Galaxy truly flexed its muscles. I reminded the designers that they could reference the internet, old files or ask me for hints on where to find assets - most of them decided to solve this issue for themselves - respect. 

As more complexity was introduced, Galaxy was in a league of its own. Here’s some of the feedback that was captured during testing: 

What's the ROI of Galaxy?

So what now? 

After a lot of work, we’ve been able to ship Galaxy. I’m really proud of what we accomplished in 7 months of part time work. Since I work with such an ambitious group, we were able to even identify and create motion states. We intentionally left out illustrations, empty states and loading states (skeletons) to be worked on in Q4 by our future UI Design hires.

We’ve rekindled the conversations with Engineering to start  the adoption process of Galaxy. The interest is starting to peak again from our ENG colleagues. Can’t wait to get our components converted into design tokens and make the lives of Engineers easier.