Design systems can be sometimes confused with pattern libraries or style guides. In fact, a design system is a combination of of both, in addition to more defined standards and principles that make it possible to achieve a complete eco-system that can enable teams to create better products more efficiently.
Generally speaking, design systems consist of three pillars; namely: the UI or Pattern Library and the style guide which includes both general principles that define the identity of the product, as well as other principles that guide the use of the different components through the product.
A pattern library is the part of the design system that holds the different elements that have been approved by the team of creators and are available to use within the design system environment.
They vary in size and complexity as they can be a single minor element like an input field, or multiple grouped elements like a navigation bar or a form.
Every element in the library serve as a Lego block which is part of the bigger picture of templates and pages that are made of smaller components, as each component can be integrated with other components to form bigger blocks of visual elements towards constructing a certain page, and ultimately a website.
These components are used according to certain rules that are also defined in the design system documentation, these rules govern how and where a component should be used relative to the context it's used in as well as to other elements around it.
These rules serve to make sure that everything is in harmony on the larger scale and components of the design system work well together, providing a visual consistency and promotes a stable user experience.
Although every pattern library could include different elements based on the nature of both the design system and the product(s) it is serving, there are some commonly used components that always exist in the majority of pattern libraries.
These common elements include: buttons, input fields, menus, and navigation to list a few:
Each component in the pattern library should have a clear and concise documentation that is easy to interpret by both designers and developers. The documentation can include:
the name of the component or pattern. It should be short and straight forward. Some low-level elements can be easily named in a direct manner, like buttons. While some more complex patterns could require more thought to end up with proper naming that is easily understood by everyone.
Each component could also have a brief description that explains its functionality and what the component actually does. The same principle of complexity applies, and each should be addressed accordingly.
Going beyond description, designers and developers could also benefit from rules that dictate when and how to use certain components and in what context. These principles ensure proper interactions among components, and could also introduce certain restrictions on component usage if needed.
Some components can have different states, as well as alternative layouts to be provide more flexibility and some times indicate certain user interface states based on user interactions.
The documentation of components and patterns can include the different layouts and states, along with their relevant class names so they are easily distinguished and accessed by both designers and developers.
An example can be a button that can have both rounded and regular corners, or maybe no borders at all.
A button can also have different states based on user interaction and data validity. A grayed out button indicates that this button is disabled, and a clicked ( active ) button will have slightly different visuals than untouched buttons.
Another element of variety can be the size of the component. There can exist different sizes of buttons in the pattern library, which should also be named consistently. For example: small, medium, large, and extra large.
Every component will eventually be implemented as a piece of code. This makes including code snippets of the components, and their respective variants, useful to reproduce the same pattern.
A design system also contains a number of policies that govern how each part of it should behave on its own, and in accordance to other system elements.
These rules indicate how a certain component should be laid out, how it should look like, how big it needs to be, what colors work with it in its default state as well as alternative colors for its various states if any exist.
They could also tell how a certain component should interact with its neighboring component, and also with what surrounds it.
These are the kind of specifications that are implied by the rules of the design system, and they serve towards having an environment where everything plays well together, to avoid inconsistency.
There are also more general guidelines that target the overall look and feel of the products built with a design system.
These guidelines highlight the standards of branding, design, typography, colors and icons to list a few. They serve to help the teams working on a product know how to publish content that speaks the same language of the design system, as they allow teams to communicate the messages intended to be delivered to the users in a clear and homogeneous manner.
The ultimate purpose of a business that is looking to establish an online presence would be to connect well with their audience, and communicate their business goals and values to the customer base they serve. This process of communication could witness some struggles if it's not done in a consistent manner that clearly highlights the characteristics of the brand or business that is trying to reach their users.
If communication is done in various ways and through differing channels, it will be harder for the audience to grasp the true meaning behind that communication. Following a style guide that specifies the voice and tone of the business limit this variation and help users feel more focused and in sync.
And the benefits of having such a style guide is not limited only to the audience, but they also help people working on the project -or those who are new to join the project- on different ends, like social media or business managers, speak the same language.
A style guide can include the following:
Design principles are a collection of rules that define the core values of a product, and they determine certain approaches to be followed within the domain of the product.
Effective design principles are:
These principles serve as a compass for guiding both stakeholders and the developing team to make better decisions. They provide an overall better picture of the product and its characteristics.
They also serve as a great reference for validating new additions to a system, so they are more in line with the product policies.
These guidelines ensure consistent branding, and prevents inconsistencies in marketing and communication.
Brand guidelines are the reflection of a product and its identity that its audience perceive. They help make a brand both understandable and consistent, and they establish proper connection with the audience.
They include different elements that make up the brand; including the shape and usage of the brand logo, the brand name, the colors, fonts, and every asset that shapes the brand, like images or illustrations.
Brand story is a key element in the brand guidelines. It gives people out there insights about the identity of the brand and helps people understand its core values.
This usually includes the brand vision, and its mission towards the world, as well as the certain values and characteristics that make up the brand.
It's necessary to define the shape and usage of a brand logo. A logo can also be used in variant formats and different situations, so it's important to include the different scenarios where the logo may be used and how to properly address its usage.
Logo guidelines should also provide examples for different use cases, along with colors of both the logo and its background, and the required spacing of the layout containing the logo.
The logo can also be made available for download, so others may use it according to the specified rules and usage guidelines.
Colors are an integral part of any brand, so brand guidelines should also highlight the color palette that the brand is made of.
These guidelines should include the different recommended color combinations, as well as both the primary and secondary colors of the brand, with their HEX / RGB color values available for copying.
The typography section should include the font family ( or families ) of the brand, the different sizes of the font being used, as well as font weight, line spacing, colors for different text conditions, and should basically cover the different cases where text is used in a product, and how it should be formatted and presented.
Each brand has a way of communicating its ideas and values to its audience. A brand may aim to communicate with its users in different ways, based on the personality of the brand.
A unique brand voice sets it apart from other brands, and also builds trust in the brand audience, so it's necessary to reflect the values the brand is based on.
Addressing the different tones of the brand voice is also crucial to make people feel connected emotionally to the brand. It enables the brand to be aware of different user conditions during communication.
Another important section in the style guide is the icons established as part of the design system.
This section showcases the icon set of the system, whether they are designed from scratch, or a ready-made set icons from another source.
The icons guidelines provide guidance on how to use and implement icons in the user interface, and could also include instructions on how to create new icons to match the currently existing ones.
Make sure to highlight necessary terms of usage, like sizing and padding, shadows and colors, so the icons deliver their optimal results when they're called.
The design system may include a set of images, whether they are photographs or illustrations. This section should provide a set of principles that guide the use of such assets so they are appropriately used in a consistent manner.
These guidelines should aim to achieve the desired engagement with the users through the available set of images.
They should also include rules on when to use, and when not use images in the design, and the best practices to be implemented when using them.
Since the ultimate purpose of having a design system is to provide consistency for both users and those working on building products using such a system, it's good to note that this consistency also extends to the written code base of the design system.
A properly styled code base makes it easier for developers to introduce changes and updates to the already existing features of a product, which results in a clean, maintainable and scalable code that is easy to understand by different developers.
Teams can choose to create their own code style guide or follow well-established ones, like the code style guide of Airbnb or Google.
At Baianat, we experimented with different code styles, AirBnB, Standard, Google, and while we agreed on the reasoning behind most of those styles, it did not boost productivity for us. For some it meant the CI failing because they forgot to do something. For others, it was an annoyance when they just want to prototype something. To strike the balance between productivity and consistency, we went with Prettier. While we also don't agree on some reasoning behind some rules in Prettier, we put our personal preference aside for better productivity.