This is the first post in a series about Design Systems where I'll dive into every detail—how they function in big companies, how they're established, common pitfalls to avoid, and guidelines to adhere to.
To truly grasp the concept of a design system, let's begin by exploring its purpose and functionality. Why do design systems exist and what problems do they solve?
Large companies and digital products often face a shared challenge: managing a multitude of design and development elements. Without clear guidelines and structures, things can quickly become disorganized.
Inconsistencies may arise when different teams work independently, resulting in disjointed advertisements, applications, and other materials. This chaos can be detrimental to the overall user experience.
Consider a scenario where a team is tasked with selecting colors for an app. One individual prefers vibrant, energetic hues, while another leans towards a more professional palette. Now multiply this decision-making process across various teams within a large organization, each with their own unique ideas. Without a centralized plan, this diversity can create a fragmented user experience and an inconsistent visual identity across different sections of the app.
The underlying issue lies in the absence of a definitive approach. While choosing between red or green text may seem subjective, it becomes problematic when determining crucial aspects such as the color of an error message within a consistent system.
Decision-making can already be challenging within a small team, but it becomes increasingly complex within larger companies, potentially leading to chaos. Now, let's explore how a well-structured design plan becomes imperative in addressing these challenges.
What is a Design System?
Here we have a well-defined explanation of a Design System:
A design system is a collection of standards that helps manage design at scale. It reduces redundancy and fosters a shared language and visual consistency across various pages and channels.
A Design System comprises various Design repositories. These repositories can come in different forms, but typically include a style guide, a set of design tokens, a component library and a pattern library.
Style Guide
Style guides are comprehensive resources that provide specific guidelines for implementing interfaces and other design deliverables. They include visual references, design principles and recommendations for creating cohesive and effective designs.
Branding elements like colors, typography, trademarks, logos, and print media are commonly covered in style guides. However, style guides also offer guidance on content, such as tone of voice and language recommendations.
Style guides include standards for visual and interaction design, often referred to as front-end style guides. These guidelines can also be incorporated into component libraries for contextual guidance.
They are valuable tools that ensure consistency and coherence in design, helping designers and developers to create exceptional user experiences.
Design Tokens
Design tokens are the visual design atoms of the design system — essentially design variables such as color palettes, font sizes, spacing, or animation durations used to maintain stylistic consistency throughout a product. They represent the tangible values of these design elements, making it easier to apply changes across platforms systematically.
For instance, a design token could define a brand's primary color as `#FF5733`, ensuring that every button or link across a digital property reflects the same hue. By using tokens, teams can avoid discrepancies and save time when updating the product's look and feel, as changing a single token can propagate the modification universally.
Design tokens empower developers and designers to work within a set of agreed-upon guidelines while streamlining collaboration and ensuring that the integrity of the design system remains intact across different products and platforms.
Component Library
Component libraries, also known as design libraries, are often associated with design systems. These comprehensive libraries house prebuilt and reusable UI elements, serving as a convenient resource for designers and developers to learn about and implement specific UI components. Building these libraries requires significant time and resources.
Along with visual examples of components, they include the following:
Component name: A unique and specific name for each UI component to ensure clear communication between designers and developers.
Description: A clear explanation of what the element is and how it is typically used, occasionally accompanied by do's and don'ts for additional context and clarity.
Attributes: Variables or adjustments that can be customized to adapt the component for specific needs, such as color, size, shape, or copy.
State: Recommended defaults and any subsequent changes in appearance.
Code snippets: Actual code excerpts for the element, with some design systems providing multiple examples and even offering a "sandbox" environment for experimenting with different component customizations.
Front-end and backend frameworks: If applicable, the frameworks required to implement the library, helping to avoid unnecessary debugging and pain points.
There are few do and don't about components :
Do's and Don'ts
DO make sure each component is correctly and accurately labeled.
DO provide clear and concise descriptions for each component.
DO include customizable attributes, but only if they are necessary and add value to the component.
DO regularly update and maintain
DO maintain consistency in coding practices throughout the library.
DON'T include components that are rarely used or not relevant to the overall design system. Use sub-libraries instead.
DON'T use technical jargon or industry-specific language that may be unfamiliar to others.
DON'T overload components with too many attributes, which can make them overwhelming and confusing for users.
DON'T overcrowd your library with too many similar components, which can lead to confusion and difficulty locating specific elements.
Pattern Library
Sometimes, the terms 'component library' and 'pattern library' are used interchangeably, but there is a distinction between these two types of libraries. Component libraries focus on specifying individual UI elements, such as buttons, inputs, and cards. On the other hand, pattern libraries encompass collections of UI element groupings or layouts, like navigation bars, sidebars, and grids.
Pattern libraries are often considered less comprehensive than component libraries, but they can be as thorough or high-level as needed. They typically include content structures, layouts, and/or templates, providing a framework for building consistent and cohesive user interfaces.
Similar to components, patterns are designed to be reused and adapted for various purposes, promoting efficiency and consistency in design and development workflows. They can also help maintain a cohesive visual language for a brand or product.
When creating and utilizing pattern libraries, there are a few do's and don'ts to keep in mind:
Do's and Don'ts
Do make sure patterns are well-documented, including descriptions, examples, and best practices for implementation.
Do provide flexibility within patterns to allow for customization and adaptability.
Do regularly update and maintain the pattern library to reflect changes and improvements in design and development processes.
Don't include unnecessary or outdated patterns, as this can cause confusion and clutter within the library.
Don't rely solely on the pattern library for design decisions; it should be used as a resource, not a strict rulebook.
Don't limit creativity and experimentation; pattern libraries should serve as a foundation, not a restriction.
In addition to the technical considerations of developing pattern libraries, it is important to also consider the overall purpose and goals of such libraries.
Pattern libraries can be used to streamline design processes and ensure consistency in user interfaces, but they can also serve as educational tools for designers.
How to organise a Design System
Organizing a Design System effectively is crucial for maximizing its usability and efficiency. The first step is to create a clear structure that organizes components, patterns, and other elements into understandable categories. This might involve groupings such as 'Foundations', 'Components', 'Patterns', and 'Guidelines'. Within these, further sub-categorizations can make navigation easier, for instance, under 'Components', you might have 'Buttons', 'Inputs', 'Navigation', etc.
For the concrete placement of library components and assets, it is beneficial to use tools specifically designed for design systems management. One popular choice is Storybook, which allows for the creation of an interactive UI component library and playground. Another option is ZeroHeight, which seamlessly integrates with design tools like Sketch and Figma, enabling designers to document and collaborate on design systems in real-time.
Version control systems such as Git can also be employed to keep track of changes within the Design System. This is especially important for teams working on the system simultaneously, ensuring everyone is aligned and updates are not overwritten.
It's essential to provide clear access points to the design system. Hosting it on an internal website or intranet, where all team members can access the most current iteration, can aid in keeping everyone up to date. Regular communication about updates to the design system and training sessions can also help ensure that everyone is using the system to its full potential.
Based on my personal experience, there is no one-size-fits-all approach to creating a Design System. It heavily depends on the organization or company where the Design System is being developed. It's important to remember that the Design System should serve the teams and designers, not the other way around.
If the Design System becomes a hindrance to production and product design, if it becomes difficult to maintain due to time constraints and limited resources, or if it becomes too large and unmanageable, then it becomes a problem.
I have worked on different Design Systems for various products, each with unique requirements. However, in general, I can say that a Design System can start as a simple UI Kit and gradually incorporate rules, guidelines, patterns, and more.
Developers and designers should have the flexibility to use the necessary components and design tokens for their specific projects. Creating a massive Design System for a small digital product that only requires a few components and design tokens can be counterproductive and detrimental.
