Within 4 years LeadGen had 3 facelifts as it crawled toward a proper design system.
An Integration Driven Design System
How I Optimized the Clariture Health Design System to Scale
Clariture Health is an online marketing agency focused on helping healthcare facilities create and manage ad campaigns on Google and Facebook. After four years of building up design debt, it needed a complete refactor to a Figma based Design System. This would involve…
Converting a disjointed collection of Sketch files into an atomic design based UIKit, Token Library, and Icon Library
Applying that UIKit to existing layouts and prototypes
Documenting the new design system using modern tools
This is going to take a while but we're in a pandemic so… let's get it done!
Manually changing design tokens is inefficient. While a designer can quickly modify a Figma file, informing the development side of those changes takes time, is prone to error, and increases work for busy developers.
While front end development standards have solidified over the years, design development standards are still in flux. Yes, we have tools like atomic design theory to inform how we build components but ask any design team whether a button is an atom or an organism and you'll see what I mean.
My goal was to automate the transfer of information between the UIKit, the front end application, and the documentation. A designer should be able to make a change in Figma (spacing, color, etc), write those design tokens to React, and then push those changes into Storybook with as little manual work as possible. There are lots of ways to get this done but I’d like to explain how I’ve done it for the Clariture Health LeadGen demo.
The first version of the design system was created in Sketch before the shared library functionality. This resulted in a lot of duplicated symbols in scattered files. In order to get a more complete idea of the work ahead I combed through those files and consolidated symbols, patterns, and templates into an organized group.
Why do an audit?
Design System audits can be a great way to begin seeing an interface as a system of components rather than a series of discrete pages.
Some of the benefits of an audit:
Ensures all interface components are accounted for
Lay the groundwork for a design system or pattern library
Refactoring Symbols into Components
Version 1 of the LeadGen UIKit was 100% built around the designer. This could not carry on into the new version. In order to maximize efficiencies I needed to look at each feature and rebuild it from a React component perspective or "Design to Code". More about that later.
Automating Design Tokens
Settings like spacing, colors, type, etc are stored in a library named Tokens. This is fed to the primary UIKit that contains the components used to build layouts. By abstracting Tokens out I can script React to import the current spacing, colors, type, etc directly into the React app. This avoids having to communicate changes to engineering or engineering having to manually enter the changes. All of that means greater efficiency and fewer errors.
Tangent: I love Font Awesome and wanted to use it for this project but I just didn't see a need. Gotta balance wants with needs!
How do we streamline writing? On the engineering side we use static type definitions to automate docs for components. Storybook reads how the React component is built and creates a good portion of the implementation details for us. Can we do the same for design usage guidelines?
I've gained efficiencies importing all the design tokens, icons, and site graphics by accessing the Figma API. I put all of those elements on Figma pages and frames that scripts recognize and then pull into the React app. I can do the same for designer written guidelines. By bundling markup formatted text within the components I'll be can extract it, place it inside an MDX story, and Storybook will display it. There needs to be parity between the UIKit component name and the React component name so the text is put in the right place.
This is not done but I'm working on it.
The Real Work
Making things is hard but explaining things is harder. That's called documentation and so far we've built a great framework for collaborating, creating, and distributing documentation but we haven't filled it out yet. That's what the next milestone is about. I've separated the remaining tasks into three major epics.
Recommendations for why, when, and how to use the various components and patterns. These are inline with the technical implementation guidelines that engineers would need.
Broader principles for how we think about and apply color, language, layout, etc to achieve a consistent experience.
Look & Feel
No one wants to use an ugly set of docs. I'll apply the Usage Guidelines and Design Guidelines to a new aesthetic treatment that's within the overall LeadGen brand.
Apps Run On Code
The glue that holds this entire system together is the Design to Code approach. By crafting a design system around the idea that the final output is code and not UX artifacts I can optimize the product design lifecycle. If your organization prizes keeping teams segregated then it's unlikely that this approach will work for you.
I'm of the opinion that cross-functional teamwork is the key to streamlining a design system. When your design team, engineers, and cross-functional partners are all speaking the same language… when your component design architecture has parity with your front end component architecture… GREAT THINGS HAPPEN! 👏