Design Systems — What’s the tea?
Part 3 — Setting the foundation
In the first part of the series, I introduced what Design Systems are and what they consist of. While on the second part I discussed how to approach it. Within this last post, I will go over the foundations. These allow your design system to be solid and successful.
The foundation
What makes your design system strong, in my perspective, consist of the following:
Design principles
What makes your product unique? What is its voice, its personality? Can you identify the essence? What is the product all about? This is the purpose of your product. You will need these as a guide for your team. Identify what the core design principles of your product are. This way, your team can build something meaningful.
Purpose and shared values
What is the goal? Why do you have this goal? What are the values of the product and/or brand? Knowing the answer to these questions will help your team understand the objectives. Having shared values will help your team be consistent in what they are building.
Brand language and identity
The brand language and identity within an established company should be already in place. You can get familiar with these by reading over a style guide. If your team is creating a product from scratch, then you will also need to create the branding for it. The company logo, fonts, colours, icons, tone of voice, etc. compose the visual part of a brand. This means having rules and guides to explain the combination of such said elements. These will make your brand be recognizable and stand out. Visual consistency is important for a memorable experience.
Components
Imagine LEGO blocks; this is what components are like. They build your product’s interface. A button, a navigation bar, icons, etc. makeup your design system.
Patterns
Design patterns build interfaces, products, and features quicker. They are reusable parts of an interface. Patterns are a part of the whole, they can’t live on their own. Interconnected patterns form the product you are building. These create familiarity, establish trust and ensure a cohesive experience.
Documentation
How do you share all the information your team needs to use to build products? Documentation is needed to explain the design system itself. Within the documentation, you will have to share all the before-mentioned points.
Within this last part of the series, I will go over patterns and tokens. I will touch on how components are built through Atomic design. About the other topics, I would like to dive deeper into them in a later post.
A very brief overview of Atomic Design
Atomic Design is a method created by Brad Frost. It originated in the last decade and encapsulates the idea of modular design. The method aims to help teams think of their interfaces “as a hierarchical, interconnected set of components that build real product screens”. If you haven’t yet, please read his book.
Atomic Design started with 5 parts:
Atoms — These are the basic building blocks. A label, an input, or a button are examples of what atoms are, like HTML tags.
Molecules — These are a group of atoms that as a whole form a unit. An input, label, and button together form an element.
Organisms — Groups of molecules come together to form more complex components. These are the blocks of a system and create distinct sections of an interface.
Templates — When a group of organisms (ie. modal, form, layout and page, etc.) come together to form a final structure, they create templates. This is when layouts come together.
Pages — This is when atoms, molecules, organisms, and templates materialize into the most concrete stage. When all components come together, function and beauty meet to form the interface. Placeholders get replaced with real content to show what the user will see in the end product. Stakeholders sign off on this.
This method has grown over time. Due to its limitation, it has pushed designers to find new workarounds and extensions of it. Atomic Design now includes subatomic particles, ions, quarks, and other layers.
If you have trouble imagining this, picture a set of Russian nesting dolls. Dolls are within each other. The larger the doll is, the more parts it will have within it. You will end up with components within components. Not confusing at all, right?
Ions — The theory of Ions was the most recent add-on by Chris Cid. It aims to add a third dimension to the Atomic Design and components relation. Chris explains ions as “a repository to manage the variety of properties that any component can have”. Ions aim to help add details to the component’s structure. Ions are the properties that form atoms, molecules, or organisms.
Not all Design Systems need to follow the Atomic Design method. It will depend on the type of project and its setup. There are other approaches to build a design system.
Patterns
When developing a design system, focus on patterns. These are crucial to your foundation. Patterns are at the core of any design system. They are essentially a language to solve recurring problems designers may encounter. They also create familiarity, allowing users to easily understand the product.
A pattern library is a collection of design artifacts. This solves common problems. Patterns pertain to the identity by aligning with the brand style guide. These are used on elements to have consistent building blocks within components. Userflows need patterns to connect product features. Also within interactions, interactivity should remain the same throughout the journey.
Patterns can be small and self-contained information within atoms. They can also be overarching when creating a user-journey. Both design and implementation are affected by patterns. Thus the need for these to be reusable and agnostic within content and code. Content is added when implementing the patterns, rather than within them.
“Using the same languages allows all people working in the same project to achieve almost having a single mind.” — Christopher Alexander in A timeless way of Building.
Perceptual vs Functional Patterns
Patterns are split into 2 different categories; perceptual and functional.
Functional Patterns
This refers to modules or elements as a whole and is concrete. Behaviours shape functional patterns. For instance, the patterns of a banking app will differ from the patterns of a workout app. Within a banking app, there will be modules that intend to show your finances or past purchases. Whereas in a workout app, you will find video cards, recipes, or workout programs.
Functional patterns can also nest and live within one another. Within the account, one may find a number stating the current balance. Or action buttons that allow to add or send money, or a table showing the history of the account. Thus, each module or element here will have its own aim. Perceptual patterns style functional patterns.
Functional patterns are more theoretical, while modules or elements manifest these patterns. Patterns evolve through iteration, such as by adding a new function. Within the workout app, you now have the option to save a video by “adding it to your favorites”.
“If functional patterns are the objects of the interface, then perceptual patterns are more likely styles” — Alla Kholmatova
Perceptual patterns
Perceptual patterns refer to the styles. Styles refer to colour, tonality, typography, layouts, illustrations, icons, shapes, textures, spacings, imagery, interactions, or animations. Perceptual patterns live in the core of the brand. This induces effectiveness and should as well get to evolve with the product. Adequately, perceptual patterns will become a powerful tool to differentiate your product.
A good read for understanding patterns is the book “Design Systems” by Alla Kholmatova.
“Perceptual patterns are not only influenced by the building Blocks such as colour or typography but the relationship between them” explains Alla.
How do colours relate between them? How do spacings and typography relate to each other? How does imagery relate to typography? How do proportion, quantity, and loudness affect the brand?
Do you use Spotify? A perceptual pattern would be the color green. The intention of the colour is to highlight interactive elements throughout the journey. The use of green shows where you are within the navigation. They also use it as an alert. If you are using 2 devices at the same time, one will state which device is currently playing something.
Spotify exemplifies perceptual patterns as intuitive rather than deriving from actions or behaviours. This pattern sways by the product; thus its ties with the design principles, language, identity, and shared values of a brand.
Design patterns and principles influence one another endlessly.
Tokens
When building up a system, you will have to start by creating the core styles. Core styles are the initial pieces of the interface. These are fonts and font-sizes, colours, grids, and spacings, etc… These tiny bits of UI information will be utilized across your digital product. These essential pieces are your Design Tokens. Design Tokens consist of the data and/or description of the smallest parts of your system. Earlier I mentioned ions; tokens are the ions of your system. They provide value and a decision.
Salesforce, the inventors of design tokens define them as:
“the visual design atoms of the design system — specifically, they are named entities that store visual design attributes. We use them in place of hard-coded values (such as hex values for color or pixel values for spacing) in order to maintain a scalable and consistent visual system for UI development.”
Although designers use tokens within the design system, the front-end team expands them on. “Tokens for dummies” is an interesting read by Louis Chenais, who is a front-end developer.
Founder of Eightshapes Nathan Curtis explains in-depth the function and implementation of tokens. The article “Tokens in design systems; 10 Tips to Architect & Implement Design Decisions for Everyone” provides insightful information.
Adobe Spectrum describes tokens as:
“the values needed to construct and maintain a design system”
They explain how the following design tokens are some of the building blocks and design decisions:
Global tokens
Within the design systems, global tokens are the ions. They are the tiniest pieces of information.
They are represented by context-agnostic names. Colors, typography, and sizes, to name a few, are global tokens. These can be used directly or indirectly within elements are modules.
[ As an example, Spotify uses the hex value #1CB954 which will be become Green300 as a global token.]
Alias tokens
These are used within a specific context. Alias is no longer the value but the decision. They are communicating the purpose of the token. These are applied when the value is intended for use on various occasions.
[ Hex value #1CB954 becomes global token Green300 which then is represented as alias cta-background-color.]
Component-specific tokens
Components inherit from the alias tokens and are named after what the component is. This allows engineering and development teams to be specific with what they are building.
[ Hex value #1CB954 becomes global token Green300 which then is represented as alias cta-background-color. The alias is then used within a component button-cta-background-color.]
Design systems are what your project wants it to be. There is no standard web-definition for what they are. In essence, design systems are a combination of shared practices and interconnected patterns.
Design systems are a language and collaborative tool. They will help you achieve the purpose of your product and your system will grow by it.
I hope this very short guide has helped you understand better what design systems are.
