Designing Our Design Systems Team
Earlier this year, we officially formed a systems team at Sprout Social to grow and evolve our design system, Seeds. While the history of the team is short, the roots of design systems at Sprout spans back to the company’s early days. This is the story of our journey from style guide side project to a full-fledged design systems team and the lessons we’ve learned along the way.
The History of Design Systems at Sprout
Sprout’s team has grown rapidly from the original four co-founders in 2009 to around 500 employees today. As the company’s headcount and has increased, so have the number of products we offer as well as the systems and tools we use to create them. In 2011, I teamed up with a front-end engineer to create what became Sprout’s first interactive style guide, a simple catalog of common UI patterns and basic usage documentation. As the years went by, the needs of our teams surpassed the capabilities of our lowly style guide. In 2014, we developed its replacement: a React based component library called Racine. Sprout was experiencing massive growth in engineering and design during this time, and the size and scope of our component library project grew along with it.
Victims of our own success
Our engineers loved being able to build global, reusable components in React and in 2016 the number of components in our library grew to over 200. The problem was that while many of components were well intended, they lacked clarity and a unique purpose. Designers and engineers would discuss which components to use in their project and when they didn’t find one that fit their use case they’d make a new version. Over and over again.
A Higher Level of Abstraction
As the number of one-off components increased and the team’s frustrations grew, we knew we needed a higher level of abstraction. Our solution was to create a common design language and a place to store it. In the Summer of 2016, our product design team took a page from Nathan Curtis and got to work Picking Parts and dicing our components into tiny bits in a Component Cut-Up Workshop. Our designers spent their downtime over the next several months creating and documenting guidelines for the building blocks of our interface like color, typography, space, icons, and motion. Our goal was to unify these core elements across our brand and product design teams. Every Friday, we casually met at the end of the day, cracked open a cold adult beverage and discussed our progress. By the end of the year, we were ready to share our work with the rest of the organization. A site for our design system took shape in early 2017 and over the next year slowly became the single source of truth for Tokens and holistic design pattern documentation.
Planting the Seeds
In early 2017, we formed the Design System Task Force, a group consisting of designers and hybrid designer/developers sourced from around the organization. The task force members remained on their existing teams but were allocated 30% of their time to focus on developing our design system, Seeds. The task force worked like other agile squads in the organization, creating a roadmap and defining sprint stories for their work. The task force roster rotated quarterly, with new teams picking up where the previous team left off.
The task force model worked well initially but due to the nature and variability of a rapid growth software company, we hit a few speed bumps. Over time, we could not maintain a consistent 30% time commitment, we underestimated the amount of effort of certain projects would require and lacked direction in others. Our product and leadership teams knew the value of the design system and could see the progress the task force made. The project was also a huge morale boost for the team, who had been trying to solve these problems for years. We knew we were heading in the right direction but we also knew that the task force model would not be tenable long-term if we intended to achieve our goal of making a large-scale impact on the organization.
Stoking the fire
Since mid-2016 I had been running Sprout’s bi-weekly Component Library Guild and spending my down time working with the guild’s members to evolve Racine, Sprout Social’s web app component library. As Racine continued to create value for our teams in the components shipped and processes we were improving, I was able to focus more and more of my time on component library and design system work. By January 2018, I had essentially automated myself out my role thanks to Racine and Seeds. At the same time, the team was determining the next steps for the design system task force, which had been on hold since late 2017 and the pieces began to fall into place.
After a number of conversations about forming a full-time design systems team, an outline of the team started to take shape:
- The scope would initially be constrained to our design system and Sprout and Bambu’s web app component libraries.
- We would treat our system not as a project but a product serving our other products.
- We would start small and scrappy.
- We would ship small and often.
- We would partner with designers and engineers across the team to set guardrails on contributions in order to avoid the mistakes of the past.
- We would not be the catch-all for the company’s design defects and regressions.
- We would create and maintain new tools and processes to evolve with the changing needs of the company.
- We would partner with our other product teams as system advocates and consultants and help them contribute.
The Design Systems Team at Sprout Social
We are small
In order to complete the work we committed to, we felt the team needed to cover three roles:
- A seasoned product designer
- A hybrid designer/developer
- And a team lead who combined both skill sets and had deep knowledge of our products and processes.
With those roles covered, we felt confident we would be able to:
- Answer global product design questions and quickly provide solutions.
- Design, build and evolve our tools and documentation.
- Develop and nurture relationships across our product teams.
- Adopt existing team rituals and processes and tailor them to our needs.
A few weeks later after developing a transition plan, my teammates and I began to divest from our squads and by March we set up our new desks and kicked things off.
There is no playbook for this
Starting a new team is hard. There is no how-to guide for handling all of the questions and decisions that must be made when introducing a design systems team into a growing product organization. Before tackling any actual design systems work or even developing a roadmap, we felt it was important to first align with other product teams. Our first step was defining our mission statement.
- Design Systems at Sprout Social aims to enable UI consistency, improve development efficiency, and provide clear guidance and documentation on all of Sprout and Bambu’s brand and design language.
Knowing our roles
With our mission statement set, we moved on to individually defining our roles. This was not simply an exercise in writing our own job descriptions but rather an opportunity for reflection, self-awareness and level setting with our teammates and leadership.
Finding our place
Our team’s primary objective is to maintain and nurture the design system’s health by creating tools, workflows, and documentation that enable and empower our colleagues to better serve the needs of Sprout’s customers. As we began to introduce the team to the organization, a common misconception was that our team’s focus would be on fixing global UI bugs and building all new components for other teams. This was concerning for a number of reasons, but primarily because as a team of three servicing a product organization with more than a dozen teams, we occasionally like to enjoy the little things in life, like sanity and sleep. When various bug tickets and requests from other teams started appearing on our Jira board, we knew we needed to convey a different message.
Playing nice with others
Our team wrote a “how to” guide for working with the design systems team which contained an overview of the types of projects the team intends to tackle along with:
- Our team structure, role, and mission
- A list of recurring meetings that the team’s members regularly attend
- A list of ways to get in touch with us (Slack, Confluence, Email, GitHub)
- Details on our weekly “office hours” (hour-long time blocks that our team sets aside to answer questions, share and discuss feedback, pair with designers or engineers, or talk about ways others can get involved)
- A list of common questions and scenarios we anticipate along with expectations from our team
- A link to our team’s Jira board (and details on when it is appropriate to add stories and when to reach out first)
- Details on how to contribute components or patterns to Sprout’s various libraries and where our team might fit into the contribution process
- An overview of the types of projects that would generally be out of scope for our team’s roadmap
- A basic communications plan detailing how we will keep other teams in the loop with what we are working on
The document did a great job of defining how we expect other teams to work with us but did not cover how our team will work with other teams. That process, we learned, is difficult to define due to the variance in scope and makeup of Sprout’s product various teams. Since we are a team of three and all bring different skills to the table, there is no reasonable way for us to work directly with more than a dozen teams while still working through our own roadmap. One solution we devised to solve this was a new initiative we call Design System Ambassadors.
Making Friends
Design System Ambassadors are designers from our various product and brand teams that act as “liaisons” between their teams and the design systems team. This program not only opens a new channel of communication between our design system team and Sprout’s other product teams but also increases the amount of impact our design system is able to make on the organization. For the ambassadors, the program also offers a career growth opportunity, as they get to lead a major design initiative on their team that is visible across the organization.
Crawling before we walk
With the rituals, roles, and expectations documented, the next big question we wrestled with was: where do we start? We poured through the design systems Jira backlog that had accumulated since the last design system task force finished its rotation and held meetings discussing potential high-value short and long-term projects. Our team had all separately been working on and triaging design systems related projects as the team began to form but we knew that we could get more value out of our effort if we came together. The common theme we were able to abstract was that the core parts of the system (color, typography, space, icons, and motion) were in many cases lacking usage documentation and clarity, which prevented us from confidently taking on bigger initiatives.
Reading the room
One problem we ran into was that when the system was initially created, it wasn’t entirely clear who the audience would be. We assumed that designers and engineers would be the primary consumers and the documentation and voice of the design language reflected that. The issue was that although our designers could find the correct hex value for our brand’s primary green and our engineers knew where to find React prop documentation, the details on why and when to use components and patterns were scarce. Additionally, after numerous discussions with teams interesting in documenting product level and global patterns for things like layouts, copy style, and common number and text formatting, we knew that the IA and scope of the system would need to be expanded for future work and new audiences.
Charting the course
It was important for us to align with the expectations and rituals of other product teams in the organization. We felt this would help us stay in tune with what other teams are working on and improve cross-team communication, camaraderie, and empathy with the work we do as it relates to other teams.
We did this not only by establishing the common and open communication channels outlined above but also by committing to a roadmap and putting it through the same approval and critique processes as every other team. At the team level, it has also been helpful for us as a small, scrappy team to be able to view things at a different altitude and see how our day to day work moves us closer to larger company objectives. It also helps keep us accountable and gives everyone on the team common goals and a sense of ownership in our work.
Just getting started
We recently finished our second full quarter as an official team. The team has been several years in the making and while the road to get here was long, we are reminded daily by the continuous improvements we see in our team’s workflow that it was absolutely worth the wait. It would not have been possible for us to get to this stage without the hard work and determination of our teammates and partners but we would would also like to call out a few others who have helped get us to this stage: our former colleague Arlo Guthrie for his hard work, guidance, and determination over the years, Jina Anne, Nathan Curtis, Brad Frost, and Diana Mounter for their inspiration, willingness to share and speak about their work, and their efforts to organize and foster a community around design systems.
