Best practices for building a design system
Get some invaluable tips on how to get started with design systems and what common pitfalls you should avoid.
Many organisations have obtained an interest for design systems. If you have a large enough organisation with several channels to feature your brand—like websites and apps, you should probably use a design system to manage your graphic components and style guidelines.
But as you start building your design system, you should pause and consider the long-term ramifications and possible pitfalls. To help you in this process, we have compiled a set of best practices for building a design system.
For most people in your organisation, a design system is "just another tool" they have to work with, or in some cases, something they aim to ignore. This sentiment must of course be avoided, making it imperative to communicate early on how a good design system can contribute to your organisation.
There are several advantages of a design system, as Oscar Insurance Corporation notes, including:
- Scalability: Either it's plain, old growth or breaking up a company into smaller pieces, scaling up or down can be a headache for any organisation. Using components and patterns in a wider or narrower context is, however, strongly alleviated by the use of a design system and will at least make your design team happier.
- Reuse: Instead of working double or unnecessarily starting from scratch on every new project, a design system allows your editors, designers, and developers to quickly reuse images, buttons, styling, and codes.
- Brand protection: Protecting the brand is an increasingly important priority for any organisation, as the brand is a quality marker and a fast-track for customers in their evaluation of your product. Having a central repository of definite brand rules in the form of a design system is another key advantage.
Be sure to make these advantages widely known in your organisation before venturing forth on the process of building a design system.
Keep it simple
Overly complex systems will turn off most people, maybe except for the most enthusiastic geeks. On the one hand, a component with a too strict definition of colour, size, layouts, functionality, and interaction patterns may be limiting and demoralising. One the other hand, too much freedom and too many options could lead to inconsistency and damage your brand.
You will need to strike a balance between freedom and control. While this might be solved component by component, a general principle can be to avoid building customisation preemptively—and rather add customisation to single components when needed.
Another principle is to build components you need, and nothing else. Don't add pretty buttons or CSS just because you admire their aesthetics—add components for a reason. Designing components without any proved use case or task to solve is like designing a poster or shooting a video without thinking about the content.
In the name of simplicity, only build components that are necessary for your current and projected needs. A logical consequence, then, is to remove any unused component from your design system.
Build for scale
Scaling means adapting your design system to a larger or a smaller sphere—e.g. taking into consideration the use of your components and patterns in a larger amount of different channels than you initially start with, or vice versa. It's never too early to build for scale, and neither is it too late.
The goal of scaling is mainly obtained through having a solid system of clear design guidelines, standards, and principles, which make it easier to scale design patterns and components alongside a growing design team or organisation. A solid design system will ensure consistency and quality across all digital experiences, and increase the speed and creativity of your designers.
If you work in a large-scale organisation, scaling design might be achieved optimally through a team effort. Not everything has to be done "by a committee," of course, but designing in isolation risks duplications and inefficiencies.
Furthermore, scaling should be of advantage for everyone in your organisation. Find people in other teams and departments, introduce them for the positive effects of a design system, and enable them to bring the principles forward in the respective functions. Involve your development team, your marketing team, your operations department, and more. No scaling will occur if it doesn't involve an increasing amount of people and functions in the long run.
For a more hands-on tip on scaling, consider whether gating certain features of a component might be a smart move to make. If your organisation is large and encompasses several digital experiences, apps, and internal tools, you might hesitate more and more before changing a component—as you might not necessarily know how a changed button will manifest across different channels. To mitigate this, you can for instance enable feature flagging to gate specific features and updates in a component, instead of an all-or-nothing design system.
Change is OK
Even though IT has rendered obsolete the notion of something being written in stone, the general feeling of stability and conservatism remains. Believing that you cannot change a primary colour or visual guidelines because "they have always been that way" is wrong thinking. We live in a digital age, where digital disruption and innovation are shifting trends quicker than ever before. Digital elements can be changed and should be—if there's a valid reason.
As far as digital design systems are concerned, no decision is permanent and anything can be changed—anytime. Don't get caught in a quagmire of indecisions and insecurity, use analytics and user insights to back up your claims of needing to change a given design component. Ensure flexibility. Take a look at the data from user paths and workflows to decide where you can be rigid and where you can be flexible in your design system.
Enable smart documentation
In any kind of project or undertaking it is paramount to document what you have been doing, what you planned, what you did, and what you are planning to do. Performing documentation might be a tedious and time-consuming process, but you gain immense advantages in the form of explaining why something happened, why you chose the way you did, and how to avoid duplicating work.
The same principle goes for a design system, especially when your design team or organisation as a whole grow larger than what a simple common understanding or a word-of-mouth approach can handle. So you need documentation for your design system, but what is the best approach to maintain an up-to-date and accessible documentation for all your components in design patterns and code?
A documentation is worthless if nobody uses it. A fabulous PDF documenting all your components, styles, and guidelines will quickly be outdated, as well as being lengthy and difficult to navigate. A style guide website might be a tad better, but if not done properly from the beginning with a dedicated CMS, this too will quickly be outdated and difficult to maintain.
An example of smart documentation, according to UX Planet, is replacing heavy documentation with lightweight, interactive, easily accessible and updated documentation—in the form of a Sketch library. Transform all components into Sketch symbols, use the Sketch plugin Lingo to create a shared team UI kit with always updated components, and use the plugin Runner to quickly search and apply a predefined component to create an interface.
Build a robust process
All of the former best practices will contribute to this last point, namely to build a robust process for the maintenance and use of your design system—enabling your team and organisation to grow and contribute for the foreseeable future. You should have an established design process, which standardises documentation, hand-off, code review, and quality assurance.
A design system is like an organism, it will continuously change, grow, and adapt to your current and future needs. Utilising these best practices, from communicating early and keeping the design system simple, to building for scale and enabling smart documentation, you should have a good shot at succeeding in your endeavours.
Bonus: 5 quick tips from Gjensidige
Gjensidige is a Norwegian mutual insurance company that has built a dedicated design system for their digital channels. We asked digital editor in chief, Torstein Aas-Hansen, to share the company's experiences and best practices for building a design system, and here are their five essential quick tips:
- Put time and effort into working with the design system, and collaborate across functions and departments.
- Find inspiration from others, but make a design system that suits you.
- Start modestly, with a design system that is easy to build and can be used by many people in different settings.
- Create a roadmap, telling you where you want to be in six months, and what you have to do to get there.
- Ensure a multidisciplinary ownership to the design system in the entire design and developer environment.