Company

VidMob, Inc.

Project includes

Product design, design system, strategy and planning

Role

Lead designer

Years involved

2020-2022


Anatomy was Aetna’s first design system and aimed to be flexible, functional, and help designers and developers work together to create cohesive products that look and act as expected.

With the CVS merger, CVS Health aimed to develop an Enterprise Design System (EDS). Pieces of Anatomy—both components and documentation—have been used as the foundation of EDS. EDS is now fully internal, so there is no public documentation.

 
 
Original Anatomy homepage
 

The beginning

Anatomy was born out of a need for consistency and cohesion in evolving products.

We wanted to set our design system up for success and started off with our foundational styles. Color and type were first, followed by icons and illustrations.

 
 

We streamlined our icons to have a cohesive set to use across platforms, paying attention to visual consistency.

 

Our illustrations went through a series of UI exploration before finally landing on something we felt was appropriate for our products.

 
 

Our final illustration style utilized the main brand color and brought some personality and friendliness into a traditionally sterile environment.

 

 

Now that we had our foundations, we were able to begin to look at how to start prioritizing components.

We sorted out all the known* components to see where they landed with effort and impact. Anything that fell into the high impact+low effort quadrant, we knew we would tackle first as these would be highly used but not take a ton of effort to get out the door.

*We knew some components would end up spawning other components, like navigation and dropdown menu, but we didn’t know what those would necessarily be.

 
 
 

How do we “do” a component?

With this being our first time tackling a design system, we weren’t necessarily sure of what work needed to be done to take a component from 0 to 100. We had products already in the marketplace, so we at least had a starting ground for many elements.

Running alongside our component efforts, we knew we needed to document everything we created, so we were also looking for what documentation sections we needed as well. .

 

We looked at many other design system documentation sites to gather info on what they included to know what we needed to cover in our components.

From other doc sites, we gathered we needed to account for:

  • Variations

  • States

  • Responsiveness

  • Size

  • Behavior

  • Accessibility (contrast guidelines)

  • Usage (when, where, how should it be used)

  • Content guidelines

 

We were off and running.

 

 

Button: The First Component.

Button is arguably the most foundational component on the web. What different products and companies need varies greatly, but having a button is consistent across the board. Button also usually has a few different variants and many different states, which makes it the perfect first component to tackle.

 
 

An external review of other design systems gave us a good indication of what to shoot for.

 

Internal research allowed us to see what the component state currently was and how designers and engineers viewed it.

 

Since we had a button in our product already, there wasn’t a ton of visual exploration needed, but we did take this opportunity to improve the contrast in our states as well as the component setup.

 
 

Then we had a button.

 

While we delivered the setup of the button, we also worked on the documentation site, which we lovingly referred to as the AnatSite.

 
 

Information that was important to our users was the focus of the content for the documentation site.

One of our must haves was making sure that what design had was what engineering had, so we made sure to build out documentation that was engineering-focused as well through Storybook.

 
 
 

Our products also supported native iOS and Android, so we needed to account for that support for a lot of our components. For most of our work, we utilized native HIG and Material components that we themed to our colors.

 
 

Using native mobile components allowed us to quickly theme our products without spending time developing custom elements.

 

 

Launching Button was a huge success and kicked off a solid process for creating other components. Utilizing our priority list, we continued the work to launch 20 web components while I was at Aetna.