Copy of Maturing the CMS Design System

Maturing the CMS Design System

Scott Weber, Reading time: about 8 min

Before we get into the details on the CMS design system I want to set a baseline of what a design system is and is not.

What is a design system?

The general definition of a design system is that it’s the outer circle that contains pattern libraries, style guides, and any other artifacts used to build web experiences and it’s also much more than that. Just because you have a collection of design patterns doesn’t mean you have a design system.

A design system is a collection of reusable components both in design and in code, guided by clear documentation and standards, that can be assembled together to build web experiences and can be easily updated within products.

Nielsen Norman Group defines a design system as “a set of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels.”

Brad Frost defines a design system as “The official story of how an organization designs and builds digital interfaces.”

What a design system is not

A design system is a collection of multiple elements such as pattern libraries, style guides and UI toolkits and more. Only having one singular element does not mean you have a design system. If you have a Sketch or Figma file but don’t have any code examples or patterns you don’t have a design system. If you have code examples but no design artifacts you don’t have a design system.

A design system requires design, code and guidelines and not having each part of it makes a design system incomplete.

So now that we have an understanding of what a design system is and is not, let’s get into the state of the CMS Design System, how we got to where we are today, as well as what’s planned for the future.

Creation of the CMS Design System

The CMS Design System was created in March of 2017 and adopted in several Healthcare.gov products. Upon adopting the CMS Design System, these applications needed more specific Healthcare.gov style and component customizations, which were originally supported through site packages.

Site packages contained styles and components unique to a particular CMS site, and were built on top of the CMS Design System. This was the first introduction of a sub-brand or theme of the design system. After creating and using site packages for over a year, we discovered that there were many challenges with how the site packages were constructed.

Site packages had a large technical overhead and were difficult to use and maintain. They had complex dependencies that required four separate dependencies. This required product teams to use and track four different code libraries. They were also difficult to build, publish and test, due to no standard practices and each site package being a little bit different. The documentation sites for these site packages were also difficult to update due to a high technical proficiency required.

We made some improvements by consolidating dependencies from four down to one. We also created shared scripts and more standard practices to be used by both the CMS Design System and site packages. Documentation site source was organized code making it easier to find and modify the Design System and increase consistency between the CMS Design System and site packages for Healthcare and Medicare.

Because the “site package” terminology was unique to the CMS Design System and was confusing for users, we renamed site packages to Child Design Systems. This created a stronger mental model of the relationship between the CMS Design System and a Child Design System like Healthcare or Medicare. This also tied into larger goals at the time of increasing design system ownership and autonomy within Healthcare and Medicare.

When version 2 of the CMS Design system was released, Medicare, Healthcare, and the CMS Design System each had different components, styles, and guidance. The concept of child design systems supported this need to have differing components, guidance and styles as well as more autonomy at the Medicare and Healthcare level.

Current state of the CMS Design System

If we look at how our design system family is set up we can see how CMS is currently working and thinking about design systems.

CMS is designing and building products in 3 and soon to be 4 separate design systems and there is a lot of similarity between these systems that could be consolidated. This siloed approach is not the ideal state, and we’ve experienced many pain points because of it.

The current siloed setup results in duplication of components, guidance, and styles. This leads to updating the same UI component 3 times over for each design system as well as verifying guidance across many different sites both in GitHub and the InVision Design System Manager.

Having documentation and guidance in two separate places also splits our users into 2 separate camps: design and development. This is not a good approach to facilitate a consistent and unified approach of how to use the design system.

For example, I should be able to find documentation, code examples and design artifacts for an alert component in one place. To fully understand the alert component a user would need to go to 3 separate places (GitHub, InVision DSM and Sketch Cloud) to get all the information about the alert component. It shouldn’t be this hard to do the right thing.

Because it requires visiting multiple sites to get the full understanding of a design system component, we're seeing inconsistent digital experiences across CMS, in addition to solving the same problems across the organization. We should be solving problems once at a design system level, and then iterating and expanding on those solutions to fit more use cases across the CMS product landscape.

Our team is also experiencing extremely large overhead in maintaining multiple design systems. Currently we are supporting 3 separate codebases, 3 separate documentation sites for code, 2 documentation sites for design and 3 separate UI Toolkits. That's eleven different properties all providing similar, overlapping or specific content. This makes it difficult to manage as well as difficult for users to know where to go to get the information they need.

With this siloed approach we see the digital sprawl increasing exponentially, as well as growing apart. This leads to technical debt and an increase of duplicative work and maintenance.

Our current contribution model is complicated and confusing because we’ve got multiple processes and places for contribution. This leads to a lack of contribution from teams. For example product teams might ask “Where do I go to propose something new?”, ”Where do I ask questions?”, “Where do I go to find documentation?”. Unfortunately for each of these questions, the answer currently isn’t straightforward because we’ve got 3 design systems which all have a slightly different process.

We’ve used these pain points to help define what needs to change to help product teams use and interact with the CMS Design System effectively, and we’ve got a future vision that we are working towards throughout 2022 and beyond.

Our future vision, a unified CMS Design System

Our future vision is to unify the entire design system by doing away with the concept of child design systems altogether and creating one themable design system that can support branding, theming and custom guidance.

Who knows? we could even give this new unified system a new name like Lyndon Design System (a nod to President Lyndon B. Johnson who signed into law legislation that established the Medicare and Medicaid programs).

This vision comes from our hypothesis that:
Healthcare, Medicare, and CMS products are more similar than they are different.

A unified design system would offer documentation on guidance, accessibility, and usability in one place both from the highest CMS level perspective while also providing space for brand specific guidance for Medicare, Healthcare or CMS in the same location.

Another part of our future vision is to create the concept of themes that can be applied to components and patterns to support Healthcare and Medicare branding along with any future themes for something like CMS.gov. We would also be streamlining and modifying our contribution model to have one set of processes for the Design System no matter which product team you are supporting.

A theme for the CMS Design System would be made up of the following parts:

Color
Type
Spacing
Icons/Illustrations
Guidance

Color would contain specific brand colors, as well as any supporting color palette to accompany the theme. These colors would come from a system-level color palette which would be defined at the top design system level as design tokens.

Type sizing and fonts would come from system-level font settings that are defined at the theme level. Spacing would also be defined in the theme and would contain specific spacing values that map back to design tokens.

In addition, a theme would contain specific logos, illustrations and imagery that apply to that particular theme. For example, the Healthcare.gov logo would be part of a theme.

Guidance is the final piece that we envision as being part of a theme. This theme-level guidance would be specific guidance as it relates to the Medicare or Healthcare brand.

For example, with a button, the CMS Design System would define high level usage and guidance around best practices and accessibility and then in addition there would be specific guidance for how buttons are used within Healthcare products.

We see many benefits of a united CMS Design System and those are:

Less overhead to maintain a single design system
A systematized approach to color, type, spacing and other foundational elements
Energy focused towards a single design system that everyone benefits from
Over time the design system will strengthen with focus on a unified system
Contribution model is straightforward and the same for everyone

So now that we have a vision for the unified design system what steps are we taking to get there?

First, we’d like to pull components, styles, guidance and icons from both Healthcare and Medicare child design systems up into the CMS Design System to have one place to reference the CMS Design System and that would be design.cms.gov. This single site would incorporate a theme switcher to allow for switching between themes to see, for example, how an alert would be styled on Medicare vs. Healthcare.

We’d develop a set of processes that work for anyone wanting to interact with the CMS Design System no matter what product they are supporting including how to contribute, how to get help, where to give feedback, where to get information needed to build a product using the design system, and other ways to get information or interact with the design system.

We’re currently in the process of upgrading the design system to utilize design tokens to give us a more systematic approach to things like color, spacing, and typography, which will fit nicely into a more unified and themable design system. In addition, we’re also exploring options to improve the documentation experience. Our team is excited to continue maturing the CMS Design System over the rest of 2022 and beyond as we begin to really see the benefits it can bring!

We’d love to hear feedback if you are using the design system or plan to in the future and you can reach out to us in the CMS Slack channel #cms-design-system, view our Jira backlog, or drop us a line through our contact form.

You can find the CMS Design System documentation site at design.cms.gov

Page tree