Best practices for building a design system

If you have a large enough organization with several channels to feature your brand—like websites and apps—you should consider using a design system to manage your graphic components and style guidelines.

But as you start planning 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.

Communicate early

For most people in your organization, 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 positively.

There are several advantages of a design system, as Oscar Insurance Corporation notes, including:

• Scalability: Whether it's plain, old growth or breaking up a company into smaller pieces, scaling up or down can be a headache for any organization. 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 organization, 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 organization before venturing forth on the process of building a design system.

Keep it simple

Overly complex systems will discourage a majority of people, maybe except for the most enthusiastic geeks. On the one hand, a component with a too strict definition of color, size, layouts, functionality, and interaction patterns may be limiting and demoralizing. 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 customization preemptively—and rather add it 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 cooking food without minding the ingredients, 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.

See also: How to build a fast and modern site with Next.js and headless CMS »

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 organization.

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 organization, 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 organization. Find people in other teams and departments, introduce them for the positive effects of a design system, and empower 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 organization 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 information technology has rendered obsolete the notion of something being permanently written in stone, the general feeling of stability and conservatism remains.

Believing that you cannot change a primary color 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 faster 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.

See also: 7 checkpoints to create success for your digital projects »

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 organization 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 organization to grow and contribute for the foreseeable future. You should have an established design process, which standardizes 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. Utilizing 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 endeavors.

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:

1. Put time and effort into working with the design system, and collaborate across functions and departments.
2. Find inspiration from others, but make a design system that suits you.
3. Start modestly, with a design system that is easy to build and can be used by many people in different settings.
4. Create a roadmap, telling you where you want to be in six months, and what you have to do to get there.
5. Ensure a multidisciplinary ownership to the design system in the entire design and developer environment.

First published 16 April 2019, updated 23 September 2022.