Design systems in government: When to start

Starting at the beginning

Before Formation went to production, VA.gov (at that time Vets.gov) had several different dynamic React applications and a host of static pages, divided roughly into topic areas. Each app and topic area was supported by a different team with some small amount of overlap.

We made a consistent effort to encourage cross-team communication, but it was difficult to ensure UI and code consistency across the entirety of the project. For example, at one point we had no fewer than four different modal window styles, each powered by different code. These weren’t four special one-off cases. They were simply the result of being built at different points in time by different teams working without a reference component.

Visual documentation wasn’t enough, either. The modal window was just one example of a UI element, and attendant code, that should have been modular but wasn’t. There were tons of bits and pieces littered throughout the code base that violated the idea of “don’t repeat yourself,” and the end result was a just-fragmented-enough-to-be-challenging UI and codebase.

In the face of these problems, we were able to get buy-in from stakeholders to take on a side-project prototype design system. The project, based on the U.S. Web Design System, went from a small-potatoes tinkering to live in production inside six months. Introducing Formation into the mix, even in its nascent stages, made it easier to standardize both the visual and interactive aspects of the user interface. It also provided a best-case-scenario reference for team members who weren’t engineers but were still expected to write reliable and consistent HTML and Markdown.

Introducing a design system to the workflow as early as possible — even as a minimum viable product — made it easier not only to gain adoption from teams, but also to show the system’s value to the product. The system’s existence was speeding up the work, even in its immature state. In turn, that meant additional resources, which supported the system’s growth.

Working with an existing, complex project

QPP’s dynamics took VA.gov’s challenges one step further. Whereas VA.gov’s UI was largely driven by a single organization, with internal teams working together, the UI for the QPP website was developed by multiple organizations. The result was a visually and experientially fragmented UI, with a code base to match.

For the QPP design system, we began by building on top of design.cms.gov, which is meant to govern all of the Center for Medicare & Medicaid Services’ products. It was a relatively mature system with a comprehensive style guide and a healthy set of fully-coded components for both designers and developers to use as a basis for their work. I was tasked with taking that foundation and growing it into a bespoke design system for QPP. As with the VA.gov system, it was helpful to build off an existing design system. But because the QPP project was further along in development, I faced a number of different challenges.

First, we needed to figure out which of the existing QPP designs were “the one.” QPP’s UI felt cohesive at first glance, but going deeper revealed inconsistencies. It was important to align all the designers, which was no small task considering they were spread among three companies. I eventually decided to narrow the scope to just Ad Hoc’s designers, in part because I had immediate access to the team. Our goal was for our design to be the master template for the entirety of QPP. Judiciously shrinking the pool of designers made it easier to start to standardize the UI. Still, there was a fair amount of back-and-forth on QPP’s sizeable UI: is it this padding for this use case, or that other one?

We also needed to support multiple tech stacks. VA.gov was built on a single, React-based stack, which made making Formation a dependency relatively straightforward. QPPDS, at last check, had React, Pug, and Angular all in active production. This made creating a production-ready design system particularly challenging.

The team needed to figure out how to support Angular, or they needed to make the decision that the entire QPP ecosystem should be redeveloped in React. If a given part of the experience wasn’t supported by the design system’s React components, it would reduce the system’s usefulness to some teams. These were weighty decisions, particularly when multiple contractors are involved, and we weren’t able to resolve them before I left the project.

Even with buy-in from stakeholders and the full support of the QPP project team, retroactively wrangling a design system onto a project in active production is slow going. The end result is that even after a full eight months of active work, the design system was still in the prototype phase. There’s a proof of concept that the system can support Ad Hoc’s corner of QPPUI as a dependency, but it’s not yet making anyone’s life more efficient.

No silver bullet

I don’t know that there’s a “perfect” time to start developing a design system. The two I worked on were begun well after the project it served went into production. That said, it’s clear that implementing a new system is easier when the product is visually consistent and runs on a single tech stack. There are fewer ducks to get in a row, although not necessarily fewer people whose buy-in you’ll need! This is a strong argument for developing design systems from the beginning of a project if at all possible. If that’s not possible, dedicate engineering resources and test environments to building the system. You’ll also need a mentality where it’s okay to experiment and stakeholders who are willing to give you that leeway to get your design system into production.

Read the rest of the Design Systems in Government series: Less can be more, Communication is critical, and Improving documentation for better collaboration.