A design system is basically like lego blocks. You can have a general kit, full of many different standard types of legos to build with, or you might have a specialized kit to make hyper-specific things, like for example, a replica of the millennium falcon.
The beauty of legos is that you can build a wide variety of things with them. The problem with legos is stepping on them, but that’s another matter entirely.
A LEGO® Star Wars™ Millennium Falcon™ built with a specialized kit. Image credit: “LEGO 10179” by STICK KIM is licensed under CC BY-ND 2.0.
So where lego creations are made out of lego blocks, design systems have components that can make digital creations. Which you can think of as pretty similar functionally.
A smattering of lego bits in their most dangerous habitat: the floor
A handful of components from Shopify’s Polaris design system, as seen in the Figma Application
These systems may be small and lean, or gargantuan. They may have different levels of organization and structure depending on the maturity and needs of the system. Think of the organizational entropy like:
Scattered legos on the floor ≈ A design system that isn’t formally documented or organized. Typically this occurs by happenstance in the process of design and development
Legos somewhat organized in a tackle box ≈ A design system that has a dedicated place, with a limited structure
Legos perfectly ordered by type and color with labels in little sections ≈ A design system with a place for components, which have clear and consistent category labels and organization
Regardless of their level of organization, these are all systems for building designs.
A handful of common organizational categories by which digital component types may be sorted. This example is from the VMware Claritydesign system, along with some typical style guide categories.
A highly organized system of lego block storage sorted by type and color at the lego store. Image credit: “The LEGO Store — Aventura Mall” by miamism is licensed under CC BY 2.0.
Now, to add more complexity; There are two sides to the components of a design system: on the design side we have what are essentially little drawings in a library. Depending on the software you are using, these design-side-drawings may be called components, symbols, patterns, elements, or even “atoms, molecules, etc.” if you’re following atomic design— In any case, let’s call them components on both sides in these articles to keep things simple. This design side of the system may also contain a “look and feel” instruction manual, called a style guide. This guide contains a lexicon of typical style choices within the system (e.g. instructions about the shades of Red and Grey we may select to build the millennium falcon, where to put the logos on it when it’s done, how to sound like Chewbacca while playing, etc).
Design-side-components are typically created using technical drawing inside of a vector-based design software tool (e.g. Figma/Sketch/AdobeXD). These components are then combined in various ways to compose wireframes. Wireframes are the design-side blueprints for digital works such as apps and websites. Think: blueprint for the lego house, made out of exact-to-spec pictures of legos. The designers are like architects building with these blocks.
On the development (code) side we have blocks of code that correspond to those design-side-components, dev-side-components. These are the building blocks to build the front end functionality (the visible part) for digital products like software applications. These code blocks may reside in a number of places, for example, you may find them in Gitlab, and/or you may find them alongside a functional visual representation of the component in a program like Storybook.
Design-side-components make wireframes (left), Development-side-components make the end digital product (right). The two are informally linked together
The link between the design-side and development-side components is a two way street, with the desire/user need to build a component impacting the request for development to create one (e.g. the lego fans said they want a block that looks like a pond, can we make that?), and the developers feedback on the feasibility/complexity/functionality to build a component effecting the design (e.g. we can make a block like a pond although it will be a lot more difficult to make it clear than to make it Dark Blue). This involves a lot of close collaboration between design and development when working on digital products together. It also involves continuous update support from both sides, to stay in sync as technology and needs inevitably progress.
Once we have a design system, whether formalized or not, we basically have a sort of lego kit of components that we can make apps with. Voila! If this is the kind of thing you are looking to get started for your business, here at Tanzu labs we proudly partner with companies in the public and private sectors to enable them to create design systems, build and modernize apps, and more.
Up next: How do we know if we need a design system?