Lets have a quick reminder as to what exactly a Design System is. It's the collection of components, and the standards that guide these components as to how they should work together in a consistent environment. These standards cover a multitude of aspects, ranging from the guidelines for each component in the system, to typography standards and content writing rules. They extend to cover the overall thought process of the system and the planning of using it through functional and technical documents.
So a design system is what brings all the different elements of a product together towards providing a shared language for everyone that is connected to product. They enable those involved in the building process of a certain product to focus on more purposeful targets by getting other smaller issues out of the way.
Design systems are different from Style Guides as they don't only focus on the style, and they incorporate more than just visual representations, but they encapsulate a whole ecosystem of guidelines related to different entities, and style being one of them.
They are also not Pattern Libraries. A pattern library is a set of reusable components and interactions, like buttons, input fields, and modals, which again could be treated as only one part of a design system.
Also, not all design systems share the exact same standards. The kind of design system to go with depends on several factors; including the number of people that are going to use the system, how familiar they are with the concept of design systems and what their backgrounds are, what product the system is built for, who it targets, and how consistent or flexible does it need to be.
There are three main ways to go about having a rough categorization of design systems, and they go as follows:
Flexibility determines the level of strictness that is enforced in the design system. A more strict system elaborates every bit of detail in its documentation. It also establishes strict processes when it comes to introducing a new pattern or component, so these types of systems are usually broader than their flexible counterpart, in order to cover the different cases that may be encountered when working with it in the same detailed manner.
Other systems are more flexible, offering freedom that is governed by some not-very-strict guidelines, which people working on the system are free to experiment with depending on what they are working with in a certain case.
It's up to the makers of a design system to decide on its level of strictness, based on the goal that the system is created for, and how its users could benefit from it the most.
The level of modularity can also vary from a design system to another. A system ultimately has a number of interchangeable components that can be combined together in different ways. But some systems offer components that could almost work any where they are instantiated, while other systems will have components that require at least a certain level of integration with other certain components, before they can fulfill their optimal potential.
A more modular system fits larger scale systems that could welcome an abundance of reusable components without the need for higher degrees of integrated components. An example for this could be an e-commerce or a government website, where breaking down all design components into the smallest element possible will reap its benefits on the larger scale and in the long run as the website grows in size. But this makes the kind of modular systems more expensive to build, since it's going to take more thought and time to make sure these modular components are both independent and also fit well together.
A system that is built with less modularity at its core, often called more of an integrated system, focuses more on a unique scenario and outcome. It's more suited towards smaller products that could often see a complete overhaul over short periods of times, like portfolio websites or promotional campaigns. These systems are still composed of parts, but these parts are made of components are put together in an often special way that will lose its goal if they were to be interchanged with other parts.
This one answers the question that decides how a team working on a design system should be organized. There are different team models that fit different conditions.
Where one team or even one person rules the design system. It's common for startups to go with a solitary model since it's cost-effective. However, it doesn't scale very well due to the involuntary tunnel vision that one person or one team might have in contrast to a diverse team or more teams that work on the system.
Often times, this kind of design systems is made to meet its owners' needs and align with their products mission, which could limit its sharing capabilities with others outside the makers' organization.
Perhaps the most common team model. It reflects a team whose main goal is to build a system to be used by others, so these systems are often free from biased decisions that are based on products the creators own, and that in turn allows them to serve multiple product teams.
However, a centralized approach may focus too much on providing whom they serve with what could sustain their autonomy while sacrificing effectiveness, since it lacks the influence on designers to balance some trade-offs between the actual product and the system objectives themselves.
This kind of system involves people from different teams that come together in order to build and manage the system, so this provides great insight into what's required for both the product features and user needs.
Design decisions in such systems are made collectively by a group in charge, and these decision then propagate to other teams who can either accept such decision or ignore them.
This model is the least biased since it involves different perspectives, and also encourages decision making across a number of individuals.
Lets make it clear as to why would anyone take the time and effort to build a design system.
Consistency is one of the core principles of proper design and user experience. A consistent design is intuitive, predictable and easy to understand.
There are different forms of consistency to be found when building applications:
Elements and components that look like they are made from the same mold and have high similarities in their visual properties promote visual consistency. This relates to the sizing, colors, fonts, and anything that the user can see from his end. Visual consistency increases the ability of users to learn a product.
For a user to go back to the previous page, he would have to click a button at the top left corner. If a user adds a product to his cart, the Add To Cart button should behave the same and give the user the same outcome, regardless of whether the user is browsing today's hottest deals, or he's looking at products in their regular categories.
Functional consistency ensures the user is getting the outcome he would expect when using an application. It helps make the user feel safe and familiar with the app by increasing predictability.
Mixing both visual and functional consistency serves to keep the consistency of the environment around the user in check. Now even if new features were added to the product, new pages were introduced, as long as they comply to the currently existing rules of consistency, the user should still feel like home and wouldn't have to learn new ways of doing things in the long run.
It allows users to focus more on their actions and tasks across an application instead of taking the time and effort to learn the user interface and how the action should be carried out.
To go the longer mile of relieving the user from having to learn to interact with products. External consistency comes into play when the same user interface principles could be reused across different platforms.
A user that has learned how to navigate and interact with your website would appreciate it and feel much better if he were to be greeted with the same environment on your mobile application. So external consistency can be achieved by keeping things familiar across different platforms, systems or products.
So it would be annoying for users if each page of an application had varying layouts and different ways of doing things, as the user would have to learn how to walk his way through every context of the application based on where he is.
Instead of trying to communicate with the user in different languages, the biggest benefit a design system could bring would be to enforce consistency across the projects implemented with such a system. The achieved consistency serves users well since the balanced outcome of products that are built using repetitive components has a positive effect on reducing the cognitive load on those using such applications. They get familiar with the interface quicker and the UI becomes overall easier to understand.
Consistency also serves designers by relieving them from focusing too much on design and the low level details of design components.
Imagine having to worry about the shape of a button to use every time you wanted to add a button element to a page, or if designers have to address the button's different states and maybe other properties or transitions like hover effects each time they're calling the component.
Instead, designers can focus more on the bigger picture. They can improve the user experience and address the flow of things on the larger scale after abstracting the agreed-upon characteristics of components.
Other major benefit would be speeding up the process of development. It's certain that a decent chunk of time needs to be dedicated to building the system in the first place, but it's an investment towards long-term benefits.
Having to build every component from scratch for every project is sure to take up a lot of time. This is especially true when each component also needs to get its various states, themes and properties set and validated.
Development and the overall work on the project after the system is in place should feel like putting certain elements together without having to care too much about the underlying specifications of the components.
All team members will find a documentation of the components they need to use, guidelines on how to use them, as well as other patterns and practices to be adopted while they're working on their next project.
Prototyping becomes much faster by using the already existing components. It frees the team working on the project from hassles by having every component and element well studied and thought before it's included in the system.
This increased speed of development will ultimately result in a faster time to market and more agile releases and deployments, and it will also allow the team to focus on other things that could take the product to the next level. Improving accessibility, addressing more of the business needs, and fine-tuning other details towards promoting the visual language.
With a growing design process and having different teams joining the production pipeline, it's necessary to make sure that everyone understands what they're working on and the resources they have at hand.
Instead of having individuals from the different teams roam different folders and files to seek the knowledge they need, a design system provides everyone with documentation as to everything they would look for to get familiar with the project.
A design system also helps to allow not only every team member working on the project, but also the stakeholders to be on the same page. This fosters collaboration across the spectrum of the project and helps developers, designers, UX engineers and clients to share a single shared source of truth.
All team members share the same language, guidelines and resources. This centralized center makes team collaboration easier and helps members make better decisions by establishing a more organized work flow, consequently increasing autonomy and speeding up both development and testing.
This makes the on-boarding process faster for new team members as well. A new designer has just joined to work on the project? The client firm has appointed a new CTO? Everyone gets to be relived from asking too many questions and can find what they're looking for in the design system documentation.
Just like financial debt, there's also technical debt that results by focusing design and development efforts too much on short-term goals instead of building for the long run.
Building for limited use cases to cover short-term issues results in an accumulation of unused and obsolete components over the course of time, and they would also require maintenance. Hence, such elements which becomes a growing burden that comes in the way of rapid development.
Design systems serve to provide a unified language for teams working on products using such a system. So teams would build general components to be used across different applications instead of building a component for a certain use case.
Reusing the already made components and elements reduces technical overhead, both design and development wise. It also allows such systems to easily scale by letting designers and developers reuse these components in different environments.
Having well-documented rules and guidelines that govern these components also make sure to maintain the purpose behind the system and unifies the user experience.
A design system should help have organized design assets and a clean code base that is easy to update and maintain. Changes should be done to the design system without having negative outcomes.
After mentioning how a Design System promotes consistency through using already made components, it can only seem like having such a system kills creativity.
However, the truth is it actually increases the potential for people working on a project to think of more innovative things to add to the project.
This is possible after setting all the tedious and repetitive work aside by using pre-defined standards and elements. Since coming up with something innovative and adding it to a project does require a considerable amount of time. Having eliminated the greater chunk of creating design elements from scratch, team members will be allowed some freedom to invest in the project itself and its business needs.
With all its guidelines and rules in place for visuals, voice, tone and every other property that make up the final product, a design system ultimately aims to communicate a specific feeling and identity behind the products it ships.
The consistency in communication delivered by design systems helps people remember how a brand speaks, what it feels to use their products, and it delivers the specific personality traits of the brand.
A streamlined design process that is achieved by a design system makes it possible to build impactful brands that communicate well with their audience through a well-developed personality and mission.
People will feel more connected to such brands and trust will develop among them when they see how the products speak to them with consistent and predictable outcomes.
These many benefits make having a Design System a solid investment especially for larger scale teams and projects, despite the process of designing and building the system that may seem like a lot of work.
In the following chapter, we discuss the process to be taken for creating a design system to reap the many benefits of having a modular system.
Getting the buy-in for creating a design system in a company is often quite hard to achieve. The main reason would be the time and man power that need to be dedicated to building such a system, and how much the company is willing to invest in such a process before it starts to reap the benefits.
Other reasons include some myths that introduce some doubts to the effectiveness of having a design system, the following are the most common ones:
Design systems are often thought of as limiting constraints that are enforced upon a work-flow that cover the general aspects of any application. This is due to the fact that they are at heart universal systems that are made or reusable components that are meant to fit multiple scenarios.
Sometimes there's a special or unique scenario that needs its own components and guidelines. Even in this case, a design system is still the better option.
Without a system, designers would keep on creating custom elements for such scenarios, and they end up increasing the technical debt of the project.
With a design system, however, these new components can also be created, but with compliance to the system's guidelines. They are then reviewed and introduced appropriately to the system and made available for everyone to use.
The same nature of a governing system often implies that the process of design using such systems will consist of merely putting some already designed components together to form bigger templates.
But the fact is, a design system offers independent components for designers to use, without having to worry too much about the low-level details of such components. It's also an equally boring task to keep crafting pages over pages for web or mobile interfaces.
Design systems actually speeds up this process by abstracting agreed-upon details in design elements. This will actually give designers the freedom and space of mind to accomplish actually exciting tasks, like thinking of new features or functionalities to be included in a project, and neatly crafting some unique ideas to add value to applications.
Also, designers are still free to make style updates all they want to the already existing components, and in a way productive manner. As these updates will resonate throughout the system, given its modularity.
Some companies may argue that every product they own or work on is unique, and that there are no two true identical applications that could share a standard design system.
However different these projects could be indeed, user interactions, or at least the most common interaction patterns do not see major changes from one app to another. Some basic elements will share the same characteristics and functionalities across different applications.
For example, there is no need to design a different drop-down component for every app, when, at heart, it's basically the same component design.
So it's better to create one standard dropdown component, and reuse it throughout different apps. This would still give designers the freedom to tinker with different design principles to add some sort of a personalized feeling if needed, but they wouldn't have to build the low-level design of the component each time they would want to use it.
Design systems are often thought of as short term projects, which could be created once and stashed, only for their components to be reused in the future.
The truth is design systems are more of an ongoing reflection of established products. These products may require certain additions or improvements along the road, so these updates would have to first be properly incorporated into the design system, which will be automatically fed to these products.
This means that design systems are meant to scale, and they also make updating products a more efficient process.