Skip to main content

You probably need a design system. Or do you?

Published September 30, 2022 | Written by Dieter Peirs

Share article on:

Design systems are a common topic if you work in product design. Look at Teamleader’s Ahoy, Salesforce’s Lightning or Google’s Material. These could definitely inspire you to have your own. Creating such a system is often sold as the fix to all of your product’s design, scaling and consistency issues. But is it really the best solution for your product?

Let’s dive into some definitions

Let's look at what a design system actually is as there are different definitions. You might have heard of pattern libraries and style guides being mentioned in the design system sales pitch.

There isn’t a standard definition of 'design system' within the web community, and people use the term in different ways – sometimes interchangeably with 'style guides' and 'pattern libraries'.

To clear things up, let’s start with the following definition of a design system:

'a complete set of standards intended to manage design at scale using reusable components and patterns.'

This contains the following parts:

  • Standards: consists of your branding or styleguide and a product design vision (often referred to as design principles). You can see this as the emotional part of your design system. The message and feeling you want to convey throughout your product.
  • Reusable components: a collection of building blocks for your interface such as buttons, links, pills, cards, alerts, …
  • Patterns: a guide of how you can use and combine components.
  • Manage design at scale: the key of the actual design systems work is how you communicate about the system. A way you enable and educate people to use the styleguide, components and patterns. Finally, you also need to maintain the system and have a flow of how to create, update and deprecate these styles, components and patterns.

Why you should have a design system

A design system starts with a product and not the other way around. This means that an established product is the minimal requirement to start. If you’re still working on the initial version of your product, skip to the next part.

In the following cases you should definitely consider building a system:

  • You have multiple teams working on different products or parts of a product: a design system will align and educate your teams. It establishes the visual identity, enables teams to build consistent interfaces quickly and can improve the overal quality, usability and accessibility of your product.
  • You want to promote your design culture inside and outside of your company: a public design system will educate junior-level designers and help with onboarding new employees. As an additional benefit you can use it as a hiring tool to attract new designers to your team.
  • You have the resources for a dedicated team and want to improve your overall design: a design system will grow and evolve with your product and good maintenance is the key to its success. A dedicated team can craft your product’s design and support the teams using the system.

Why you shouldn’t bother with a design system

If you are still developing your product, things are changing too often to keep up. A design system will cripple your flexibility and feel like a costly burden when you are still iterating on functionality.

You might be a bit further along, but are still working with a small team. You could invest in a design system but you simply cannot maintain it. A better option is to start small. Slowly introduce a workflow to document components and write some general design principles. Make it manageable and evaluate often.

A documented modal component in Storybook

When you should definitely maintain a component library

The current complexity of front-end development prevents even code-savvy designers to work directly on the product design. There’s also a good chance that your interface has been designed with a design tool like Figma. This creates a gap between the design and the implementation of that design.

A component (and pattern) library can be seen as the middle ground between design and development. It’s an environment that’s easier to learn for a designer and a good place for both profiles to meet each other and discuss. You share ownership so you can work together towards a better design and implementation.

No matter the size of your team and the phase of your product, a component library is something to look into. It’s a small effort to document components as you develop them. It will definitely speed up development along the line because you can centralise visual changes, accessibility improvements and bug fixes.

Eventually, it will give you a solid base to create a full design system.

Getting started

I want to end this piece by pointing you in the right direction. Here are some good tools to kickstart your pattern library:

Published September 30, 2022 | Written by Dieter Peirs

Share article on:

Articles by Dieter

  • Website in browser with accessibility pane and color contrast checker open

    Everyone benefits from accessible apps

    A typical product design process aims to ensure your product meets the needs of your users. But does it account for all users and situations? If inclusivity is important to you, incorporating accessibility into your design process is essential. In fact, adding accessibility offers additional benefits.

    By Dieter Peirs