Creating Reusable Components in Design Systems
As development team and products grow, creating a unified design system becomes more appealing for teams to be able to get a single source of truth for design and shared components. A robust system can help teams develop UIs faster, more consistently, and with greater browser support.
I’ve helped teams create Design Systems to enable teams to move fast, but still be consistent by creating reusable tokens and components for all of our development teams to use.
Building A Design System
Before we jump into the how, let’s start with the what. What is a design system?
A design system is the source of truth for your design and UI development; it includes documentation on processes for updating that source of truth, as well as documentation on how to use the design system.
For the purposes of this article, the product teams I have worked with mainly use React and SCSS to build their frontends. The codified design system we built therefore supports these technologies by providing SCSS tokens and React components for teams to use throughout the products.
Since these components are heavily used by all of the product teams, it is essential that we provide performant and stable components. It’s important that when building a design system, that the team responsible for it considers the following so that they don’t break downstream consumers:
- thoroughly tests components on modern and older browsers,
- create testing pipelines to test functionality,
- create testing pipelines to take visual screenshots of components.
Of course, none of these components would be useable or discoverable by teams if we didn’t provide them with comprehensive documentation on what components are available or how to use these components.
I’ve used Storybook in the past to give developers a list of what components are available, but some teams would quickly out-grow Storybook. Some teams needed to provide full code examples of complex components and comprehensive design documentation alongside design system components as well. In these cases, the teams would create a design system website provides designers, developers, and product owners with:
- Design documentation
- Component and utility documentation
- Live, working code examples
Building the Pieces
In order for design systems to provide consistency while still making it easy to maintain, many aspects of the design system should build off of each other and provide composability that we can utilize to create even more complex components.
Scaffolding
At the base layer of a design system, we have our colors, typography, icons, and grid. If you are using SCSS, then all of these properties are available as SCSS tokens, but some are codified as React components as well:
<Text type="h1">
Hello world
</Text><Text>
Welcome to Nextiva!
</Text>
This allows product teams to use these low level scaffolding components directly if needed and build their own complex functionality on top of them.
Composable Pieces
SCSS tokens and component architecture allow us to create building blocks that let us compose together more complicated design system components.
From these tokens, we can build low level components like <Button>, <Label>, <Input>, and more. These base components that map to standard HTML elements are what we consider to be our atoms according to atomic design.
Now we can start to compose these components together to provide molecules that make developers’ lives easier: <LabeledInput> , <ButtonWithDropdown> , etc.
By making sure our components are reusable, we can continue to build up more complex functionality using components we have already built.
Making Sure Components Get Used
The worst thing we could do as a Design System team is spend all this time designing and writing code and teams don’t use our components. To ease any friction with using a design system, teams should pay careful attention to:
- Communication — make sure to communicate releases, deprecations, upgrade paths, and more to the rest of the product organization. Provide channels for developers to reach out directly with any questions or suggestions they may have.
- Documentation — we can’t expect people to use what they don’t know about. Make sure that every component is well documented so others know that the component exists and how to use it.
- Component APIs — if a developer can’t override styles or behavior, they will just re-implement the component in their application. Make sure there are ways to override component props when necessary so that we don’t encounter friction here.
On the Shoulders of Giants
If you are using React, you don’t need to start from scratch. You can create a design system on top of existing design system frameworks. Some of my favorite are:
Now go forth and build consistently!
Ivan Montiel is a UI Engineer at Lacework and the founder and CEO of Clarity Hub.
