Designing Systems at Gusto
Building tools for and collaborating with product designers on the Gusto design team.
Gusto is an all-in-one people platform making it easy to onboard, pay, insure, and support your hardworking team. With a primary focus on small businesses, we have grown to support many different size companies, and have grown as a company ourselves. Our engineering, product, and design organization are all working toward the same goal — building payroll, HR, and benefits tools to support small businesses and their growing teams.
With a growing team and an ever-evolving product comes the need for an ecosystem of reusable components and helpful guidelines to build the best product we can for our customers in the most efficient way. That’s where Workbench, our design system, comes in.
As a design systems team, our goal is to help people work better together. The first step in figuring out how to do this is to learn from the people who use the design system resources and understand how they use them. In this article, we will focus on how we learned from and built design system tools for product designers helping to build the Gusto product. We will cover how we built an entirely new Figma asset library from the ground up and how we form relationships with the designers we are providing tools for.
Learning
Through a series of 30-minute interviews, we learned the different ways designers were using our existing design system in Figma. During these interviews, we asked questions around each designers’ unique workflow, what they felt was going well, and what their frustrations with the current system were. These findings, along with details on the team and location for each designer, were documented in Airtable to refer back to.
Generally, designers were excited to have a team dedicated to building tools for them to work better together with engineers and to bring cohesiveness to our product. Some things they were asking for included:
- The need for parity between what was available to engineers in their component library and what was available to designers in their Figma libraries
- The desire to utilize the latest features in Figma, such as Auto Layout and Variants.
Currently, the components in Figma were able to be used through an asset library, as well as in a UI kit, allowing for a “window-shopping” experience. A request from everyone was to maintain both these ways of using the design system in Figma. Since we had an existing component library in Figma, we had an important decision to make.
Should we revise the current design system file in Figma, allowing designers to run a quick update and have everything in their files be updated in a flash, or should we start a net new file that designers would have to adopt?
There were benefits and disadvantages to both of these options —
Use the existing file
Pros:
- Nothing new to adopt
- Components automatically update based on file and choice
- Doesn’t interrupt current workflow
Cons:
- Components won’t always update correctly due to new features and how they were built previously
- Will likely break files due to new spacing structure and grid system
- Doesn’t encourage the feeling of a new design system and product design collaboration
Create a new file
Pros:
- Nothing needs to be updated, just adopted, so nothing existing breaks
- Encourages the feeling of something new and a new season of design culture
- Allows the ability to work in conjunction with the previous system
Cons:
- Something new to adopt
- Slightly different workflow
- Designers have to know how and when to turn on and off previous and new asset libraries during migration
With this in mind, we sent out a survey to our Product Design Slack channel allowing everyone to weigh in on the decision between updating the existing file and starting an entirely new one. We included communication about these pros and cons with both options in the message, as well as some insight into how the engineering side of the design system recently handled this same type of decision.
The consensus was to create entirely new files, to avoid any issues with updating existing mockups as well as still being able to maintain and build designs with the previous system if need be.
We have to find the balance between meeting designers where they are and helping evolve the team and system to grow with the future of the product and end-users the system is built for.
Setting up Figma
When it comes to preparing a Figma file to be a library asset file, there are many ways to organize and name your pages, even the spaces between the pages (there’s even a Twitter thread about this). As with many aspects of file and naming structure, there’s no right way to do this. In the wild, some asset libraries use multiple Figma files — one for colors, one for icons, one for web components and patterns, then another for mobile assets. While our long term goal is to separate the different elements into their own files, so different teams can choose to install only the libraries with the assets they need, in the interim, to maintain some familiarity with how the design team was currently using the system, we combined everything into one file with the exception of specific mobile assets.
As for the UI kit file, there were a couple ways we wanted to set it up based on feedback from designers. Some people desired having all of the assets, components, patterns, etc. all on one page, since that allows them to browse and that’s what they were used to, while others wanted a bit more organization with individual pages for components, patterns, templates, etc. To help organize the overview page a bit, everything is laid out horizontally so people could always know they could scroll left or right to find more, instead of having frames all over the place. Each element has its own frame, complete with a title, labels, an updated status, a link to the documentation, and specific notes relevant to that element. The elements in the UI kit file are linked instances coming directly from the root design system file. This helps make sure everything stays updated accordingly. From the overview page, each of the element frames become components themselves that are replicated onto labeled pages for slightly more organization.
Foundations
Since we were starting from scratch with a brand new file, we had plenty of opportunities to improve on what already existed as well as carry over anything that was working well. When it came to laying the foundations — ie. color, typography, border radii, shadows, and other styles — the only improvements that were made were on the organization of how items were named and laid out together. The naming conventions now follow the tokens we put together for engineers. This aligned with one of our main values throughout the recreation process of having parity as much as possible with how designs were being implemented in development. Everywhere we were able to, starting with these foundational elements, we included documentation through descriptions to guide designers on what to use certain colors and text styles for.
Components
Once the foundations were in place, we could start using them to build components. As with most systems, we started with our most commonly used interactive items such as buttons and inputs. It also helped to start with these because the sizing of these components help influence many other decisions when it comes to less used components that fit within the same layout. Though tedious, it was important that we took the time to name every single layer as intuitively as we could inside every component or hidden component we had. Doing this helped ensure that if and when a designer digs deep within a component, they can hopefully understand how it’s built, and what they can or should change, and what they shouldn’t. This detail is especially important when it comes to the use of hidden components.
Figma Tip
Figma allows you to build components that are available to use to build options and variants into other components, but they are not searchable within an installed asset library. To do this, you just insert a ‘.’ (period) or ‘_’ (underscore) in front of the component name.
With the release of an exciting new feature in Figma like Variants, it’s easy to get sucked into going overboard with too many variants inside one component. For example, we do have an instance where a component has over 750 variants, plus variants on hidden components inside. (hint: it’s the Input component) As with everything in an ever-evolving design system, we are working to improve these components to be as intuitive as possible. Maybe our case is an appropriate use of that many variants, and maybe there’s a way to improve it. Ultimately, it’s important that the designers are involved in this evolution and these decisions, and that using the component makes the most sense for them. But it is important to understand when to use variants and when not to use them. Another important factor to consider here is how simple it is to maintain these components with many variants from a design system in Figma standpoint.
Every system is different, every component is different, and every designer is different. There is no right or wrong way to build components. The way Figma is built actually allows and encourages many ways to build the same thing. That is the power of the program, and beauty of the different ways designers work. What’s important, is that we build tools that are flexible and allow designers to use them without thinking about how they work.
Patterns
The next step after components, which utilize foundational elements to become something interactive or informational, is the compiling of patterns. Patterns are made up of components to complete an entire interaction. For example, one pattern we use a lot at Gusto is a Form. This is made up of a section title (using text styles — Foundation), any combination of inputs (Components), possibly a checkbox or disclaimer text for agreement (Components/Foundation text styles), and actions (another pattern made up of button components).
Together, these all combine to make the Form Pattern in our system. What comes with this pattern is an example using the previous stated components, patterns, and foundations, in an auto layout which implies our intended spacing. Patterns are a great way to build in documentation through things like spacing. In certain circumstances, we also encourage detaching patterns. An example of an encouraging detachment of a pattern would be when the Form pattern does not have all of the elements you need in the example that comes out of the box. If a designer needs an additional input or another checkbox group, the pattern can be detached, allowing designers to add in more elements that fit directly into the auto layout that is the entire Form frame. At this point of the design process, guidelines on what can be added to a form and how it should be used in that form would be found in our documentation on the docs website.
Templates
To help designers get started designing their projects, we created a set of templates they can use to easily and quickly jump into designing without worrying about finding an existing design to duplicate. These templates are built for several different user types and at our most commonly used screen sizes.
Lab
On the design systems team, we have developed an area of our component library called Lab, which is a place where we can surface items that are in progress but ready to start being tested and used. This practice helps us to inform designers and engineers on what we’re working on and what is coming soon.
Tools
To help designers easily find what they’re looking for when searching in the Figma asset library, all of these foundational elements, components, patterns, and templates utilize a description to include any possible search terms. It’s very important that each designer feels free to know items as they do based on their experience and are able to search what comes to their mind to find what they are looking for.
At Gusto, we sometimes show mockups externally, and therefore have certain names, photos, emails, company names, etc. which have been approved by our legal team that we must use in these mockups. To help designers quickly and efficiently populate mockups, we created a Google Sheet that has a variety of approved details on it that can be used with the Google Sheets Sync plugin for Figma.
Continuing the work of helping designers get started more easily and collaborate more efficiently, we created a Figma plugin that populates a new Figma file with a page structure and starter templates. The page structure we insert when running the plugin was influenced by what designers were using in their own file templates.
Gathering Feedback
The design systems team in continuously helping onboard new designers and providing workshops for people to learn and understand how to build for Gusto using Workbench Figma. To help us gather insights, we send out surveys that allow people to submit anonymous feedback so we can learn how we can improve what we are doing for the team, and ultimately our customers.
Since a design system is a living and breathing ecosystem of assets built for designers, engineers, researchers, writers, etc. provided to a product organization, it’s important for us to remember that there is always work to be done, and things to be improved upon. Our work is meant to sustain, help people work better together, and be something that is maintained and evolved with the product and company. The reality is that we are imperfect and there is always room for improvement, there may be something we missed that we need to go back and fix, or the brand changes, the product grows and we need to move with the swerves of the business and team.
We use periodic sentiment analysis through surveys to understand how our work is affecting the rest of the organization, retrospective usage reflections with designers and engineers to know how we could have done better with the tools we provided them, and metric tools like Figma library analytics to know how and when certain components are being used to build designs. With metrics inside of Figma, we have also been able to watch the trends of how the new asset library is used in comparison to the legacy library, and how adoption changes week to week.
Communication
The continuous evolution of our design system tools informs a very necessary collaborative process with our broader team members.
There’s much more communication with product designers from a design systems team than updates when there is a new release. Communication is the most important aspect of a relationship between a design systems team member and those they are building tools for. Especially in a remote environment, intentionality around communication is absolutely crucial. The designers we build tools for should feel comfortable reaching out to us with a question on how to use a Figma component, or to tell us that it’s broken and needs fixing, or to pair with us on ideas for a new component.
One way we asynchronously communicate with designers is through providing screen recorded documentation on how to use the components in Figma. These videos are recorded using Loom and have a home on each component page on our documentation website. With these videos comes written communication on how to properly use assets from our design system — ie. When to use, when not to use, ways to use, etc.
Another way of communicating is simply through Slack. We have a dedicated channel for design systems, where people can reach out with any design system specific questions. There is also a channel for product design. Per the designers preference, we share updates to them directly in the product design channel, and use it to initiate conversations for anything new we’re working on.
Collaboration
Product designers should feel as much a part of the design system creation process as they wish. Whether that means submitting an idea, helping work through a bug, or contributing to working through a new component proposal and helping to build the asset in Figma. We have refined our contribution process recently to help make this more approachable for designers. It’s very important to us that designers are a part of the decision making process when it comes to creating new or altering existing components, patterns, styles, etc.
Using Airtable, we created an inquiry submission as the first phase of this collaborative process. This form is accessible from our design system website as well as the UI kit we mentioned before. It allows designers to input their name, team, and choose from a few options of either reporting a bug, submitting a change request, nominating a new component or icon, or to let us know they detached something they don’t feel they should need to.
A reporter can also attach an image or screenshot, along with any description about what they are reporting. From here, we reach out to them directly to gather any additional information. For nominations of something new, we ask other designers to help validate the need of this item. This validation doesn’t determine whether or not we create what they need, but more so tells us how greatly it will affect the organization. After we receive any validation which influences how we prioritize this new item in our production roadmap, someone from Design Systems will pair with the designer who wants to work on the item to construct a proposal. This proposal is created in Figma, and walks through user stories, business goals, internal and external audits, then explorations for the actual item. Once we feel confident in our solution, we then bring in other designers to help test the component to work out any kinks. When appropriate, we build a prototype to test and gather feedback from potential customers. After any necessary revisions, we are ready to work with engineering to develop the component.
In addition to pairing with designers to help work through component decisions, there are other ways to create space to collaborate with designers. One way is to insert ourselves as much as we can into team-wide design reviews. Each week we have design reviews where designers present what they’re working on. It always helps for one of the designers from the design systems team to be representing design systems in the meeting. This allows us to approach feedback in a different way than their fellow product designers, and focus on new components they may be thinking about, or how they might be able to more closely align with the guidance from the design system.
With a new design system in Figma, revisions to naming structures, and how components are built utilizing features in Figma like Auto Layout and Variants, comes the need to allow space for designers to come ask questions. This encouraged us to open Figma Office Hours, an optional weekly thirty minute call for people to come and ask any questions they may have about our design system in Figma. This is in addition to our weekly Design System Office Hours, which is used to discuss the progress and status of components.
Involving the people using what we’re making in the process and nurturing a transparent relationship with them is the most important thing about our role as system designers.
Thank you for reading and learning more about design systems at Gusto! :)
