Taking a closer look at understanding the Design System model. Tools and tips for building the right system for your product.
Modern Front End development practices focus on Component Driven Development, which is a concept of focusing on components and reusable source code. A very popular design concept which borrows from this methodology is the Atomic Design structure, coined by Brad Frost. This focuses on breaking down design & UI elements into their very basic structures and reapplies them into future stages.
Atoms: Definitions for the most core design styles: color, spacing, fonts
Molecules: Collections of Atoms that establish fundamental components of a theme: buttons, inputs, lists
Organisms: Molecules functioning together. Commonly understood as Modules, typically demonstrate business logic. Think along the lines of: Tables, Forms, Modals
Templates: Functioning groups of Organisms. Examples: Headers, Footers, Organisms that affect each other (ex. filtering a table)
Pages: Can be made up of several Templates, mixing in Organisms and Molecules
Much like the Atomic Design structure, Style Guides and Component (often referred to as Pattern) Libraries are considered submodules that contribute to Design Systems.
Design Systems are dynamic entities that can be made up of different kinds of modules. They can support many styling definitions, containing several components within their library. In other cases, they focus solely on defining fundamental styles and branding elements. The most important aspect to note here is that there is no singular perfect definition for a Design System.
The graphic below describes how these concepts relate:
The gap between design and front-end development continues to shorten with tools that bridge more dialogue between these disciplines. Using design tools that output some surface-level styling and component inheritance allows for quick design-to-develop conversions. Developing UI components in isolation from business logic makes UI source code accessible and promotes best practices. Successful implementations should be capable of:
Onto the realm of development, this open-source tool encompasses several features for building UI components in isolation. Out of the box, the software product supports a large base of commonly used JavaScript frameworks. Other features include community-developed add-ons such as: “Controls”, which allow for props to be passed into components and edited by the user in live preview to support visual testing and edge case discovery. The “Story” addon feature also exposes source code for the specific components in the view window. Furthermore, an entire set of tools for validation testing and accessibility are already baked in. The configuration flexibility allows for this product to benefit many ranges of workflows, from Style Guides to full-on Design Systems.
This is also an open-source tool that allows for development in isolation. Similar to Storybook, it supports live manipulation to props, testing and exposes source code. However, as the name suggests, this tool is built specifically for React. One stand-out feature here is that docs are autogenerated based on the source code.
Jumping over into the first half of the stack, Figma is a great tool for building design architecture for any system as a team. This web-based platform offers the potential to create themes, style guides, components and fully designed prototype pages. With the added benefit of being able to seamlessly work on a single page with multiple designers at the same time. This tool provides some surface-level styling attributes which can aid developers in matching exact values. Furthermore, designs can be directly imported into Storybook’s component pages to visually compare the design to the development version.
While it slightly underwhelms the accessibility that Figma offers to work within a team of designers at the same time, it shines in the ability to integrate 3rd party applications. Ranging from references to libraries and framework components to drop directly into designs all the way to mocking data tables and skeleton placeholders. Sketch takes the route of professional software for large scale design-to-development approaches. This platform offers its own version of organization for a design system that designers can reference to build off as well.
There is an assumption in the industry that a Design System must contain every ounce of design content from launch; as you may have guessed, this is a fallacy. Iterations of a Design System are just as important as is for any other product’s lifecycle. Having dedicated resources to maintain style definitions, source code and releases make for a much more reliable and effective system.
Deciding on the best approach early on can be the difference between a cohesive design to development process and a very complicated and time-extensive endeavor.
While assessing the right Design System for your product, keep in mind that defining the lifecycle of a digital product informs the UXUI design-to-development process. Is the focus more utilitarian with an emphasis on features from the backend? Then maybe a Style Guide and some defined Patterns is all your team needs to build coherent front-end features. Or maybe there are a few products in production with varying styles and user experiences. Perhaps this is an opportunity to create stellar documentation and define every aspect of the Design System for better cohesion between your digital products moving forward.
