Dango Design System 🍡

How might we maintain consistency and empower designers to design more effectively?

Supermove covers every aspect of a moving company's operations. Despite our teams’ consistent collaboration on various parts of the product, the absence of a cohesive design system has led to inconsistencies and longer development cycles.

Therefore, Dango was created. We had some more moving-related names, like Axle or Engine, but to be honest, I used the dango emoji 🍡 in our documentation while we brainstormed names and it just stuck. It makes sense, though—while dango technically is one Japanese rice dumping, it's usually served together on a skewer. Pieces make a whole, like a design system.

Team
Lead Designer (me!)
3Designers
2 Engineers

Year
Launched 2022, ongoing project

Skills
Design Systems
Research
UI Design

Tools
Figma
Notion

︎ My Role

Other than choosing the fateful dango emoji, I led the research, design, documentation, and maintenance of the component and style libraries. Additionally, for non-designers and a team with limited resources, it might not be clear what value a design system could bring. We knew that the tradeoff was to postpone some of our feature work in order to focus on the design system, so I took the lead in making sure every department understood the value through 1:1 chats and presentations at all-hands. Once we had the buy-in from the rest of our team, we kicked off the project.

Dango was initially launched exclusively for desktop use in August 2022. However, with the growth of our product (and Figma), we expanded its responsive functionalities so building Supermove for various devices is significantly more convenient.

︎ Understanding the Why

Before Dango, our team used a loose set of colors, typography, and basic components based off open React libraries. It lacked clear information architecture and design patterns. As the team and product grew, maintaining consistency became challenging since we spent a lot of time cross-referencing and rebuilding components for each new project.

We knew we needed to invest the time to build a more scalable, robust design system. In order to prevent introducing unnecessary components and patterns, we defined a few guiding principles:

Flexible

Create a toolbox so our designers have the tools to build what they need, not tell them what they need to build.

Scalable

Avoid repeat components and make maintenance painless for both designers and developers.

Intentional

Keep the essentials and only add a new pattern or component when there’s no better alternative for it.

Accessible

Bake in accessibility as a necessary ingredient, rather than leaving it as an afterthought.

︎ The Foundation

Color

My teammate found that only 32 of the 54 colors were being used, and 3 of them failed AA contrast. Instead of just eliminating the ones that weren’t in use, we specified how each color should be used and created sets of colors that both pass accessibility requirements and capture our use cases. To make sure that the colors were clear and were used properly, I wrote usage guidelines and captured them within each design token.

Typography

Our typography system was being used loosely since no one knew how to choose between Body 1 and Body 3, and like color, only 9 of 17 styles were being used, which meant a lot of pages in our product lacked visual hierarchy. I also found that there was inconsistent casing and tenses throughout the app—for example, some buttons were title case while some where sentence case. To create a more cohesive language in our product, I defined new styles with guidelines around casing, voice, and provided examples on how to use each style.

Building Blocks

I decided that it would be easier to sunset the few existing components and start from scratch. Taking the atomic approach, I built master components that would then be used to piece together the main components to create a more scalable process to update elements that are shared across components. Using input fields as an example, we have four base components to choose from (text, dropdown, pill, and date). The designer is then able to customize the input fields from the nested instances.

︎ Documentation & Impact

In addition to using Figma’s built-in component configuration, I documented our new patterns and components with examples, best practices, and created simple flow charts to help our teams decide what’s best for their projects. I also worked with the platform engineer on my team to create a bot that feeds library updates to a Slack channel so that everyone can see what changes have been made without digging through Figma or Notion.

Since our engineering team was involved throughout the process, the handoff was seamless. We treated this project the same as any other feature build, and went through QA testing before pushing it live.

Of course, the best part of working on this is being able to experience the fruits of our labor. Iterating, prototyping, and delivering with have these tools at hand is much faster, and we’re even able to do it while brainstorming with our teams. Our engineers also spend significantly less time building custom components and are able to ship features faster.

︎ Reflections and Learnings

Iteration, not perfection

In the earlier stages, I was obsessed with having it perfect right off the bat so we could spend less time updating it in the future. This meant I spent a decent amount of time mulling over the potential use cases of each component and pattern. I quickly learned from design critiques that we will continue to uncover scenarios, so it’s better to treat the design system as a living and breathing entity.

Build mobile-first

When this project launched, we were only focused on expanding our desktop web app. We’ve since added support for responsive and mobile components, but there were (and still are) a lot of pain points associated with translating some of our components to work well on mobile. If I had a chance to go back in time, I’d advocate for a mobile-first approach.

Moving forward

What we have now works well for us. We actually haven’t had to add a new component to our core library for a few months now, but as we continue to grow, our tools will continue to grow as well. Since launching Dango, Figma has introduced tools like boolean variants, instance swaps, variables, and dev mode—all powerful tools I would love to implement to 10x the way that designers work at Supermove. Time to get to work. ︎

︎ Thank you

I’m so fortunate to have worked with a phenomenal team throughout Dango’s growth.

Designers: Sara Prestley, Angela Kang, Annie Yu
Developers: Dan Nam, Joe Holston

valerie wong ︎

︎

︎

valerie wong