Design Systems at Thumbtack
Design systems provide a common language for designers and engineers to use when building products. This common language allows for better communication and collaboration between teams. Design systems also help to ensure that products are consistent and meet the needs of users.
At Thumbtack, we always look for ways to improve our design systems. Recently, we conducted an audit of our Thumbprint Design System to better understand where the system is successful, where we could improve, and ultimately determine what needed to be changed.
What is Thumbprint, you ask? Well, simply put, it’s a consolidated and standardized platform that streamlines the design and development process. By reducing decision-making friction, the system frees up teams to focus on higher-order problems while increasing customer quality and consistency.
In this article, we’ll talk about how we went about auditing the existing system and how we developed an improvement plan through the lens of a design team member here at Thumbtack.
Auditing our processes
Quantitive metrics
If you work for a larger design organization, you may have access to Figma’s analytics. This feature is only available to Figma enterprise accounts.
Figma analytics enables design system admins to understand the usage patterns of library components by tracking instance usage and detaching patterns. The usage patterns express the number of times a given component was inserted into a design file, and when the insertion occurred.
These insights can help provide quantitative metrics on component patterns and behaviors of the design team. They add value to the storyline of design practices, but they only express a portion of how your team engages with the design system.
For a more in-depth understanding of intentions, it’s imperative that you engage with fellow designs and engineer team members by interviewing them and understanding the pitfalls and gains the system provides.
Qualitative metrics
Like any good UX study, a fair judgment on use cases is best measured through quantitative and qualitative data. While quantitative metrics may express how the system is being used, take time to sit down with your team and ask how they intend to engage with the system.
With a more robust understanding of team intentions, we could turn our focus on how the system should operate.
Teams and file organization
Figma Team structure
To help support a broader range of initiatives, our design system resources live within a separate team structure than the Thumbtack design team. This structure provides a deeper level of organization that is otherwise impossible with project organization within Figma.
In addition to basic organizational needs, this also helps govern the contributions to the design system’s work, by enabling and disabling editing rights to the library files when collaborating on components.
Project organization
The responsibilities of our design systems team are full of complexities. Not only is the team responsible for generating and maintaining a library of components, but it’s also imperative that teams understand how our approach compares to other systems, how to use Thumbprint, where to find our libraries, and why our components exist. Collectively these needs help define how we organize design system projects.
1. Research
This folder houses efforts and outcomes of how we research design system efforts at a larger system-wide scale. This is where the results of the Figma audit, font scaling explorations, design systems competitive analysis, and other large-scale research efforts reside.
2. Getting started
Understanding how to get started with Thumbprint and how our system differs from others that a new hire may have encountered previously can be challenging.
These challenges are also not unique to new hires. On occasion, systems processes may change or, as a designer, may need a refresher. This is where our getting started resource comes into play. This project provides any team member with an understanding of the underpinnings of the design system.
3. Libraries
At the heart and soul of any functional design system lives library files. Our Library project includes all libraries leveraged by Thumbtack’s design team that are not considered a work in progress (WIP). There is more to come on Libraries (WIP), but for now, we’ll cover how we organize our library files.
There are many opinions on organizing system files within a Figma ecosystem. Most importantly, it’s critical to find a method that works for your team and suits your operational efforts.
Thumbprint is a multi-platform design system. This means there needs to be some methodology on particular concerns exclusive to the web platform, which components serve the native experience, and where the two libraries overlap.
Due to the need to separate concerns, we’ve opted to produce libraries exclusive to each platform and a library for overlapping components. These libraries are named by the platform they serve (web & native) and the shared or Global library resources.
Our Global library is also responsible for delivering our general styling needs (font system, brand colors, spacers, etc…). While this approach is viable, the intentionality of the Global resource and styling is deviating enough to consider peeling the styles into a more foundational resource.
4. Libraries (WIP)
In addition to our standard libraries, we continuously look to improve how we deliver design solutions. This expansion work includes testing approaches that fall within the scope of what’s considered a work in progress (WIP).
Libraries housed in the Figma Libraries (WIP) project are accessible by the design team, but caution should be used when adopting these resources. This general WIP classification can consist of libraries that can be in a variety of states that are not otherwise production ready. Files in this project are subject to change. In some cases, change can happen rapidly and be drastic.
While applying the WIP resources may require a cautious approach, the experimental nature of these files allows us to test the practical feasibility and usefulness of a pivoting approach.
For example, how can we leverage our existing standard library components to generate a systematic approach to a swappable set of organisms? Going even further, how can we use these organisms to feed template components?
Once files within the WIP project have become refined enough to graduate from this space, they are moved into the Library project and evolve standardized into our design workflow.
5. Components
Components aren’t born out of thin air without an understanding of intention, nor do they remain unchanged after being released. To help better serve the breadth and depth of each component carried in the design system, a Figma resource file provides a comprehensive representation of the component.
This model is inspired by a Figma YouTube “In the File” series where Asea Brown Boveri (ABB) builds a collaborative design system at scale (alternatively, you can read the “Building and Scaling a Design System in Figma: A Case Study” case study). The basic principle of this approach is to provide as much information about each system component from research, explorations, anatomy, version, history, etc., within a single resource.
Support
Designers need to have a deep understanding of the design process to create a system that will meet the needs of their team. In addition, they need to be able to evolve the system as the team’s needs change constantly. Knowing how to support a design team with a design system can be challenging but can also be a rewarding experience.
Loom videos
If a picture is worth a thousand words, then quantifying our Loom videos would be difficult to estimate. An integral part of the design system component support consists of recording a short informational Loom video for each component.
These videos range anywhere from 1–5 minutes. The length depends on the complexity of the component and provides team members with a visual demonstration of how to use the Figma component.
The general purpose of these resources is to provide an asynchronous synopsis of how the component is intended to be used, what properties are applied, which variants are available, and if those variants are design-specific or if they also apply to eng component properties.
Request workflow
Components are a continuous work in progress. We use a Coda for our support framework to provide the team with the necessary tools to request changes.
Because Coda is an incredibly flexible tool, we can capture inquiries, collect and triage them, track progress, provide feedback, and notify team members of any changes to their requests.
We also have an additional support layer connecting our Jira ticketing system for when requests elevate to a level where engineering resources are needed. This is done by leveraging the Jira Coda pack provided by Coda.
Custom Figma plugin
We know that finding the right support channel can be a tedious process. For example, how can you find the direct URL for a Loom component video? Or how do you get to the Coda submission form when you have a suggestion for improving a Figma component? Sure, this can be done by adding a few bookmarks to your browser or a few links to a reference sheet, but maybe there’s a better way.
To make this support workflow simpler, we developed a custom Figma plugin targeted toward supporting Figma component usage. We could attach a URL directly to the library master component by leveraging the inheritance methodology of Figma components. Any instance will naturally inherit the details of the master component.
This means we can attach a link to the Loom instructional video to each component and a link to the Coda request form if a team member is interested in providing additional feedback.
Thumbprint.design
Thumbprint.design is a great online resource for designers. It provides guidelines and usage patterns for design systems outside of our Figma ecosystem. Not only is this a valuable resource for designers who want to learn more about how their design work is applied from an engineering perspective, but this online resource also provides a cross-functional understanding of team guidance.
Final thoughts
There are a lot of moving pieces when it comes to design systems. But by breaking down the process into its component parts, you can develop a system that works for your team and your project. With a little planning and forethought, you can create a design system that will save you time and headaches in the long run. Thanks for reading!
