Do you really need a design system?

— 7 minute read

Much like you probably don‘t need a microservices architecture you also don’t need a design system, because with great power comes great responsibility. They have been around for a long time but recently gained a massive amount of traction and I strongly believe that they can bring added value to your business when done right.

Attention please permalink

Great, now that I have your attention we can get started. I’ll start with a disclaimer: I’m not here to lecture you about design systems because I’m definitely not an authority on the subject, but I do know a couple of things about them.

A few years ago I have been involved in building a quite large application that contained two separate parts that had a lot of visual styles and logic in common. At that time we thought the right thing to do was to create a shared codebase. Little did we know that we would reach a point where this would become a bottleneck.

I’ll tell you why:

  • All development took place in the projects, not in the shared codebase
  • There was tight coupling between the shared codebase and the projects
  • It was not possible to run the shared codebase as a standalone application to view all components
  • There was no way to target different shared codebase versions for each project

Luckily, our team was fairly small and we could work as agile and lean as possible to get things going and we still managed to deliver the projects 3 months before deadline.

Rebranding permalink

We sure learned our lesson and decided to take another approach when the same company asked our team to take care of 3 new applications of many more to come.

They were in the midst of rebranding everything and explicitly asked us to take into account that the applications looked and behaved the same. At that time I was reading the book Atomic Design by Brad Frost and decided to take the approach of building our own design system.

The application stack mainly focussed on Angular, so we created a separate Angular project that contained the following:

  • Design tokens
  • Development guidelines
  • Coded UI components
  • Icon system
  • Internal and external resources linking to best practices
  • Brand guidelines

A design system can contain a lot of things and is not limited to the things above. Some things we didn’t include were:

  • Design Principles
  • UX guidelines
  • Writing guidelines
  • Voice and tone guidelines
  • Design resources (e.g. sketch UI kit)
  • Page templates
  • Common flows and UX patterns

“A design system is the product of your design work. You don’t have to bite everything off at once — what’s the quick win to get to the foundations of your product? Find the sweet spot.” — Brad Frost

Because we didn‘t include many "non-development" aspects we mostly referenced to the pattern library instead of the design system. A pattern library is also known as front-end style guide, UI library, or component library.

After our initial effort in setting up the basics of the design system we were very pleased to see how easy it was to create pages. Redesigning your website(s) or application(s) will never be the same again. It doesn’t matter whether you have 30,000 or 100 pages. In reality, those 30,000 pages may consist of three content types and two overarching layouts.

“We’re not designing pages, we’re designing systems of components.” — Stephen Hay

In short, a design system has the following ingredients:

  • Tangible User Interface (UI) Components
  • Guidelines for using those components

By mixing and matching components you can get to totally new layouts. This makes it possible to free up designers and developers for more worthwhile work.

By connecting your ongoing product design work with the evolution of your design system, each iteration over the components of your design system results in a sturdier, more flexible, resilient more powerful system.

Benefits permalink

Development benefits permalink

  • Launch work faster
  • Launch higher quality work: focus shifts to accessibility, localisation, ...
  • Provide a shared vocabulary
    • Helps bring together different disciplines: developers > utility bar, designers > admin bar, product team > grey bar across the top
  • Make testing easier
  • Provide a single reference
  • Future-friendly foundation:
    • Iterating over time
    • Quality improves over time
    • Visual changes don’t mean starting all over

User benefits permalink

  • Cognitive impact: same components instead of different throughout application
  • Ease of use of the interface. Generally more fluent

Note: make no mistake, the user benefits list may be smaller, but it doesn’t make it less important. The current user-centered world demands good experiences.

The hard parts permalink

Along the road I experienced some difficulties:

  • You will need to get adoption on different layers of the organisation. It’s not enough to have your developers on board. You will need designers, business, even c-level to get aboard. Only this will ensure widespread adoption throughout your organisation.
  • Make sure you have a decent process in place to coordinate and manage your design system. People of all layers of the organisation need to be aware of this. That way you’ll keep all parties happy and will prevent people abandoning the design system because they are frustrated.
  • Be clear what people can expect of the design system and more importantly, what not.

Getting started permalink

So, you’ve convinced yourself you do need a design system. How do you get started? There are a few things you can do to help you get started, but the most important part is to just start.

  • Define the digital DNA of your products
  • Define an interface inventory
  • Perform user research
  • Set your priorities
  • Choose your pilot project
  • Choose your tooling
  • Choose your technological approach

Building an interface inventory is a good starting point. By creating an interface inventory you’re taking stock and categorising the components making up your website, app, intranet, ... An interface inventory is a comprehensive collection of the bits and pieces that make up your interface.

Once you‘ve done the interface inventory exercise you‘re good to go. It‘s OK to start small and lend an eye to other design systems and let them inspire you. But there are also a lot of helpful tools out there to facilitate in building your design system.

For developers

  • Fractal: Powerful component libraries & styleguides that fit the way you work.
  • Pattern Lab: Pattern Lab is a frontend workshop environment that helps you build, view, test, and showcase your design system's UI components.
  • Storybook: Storybook is an open source tool for developing UI components in isolation for React, Vue, and Angular. It makes building stunning UIs organized and efficient.

For designers

  • Figma: collaborative interface design tool.
  • Sketch: digital design toolkit
  • Adobe XD: UI/UX design and collaboration tool

So, do I need one? permalink

I’m glad I was able to partake in the development of a design system. At the time I left the team, we were building 10+ applications based on the design system we made. My journey has not only showed me what the benefits are and what a design system can do for organisations that are struggling with managing a multitude of projects and need to optimise resources. But also what the pitfalls are when going on this journey.

I strongly believe you will benefit from a design system when you‘re producing content (applications, websites, ...) on a large scale and you have a culture that encourages cross-disciplinary communication and work. If the idea of a design system seems overwhelming it’s perfectly fine to start with a style guide or pattern library. The most important part is to just get started.