uring Gusto’s 2019 brand refresh, the Design Systems Team created dozens of components, UI libraries, and assets for the company’s hundreds of engineers and designers. After rebrand work wound down, the systems team shifted focus elsewhere.
As the Design System became widely adopted, components and patterns started bending and stretching in new ways, beyond their original scope. The volume of incoming questions and requests to the Design Systems Team made allocating time to work on new projects a challenge.
Maturing with the system
We outgrew our team model and knew that to continue making meaningful progress on system improvements, long-term planning, and system advocacy, we would have to adjust how we work. This would enable engineers to focus on component evolution and reducing tech debt and designers to work with peers to define patterns and keep our UI libraries up to date. To avoid becoming reactive and having to pivot when our partners had a new request, we decided to evolve from a centralized team model to a hybrid of a federated model. With this change, our centralized team would partner with other product teams to steer contributions while so we could focus on advocacy, maintenance, and the long term vision of the system.
Start by listening
We began with a listening tour, collecting feedback from engineers and designers across the company (our customers). In phases, we collectively met with peers for 30–60mins and discussed pain points, inefficiencies, and opportunities.
When we reviewed the feedback, it was clear that adding more visual examples and usage guidelines would be big wins for our design system and its users. The Design Systems team already had much of the information our peers were looking for in various places, but without a single source of truth, we became an information silo.
The disconnect was: regardless of how much documentation we had, if we couldn’t find more efficient ways to share it, it wasn’t helpful. To paint the picture: our peers were out hunting for treasure but had to sail to us each time they needed to look at the map.
Taking smaller bites
With a better understanding of our peers’ pain points, we assessed the scope of our responsibilities as a team and concluded that we knew the only way to make meaningful progress was together. We decided to start looking for partners and advocates across the company who had the availability to collaborate with us. This freed us up to reframe our objectives and begin the shift from large long-term projects to small pieces shipped incrementally.
The pitch to potential collaborators was simple: help us help you to stay unblocked. In turn, we’ll reduce overhead for future projects together. The bonus was this collaboration would also increase our domain knowledge, as we would be more connected to the day to day of our peers and their teams. We also used the opportunity to develop and test a new intake process for system requests with collaborators.
The output was a new component proposal template in Figma. Since rolling out the new intake model earlier this year, we have been able to see a noticeable reduction in Slack messages, emails, and expensive meetings. Taking it a step further, we also built a proposal generator plugin in Figma to help speed up the proposal creation process.
Uncovering opportunities
With a new intake process in place, we got to work codifying our design language. Although we had thorough brand guidelines, we knew we could also benefit from strengthening the shared dialect between product designers and engineers. Additionally, most of the guidelines that our peers were looking for were in a myriad of places.
To bridge between engineers and designers on naming and common style values, we decided to create a new design token system. Building the system was pretty straightforward after we agreed on the values. The real challenge was going to be maintaining the alignment over time.
After experimenting with Figma’s API, I found it was pretty simple to pull style values from our Figma library and format them into JSON. We plugged the JSON into Style Dictionary, and with a few tweaks, we had a pipeline for syncing design tokens between Figma and code. For us, the real benefit of tokens was not the style values; it was the process changes they introduced. In addition to better alignment between designers and engineers, we also established a workflow that could be applied to other projects that drive the system forward instead of things like updating icons and illustrations. Additionally, we decided to create a new site for the system that reflected our new brand and product direction and could house these new tokens and guidelines.
Our team is still just scratching the surface of what’s possible with Figma’s API. We’re currently exploring optimizations like generating a pull request when a Figma style update is published, creating plugins to make repetitive tasks easier for designers (formatted templates, tables, lists, etc…), and communicating design changes and comments outside of Figma.
“Pull requests let you tell others about changes you’ve pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.”
— GitHub
Looking forward
This progress didn’t happen overnight, and there are adjustments and improvements we’ll continue to make. What we have built is a strong foundation for collaboration and shared accountability. Small steps have led to big changes, and slowing down to refocus has helped us continue measuring our work in terms of outcomes, not output. As a result, we have strengthened partnerships, developed new frameworks and processes, and brought engineers and designers closer together to improve our products.