Racine

Case Study: Racine (2015-Present)

Racine is Sprout Social's Component Library.

Racine was created in 2015 to help combat years of mounting tech and design debt. Prior to Racine, teams at Sprout would reference a static style guide website I had put together in the early days of the company and manually copy and paste the markup for each UI pattern. Since the style guide was static, it was frequently out of date, and its patterns could rarely be used without one-off modifications.

As Sprout began experiencing rapid growth in 2014, it quickly became untenable to manually document and maintain UI patterns and the style guide soon languished. Eventually, when we realized we had inadvertently created five similar message bubble components, more than a dozen identical-looking buttons and had over 250 colors in our app. It was clear that we needed a new approach.

Using our style guide as a reference, a small group of designers and engineers put together a proof of concept in late 2015 as a skunkworks project. The initial version was a simple internal-only React app that housed a live visual inventory of our global React components bundled with Sass and JSON files for metadata and component documentation.

Screenshot of Racine 1 from November 2015
Prototype of Racine from November 2015.

The original release was a great start and a big morale booster for the team. As the library gained more traction over the next few months, we started to see more and more conflicts and frustration on the team around arbitrary component acceptance criteria and the contribution review process.

In July 2016, I took over as project lead, and as one of my first objectives, looked for ways to increase adoption and transparency of the library while maintaining the quality of our components. The project had a bi-weekly Guild meeting which consisted of a small revolving group of invitees that had been given the responsibility of making decisions for the library and its contents. As project lead, one of the first things I did was open the meeting to all product designers and front-end engineers on the team. This change brought new perspectives to the project and also helped surface more teammates who were passionate about design systems. The new perspectives also increased transparency and breadth of the subjects discussed at the meeting and helped us find common ground, eventually enabling us to establish holistic standards and conventions for our products.

Racine has made it so much faster and easier to find and build new components now that it has become the single source of truth for our components.

The shift in focus of the meeting and the inclusion of diverse, new perspectives also helped uncover which features the primary consumers of Racine–our designers and engineers–actually needed to make their jobs easier.

Armed with findings from the Guild meetings, I was able to begin developing a roadmap for Racine. At the time, we did not have dedicated a design systems or component library team, so most of the work on developing the library was done in our downtime between sprint work. I was able to make do with the circumstances by creating a roadmap of prioritized stories and recruiting volunteers to focus their efforts on specific, high-value features for the library.

Walkthrough of Racine, Summer 2017

The momentum added by having a roadmap, along with the cumulative power of the features added through the volunteers' efforts helped Racine grow from a handful of components from 5 contributors in December 2015 to over 200 by 50 contributors by December 2017. Having these results to draw on helped establish the fact that this work was extremely valuable and not merely another tool but how we work.

My responsibilities as project lead were not only to evolve the physical component library and break down barriers around contributing but also to evangelize our design system to the entire product organization from product managers to QA to engineering and design.

In Q2 2017, I was able to get buy-in on component library related work for the Sprout Analytics team's official roadmap. In Q4 2017 3 more of our product teams had stories related to our component library on their roadmap, with objectives that affected nearly every corner of the company.

A Scene from a Design Developer Meeting / Component Library Planning Session
A Scene from a Design Developer Meeting / Component Library Planning Session
Scenes from a 2017 Planning Session

In December 2017, I led a Sprout Hack Day project that focused on increasing the transparency and reach of Racine. Our project centered around sharing components across the organization and breaking out the existing library (which was coupled to Sprout's main code base) into its own GitHub repo with a build system and modern tooling. The question we set out to answer was: How might we improve the transparency of Sprout's Component Library for the Sprout product team and other organizations so that we can increase participation, collaboration, and visibility of our efforts?

Scenes from our Hack Day Project Snippets of our Project Brief
Walkthrough of the 2017 Racine Hack Day Project

By the end of our hack day, we ended up with a functional prototype that was completely decoupled from Sprout's web app code. We leveraged modern tooling to make automated component creation faster, we also saw a dramatic performance gain in the library itself, loading nearly 4 times faster on each page reload and reduced initial setup time from several minutes to just a few seconds. These performance gains and process simplifications, along with the work done to decouple the project were intended to increase participation and transparency and finally help us reach the goal of providing a single source of truth for UI components which we set out to do back in 2015.

Since it's inception, Racine has fundamentally reshaped how Sprout's product teams work. Leading the project was a rewarding experience for me personally as it has allowed me to contribute to a major cultural change in both the design and development workflows for our organization.

Shortly after launching this project in early 2018, I helped form a dedicated Design Systems team at Sprout, which I currently lead. My team consists of two other members, both of whom have cross-cutting Design, UX and Front-End Development backgrounds. We are responsible for creating and delivering on an official product roadmap for all of our component libraries as well as Sprout's Design System, Seeds.

In April 2018, the team shipped a new version of Racine, which is currently used by all of Sprout's core products. As the new library was rolled out, we aimed to avoid the mistakes that plagued us in the past by thoroughly documenting new processes, holding workshops with the team and established high-level criteria that all new submissions must meet. While the newly minted design systems team has plenty of work to do on evolving, evangelizing and maintaining the health of our design system, we now have the confidence and bandwidth to move forward along with the full support of the team.

Racine, April 2018

Project Summary

Racine is Sprout Social's component library. It was created to facilitate code sharing and create a single source of truth for our reusable components.

Quotes from a 2017 Racine user survey

Before building anything new I always check Racine first.
Racine has made it so much faster and easier to find and build new components now that it has become the single source of truth for our components.
It's really changed how we all work from design to engineering. Designers are asking more questions about components that we already have and engineers are collaborating cross-squad to make sure we're not doing the same work twice. It's really going to pay off in the future.

Other Details

  • My Roles: 2016-2017: Racine Project Lead 2018: Design Systems team Lead
  • Project Dates: 11/2015 - Present
  • Total contributors 2016: 5
  • Total contributors 2018: 50+
Thanks for reading! Have questions, comments?
Feel free to reach out.