systemssystems

Where to start…

Over the years I'd started a product audit so we already had a jump on some of the UI problem areas in terms of inconsistencies.

I'd broken the product UI out into its various components based loosely on Brad Frost's Atomic Design principles, and the function each component served within Mixpanel.

A product audit I began working on within weeks of starting at Mixpanel in 2014. Top: Some buttons. Bottom: Some drop downs.

After much deliberation as an EPD team, we came to the conclusion it would be best to start with:

• Color
• Typography
• CTAs (More specifically, buttons)

Color and typography would have the biggest impact in laying a foundation for unifying the product and creating a solid visual language. Consistent CTAs was a step toward giving our users the muscle memory and confidence to tackle the tasks they came to Mixpanel to tackle.

Move fast. Hack things.

I wrote a short Javascript that crawled the Mixpanel UI stylesheets and js files pulling out all colors and converted them to 2,015 unique hexcodes. I then did the same for fonts and found 35 unique font-size and 42 unique font-family declarations.

A group of colors found by the CSS and JS file crawler application I wrote.

After we had all the colors from our marketing site and product properties, I wrote a script to sort them based on their HSL values. From there it would be much easier to pin-point like-colors to Find & Replace throughout the UI.

The same group of colors sorted by their hue, saturation, and lightness values.

After multiple iterations, practical applications, and usability tests (especially for color and accessiblity) we established a foundation for Mixpanel's Design System.

• Colors — 15 for UI, 8 for data visualization (23 total)
• Typography — 1 font, 3 weights, 6 sizes
• Buttons — Primary & secondary (with variations depending on application)

Maintaining and integrating.

Integration was one of the more difficult problems to solve. In an ideal world, we'd have a single source of truth that would pull in updates we made to design elements, and then push them to their respective properties in code. Three years later, there are entire companies dedicated to this exact problem (Abstract, Sketch Cloud, Figma, etc.)

Since this was a V1 (and to a certain extent a proof of concept), we didn't have the time or resources to do it "right".

We finally landed on a solution that while not automated, worked for our team and its size.

Step 1

Present your design proposal to the team outlining why the component or change is necessary:

An example of a proposal posted to Slack for implementing a new component.

Step 2

If approved, add your component to the Design System Master sticker sheet:

The Mixpanel Design Master sticker sheet.

Step 3

The designer then notifies either myself or the other Design Systems designer:

A text bubble with a conversation between designers.

Step 4

Component is built and added to a Github repo and a PR is opened for engineering review:

A screenshot of the Mixpanel Design System website which pulls from a Github repo.

There was of course one last step…

It was necessary we make sure everyone knew what updates had been made to MP Common.

A screenshot of Slack, showing a SlackBot notifying the channel of the changelog.

Closure and follow-up.

The Mixpanel Design System was a highly-successful internal project. While tough to measure, we estimated it helped increase effeciency within the team by ~30%. Perhaps the most important thing it did however, was boost the morale of the team as a whole. It brought the design team and EPD organization together more than anything else we'd built because everyone was working in lockstep the entire way.

It's still being used today, including most of the patterns, elements, and components we established in the beginning.