Assembly Design System

Genome Medical
Product Designer

In collaboration with the engineering team, I am in the process of building Assembly, Genome Medical’s first design system. Assembly represents a unified, accessible system of styles and components relying on a platform-agnostic token system as a source of truth.

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

I gathered together our other UX designers along with front-end engineers and our front-end engineering manager. We discussed what was important to us going forward if we were to spend the time and effort building a design system. After a few brainstorming sessions, we came up with the following. 

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 

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 

We decided that I would spearhead the design side of the process while another front-end engineer would take charge of building out Storybook capabilities. The developer and I decided to communicate through weekly meetings to keep each other up to date on progress. 


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. 

Audit Sample

I then collaborated with other designers to create 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.

Sample Global Token Documentation: Color & Typography

Once the global styles were established, I began building individual components using semantic tokens.

Sample Form Field Token Documentation

Component Sample: Form Field


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.

Interested in talking?

Feel free to reach out.

get in touch