Read the U.S. Web Design System documentation and you will find something genuinely well-considered. The token system is sensible. The components are accessible. The guidance on typography and spacing reflects real research. If every federal website used it faithfully, the public-facing web would be dramatically more consistent.
The federal websites most people actually interact with are not running USWDS. They are running
something that started as USWDS, then went through a procurement, then through two contractors
over
four years, then through an agency-specific rebrand, and now has tokens named
--agency-blue-override and a button component that diverged from the spec in 2021
and nobody knows why.
This is not a criticism. It is a description of how large institutions work. But it matters if you are trying to understand government website design as a practice rather than as a document.
VA.gov is the clearest example of what it can look like
The VA Design System is worth studying because it went further than most. The team built public documentation, maintained a component library with real accessibility testing, published a Figma kit, and kept all of it aligned with USWDS rather than quietly forking it. They named components clearly, wrote migration guides, and published a roadmap.
None of that is technically difficult. All of it requires organizational commitment that most agencies do not sustain past the first contract cycle. VA succeeded partly because veterans depending on it for benefits and healthcare created a different accountability dynamic. When a form fails, real people cannot access services. That sharpens focus in ways that an internal tool audit does not.
The Veterans Affairs redesign also benefited from a sustained team rather than a rotating roster. Design systems drift when the people who built them leave and nobody is accountable for keeping the pattern library in sync with what is shipping. VA avoided the worst of this by treating the design system as infrastructure, not a deliverable.
Content workflow is usually the limiting factor, not components
COVID-19 put public health web publishing under stress in ways that exposed something structural. The bottleneck was not the component library. It was the process that stood between a subject matter expert and a published page.
Publishing updated guidance meant routing copy through review cycles that were designed for stability, not speed. Corrections that should have taken hours took days. Meanwhile the design system banner, the header component, and the breadcrumb worked exactly as specified. The components were fine. The approval chain was not built for an emergency.
This is not a federal-only problem. State agencies face the same thing. But because federal public health guidance gets national attention, the gap between what CMS publishing workflows can do and what a crisis demands becomes visible. Design systems address the wrong layer when the actual constraint is organizational.
Three things that actually make these sites hard to build
If you work on government websites, the following will be familiar. If you are thinking about getting into the space, these are worth understanding before you assume the work is mostly component selection.
Component divergence. Once a contractor customizes a USWDS component for an agency-specific need, that modification lives in the codebase indefinitely. The original team that made the decision is gone. The next team inherits the change without context and works around it rather than reverting it. Over several contract cycles, the gap between the agency's components and the upstream design system grows until a migration is impractical.
CMS gaps. Most federal and state web properties run Drupal. Drupal's block and paragraph model does not map cleanly to modern design system components. Getting a card grid component to render from a Drupal content type requires a template layer that frequently gets treated as a one-off solution rather than a maintained abstraction. The result is that the design system component exists in Figma and in the pattern library, but what is actually rendering in production was wired together in a theme template two agencies ago and touches none of the official component CSS.
Translation surface area. Federal websites serving diverse populations need to render content in dozens of languages. Right-to-left languages surface CSS assumptions that nobody noticed during English-only QA: flex direction issues, hardcoded left/right margin values, absolute positioning that assumes LTR reading flow. USWDS is better about this than most design systems, but third-party components dropped into a Drupal theme frequently are not. You find out when the Spanish or Arabic version launches.
State systems are a different problem
The federal picture is complicated. The state picture is fragmented.
California has the most mature state design system outside the major federal agencies. The CA Design System is built on web components, has public documentation, and is actively maintained by the Office of Digital Innovation. It diverges significantly from USWDS in token naming and component API, which means teams working across both federal and California contracts are maintaining parallel skills for similar problems.
Massachusetts and New York have published design systems with component libraries and varying levels of governance. Most other states have published web standards without published component code. Texas is a clear example: the Department of Information Resources maintains web standards that apply to all state agency digital properties, but there is no open-source component library that agencies can pull from. Each agency implements the standards independently, which produces predictable variance.
If you work across state and federal government properties, you are maintaining parallel implementations with no shared code and significant conceptual overlap. The Accordion component exists in USWDS, in the CA Design System, and in a bespoke Drupal paragraph type for a state that has no formal design system. All three are solving the same problem differently. None of them can be consolidated.
Governance is the product
Design systems in government succeed or fail on governance, not technology. The VA Design System works because the team treats it as a living system with owners and processes. California's works because the Office of Digital Innovation is funded and accountable for it.
The pattern I see most often in struggling implementations: the design system was delivered as a project, not adopted as infrastructure. There is a Figma file. There is a component library. There is no one responsible for keeping them aligned with what is actually shipping in production. Within eighteen months of the delivery contract ending, the gap has grown enough that engineers stop consulting the pattern library and start making local decisions.
This is fixable, but not with better components. It is fixed by embedding design system ownership into product teams, not treating it as a separate deliverable. The technical work is the easy part.
If you are starting to work in this space, the most useful thing you can develop is not USWDS expertise. It is a vocabulary for talking about governance, ownership, and migration paths with people who have never heard of a design token. The components are public and documented. The organizational dynamics are what actually determine the outcome.