Change Healthcare / Design System

Change Healthcare is embarking on a new era as a company. They have transitioned from being an acquisition company to a platform company. As a platform company, one of its challenges was to develop a design system. A design system would become the company’s most valuable asset after it had designed and acquired more than 50 products.

Overview

The Director of Design, Platform, and Design Systems (my boss) had already begun building the Design System when I joined Change Healthcare. Many pieces were in place. I was brought on to continue its growth, coordinate priorities, strategy and provide training.

Atomic Design

The design system is built upon the methodology of Atomic Design. Our design system is categorized by Atoms, Molecules, Organisms, Patterns, and Paradigms, which were our templates. We also have Brand Core which consists of our tokens, icons, and shapes.

As our design system was relatively new, we were still developing our process. Our end goal was to become a hybrid design system with multiple designers and multiple contributors, but to start, our small team (my boss and I) were sole owners.

Process

To begin with, we added to the system based on past designs/user research and company objectives. We had a roadmap of multiple components that had yet to be added to the system.

 In order to add to our design system on a daily basis, I created the following steps:

Accessibility

The auditing and iteration of the design system for accessibility was one of my major projects within the design system. Since we had users of all ages and backgrounds, this was an area I knew couldn’t be skipped. I like to think of accessibility from the perspective of “Someday, we will all be disabled.” 

I carefully reviewed every component, pattern, and paradigm of the design system. These are just a few of the accessibility issues I addressed:

1. Clear headings and hierarchy
2. Color contrast for text is 4.5:1 at the least
3. Color contrast for adjacent colors of 3:1
4. Clear link styles
5. Keyboard navigation 

Documentation

When I joined Change Healthcare, the documentation was robust, but I noticed some gaps when bringing on new team members. Some of the new team members seemed overwhelmed. The documentation was long, wordy, and hard to scan. 

With my knowledge of UX, I knew that easily digestible and easily scannable content was best. As a result, I decided to change the format of our documentation. Rather than long, hard-to-read paragraphs, I divided our documentation into sections. I divided the documentation into the following categories:

1. Overview – A general description of the component
2. Usage – How the component is used within Change Healthcare’s products
3. Rules – Any hard and fast rules that can’t be changed regarding the component
4. Behavior – How the component behaves, whether it was interactive etc
5. Anatomy – All the aspects of the component, including whether the component included other components
6. Variant Options – All the variant toggles within the component and definitions of what they mean
7. Accessibility – How the component is used accessibly

Training & Governing

Training

Early on, I realized how important it was to be able to train others on our design system effectively. We used a variety of methods to teach.

1. Prototype as much as possible
2. Have 1:1 trainings with new designers going over the system as a whole, components, and a bit of tandem designing.
3. Weekly training series, going over 1-3 components each week.

Governing

It’s important to maintain a balance when governing a design system. While you don’t want teams to feel stifled design-wise, you also don’t want them to go rogue. As the lead designer for the design system, I participated in planning meetings for new products, giving them advice on how to use the system, and answering questions as needed. Being okay with saying “No” and explaining why was one of the most important things I learned while governing. There is a quote I once heard from Ashley Seto at Pinterest that says, “If someone complains, you are doing a good job.” That statement could not be more true with regards to running a design system. While it’s inevitable that people will complain about your design system, it’s essential to stick to it to create a consistent, cohesive experience for your users.

Roadmap

There are many goals I’d like to accomplish within the Design system, such as:

• Auditing our component library for responsive design.
• Overall “beefing up” documentation by adding areas such as Figma Training, collaboration guidelines/forms, release notes, roadmap, and overview pages. 
• Create Dark Mode theme.
• Give the design system a fun name.

My Key Learnings

• Being thorough and thinking of every single micro-interaction is key to creating a solid component.
• Learn to say and be okay with saying “No” often.
• Keep learning and iterating.
• Other designers are your user, so make sure all documentation you make is easy for your user to grasp.
• Try and create ways to make learning a design system fun, whether with collaboration or adding a bit of humor.