A quick guide for setting up a design system: Figma edition
By: Gavin Chiemsombat
Tags: Product Management, Figma, UI, Design Systems, UX

A quick guide for setting up a design system: Figma edition

Let’s take a closer look at how we can (and should) implement our design systems to lighten the load of keeping all elements organised as well as better onboarding for other designers.

As mentioned previously in my other articles, having an ‘explain once, works everywhere’ method is the best approach when it comes to an agency working with rapid deliverables. Therefore, I’ll stick to using as little documentation as possible.

I’ll be using Figma as it is our team's current tool at OOZOU. However, it still works anywhere else with a bit of a tweak here and there. You can always leave me questions if you wonder how to do that on your stacks of design software.

Create a reasonable file structure for your projects

A design file is perhaps the most important aspect of your work. After all, it’s what you’ll be living in throughout your project.

We’re faced with ‘to separate or not to separate’ a library dilemma pretty much every once in a while during our time at OOZOU. Here’s the team approach on it:

A. If you’re having a so-called short-term project, go with a Single file.

Self-contained file structure

Don’t waste your time creating a library and link it to a single file you’ll be working on. You can always migrate it later into a dedicated ‘style guide’ library should your project grow larger in scope. Time is of the essence and you have to be practical in your approach.

Be mindful that the file will be harder to manage over time and could present some performance issues if the project went on for too long and involves many features in and out of the project.

B. If you’re sensing a big potential for growth. Build 1 or 2 libraries file.

It is recommended to try separating the file now and link them together. As there will be more variables at play, eg. Responsive Desktop, Mobile, PWA, and Native version of the same application.

Consider building the file structure where you have your UI foundation pieces (more on what this is later) on one file and (if need be) illustrations & exportable assets on the other.

Probably the most common structure we have

C. If it’s time to expand. Pump it into a full-on design system!

Having both Desktop and mobile web apps and Native iOS Android with a CMS system? It is time you take on the glory! We usually do these practices with our bigger projects divided by either a platform it needs to be in (mobile, CMS, web apps, etc.) or features we’re delivering to stakeholders (settings, onboarding):

Full-on enterprise-level work

Branding (consists of common elements such as branding, colour, font styles)

Assets & Illustrations (with its own set of colour and effects expanding upon the main branding guidelines)

UI elements & templates

Design files (divided by feature like Home_Web, Mobile, Apps, PWA, CMS, and so on, or platform-based with multiple features, Language-based if doing multi-region app design)

Design Library

Our main UI Library (or libraries) will contain some or more of the following categories:

1.Foundation - Classic ‘building block’ elements where it dictates the overall structure of our UI elements. Which includes:

Branding assets - Logo and its Tagline

- Logo and its Tagline Colour Palette - The basic and extended colour swatch created using the Corporate Identity (CI) guidelines

- The basic and extended colour swatch created using the Corporate Identity (CI) guidelines Font family - Contains font types and family used throughout the product. Because of how Figma handles font colour styles, we would also have a set specific font colour defined in here as well (using Text/ as a parent group)

2.Spacing options - The number of spacing options allowed throughout the system (for example, a system of spacing in a project could start with 4px, incremented by 4px, maxed out at 80px)

a spacing example

3.A style guide (Optional) — This page is a digested format of everything in the file wrapped up in a simple format for handoff. We encouraged all stakeholders to comment on anything appearing here in order to keep our (occasionally) messy working area separated from the presentation area

Sort your system out and walk developers through your system

4.Assets — Any exportable assets and illustrations we made will be on a separated file. This is because oftentimes we would need a little bit more extended range of colours and effects to create these assets and we wouldn’t want it to clog up the core UI elements.

Iconset could be put in assets file for reusability

5.Component Library — Common elements used throughout the design. This is where we keep our base components and their instance

In some cases where the project gets larger and expands towards some constraints, it is common to separate the foundation file in order to pair it with different design components to be used in each working file.

However, these methods still produced some problems to be addressed

Components (or Symbols)

These reusable parts play a vital role in building and maintaining an engaging and useful design system. Without proper preparation, you might find yourself and your team stumbles across many inconveniences throughout your project. To alleviate this, we suggest you prepare your team by establishing a pre-project meeting before setting out to create a components library.

Step 1: Define your components hierarchy system

There’s quite a large part of Medium articles that mention Atomic design by Brad Frost. I found the method easily understandable but harder in practice because our team finds separating anything apart between Atoms, Molecules, and Organisms very difficult in practice.

To fix that, establish a universal ‘components’ system by remembering everything by its own name. Omit the grouping entirely and keep it in your mind when you’re reaching a certain limit of ‘putting components together’ for example, a set of 2 buttons aligned horizontally next to each other will be more than a component and will be named with a prefix called ‘Template/’ or something along the line.

Components forming into a template

This will help others while they’re searching for any established rules that have already been made. Avoiding combining the same thing again. Remember to talk it through with your team members and establish a general rule set that will help them decide whether it is a template or not. Everything else besides that can just be a ‘normie’ component.

Step 2: Decide on the system’s component override levels

Sooner or later you’re going to be building nested components or templates that can be overridden with other siblings to fit the context of the current screen (or state).

In doing so, you will have to plan ahead for a little bit and set out to maintain our systems of components. To put it simply, the team will have to balance out the 2 main aspects of components overriding: Flexibility and Accessibility.