Róbert Macháč | Mar 2020
How will your business change due to the Coronavirus
A design system is a living set of components, style guides, pattern libraries, principles, brand values, shared beliefs, integrated directly into an everyday workflow of teams at your company. They are a more mature, direct continuation in the digital world of graphic standards manuals.
In short, the design system saves your company time and therefore money. It is a foundation of your design and engineering teams that helps them to create better products, improve efficiency, cohesiveness, quality and provides meaning to their work. Design system, among other things, makes sure your products have a consistent experience across all platforms, it guides the teams with its functional documentations on the decisions behind individual parts of your products, and how and why to use them.
Karri Saarinen, a co-creator of design systems at Airbnb, said this about design systems:
"The design language system provides us with a shared understanding of our visual style and streamlines contributions to a single system. This system also enables all of us to prototype and experiment with ideas in high fidelity faster and at a lower cost. I believe that aided with these systems we can focus more on actual user experiences and concepts we want to create in the future."
Not everyone needs to have a design system and what is important to realise is that you can create an amazing product even without a design system. You should, however, consider creating a design system if you work on a larger, more complex products, if you have multiple teams at your company or if you feel you need more systemic ways to guide and manage collective efforts of your teams. A good design system articulates the culture of the brand and over time it will help all teams to be more aligned & in sync of understanding what is the company's one shared vision.
There should be only one design system per product or a team. Large corporations like IBM or Apple have multiple design systems, each covering different products, areas or platforms. When it comes to design systems, there are three main issues of why having them might not work out. The first is, they never get implemented enough into the everyday workflow of the teams, the second is that the design system is simply poorly made and the third is that they don't evolve with the product or they don't evolve at all. This is what I meant at the beginning of this article when I wrote the design system is a living set of deliverables.
Example of Design system for our client Kontentino
A loose design system leaves space for experimentation and merely recommends rules the teams should follow. The teams are encouraged to think openly, they are more autonomous and have more freedom in discussing what should be included in the design system.
Risks of having a loose system may result in having too few constraints, a lot of inconsistencies, many solutions to the same problem and too vague documentations. The team has a lot of creative freedom which can result in custom tweaking over and over again of even the basic components. Worst case scenario, nobody will follow the design system, because nobody uses it anyway.
A strict design system requires the team to follow the rules. There is an emphasis on detailed and precise documentation. The system also needs to very broad and cover all cases the team may encounter. Introducing updates or new components to the design system need to follow a strict review process.
Having a strict design system may slow down innovation and kill creativity because new ideas take too long to implement. The system preserves outdated, ineffective patterns as well as the good ones. Ultimately, strict rules may become too frustrating to follow as they can often become too limiting.
An ideal design system is a balance between loose and strict. It should be able to evolve, the base principles should be followed, used and revised maybe once a year. The UI should be as timeless as possible, take into account future development changes, which shouldn't be too drastic or difficult to implement. Core values and style guides should ensure that everything goes well together, provides value to the end customers and benefits the product experience.
When it comes to the organisation around design systems, there can be many models. In the centralised model, a single design team produces a design system used by many other teams as part of their everyday tasks. In this model, the team can be implementing a system an outside agency produced. They serve many product teams, while not being deeply involved in product development. This often results in them lacking context and knowledge of challenges the end customer faces when using the product.
A perfect example of a solitary model is Bootstrap. There is usually one team that makes a system available, but their efforts are focused primarily on their own needs. This means that the design system must be considerably customised by another team who wants to use it. You can learn more about these models in this article from Nathan Curtis.
The process of making your first design system starts with assembling a small group of designers and engineers. This group should have less than 12 members. Decide who will be responsible for which parts and who will manage and guide the whole process.
Set a goal for the design system. It can be for example making a visually stunning and accessible design language consisting of well-thought, reusable components. If the scope is too large, reduce it, for example by focusing on one or two platforms at first.
The next step is to set a strategy to find out all the customer needs, brand values, design directions, make a roadmap and commit the company to make a design system by illustrating the benefits it can bring. Part of this step is also defining the organisation method and rules.
A strategy is also deciding how will you and your team communicate and collaborate. Communication should be clear and direct, collaboration easy to adopt.
One of the most overlooked parts of a design system are company values, vision and principles. Businesses are constantly evolving, and so are design systems. A good design system needs to empower the teams who are using it in their everyday workflow. It should give meaning to their work, and explanation why certain design decisions were made.
Here are a few questions to help you define values:
Principles of philosophy define the shared direction, not a solution. In other words, make tools that will help people with their work. When defining the principles, strive to articulate them in a way, so that anyone who reads them understands what they mean. You can use a simple word, but only if there is included an explanation for it. Good principles are authentic and genuine. Principles that can be found everywhere are for example simple, useful, enjoyable, however, these qualities should be given and don't provide a useful guide for the team on their own.
Instead, go into more details, make the principles more actionable and practical. For example, a vague principle could be "Clear." A practical principle would be "There should be only one priority for the users." Another example of a vague principle could be "Useful". A practical principle would be "Understand the customer needs, talk to them, research and analyse data. Don't shoot blindly."
A good real-world example of well-articulated philosophy and principles is Apple's Marketing Philosophy from 1977.
Make an interface inventory by auditing and collecting all the elements in your product. You can start with the smallest, most commonly used components like icons, inputs or buttons and finish up with whole pages consisting of modular components, groups and sections.
Now that you have all of the parts of your product collected, break them down into atoms (fundamental components). To work more effectively, use the Atomic Design methodology. This step is necessary for you to find any inconsistencies or old versions in the interface and will help you steer your focus towards those parts of the product that need more attention.
The visual design language, style guide or UI kit is arguably the most important part of the design system. It is the core foundation of the design system, because it defines the overall style, feel and interface of the product.
If you already have a simple style guide or pattern library, feel free to use & improve them. You can cover all of these:
A lot of design systems contain parts of the interface on their own, without any context or guides on how or why to use them and how to combine them with other elements. In your design system, you should include all possible combinations of said elements, let's call them components. By doing this, you will show how and when these elements should be used, which helps to avoid inconsistencies and misuses later on.
Each component should have optional elements inside of them, for example, there should be only one component for a card that has a title, description and an image. This component should work even when there is no description or the title is too long to show on one line. I encourage you to use Components & Variants in Figma or Symbols in Sketch, so if you ever need to make a change to one component, it will update everywhere, even if this component is inside of another component. This allows you to create reusable, customisable components and saves you a lot of time.
When it comes to documentation, there are two ways you can tackle it. The first way would be to explain early, during the process of making a pattern library. The second way to approach this task would be to describe the design choices and solutions after you are done with making the pattern library. I prefer to document the components as soon as I add them to my design system. I do this so that I don't have to remember why I made certain decisions or how the hundreds of components should work.
The documentation should be direct and clear, definitely leave out any abstract or fancy words. Write, so that people understand what you meant right away. Assume, that people who will use the design system are not designers or someone with extensive terminology knowledge in your area of work.
Remember, design systems are made for people who need to be able to use them in their everyday workflow. Ideally, you should be able to find a component or information within half a minute. Having a large design system in a long list or a single page in the Figma/Sketch file might not be the best way to present it. However, I'd still recommend using Figma to design the design system, because of its collaboration features.
A lot of companies like Apple, Mailchimp or IBM have large design systems used in many cases by millions. These systems need to be accessible and easy to navigate around. All of the three mentioned companies use a sidebar with links to sections or pages of the design system. Using this kind of layout enables them to structure their design systems in a clear, easy to use way, and always allows them to get to other parts of the system with one or two clicks.
Think of a design system as a "living organism". It evolves and it guides people who work with it about the proper use of the components, about the brand, principles, and much more. It helps to improve communication and understanding between designers and engineers.
Introducing a design system means that some decisions that were previously handled by the teams or individuals on their own will be taken care of centrally. You should ensure that the system will be used and followed by all teams and that everyone knows how to use it and contribute to it. I've already written about strict and loose rules that you can use to manage additions and changes to the design system. It is up to you and your team to decide what approach is best for you.
With each contribution, always ask these questions:
You can also ask the above-written questions if you can't decide whether to remove or keep something that is part of the system already.
A design system's success shouldn't be judged solely by its release or launch. Measuring a design system's success is a continuous process determined by monitoring team & product improvements. Systems are meant to be actively used. Your main motivation is to help your team by improving the quality of their work, efficiency, and cohesiveness of your product. That’s accomplished by your team integrating the design system into their everyday workflow.
A design system is a success when it meets the goal you set when you started building your design system. This goal can for example be:
I like this quote from Nathan Curtis that you can use as your design system goal: "A system’s value is realized when products ship features that use a system’s parts."
To sum up, you should judge the success of your design system by goals that can be measured and that are realistic. During the process of making your design system, regularly refer to your goals and priorities, to make sure there is an improvement in the right direction. Feel free to set more goals or clear up any priorities along the way and do everything you can to make the best design system possible.
In the Hack the Design System book the authors asked their interviewees about what they think is next for design systems. Here is an excerpt of one of their thoughts:
"High fidelity interface design is becoming increasingly accessible with ready-made components and right tooling. Developers and product managers can now do work in a span of a few hours, where it used to take designers many days to complete. While many feel threatened by this, it’s a very good thing. It just means that designers do less busy work with mockups, and can focus more time on things that make a difference and have more value like: spending more time with users, exploring alternative solutions, creating new illustrations and brand assets, perfecting service patterns, and thinking beyond the screen."
I'd like to also add, that with more and more advanced AI like GPT-3, the traditional repetitive work of making a visual audit of your product or working with texts in documentation or manipulation with any kind of data makes it likely these tasks will be eventually automated. However, I wouldn't worry, since artificial intelligence isn't capable of thinking creatively. Yet. While the building of design systems may eventually become automated, the systems are only tools and they are not essential for designers or developers to do their job. They are used to help teams speed up their workflow and create better products.
First of all, if you are reading this you are amazing and I appreciate your time reading this article. There is an infinite number of ways to building a design system and it's entirely up to you and your team what will you include in them. Design is about experimentation, people, always trying to improve and find better solutions.
