The Win Wins of an Effective Design System

3 minute read along with visual samples


Design Systems are critical to any application that strives for a consistently strong user experience. Effective systems solve "boring" problems in a repeatable way and therefore allow developers, designers and product people to solve more "non routine" issues.

In this article I'm going to share with you my experience of building a design system, show you some examples and teach you some of the lessons I've learned along the way.

Firstly, allow me to explain "routine" vs "non routine" aspects of a product's design system. A routine UI element might be something like a button which indicates a dangerous action ("you are about to delete 500 files") or a successful action ("press this and you're finished!").

Take a look at the image below...

example of routine and non routine UI

Buttons, such as the ones above commonly feature across our products and therefore are documented in our design system documentation as they are "routine" UI elements. A visual of how braces would appear after an Ortho operation? Less so and therefore "non routine".

Initial Attempt

A co-worker and I started working on our first attempt at a design system about 3 years ago. It was based on Brad Frost's Atomic Design System - if you're not familiar with this, follow this link to an article on atomic design.

It all made sense in theory but our initial approach had some shortcomings:

1. We didn't dedicate enough continuous time to it

Establishing a robust design system can take time, involves multiple stakeholders and requires continuous maintenance and effort. Initially we didn't put aside enough time to accommodate all of this.

2. The terminology alienated other stakeholders

The "Atomic Design" approach as the name suggests, uses analogous language from chemistry to describe the breakdown of page elements (eg. an "atom" is a an example of a "button"). Reusing this terminology made it a difficult sell to internal stakeholders who have enough new learning on their respective plates.

However, I know we simply couldn't abandon it because it didn't work the first time around. It required a deeper investigation in order to get full buy in and be effective.

New Approach, New Design System

a book on design systems

A brilliant book by Alla Kholmatova on behalf of Smashing Magazine.

I needed to go back to the drawing board after the first attempt. Our application was beginning to grow, new members joined the team and others left - a consistent path towards UI rollout was critical before it became a real headache.

Here's what I did to ensure the next iteration was more successful.

1. Educate, explain and obtain buy in

I arranged a meeting with all relevant stakeholders where I showed videos of how other companies were conducting design systems along with some explainer slides. Team members clearly saw the multiple benefits of establishing one but were also versed on time commitments and how it wasn't going to be something that could get done overnight - that it would involve continuous maintenance but ultimately make our lives easier and produce front end designs at a faster pace.

2. Define its purpose and principles

It's tempting to jump in at this point and start building out various pattern libraries and explainer info. as to when certain UI elements or templates should be used. However, a soundboard is needed to ensure the ultimate goals of the product are not forgotten about.

I therefore consulted internal stakeholders to determine the purpose and principles of our design system. After all, its a shared resource - not just for designer/s and developers. Business goals need to be considered.

Below are the purposes and principles of our new flagship application.

list of design principles

This is a really important step ideally taken before you start building one - What is the point of a design system? What principles should it have? Doing this ensures design patterns adhere to the purpose and principles set out - not what's popular to do at any given moment in time.

3. Start small and continuously build it out

A design system is a "living thing" and can take time for it to evolve. My best advice on this would be to start documenting some typical UI patterns such as buttons and lists and build from there.


  • A shared language and understanding: Common and clear terminology created better communication between developers, testers, BAs and the product manager.
  • Quicker rollout of routine UI: Components were reused in other areas of the application for parts that needed to achieve the same thing.
  • Consistent user experience: Design systems enable a consistency of user tasks throughout an app. This means less learning and surprises for the end user.

Developer Collaboration

Collaboration is everything when it comes to a design system. One of our front end developers came up with a great idea of creating sections within our web documentation that enabled front enders to visually see the effects of adding particular classes to elements. This has proven to be a useful tool for a variety of reasons but in particular when onboarding new front end or junior devs to the team.

One of the developers added this section to our design system. It enables front end developers, especially newcomers, to get a feel for how our design system elements work and the naming conventions we use. They're able to visually see the effects of adding a few simple class names to elements.

Lessons learned

  • Collaboration is everything: Good design systems require a lot of communication. Therefore collaboration with other internal stakeholders is essential.
  • Creating a shared language is key: Simple, generic terminology for particular elements has made it easier for non technical members of the team to communicate front end needs.
  • Design systems can be applied to anything: Print design, AR/VR, a person's home.... a design system can be applied to almost anything!