Design Systems Operations at Plaid
A peek inside how the design systems team operates at Plaid
What to Expect
In this article we will walk through how the product design system team operates. Some topics that will be summarized are:
- how we plan each quarter
- how we communicate with cross-functional partners
- the processes in which we work
- how we collaborate
- the tools and methodologies we use
- how we measure usage of our system
About Threads
At Plaid, the design system is called Threads, and consists of two sides — the Platform side, serving all product work, and the Brand side, serving all things marketing and branding. Threads is a centralized, foundational function, focused on Plaid-wide goals and managing the entire organization as an entity. This article is going to focus on the ways that the Platform team generally operates.
The mission of Plaid is to unlock financial freedom for everyone and democratize financial services through technology. As a design systems team, our goal is to support all of these surfaces with tools, components, and guidance to build new features and products that align with Plaid’s mission.
Finding Purpose
Our purpose is to ensure a unified, cohesive user experience across Plaid through both brand and product touch points and enable designers and engineers to build more quickly and efficiently without sacrificing quality. Accessibility compliance is a general principle at Plaid, as it aligns with our mission of inclusivity, and Threads Platform helps lead this initiative. We focus on providing tools, components, and guidance which comply with the WCAG 2.1 Level AA criteria from within our design system, allowing designers and engineers to build with confidence with regard to accessibility best practices.
During moments of decision making, we often rely on our strategic pillars to guide us in the right direction. Our strategic pillars as a design systems team are:
Shared experiences — Promote collaboration to create and maintain the most impactful core component needed to create seamless shared product experiences across all of Plaid’s products and services.
Foundations — Provide our users a best-in-class experience using the design system through supportive onboarding, documentation, tools, and long-term technical capabilities.
Accessibility — Ensure Threads is compliant with WCAG 2.1 Level AA accessibility criteria and encourages inclusivity efforts by providing guidance, audits, and support.
Project Planning
As a team, we operate on two-week sprints within quarters throughout the calendar year, aligning with how the rest of the product organization operates. During the last two weeks of each quarter, the design systems team conducts a retrospective, brainstorms new ideas, and gathers future needs from cross-functional partners.
After other product teams have had a chance to do their own team planning, we send a survey using Airtable to design partners from each team, asking them what design system needs they have in order to accomplish their goals for the next quarter. Typically, we receive feedback around needs for new components, guidance for existing components or patterns, or general partnerships to ensure proper design system usage during their projects.
Gathering these needs from design partners helps us to validate our new ideas and prioritize our projects for the next quarter. From these needs, we develop objectives and key results specific to the design systems team. For the most part, we prioritize work which aligns with the needs of product teams working on initiatives that meet the current goals of the company. As this shifts, even within a quarter or project, we shift with it to continue supporting our customers (the financial institutions, financial services applications, and consumers that rely on Plaid) the best we can. Other reasons we might prioritize work are if there is a bug to fix or accessibility compliance improvements to be made within our existing offerings. Tasks like these usually find their way to the top of our to-do list, to ensure that the tools we already provide in our design system instill confidence in those who are using them.
Communications
As a foundational team, it is important that we invite cross-functional teams into our process through transparent communication. The most frequent way we do this is with weekly internal update announcements.
At the beginning of each week, our team gets together to review any new work that we published or released the previous week, as well as anything that is in progress. We gather these updates into a document as a log, which we format into announcements, updates, and in progress sections. Depending on what we are covering, we will get as granular as is appropriate per section. Once we finalize the week’s updates together, we share the message in an open design systems channel in Slack. The responsibility of sharing the updates rotates through each of the members of our team. The benefit to having this message come from someone different each week is that it allows designers, engineers, and others visibility into our team and familiarizes them with who works on design systems, and who they might need to reach out to for support. It also means that when someone is on leave, there is someone else who understands the process and can take the lead. The open design systems channel is also a place for anyone to come and ask questions about anything relating to Threads.
At the end of each quarter, after we conduct our retrospective, we put together a newsletter summarizing everything that we accomplished during the quarter. The newsletter is formatted in Figma as a slideshow and summarized in an email sent to the company. In this update, we circle back to the objectives and key results we planned and communicated at the beginning of the quarter, noting how what we worked on met our goals or was adjusted due to shifts in priorities.
Process Overview
Defining processes within our team helps us to function productively with an understanding of how we set goals and expectations. Knowing how we navigate different tasks helps us to communicate to external contributors how they can get involved.
As a design systems team, our main focus is the creation of new components as needed — including designing, engineering, and documenting. When considering component builds, we think of them in different sizes (denoted by a numerical value), which describe their complexity and estimated time needed to complete (key word: estimated). We invite designers and engineers to join or lead any part of the following process as they desire. Our team understands that it is our responsibility to ensure that components are stable, follow our principles and meet our standards around structure and accessibility, and get released into our libraries. That said, we prefer to work with others to build new components, as the designers and engineers who are requesting them are the ones who know what is needed from a product and usability perspective the most. As systems designers and engineers, we are able to help guide how a component should be built from a systems perspective, and how it relates to or differs from similar components already available in the system. Together, we are able to build a versatile and flexible component and craft guidelines for how to use it when it comes to implementation within the product.
Not all parts of the build process happen in a linear manner, meaning, for example, sometimes an engineer can start scaffolding the component while design is still in finalization. But all new components start from the same point — the beginning.
Phase: Plan
Components find their way onto our table a few different ways: sometimes as a completely new component or replacement for an existing component, other times as an improvement upon an existing component due to non-breaking styling or technical changes, or as a high priority fix to an existing component due to a bug, accessibility concern, or breaking library update.
Once we prioritize the component task accordingly into an appropriate quarter, we split the task up into a few different sub-tasks for design, engineering, and documentation. Depending on the size of the component — we use t-shirt sizing: small, medium, large, x-large — the steps and time it takes to complete them in each phase vary.
Phase: Design
The design phase usually starts with defining the details and understanding the need for the component, which is documented in a Google Doc template. Then, we conduct an internal and external audit within Figma to understand how this component or similar components are used either inside our product or in other products and design systems. Once we gather said information, our designers can then start exploring designs for the component. After gathering feedback from team members and cross-functional partners, or designers and engineers who will likely use the component, we will conduct a user research study to get potential customer feedback. User studies can look like anything from an internal unmoderated questionnaire to a detailed, moderated session using a third-party research platform and an interactive prototype.
Phase: Build
As mentioned, while design is finalizing the Figma component, engineering starts on the initial scaffolding of the component API in React. During this process, we make sure that any accessibility compliance standards are being researched and built into the component or documented to provide guidance where we are unable to imply them through the API. Through reviews with fellow engineers, the component build gets finalized and tests to ensure its stability are written and conducted.
Phase: Documentation
Before releasing a component, we construct documentation to accompany a release publication, like in our weekly Threads updates. As is the nature of ever-evolving systems, guidance on component usage changes over time as well, as we learn new needs and uses for elements within our design system. This is a natural part of the process and should continue to gain the attention it deserves.
Open Studio and Review Sessions
Another important part of our duties as a design systems team is reviewing work from designers and engineers using a Threads perspective. There are a few ways that we do this, so to better know what cross-functional partners are working on and how they are using our system tools.
Each week, we host an open studio session where designers can schedule a spot to come and talk about anything they would like help on relating to the design system. Using an Airtable form, they sign up for a slot, share any links or information about their topic they would like to discuss, and invite any other designers, engineers or product folx to attend as well.
In addition to this specific Threads meeting that anyone is welcome to attend, each product team has their own team review session where we are able to join to view the work designers are showing and gathering feedback on. Each month we host a meeting with designated product design leads from each team to provide insight into what their team is working on and how anything in their projects might relate to the design system.
All these meetings serve as opportunities for us to surface any unplanned needs from the design system team, whether new components, guidance, or help in thinking through specific experiences and how to incorporate the system tools. Embedding ourselves into each different team and the work they are sharing also allows us to understand how different teams are using Threads similarly and differently, enabling us to find more cohesive connections or disconnections, either intentional or not, throughout different products.
Tools, Methodologies and Practices
Within our organization, we use Figma for all user interface related design work. The Threads Brand team uses Adobe products to create new illustrations and other marketing materials, the illustrations then being imported into Figma to use within product designs.
From the design systems point of view, we serve two main environments: Threads Core, which includes any reusable visual design element provided through an asset library, and Toolkits, which are nurtured by Threads but owned by the different product teams and include product specific files where designers can create unique implementations of components and patterns from Core to use within their product spaces. These toolkits can be thought of almost as sub-libraries. When we work with designers on new components, we work through our new component process and add those components back into Core instead of in the product specific toolkits. This enables the components to be more discoverable by other teams should they need something similar for another experience. If a component is created for a certain product space, we might add written guidance in documentation to help inform designers as to how the component is currently being used within products.
The Threads Core environment consists of four main files. The most foundational is the Tokens file, storing all color styles in both base and semantic form, typographic styles, elevation or shadow styles, and grid options. A less global but still helpful file we provide is the Utilities file, housing a Figma thumbnail cover component, cursors, device mockups, and user flow tools for wireframing and prototyping. The Assets file contains all visual elements such as icons, illustrations, logos, and more. The largest file, Components, is where we provide all reusable components organized alphabetically.
For the most part, Threads Platform maintains the files within Core, with the exception of illustrations in the Assets file, maintained by our illustrator on Threads Brand, and device mockups in the Utilities file, maintained by a designer on Threads Brand who works with product device mockups for marketing purposes. When it comes to making decisions around the Tokens, including colors and typography, both the Platform and Brand teams work together to collaborate on any updates or changes.
Figma Optimizations
A couple of examples of how we optimize our Figma experience for designers are with basic guidance and alternate names within component descriptions. In the description of each component, we include a link to any documentation for the component, as well as communicating the availability status of the component, since in some cases there might be an intentional lack of parity between design and engineering and it’s helpful for designers to know this going into a design. We will also include any alternate names for elements, either in components, icons, or illustrations, where something might be thought of in different ways. For example, one designer might think of an “edit” icon as “pencil”, so including these alternate names in the description enables designers to search for items in whatever way they uniquely think of them.
We are of course always willing to add to or change these types of aspects in our library files, and invite others to follow the same process that system designers have to update Threads library files. This process includes creating a branch on the Figma file one wishes to update, completing their changes, and submitting for review from a Threads designer. Asking ourselves to follow this same procedure keeps us honest and transparent with our consumers, helping build the relationships we have with product designers who use our design system.
Another small way we help guide designers in Figma is with the use of layer names to imply editable text. We use a consistent naming convention for layer names which serve as placeholders, implying preferred casing for particular elements in the layer name as well as using an emoji to denote text which should be edited to fit each use case.
Engineering
On the engineering side, we use React to build our components. All styles, components, and assets are bundled into an npm package for use by React-based applications within the company , utilizing a major/minor/patch changelog system to communicate updates to consumers. We use a single Storybook instance, published internally as a static website, to showcase Threads React components. In addition, we spin up ad hoc Storybook instances in order to share works-in-progress with stakeholders for early UX/UI feedback during the component build process.
Adoption
Though we primarily focus on providing tools for designers and engineers to use to help improve their workflows and ensure products are cohesive, we don’t stop at making these tools available. Helping consumers adopt components is key to the success of our team.
In addition to the previously mentioned recurring meetings which help aid in the understanding and adoption of components, we also partner with product teams and consumers as needed to ensure they feel comfortable and confident in using our design system. Each design system member of the systems team is paired with different consumer leads to build relationships and be sure they have the support needed during both planning and active work.
To gauge how we’re doing as a design systems team, we send out a survey to gather sentiment usually every six months. This survey is decently short — around ten questions long — and helps us to understand how cross-functional partners use our design system tools, the confidence and increased efficiency these tools give them, and any ways they feel we can improve in order to better support our consumers.
Finally, we use analytics to measure the usage of Threads components within different product areas. More specifically, we audit the codebases of these product areas to determine which components are available in which products, the number of instances of these components, and how they measure against use of local (wrapped) components (or recognizable reusable elements which are not consumed from Threads), and the percentage of coverage that Threads provides.Collecting all this information over time helps us to know how our components are being used and where, which allows us to dig deeper into intentional uses and intentional non-uses. It allows us to communicate to stakeholders the progress of our design system and how it has historically been used.
Conclusion
We are constantly growing and learning new ways to evolve our system and improve the availability of components and guidance around usage. As our products shift and change, and as consumers find new needs within new experiences, it is important that we adapt to continue to best support those who use Threads to build Plaid’s products. To borrow José Torre’s metaphor from the excellent article about the flawed nature of design systems, Plaid’s design system is a garden that needs tending. It’s a fabric that requires tailoring. A thread that calls for weaving. Each day, with each evolution of our design system, we’re becoming better equipped to answer that call.
Have thoughts about how we operate as a design systems team or care to share learnings from your own teams’ processes? We would love to hear from you!
