Using an updated version of Brad Frost's Atomic Design theory, I build and scale design from brand colors all the way to complex page templates. As the design of a product matures, so does its design system.
Throughout the years as my process matured, I have evolved my design systems to stay current with technological capabilities. This is the story of three design systems.
Design Systems
-
Create a consistent design and visual language
-
Speed up process from wireframes to final interface
-
Facilitate developer handoff
-
Trickle changes throughout systems and avoid rework
Project Goal
Initial Setup: X months
Discovery: X month
Design: X month
Development: X months
Maintainance: Ongoing
TimeFrame
-
Atomic Design Principles
-
Component Inventory
-
Developer collaboration
-
Inheritance through symbols/variables and instances
Methodologies
The Origins
I started using component libraries in tools like Balsamiq to create reusable elements long before design systems became mainstream. After seeing Brad Frost present his proposal for Atomic Design at An Event Apart in 2013, I learned about using CSS precompilers to create design variables that could cascade changes throughout a project. Since Photoshop lacked these capabilities at the time, I had to work closely with developers to implement these systems.
An anonymized cover page for a consulting client's design system.
The first time I deployed this process at a large scale was with Microsoft's CRM Portals where I created a templated website builder for clients to whitelabel and customize their sites, while maintaining accessibility standards. This required using design tokens and inheritance rules for styling - when users changed brand colors, dependent shades would automatically update; adjusting a corner radius would affect buttons, cards, and other elements.
Around this time, design systems were gaining momentum. Not to be outdone by Salesforce's Lightning Design System, I decided to invest more time into learning and building pattern libraries for my work, and integrating them into my processes.
The Process
Initiation
My first step in creating a design system is to see what has already been established. I explore the product and chat with development to see if we are using an existing system as a base. For example, while at Curavi Health, we were using Google's Material Design, while CivicScience was building up from React Bootstrap components.
Understanding the platform helps me quickly identify what comes "out of the box" versus what's been customized. I reverse-engineer the visual language into its basic elements (colors, typography, corner radius) and build up to more complex components needed for the product until I have everything I need to recreate the product in my design library.
When there's no existing product, like with Vest at Home, I work with whatever assets are available - brand colors or logos - to create the foundation of the design system.
 Current Design System and BrandingAn inventory of commonly used elements from the design system using the current visual design. |  Proposal 1: Design System Visual DesignUsing the template from the current design, this is the first visual design refresh proposal, with updated elements. |  Proposal 2: Design System Visual DesignUsing the template from the current design, this is the second visual design refresh proposal, with updated elements. |
|---|---|---|
 Proposal 3: Design System Visual DesignUsing the template from the current design, this is the third visual design refresh proposal, with updated elements. |
Inventory and Gap Analysis
This process allows me to inventory the variations we had on similar elements, and cut down on redundancy or expand elements where needed. Once inventoried, I verified that the components were appropriate for their context of use - for example, Curavi had three different ways to enter the current time throughout the system, when we only needed one with a smart default. On the other hand, we only had one way to enter the date, but entering the current day and a patient's birthday required different calendar input controls. By seeing what we had and comparing against what was needed, I was able to reduce redundant controls, and expand on necessary variations.
The inventory also allows me to check for consistency across pages by how closely they each followed their respective templates from the design system. At Curavi, we had four different variations of a consult type, but we did not yet have rules for an abstracted "consult" template. With more consult types in the works, I created and refined what the base template should contain and how each variant would fit into the system. At CivicScience, once I inventoried the page types, it was clear that we could reuse the same template not just for questions, but also segments and other item types.
An example of a base "consult" template in the design system, and the resulting variations for each subtype.
Development Collaboration
An important part of the inventory and gap analysis is checking the software and verifying with the development team to ensure that what I capture is true to the system. This also allows me to be on the same page with the dev team to ensure refinements are feasible. If we quickly needed a new control, we could look at existing input libraries and tweak them. This also ensures that what I had designed within my tools was also reflected within the developer side of the library; what I create doesn't matter if it isn't reflected in the "truth" of the developer components. Having a code-side library also allows me to quickly play with any browser-based pages and tweak them using Inspect Mode.
Design Refinement
Having identified gaps and redundancies in the system, I prioritize work by how frequently an item occurs, weighted by how important it is to the primary flows.
At CivicScience, once the base rules and templates were set, handoff to engineering was sped up. I was able to hand over a new Information Architecture and the page templates, enabling development to implement the changes without needing the UX team to draw out each page individually. Since rules were well established, once I determined the hierarchy of information, it fit neatly within the page templates. Any pages that did not would be given special attention and either the template was updated to accommodate the edge cases, or a new template was created.
Old Question Example with left and right aligned navigation bars
Updated page template applied Questions, following the updated information hierarchy rules
New Controls
Once created, a design system is not a static thing. When I designed the new flow for CuraviGo, I already had a foundation to draw upon that greatly accelerated the speed from concept to final designs, so I could focus my time on solving issues instead of refining the visual design.
Likewise, when we needed drag-and-drop interactions for CivicScience Crosstabs, the speed from wireframes to final design was greatly accelerated by leveraging the existing design pattern library to quickly build the new controls. Even development handoff was faster, since they were already familiar with the controls and templates, having created them in their code library.
Legacy Examples
The following examples are for demonstrative purposes only. Please note that these are no longer maintained and are not for public use.
Current Design System and BrandingAn inventory of commonly used elements from the design system using the current visual design. | Design System Visual Design Proposal 1Using the template from the current design, this is the first visual design refresh proposal, with updated elements. | Design System Visual Design Proposal 2Using the template from the current design, this is the second visual design refresh proposal, with updated elements. |
|---|---|---|
Design System Visual Design Proposal 3Using the template from the current design, this is the third visual design refresh proposal, with updated elements. |