The output of a Design System
I always feel something is missing when I read “What is a Design System?” articles. But here the other day I finally realised what I felt was missing — but more on that later
I went online to see what others have to say about design systems and it turns out people have various interpretations of what makes up a design system. Ask a developer and he might say that it is a collection of reusable components whilst a ux designer might say it is a systematic approach to product development. But at least there is a general consensus on what it is.
So what is a Design System?
A design system is a collection of design principles and guidelines, constraints, best practices, design files, component libraries and documentation. It’s what we like to call the Single Source of Truth and it’s what designers and developers use when working on projects.
Why use a Design System?
With a design system you can design at scale while delivering a consistent brand and user experience. Developers will have access to tried and tested reusable components that hopefully conforms to WCAG standards. This will streamline development across the organization reducing time writing code and performing unit testing.
When should the organization embrace a design system?
That depends on the organisation’s maturity. A design system should come from the need to increase efficiency at scale. But while the need might come from developers and designers, it’s the company leaders who need to implement it across the organisation. Because developing and maintaining a design system is time-consuming and requires resources.
I would recommend any organisation that has multiple designers working on a large product / multiple products to invest in a design system. Because having a design system will be cost effective in the long run.
What makes up a Design System?
A Design System includes a mix of workflows, processes, design principles and libraries. It’s a living “document” that is continuously updated, shaped and formed.
Style Guide
The style guide describes the principles, rules and guidelines about colors, typography, spacing and the general “tone of voice”. It also describes UI and interaction patterns as well as page templates.
Design Kit
Over the past few years a range of tools have come and replaced Photoshop for designing web pages. So if you are following the time you are probably using design tools such as Sketch, Figma or Adobe XD. Following the design guide you will use the tool of your choice to define:
- Color Palettes (Color tokens)
- Typography
- Icon library
- Component library
- Templates
Documentation and sharing
Once you have created a style guide and some pattern libraries, you need to share it with your organization.
The easiest way is to use online services like InVision / Zeplin if you are using Sketch / Illustrator or by using Figma / Adobe XD which eliminates the need for InVision or Zeplin.
I also recommend creating a web page where developers can go to read documentation and see the code for various components. And this brings us to what I feel is missing from many design system articles; The output from a design system.
CSS Framework
The chances are that you already have used CSS Frameworks like Bootstrap, Foundation, Materialize or Skeleton. The output of your design system is exactly the same. It’s a downloadable package containing your component and icon libraries, fonts, typography and images. On top of that you have your sass files, config files and anything else needed to compile into production ready css files.
For large organisations your framework might not be enough for some projects and that’s ok. As long as the project follows the design principles and guidelines, they are free to develop their own components which may be considered added to the design system thus giving it an organic growth.
Contributions and growth
There are multiple ways to go about growing your design system. Some are very strict where only have a few people managing the design system, but this can quickly become a bottleneck. Others may treat it as a “open source” where anyone can contribute, but this may lead to the design system spin out of control.
In my organisation we encourage project teams to submit components for review if they have created a component to solve a specific problem and they think it could be useful for other projects. Over time the Design System will grow and follow new user behaviour and technology.
It´s also important to point out that in large organisations there may not be a “one size fits all”. Our approach is to have the core Design System with its style guides and common components at the bottom and from here branch out to create industry specific libraries.
