The creation of a design system is crucial infrastructure for implementation teams with design and development roles. Design systems documents tokens, user interface elements, and patterns for use in a software application. A design system creates constraints, standardizes the user’s experience, and improves the speed of development when creating user interfaces.
The transparent nature of visualizing design systems can be extremely powerful. Applications like Storybook catalog a design system visually. Without this ability, there is often a valley of fog between the design’s tooling and a developer’s component code.
The Importance of a Visualization
Lifting the fog by creating a source of truth for both developers and designers to see the design system should be a standard on software projects.
An inventory of colors, typography, components, and patterns can be extremely helpful to the novice frontend developer and the experienced alike. Not all teams have a designer choosing the user interface elements for a feature. When that job falls on a product owner or developer having a visual catalog of out-of-the-box options can help them make a good choice.
The system can also include documentation that can specify how and why to use the elements under different conditions. Documentation becomes more useful the more variants a component has. That’s because the choice to use one variant over another may not be obvious to those implementing it. You can group the visualization of the design system into logical sections to aid in the discoverability and usability of the catalog.
Improving Standardization
Visualizing the design system can improve standardization between design and development. Naming conventions can be mirrored in the code base and the design tooling. For example, the button and all its properties can have the same name and options. This can greatly improve handoff between design and development as there is less room for error. When you need to make changes to the design system, designers can now easily see the production version of that element. Designers can inspect the code through the browser’s inspector. Meanwhile, developers can view the components and tokens from within Figma, creating a balanced view of the building blocks of the design system.
Developers can also use Storybook as a sandbox for developing components in isolation. It can force the creation of reusable components that are free from other styling implications and have clear inputs and outputs. Building in isolation means you can focus on just one component and how it will respond based on changes to the page or container width. This can otherwise be distracting when implemented alongside other elements on the page.
The properties, states, and data can all be visually tested to ensure proper behavior. The ability to modify the component using real data and inputs and see the implications of those changes can be helpful for testing or just seeing the expected behavior.
A User Interface Inventory
What if you already have an existing product but haven’t defined user interface elements in a design system? Starting with a user interface inventory is a great first step. First, identify all the colors, fonts, and elements used across the application. Group all of these findings. Put all the buttons together, all the inputs together, the colors together, etc. Then, identify where similar styling can be simplified into a single use. It’s not uncommon to find multiple styles defined twice.
If this all seems daunting, breaking it up is likely the answer. Start small and build on the complexity as needed. Not all projects or applications need robust design systems like SAP or Carbon. Consider just starting with the tokens. The shared alignment of just colors and font styles used in the application will go a very long way.
From there start tackling the atom and organism elements in your component library. And, finally, when your team sees inconsistencies in component usages that make it challenging for the users, start defining patterns to make use of these components more consistently. This doesn’t need to be a linear process. It can often be helpful to update a part of the design system when you define or edit it.
Create a System That Will Be Used
A design system on its own can be helpful, but a shared design system all implementors can view is a design system that will be used.