Design System In Flux: 3 Lessons from the Flow-UI Migration

Design Systems are increasingly popular with the web development circle over the past decade, even the US Government is in on the trend! Here at FloQast, we are in the process of migrating to a second iteration of our in-house design system, Flow-UI. A design system offers the organization many benefits, including:

• A standard design language shared across functional teams. 
• More cohesive user experience through additional quality control. 
• Scalability and fast change propagation through component centralization. 

And of course, they also come with reusable components which allow us developers to ship code fast and spend less time troubleshooting UX edge case — hooray for not worrying about what a disabled destructive button should look like on hover!

Yet things are not all sunshine and rainbows even with a Design Systems in place. Working with a new design system can cause some headaches for devs, especially when an old favorite dropdown disappears and a new color scheme appears out of nowhere. Here are a few lessons we learned wile migrating our MFE to the new Flow-UI Design system.

Focus on the Fundamentals

As the old Bruce Lee quote goes: “I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times”. Likewise, I fear not the developer who has tried a thousand Design Systems once, but I fear the developer who knows the difference between display:inline-flex and display: flow-root.

One key feature of our new design system is the removal of many utility layout components, as we started our migration we realized that often times the old components are merely syntactic sugar for a few lines of CSS, and we can even replace multiple layout / container components with a single custom component and a few lines of CSS. As a result, our post-migration codebase can be easier to read and configure.

The Joy of Product / Design Partnership

Collaboration is a key principle here at FloQast, and our new Design System implementation is an embodiment of this principle. Here’s a common pitfall: the product manager handoffs the product spec to a designer, then the designer handsoff UX specs to developers, only to find out that the component required isn’t quite ready in the Design System or the component doesn’t quite work the way it was originally envisioned. We managed to avoid the anit-pattern by engaging devs early and often throughout the design process. This way the development team can raise any issues early on and replace components in our designs before they reach the development stage.

In a few occasions, we also swapped components midway through the development, or even kept older components in place with full buy in from the design and product team. Staying pragmatic and collaborative allowed us to ship faster without sacrificing on end-user experience or release broken features.

Leverage the Full Design System

A Design System is more than just a set of reusable components — it’s also a new design language that comes with its own set of vocabulary. Just like signing up for Duolingo before a trip to Barcelona, it’s helpful for developers to learn the vocabulary of the new Design System before and during a migration.

In our case, the new words are CSS Custom Properties that represent new design decisions.By spending some time with the new design language, we can translate font-size: 20px; into font-size: var(--flo-base-font-size-8);. As developers, we do not need to know the new tokens inside out, but it helps greatly to be at least ‘conversational’ in the new design system during a migration.

While I cannot promise that the above lessons will solve all Design System related issues, I hope they can make your journey a little easier. Bon voyage!

Shimin Zhang

Shimin is a Senior Software Engineer at FloQast with a focus on the Flux Analysis product line. When not in front of his desk, Shimin can be found cooking, hiking, cycling, and trail running in the Pacific Northwest.