Page History

Image Removed

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.  

Image Removed

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

Read more about design systems…

• Creating Themeable Design Systems - Brad Frost
• Why you don't need a separate design system for internal services - Amy Hupe   
• How I made a themeable Design System - Oscar Gonzalez
• Design system theming: How and why it works- Adam Sadowski
• An approach to theming Design Systems - Daniel Del Core
• Structuring documentation in multi-brand design systems- Amy Hupe

Design Systems are for user interfaces - Brad Frost

Why these stages matter

HCD practitioners can better understand their own learning process and set appropriate expectations if they know the typical stages of the learning journey. 

NN/g concluded that:

• Most learning journeys feel frustrating at some point. Having insight into the HCD learning journey and the end goal can provide encouragement during “what’s the point” moments. If you’re learning HCD independently, awareness of the journey can help you feel less alone.
• Identifying one’s current phase can help predict future progress, staying focused on the goals of the current learning phase rather than jumping ahead. Jumping ahead runs the risk of creating experiences that may be confusing, and thus less motivated to continue to learn. 

Course facilitators (or managers or mentors), must empathize, create an effective HCD learning experience for others, and enable sustainable, long-term success. 

• Understanding that different people will be at different stages in the learning process is a key part in being an effective educator. It allows for the delivery of effective learning experiences without overwhelming the audience with too much complexity and also preemptively mitigate learners’ pain points at each phase. 

Educating and activating a group of people takes a lot of resources (time, money, and effort). The education process should be intentionally designed, in order to maximize resources and return on investment. Mapping participants’ phases and their progression through the learning journey allows an educator to benchmark progress, and indirectly, success of the training. 

Image Added

As practitioners progress through the stages, their mastery increases in a nonlinear fashion — experiencing fluctuations due to various factors, especially, lack of self-confidence. Note that mastery is a combination of competence and confidence; both are required to effectively use HCD. If a practitioner is good but still feels insecure, they won’t deviate from the strict steps of HCD and won’t teach others.  The goal is to create alignment between competence and confidence in order to master HCD.

The Structure

Rather than thinking of each phase as a discrete checklist, NN/g created a three-component framework for characterizing each learning stage: criteria, primary activities, and educator goals.

1. Criteria are observable qualities that can help the learner (or an external observer, such as a trainer) identify the learner’s current stage along the learning journey. It includes awareness of one’s own competence, level of exposure, and confidence.
2. Primary activities are the learner’s actions and use of HCD methodologies.
3. Educator goals and obstacles summarize learner’s pain points at any given stage and corresponding educator goals that can help learners overcome them. 

Phase 1: Newcomer 

This phase is the first in the learning journey. For the majority of HCD practitioners, this exposure occurs via a university or institution, a place of work, or an online resource. The amount of time spent at this first stage depends on how motivated the learner is. Interestingly, many practitioners immediately perceive HCD as useless and never leave this stage.

Criteria

Individuals in this stage have been introduced to HCD, but have limited experience with it. Practitioners in this phase fall into 2 buckets:

1. Individuals who are committed to learn HCD
2. Individuals who are not interested to learn more about HCD. They’ve been exposed to it, but that is where their learning journey halts. Newcomers may remain in this stage indefinitely until they encounter a deeper exposure to HCD that broadens their perspective, experience, or acceptance. 

Newcomers’ knowledge is minimal; they have a surface-level understanding of HCD, often rooted in the definition they received during their first exposure. They may be able to provide a definition, but are not familiar with the details of a framework or its value. They have topical associations with HCD — sticky-notes, phase models, and whiteboards. Newcomers are unaware of their HCD incompetence. In other words, they don’t yet know what they don’t know.

Primary Activities

Newcomers’ primary goal is to understand the basics — what HCD is and why it’s useful. Often, this stage’s activities are self-initiated: browsing articles, reading books, or signing up for a course. In other cases, HCD is learned by necessity or requirement at work or school through onboarding programs, collaborative workshops, required courses, or mandated trainings. Most newcomers have not yet actively practiced HCD activities. If they have practiced HCD at all, their participation is limited and surface-level. 

Educator’s Goals and Obstacles

The goal of an HCD educator at this stage is to communicate the purpose and potential value of HCD and to motivate the newcomer to pursue learning, then make time for it and move on to the next phases. Common obstacles are overcoming learners’ negative sentiments: annoyance with “yet another thing to learn,” unsuccessful previous attempts or experiences, capped bandwidth, and realization of their own limits (in this case, how little they know about HCD). 

Phase 2: Adopter

Individuals in phase 2 have adopted HCD and begun to practice it. They may have had some ups and downs in their limited experience with HCD. It is common for adopters to flip-flop between overconfidence and self-doubt and to feel both confused and successful at the same time. Successful adopters have discovered how relevant HCD is to their work or life and, thus, make a commitment to continue learning.

Criteria

Increased (passive or active) exposure and familiarity with HCD has made adopters aware of their knowledge limits. They understand the potential of HCD, but still have a lot to learn. Adopters have invested time, effort, and energy into HCD and have started applying it to their work with mixed success. The commitment to HCD at this phase can be self-initiated or dictated by an authority with an invested interest (leadership, organization, or supervisor). 

Primary Activities

Adopters practice HCD in a linear way — by the book. They rely heavily on checklists — for example an HCD Phases Model, as well as for the activities associated with each of its steps. Many adopters lean towards a prescribed, branded version of HCD, often provided by their institution, company, or a reputable external organization.  

It is common for HCD practitioners to encounter failure in this phase — especially if they are learning predominately on their own — because of their incomplete understanding of the HCD framework. Common types of failure include jumping to conclusions, using the wrong activity at the wrong time, and lack of buy-in or support from others. These failures push some practitioners to abandon HCD altogether. However, most learning in this phase occurs through failure. Practitioners who embrace failure tend to develop a better understanding of HCD in future phases.

Some adopters might learn primarily by actively participating in HCD training, coaching and activities together with experienced HCD practitioners. While this group of adopters may not have the opportunity to experience a sense of failure because of the support received from their peers, it is still likely they will question the value and legitimacy of HCD from time-to-time.   

Educator’s Goals and Obstacles

Adopters are on the bike, but still need training wheels and coaching. Adopters’ confidence drops as they realize the indirect ways in which HCD can be applied and how much they have to learn — for example, how straightforward they originally thought the process was versus how abstract (and potentially overwhelming) it really is. The goal of the educator at this stage is to help learners through hands-on practice and assistance until they can comfortably use HCD on their own. Many individuals can become confused in this phase when they cannot make a direct connection to the relevance of HCD. Thus, it is imperative that adopters find relevance and application to their everyday work.

Phase 3: Leader 

This is the proficiency stage of HCD. Leaders can articulate HCD succinctly to others, steadily growing their confidence, with varied experiences and continued exposure. Leaders take an active, independent role in their learning journey and begin to think adaptively about HCD; starting to explore new applications and may even have established a reputation as a subject matter expert. 

Criteria

Leaders practice HCD with general ease, confidence, and independence. Leaders become more and more aware of their new knowledge and comfort as they mature through this phase. They often teach others earlier in the learning journey. They are able to consistently and somewhat adaptively perform HCD activities without thinking too much about them. Leaders don’t try to apply HCD by the book, rather use it as needed depending on the goals. 

Primary Activities

HCD practitioners in this phase lead HCD activities with others or perform HCD without coaching, but still apply preparation and focus. While they were previously participants, they now facilitate, initiate, and even advocate for collaborative HCD activities. Activities that leaders are involved in gradually increase in complexity, ranging from involving users in learning opportunities to fostering stakeholders into the process and prototyping. 

Educator’s Goals and Obstacles

The goal of the educator in this phase is to continue to instill confidence and help sustain learner commitment. The goal should be to empower leaders to transition into the role of HCD educators and facilitators. As much as they’ve progressed, they still may not be aware of weaknesses or potential improvements (even though they often recognize a mistake after they made it). Promoting reflection in this phase is the key to helping leaders continue to grow (and progress to grandmasters). They must take an active role in adapting the HCD practice to fit their contextual goals and needs, be sustainable over time, and maximize potential benefits.  

Phase 4: Grandmaster

If you are familiar with the game of chess, the title of grandmaster is only given to the most exceptional players—those who have spent countless hours perfecting their skills and techniques.

HCD practitioners at this stage have not only become teachers of HCD, but create new ways of applying it, thinking about it, and adding to it. The practice of HCD is so embodied in their behavior that they seldom have to think about applying it. Grandmasters view HCD as a flexible, dynamic toolkit. They’ve long departed from the concept of a prescribed process and rather view it as scaffolding to solve both organizational (often internal) and end-user (external, product-related) problems. However, this phase doesn’t come without downsides. Grandmasters are more likely to doubt HCD than leaders, often when early-stage learners fall victim to mismanaged HCD marketing and thus misinterpret, misapply, or undercut the practice as a whole. 

Criteria

Grandmasters’ defining characteristic is the ability to critically reflect on their HCD practice. This enables them to judge what is useful and potentially depart from the traditional ways and activities of HCD. Grandmasters also know how to help others to this same stage of enlightenment. Grandmasters are aware of their competence. They have an in-depth, intuitive understanding and can blend HCD skills together to meet specific needs. 

Primary Activities

Traditional HCD activities are still used by grandmasters, but are altered, adapted, and applied in complex ways, depending on the goal, audience, and potential obstacles. Grandmasters don’t stick to prescribed or branded versions of HCD and more often pull tools and/or activities from other realms, like service design and business strategy. While basic HCD activities are still carried out in this phase, they differ from those in earlier stages because they are inputs or alignment strategies for more complex, involved activities (compared to previous stages where the basic activities are the end goal). 

Educator’s Goals and Obstacle

Grandmasters have very likely surpassed their original teachers. Their goal becomes not just activating and educating individual learners, but rather organizations as a whole. As practitioners themselves, grandmasters face an increasing likelihood of (re)questioning the value of HCD. Increased knowledge and mastery are a blessing and curse; this pessimistic view is often rooted in the realization of what HCD can and cannot solve (contrary to earlier naive ideas that HCD can be a cure-all). However, even grandmasters can get better, by self-reflection, by learning from their peers, and also by learning from their juniors: one of the skills of supreme mastery is the ability to discern which of the hundreds of ideas generated by eager newcomers is actually a stroke of genius.

Other Considerations 

• Trained designers experience the HCD learning journey too, just differently. Many designers view HCD as simply a way to articulate and communicate a creative approach to problem solving. Thus, many designers are likely to feel as if they bypassed this learning journey altogether because this is how they instinctively think. However, designers experience this learning journey too, albeit much earlier in their education or career, and likely not packaged or branded as HCD. This does not mean that all grandmasters are designers, but rather that many successful designers likely are. 
• Individual practitioners can be at multiple levels at the same time. Some skills may fall into one phase, while others into a lower different phase. For example, a practitioner’s mindset and reflection may fall into Grandmaster, while their hands-on experience and exposure to activities into Leader. The goal is to identify this imbalance and invest in experiences that bolster weaker dimensions of our practice. 

The HCD learning journey is a high-level, distilled representation of the most common learning phases observed in the NN/g research. Learning and teaching HCD is messy; not all experiences will fit squarely into this model. 

Regardless, it is imperative to frame and articulate learning HCD as an experiential journey. Doing so can help all practitioners become more effective learners and educators. Learners can gain insight and awareness into the greater journey and goals, while educators can thoughtfully and successfully execute the HCD learning experience they aim to create.  

Image Added

This article is based on a research study conducted by the Nielsen Norman Group. Originally published January 2021.