The 21st Century IDEA Act Playbook Part 5: Scaling design systems

The 21st Century IDEA Act mandates that any website of an executive agency adhere to the website standards of the Technology Transformation Services of the General Services Administration. Though the law isn’t explicit, the “website standards” likely refers to the U.S. Web Design System (USWDS), a library of components built especially for federal government websites.

This addresses one large problem in the ecosystem of federal websites — that rampant inconsistency can hurt users’ ability to access digital services. Our experience has taught us that this is a great place to start but doesn’t provide a full vision or strategy for the complex reality of most federal agencies. The details of how the Office of Management and Budget will interpret this mandate into regulation are still to be determined, and it’s important that those regulations provide a smart, flexible way for agencies to adopt the USWDS.

Using design systems and best-practices is fundamental to almost every project we work on at Ad Hoc. We’ve supported the USWDS or derivative design systems on projects across the Centers for Medicare & Medicaid Services and the Department of Veterans Affairs. At a high level, this is the bar of success that the IDEA Act puts forth — but it’s also a picture of the potential for difficulty when mandating standards in complex federal government agencies and programs.

We work on developer-facing APIs, tools to help Medicare beneficiaries select healthcare coverage options, and resources Veterans depend on — all of which consume design systems based on the USWDS. But the demographics and needs of each individual user of the programs are drastically different. The styles, content, and components that are usable for a developer are not always the same for a Medicare beneficiary. These programs need to grow and expand in ways that can not possibly be anticipated by any single system.

In an effort to find a better option, and to better understand the tension of adherence and scalability, Ad Hoc created a Design Systems Working Group that conducted research on the design systems we work with and the problems our teams and users were encountering. The findings of the working group and the general consensus at Ad Hoc is an exciting picture of where the federal government can grow in this space.

Keep the underlying standards and systems as small as possible

For a design system or set of standards to be effectively used across the federal government, it needs to be as small as possible to prevent tension during adoption. Defining global priorities such as 508 compliance, general code conventions, and a structure for growth ensure that all users will have consistent and usable access to digital services. It also ensures that the teams that maintain those services have the freedom to make more granular choices on behalf of those users.

The implementation and use of the USWDS can be different in each agency and even within each program under that agency. And of course it is — different teams are working with different technology stacks, team sizes, and end users. As the USWDS continues to update that underlying system, gaps can start to form. Fortunately, in the announcement of version two of the USWDS, they clearly state the desire to, “support designing with flexibility and coherence” and promote, “easier, incremental adoption.” We think this is absolutely a step in the right direction and continue to advocate for a flexible, scalable system.

Continuing to build on this idea of flexibility is essential for the regulatory side of this equation as well. Even if the USWDS continues to become more flexible, its adoption is already so widespread and varied that the definition of compliance can be difficult to determine. However, if the requirements for compliance relied on a small set of universal requirements (instead of the perfect, absolute adoption of a single system), all federal websites could move in that direction together, regardless of technological stack or design needs.

Encourage pathways for growth

It would be an impossible task to build a design system that contained all the components and resources every program in the federal government might need. Even if you could, that system would be incredibly slow and difficult to maintain.

So if the design system is built to be as small as possible, it can become much more like a library of packages where consumers are only taking the parts they need, but still conforming to global standards. And much like a library of packages, the underlying design system can (and should) be very opinionated about what growth should look like. How does a program develop, add, and document a new component? How can that component be consumed by other programs easily to promote efficiency?

In the diverse collection of federal agencies, this model empowers individual programs to build components and resources that directly meet the needs of their users without sacrificing the goal of this section of the IDEA Act.

Pave the way for effective oversight

One of the other problems with a design system that tries to do everything is that it increases the complexity of oversight. We’re advocating for an incredibly small set of thoughtful requirements that would allow compliance checking to be automated, even as programs scale.

It’s difficult to know with complete certainty how many federal agencies exist. Based on reporting by Forbes, the Administrative Conference of the United States lists 115 agencies and says in it’s Sourcebook of United States Executive Agencies that “[T]here is no authoritative list of government agencies.” If we look at the domain data from the General Services Administration and Pulse, we find somewhere around 1,200 federal websites from around 124 federal agencies that would all need to be checked for compliance.

Automated solutions can be imperfect, but can easily determine systemic issues. Automated accessibility tests, for example, give our teams instant insight into what portions of a site might need manual attention. So, given a specific definition for compliance in a varied ecosystem, an automated scraper could crawl sites and repositories to ensure they’re meeting a baseline of compliance. At the very least, it would allow more thoughtful intervention at a manual level. And with the sheer, somewhat unknowable amount of federal websites, determining compliance will be practically impossible if the standard for compliance can’t be clearly defined by a small and flexible standard.

So, what the future will bring?

The exact ramifications of the 21st Century IDEA Act and design system compliance are still up in the air, but Ad Hoc remains optimistic about the benefits it might bring. We will continue to try to be a leader with all the work we do to help define small, scaleable standards and best-practices for encouraging automated compliance checks. Most of all, we’ll continue to work on making federal websites and digital services as usable as possible for the people that depend on them.

Read part 1, part 2, part 3, and part 4 of the 21st Century IDEA Act Playbook.