How Avalara built a design system to unify their products
Avalara‘s meticulously documented design system “Skylab” has been gradually built up over the past few years. They have a dedicated design system team comprised of one manager, two designers and two developers. The team works full time on the project using Figma, zeroheight, and their own SDK. We interviewed Will Rodenbough, primary UX designer on the project, about his experience building a design system.
Importance of a design system
Avalara has made multiple acquisitions over the years. This is one of the drivers behind the idea of having a design system at Avalara. In this situation, one of the questions that arises is, from a product perspective, what happens to this new acquisition? Is it going to remain an independent product or is it going to merge with some existing products? According to Will, “Integrating new products into the existing Avalara ecosystem is a strategic focus for us – it’s important to do that well.”
A design system can be a helpful tool in this scenario. Product can have a source of truth to understand what the standards and guidelines are for product design at Avalara. That way, the new and existing products can start to look and behave more similarly as they take on more and more of the design system content.
Why zeroheight?
The original plan was to have a custom documentation website for both design and engineering content. However, the team soon realised that requiring engineering resources for frequent updates to the design content was inefficient and expensive. This was when they came across zeroheight.
Will pretty much lives in zeroheight during his workday, and has been an extremely active contributor on the zeroheight forum as a result! He works with zeroheight open on one screen and Figma on the other, and says “zeroheight has been a great tool for our needs. It allows us to create and manage our design system documentation website without requiring engineering resources, which makes our team much more efficient.”
DesignOps process
The approach at Avalara has been methodical. “At Avalara we want to be really thorough about every decision we make about the design system – we emphasize research, documentation, responsiveness, and accessibility.” Their design system is made for over twenty different products, so the research and analysis behind every design system decision is documented. If someone were to question why something in the design system has been done in a particular way, the team can point to the page in zeroheight and the extensive research that has been done.
Research
The team holds sprint planning meetings every other week, plus quarterly planning meetings. They use Jira for tracking their tasks and backlog, and have a precise workflow for each part of the design system. The first stage of this is the research process (see image below). This includes looking at how external design systems address the issue and collecting best practices from trusted industry sources, such as Nielsen Norman Group.
Design
Next up is the design process (see image above), which includes making everything responsive. As Will says, “We provide solutions for a wide variety of web-based products, so we ensure that all design system content is responsive from 320 pixels wide and up.” It must also meet the Skylab usability principles and their accessibility requirements, for which they worked with an accessibility consultant who is an experienced contributor to WCAG.
Documentation
Then specs and usage guidelines need to be documented in zeroheight. The team has a set of key attributes to address for both components and patterns (see below). They also work with UX writers to apply writing guidelines and principles.
Publish
The design system team is proactive and keeps everything in sync. They push updates to the teams using the system and then message that updates have occurred on the Skylab Slack channel.
Skylab Experimental
One area the team has been focusing on recently is: “How can we provide more opportunities for Avalarians outside of the design system team to be heard, get involved, and contribute their ideas to the design system?” The team is trying a few different ways to increase communication, feedback, and contribution.
As part of their quarterly planning, they send out surveys to the wider product and UX teams to ask recipients to weigh in and prioritize what goes into the design system next. During the review and iteration, as part of the design process above, the team shares their work with the broader product org. They accept feedback and make changes if the designs aren’t resonating with everyone.
Employees can also submit a request to the design system team via a form. This is designed to be as simple as possible so that everyone in the company feels they can contribute, even if it’s not a space they’re used to. The team has also introduced Skylab Experimental (see image below), a platform for Avalarians to share and reuse community-generated content. Content shared here can help inform decisions made in the design system.
Will gives this advice, “I think it’s important for design system teams to have close relationships and open communication with the teams that use the design system. Collaborating gives everyone a voice, and helps ensure that the design system addresses the needs of the products and users as effectively as possible.”
Living in code
Finally, Will believes making a design system available in code is key to adoption and long-term success of design systems. “A design system without code can make product design more consistent and efficient, but it doesn’t address the engineering process, which is typically much more expensive. Design system code helps minimize the need for engineering teams to repeatedly develop redundant solutions from scratch, and saving engineering time and resources is a huge value prop for long-term adoption of a design system.”
At Avalara, they have a code repository (SDK) where everything in the design system lives after being documented and built. Product teams can pull that code package into their product, and then have access to all the design system content. This includes not only frontend components but miscellaneous tooling like their file validation service, so there are added benefits to using it. This is a way of efficiently delivering shared resources to many teams simultaneously.
Overall, Will and the team have built a process that scales across their organization, allows teams to adopt the design system, and ultimately helps to unify their complex product ecosystem.