3 tips to make your design system easier to setup and maintain

Build a lightweight design system

Jason Zhou
UX Planet
Published in
7 min readDec 12, 2017

If you are on a team with no design system yet, setting up your design system can be an exciting, yet colossal task to complete.

In early 2016, the SafetyCulture design team set up our own design system — we spent around one and a half months redesigning our products and putting together a style guide, with everything needed to make a design system.

Grant Zanni and Jason Zhou were reviewing SafetyCulture design systems on a ping pong table

However, things didn’t work out well in the beginning. We had many problems, but our two most significant ones were:

  1. It was a big system to maintain and update.
  2. We were continually battling between making our output consistent vs giving designers freedom to be creative and design new components.

Here are 3 pitfalls we experienced that will make a big difference in the outcome of the design system:

1. Only build components that you need

When setting up a design system, people tend to include every possible UI component — Radio button, switch, checkbox, card, toast, table, etc. I know it is exciting to set up a foundation for everything, But do you really need all of them?

We started our design system with every possible component we can think of, and it was ton of unnecessary work

We started our design system in the same way, including every possible component, and even invented some new components, this led to a complicated design system. It was not just complicated to build, but also complicated to use. The documentation was long and big, yet many of those components were rarely or never used in our designs.

The most significant problem of this approach is: Designing UI components without a real problem/user case to solve is like designing a poster without considering the content, it won’t achieve the best result to address your future problems.

In fact, those components will become a limitation in practical scenarios that make designers struggle to put together an interface with those pre-defined components because it doesn’t fit in to a solution.

Our solution

Don’t think ahead too much: Build only components that are necessary for your current needs, and remove components that you are not using out of your design system. If your app currently only has two main pages that need to be redesigned, then just design the components that are necessary to build these two pages and add them to your design system.

We removed many underused components out of the design system and left only necessary components, which makes our design system more lightweight and easier to be used

So the next time you have a new feature to design, try to validate whether existing components can achieve the purpose of your design/wireframes, if not, a new component can be introduced and added into the design system.

By doing this, you can be confident about all the components you put into the system and the problems each component is supposed to solve.

2. Replace heavy documentation with easy to use components

The design system is a productivity tool to help designers get to a good design solution faster, so making a design system to be easily accessible is essential.

When we started our design system, we spent a lot of time putting together a big, detailed, beautifully designed document — Like what other design systems do.

Referring to a document every time you do design is painful.

The documents look amazing and people were impressed — yet no one really used it or read it afterwards:

  1. PDF document style guide: We spent time composing a well designed, comprehensive PDF document, which has detailed descriptions of every single UI component. The problem is — PDF is lengthy and not easy to find what you need; Also it is difficult to update the file and no way to make sure everyone is looking at the latest version.
  2. Style guide website: Like many other design systems, we made a dedicated style guide website, where people can easily find what they need. However, the time cost to maintain was high — We didn’t build the website with a CMS, and after couple of months, almost 50% of the content was out-dated, and everyone stopped referring to the website as the content seemed unreliable. Note: other teams in the company have started referring to the style guide as it does provide value from a brand perspective however we designers needed a more integrated approach.
  3. Sketch, Photoshop UI kit: We made a UI kit for design tools. The problem was the same as the PDF document — It is too difficult for designers to tell whether their Sketch or Photoshop file is up to date.

All those failed experiences just told us one thing — Heavy documentation is boring and useless; What we needed was a lightweight system that can be easily accessed & updated during the design process by any designer, and the content had to be always up-to-date.

Our solution

Luckily, inspired by Bunin, we found a solution to achieve this with some Sketch plugins:

  1. We transferred all components into Sketch symbols;
  2. We used Lingo to create a shared team UI kit. With Lingo we can make sure the designers are always using an up-to-date component, no matter if it is a small colour change or if a new component needs to be added.
  3. With the Sketch plugin ‘Runner’, designers can quickly search and apply a predefined component to put together an interface.
We use Lingo + Runner to build an efficient way to use our design system

3. Have a shared understanding of ‘why those components are good’

One of the common problems you might have is: We designers sometimes have a tendency to reinvent the wheel, and thats when engineers start yelling — “Why the heck do you have two different drop-down selects? Aren’t they serving the same functionality, to pick up an item from a list?” Etc.

The reason behind this is not that designers want to be cool or different; They just don’t believe the component in the system is the best solution. Lack of a shared understanding of why/whether the components in the UI kit is the best practices is the primary cause.

Consider your design system as a collection of the best practices that your team has tried and explored for different problems/scenario, instead of just a UI kit that designers need to follow.

Our solution

If you did something similar to us like not defining the JTBD for each component at the beginning, you will find yourself in a similar situation as mentioned above, a good way to mitigate this situation can be having a component deep dive process:

  1. Pick up a component from your design system.
  2. Collect scenarios/cases where this component has been used.
  3. Define the Job to be done of each scenario (For example, for the dialogue in the image below, the Job to be done is: When a user clicks the delete button to remove another user out of his team, we want to communicate clearly to users that once the users is removed, the data will be removed permanently as well, so that users won’t lose their data and get angry).
  4. Research/discuss whether this is the best practice to do so in this Job to be done.
Component deep dive to find the best practice for each component.

Each week we have a dedicated 1-hour-session to gather all the designers together and pick up 1 component from the system to discuss what’s the best practice.

By doing this, each designer on the team reaches a shared understanding that for this type of situation, here is the best practice that we should use. Make sure every designer agrees with why those components in the system are the best practice, otherwise the design system is just a constraint rather than a productivity tool.

Conclusion

A lightweight design system means a system that has just enough components for your current needs, which is easier to setup, maintain and update, Our approach to achieving that is:

  1. List out components that are necessary to your app’s current needs, and remove underused components out of your design system.
  2. Discuss at the team level to gain a shared understanding of what is the best practice based on the JTBD of each component.
  3. Create a lightweight approach for your team to access & update the design system.
  4. Keep doing step 1,2,3 every time when you have a new design

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Published in UX Planet

UX Planet is a one-stop resource for everything related to user experience.

Written by Jason Zhou

Product designer @SafetyCultureHQ. I love building & scaling products.

Responses (6)

What are your thoughts?

Great to see all the learnings! This will be helpful on future journeys!
Keep up the good work!

--

Can you tell the Lingo+Runner alternative for windows and photoshop users?

--

I’ve been involved in same experience many years ago. The Sketch tip you suggest is a great solution now. Thank you to share

--