Figma & design thinking: Building a design system for an existing product

Tammy Taabassum
UX Collective
Published in
6 min readSep 7, 2020

--

WWhen I joined Potluck as a UX Design intern, we were using Sketch, Craft, and Invision for our design-to-development pipeline. I learned how to use this system to build my prototypes. Unfortunately, I found it challenging to collaborate with non-designers who didn’t have the system already set up. My manager, who was also the engineer and the CEO, all wanted to provide feedback.

So when I was offered the chance to come back and lead design at Potluck, I decided that Figma was probably the best bet. Having gone through both the design system on Sketch and what was coded on the site, it was clear the design system needed some spring cleaning. There were several components on the site that didn’t reflect the design system, and the engineer mentioned having some difficulty with trying to convert the designs to code. I decided to create a development-friendly design system using Figma. Since I am a UX designer, I wanted this endeavor to result in something useful…and delightful, so I followed the design thinking process as I built it.

Here is how I went about creating a Design System in Figma for a product that already exists by using the design thinking process.

Step One: Assess the situation (Discovery)

Any good UX project starts with understanding the problem, and that is what I did. To create a new design system, I had to figure out the state of the current one. Figma allows you to import sketch files (thanks, Figma!), and this allowed me to save hours of work. I went through this file and compared components to what existed in production, in case some of the components could be salvaged. I switched a lot between looking at the current Sketch’s design system manager, production, and what I had in Figma to see the current state of affairs.

Next, I assessed my own experience of coming on board and trying to design a new prototype, and I found it very difficult to find or locate the components I needed. The naming convention was hard to follow, and I didn’t know what components were available to me.

The state of components made things harder to find

Finally, I assessed the experience the engineer had with developing new components. He mentioned the color system being difficult to follow. He would have to look up the color variables a lot. Lots of new colors existed in the designs that weren’t present in production.

Step Two: Setting Goals (Define)

Once I had a good understanding of the problems, I set some goals for myself to make sure I’m always keeping the user problems in the back of my mind.

  1. Make sure the design system is clear. The naming convention should be simple.
  2. New designers should understand how to use the design system. If not, the system should be laid out in such a way that they should be able to find things for themselves.
  3. Engineers should be able to develop with ease. Components, colors, and states should be part of the coded design system.
  4. Focus on the essential components for V1 (Buttons, inputs, colors, type scale, etc.)
  5. Build V1 of the design system by only having the components, no states. Since the design system is already coded, and the component states exist, the engineer didn’t need those states at the moment. So, I decided to break down the process and do it in the next iteration. This leads us to the next goal.
  6. Be kind to yourself. It’s a long process. It’s important not to get overwhelmed with everything that needs to get done. By chunking the work (first basics, then states, then language, etc.), I can work on manageable problems with clear boundaries.

Step Three: Prototype

Once I had my goals and knew what I needed to do, I started creating the components. Here are the basics of what I did.

Get to know the tool

I found that Figma has some helpful features that make building and scaling components so much easier. This meant that I wouldn’t have to spend as much time resizing components and focus on actual people problems. Here are two examples of the features I used the most, and what I did with them:

1. Constraints

Constraints let you “stick” an element to a direction upon resizing. I found this to be really helpful for select components in particular.

Resizing the dropdown keeps the style the same.

2. Auto Layout

I used the auto layout for things I knew would require specific spacing and elements that had lists. Here is an example of it using a button and a menu.

Change button text without having to resize

Naming Convention

The next step was to build out the information architecture. To make the design system easy to navigate, its structure had to be easy to understand. I read this article by InVision, which provided some excellent insight into naming conventions and standard structure. I learned that when naming, it’s essential to label from broad to specific and separated by a forward slash. One major thing I had to worry about was dark and light mode and figure out where to place the variation in the naming.

Essentially, the structure I followed is this:

component / dark or light / type / variation

Colors

The final step for this version was to sync up the colors. This was a significant pain point for the engineer. The naming of the color did not match what was in the code, and there were many more colors used than what was in the code. For this, I pulled all the names from the code and spent time matching the colors and renaming them. This made sure that when the engineer coded the design, he could copy the variable name and not have to look up the matching. In fact, the engineer mentioned that since this change has been implemented, it has saved him a lot of time in building new components and flows.

With that, I came up with my very first version of the design system in Figma. I’m excited about V2, where I will tackle some bigger components (molecules and organisms). For now, I’m really happy with how this turned out. It has made my life a lot easier, and I find sharing new designs with stakeholders faster and easier.

In the future, I think I want to test this out with other designers to see if my goal of making it easy to onboard new people has been achieved. I’d also like to make the system more robust by adding more interactive components.

All in all, this was a great learning experience for me. I’m glad I got the chance to explore the inner workings of a simple design system, and I’m excited to take this to the next level over time.

The UX Collective donates US$1 for each article published in our platform. This story contributed to Bay Area Black Designers: a professional development community for Black people who are digital designers and researchers in the San Francisco Bay Area. By joining together in community, members share inspiration, connection, peer mentorship, professional development, resources, feedback, support, and resilience. Silence against systemic racism is not an option. Build the design community you believe in.

--

--