Defining the Problem Space
When I started working at Genome Medical, there was no design system in existence. This means there was no centralized language or system of building blocks to unite the UI and give both developers and designers a single source of truth—rather, there was a scattered collection of components and styles.
Pain Points:
- Inconsistent use of components and styling across Genome Medical products, which ultimately created a disjointed brand experience for end users
- Added time and friction for designers: since there was not an effective, flexible, and efficient set of components and styles, much unnecessary work was being done when recreating elements
- A fundamental understanding gap within the design team: extra time and friction when a member needed a new component or style a new page
- An understanding gap between design and engineering: there was no single source of truth that both teams could turn to in order to understand the components in use or better facilitate design handoff
Project Goals
Two great challenge of getting a design system off the ground is generating buy in and harnessing engineering capacity. I started off by aligning with the front-end engineering manager and a couple of front end engineers. After discussion, they agreed that allocating engineering capacity to this project would lead to the following goals:
High-Level Goals:
- Create more brand consistency for the end user
- Save time for both designers and engineers
- Reduce cross-team friction and misunderstanding by uniting on a shared language and values
We then aligned on a set of deliverables:
Granular Deliverables:
- Asset library in Figma containing all components in use
- Style library in Figma containing all styles in use
- Documentation of all components and styles managed through Figma Tokens plugin
- Storybook library containing all components in use
Once I aligned with engineering, I met with my product management colleagues and presented my proposal. We agreed that we would create and Epic and stories within one of our scrum teams and dedicate front end capacity each sprint to building out Assembly.
Outcomes
As I began work building the design system in Figma, I wanted to make sure my approach would be as efficient as possible.
Design Framework:
- Use atomic design principles
- Harness the power of Figma component & variant properties / autolayout / nested instances to create flexible, responsive components with as few frames as possible for ease of editing and use
- Harness the powers of the Tokens Studio plugin to create and manage a platform-agnostic token system that will serve as documentation and the source of truth for developers and designers
I began by doing an audit of our current styles and components in production. I found a lot of overlap and inconsistency.
I then created styles that we could apply throughout our design system. When starting to create the styles, I took a lot of inspiration from Nathan Curtis' work with tokens and how he uses them to underpin his entire design system. I started by creating the global styles.
Once the global styles were established, I began building individual components using semantic tokens.
As I completed each style set and token, my engineering counterpart built out each. We worked in a step-wise manner, meeting weekly to align on our progress.
Takeaways
Before beginning this project, I hadn't truly grasped the difference between a simple UI kit and a robust design system. As I move forward, I see a design system like the blueprint of a house - it's not just about the individual bricks, but how they fit together to create something greater than the sum of its parts. By documenting every decision made, a design system becomes the go-to resource for anyone looking to understand why something is the way it is.
But a design system isn't just about easy-to-use components. It's about standardizing design patterns across the board, from navigation to interactions to color schemes. By doing so, we don't have to worry so much about whether every form element is doing what it's supposed to, and instead we can focus on creating something greater than the sum of its parts.
Additionally, by working with engineers, I've learned that the most important factor in any design system is adoption. The more of our codebase that makes use of the design system's tokens and components, the easier it becomes to iterate and make changes. With a well-designed system in place, we can change one thing and see that change reflected everywhere, which is truly powerful.
