The U.S. Data Federation

Building shared infrastructure for federated data and securing the longevity of a 10x effort by redesigning a government-wide data resource hub

Challenge
The U.S. Data Federation was a multi-phase initiative of the GSA 10x program — a fund for technology ideas from federal employees. The project set out to answer a deceptively simple question: could the federal government build shared, reusable infrastructure to make it easier for agencies to collect, validate, and exchange data across organizational boundaries?

Federal agencies routinely collect data from states, municipalities, and other agencies — for program oversight, policy analysis, and public reporting. But these efforts are almost always built in isolation, with each agency reinventing the same infrastructure: intake forms, validation rules, error correction workflows. The duplication is costly, inconsistent, and invisible to those doing it.

For the data providers — school districts, state agencies, local governments — the burden is real: submitting data, receiving errors weeks or months later, and correcting them under time pressure. The U.S. Data Federation set out to change this pattern.

Client
GSA Technology Transformation Services (TTS) / 10x Program

Partners
USDA Food and Nutrition Services, US Department of Transportation (USDOT), US Census Bureau, Office of Management and Budget (OMB), The Office of Government Information Services (OGIS)

Contribution

• Phase 3: Project lead and stakeholder manager. Coordinated across partner agencies, scoped work with engineers, and developed strategy for project continuation.

• Phase 4: Project lead, researcher, and designer. Led a cross-functional team (engineer, strategist, content designer) across multiple simultaneous workstreams: user research, information architecture, visual/interaction design, resource curation, and cross-agency positioning.

Impact

• ReVAL adopted by three federal agencies (USDA FNS, Census Bureau, Dept. of Transportation) for real-world data validation use cases

• Phase 4 fully funded based on the Phase 3 pitch and strategic positioning

• resources.data.gov launched as a Federal Data Strategy product with a multi-agency maintenance model ensuring post-10x sustainability

• Cross-agency ownership secured with co-maintenance from Data.gov, OGIS, and OMB — giving the product an institutional identity beyond any single team's funding

Phase 3: Making it real

Phase 3 had two parallel goals: deepen the prototype validation tool (ReVAL) with real agency partners, and broaden the effort by finding additional use cases, curating resources and best practices, and developing a sustainability plan for the project beyond 10x funding.

Branding the U.S. Data Federation

In order to achieve our goal of surfacing additional use cases, I invested in branding, marketing, and communications efforts in order to] tell the story of the U.S. Data Federation and make the problem it was trying to solve more approachable. Building on a logo that had been designed in a prior phase, I built out a typographic style and color palette, which I was able to apply to documents, presentations, and a static webpage about the project, lending legitimacy through visual coherence.

ReVAL: The Reusable Validation Library

ReVAL is an open source Django-based library that allows agencies to validate data submissions — via web interface or API — against a configurable set of rules in real time. Rather than every agency building and maintaining its own validation logic, ReVAL offers a shared, federally-maintainable service that can be integrated into state and local systems.

The FNS use case
USDA's Food and Nutrition Service used ReVAL to implement a Data Validation Service for FNS-742 form submissions — annual reporting from 20,000 school districts participating in the National School Lunch Program and School Breakfast Program. Errors that had previously taken months to surface and correct could now be caught at the point of submission.

The sustainability challenge

While the tool work proceeded, I was grappling with a structural problem: 10x projects are time-limited. If the Data Federation was going to have lasting impact, it needed an institutional identity beyond its funding cycle.

This required stakeholder alignment across agencies with different mandates, incentives, and relationships to data governance. I spent Phase 3 mapping the landscape — identifying who cared about federated data problems, who had the authority to sponsor the work, and where there was existing momentum to connect with.

The answer was the Federal Data Strategy — a new cross-agency initiative that OMB and other agencies were actively building. Integrating the Data Federation's work into that effort would give it both a natural home and a built-in audience. That insight became the foundation of the Phase 4 pitch.

What the research revealed

• Practitioners approached the resource library from multiple angles: by topic, by resource type, and by their current challenge or situation

• The IA needed to support all three modes simultaneously, not privilege one navigation path over others

• Terminology varied significantly across agencies — a shared vocabulary problem that would require a dedicated design solution

Information architecture and taxonomy

Based on the research, I developed a taxonomy organizing resources into five top-level categories: Data management and governance, Data tools, Skills development, Policy, and Case studies and examples. Each resource was tagged with source, keywords, and format — enabling browsing by category, keyword filtering, and contextual search.

Getting alignment on the taxonomy required working across agency stakeholders with different domain vocabularies and priorities. The structure needed to be broad enough to serve the whole government, but specific enough to be genuinely useful. I facilitated multiple rounds of feedback and revision to land on a framework that worked across agencies.

Visual and interaction design

Comparative landscape and interface audit
Before making design decisions, I conducted a comparative audit of analogous resource repositories and government design patterns — surveying how similar sites handled navigation, resource metadata display, filtering, and content hierarchy. The audit surfaced conventions worth adopting, patterns to avoid, and gaps that the design could fill. I also conducted a detailed heuristic review of the existing resources.data.gov to note opportunities for improvement and consistency.

The glossary tool
One of the more distinctive design decisions was the integration of a glossary tool — itself a reusable open source product built by 18F. Federal data practitioners across agencies often define the same terms differently; inconsistent vocabulary creates real friction in cross-agency work and reduces the utility of shared resources.

The glossary gave practitioners a shared reference point built directly into the site — a small but meaningful intervention for a community where definitional disagreements are a genuine obstacle to collaboration.

Design system and approach
The design system built on the U.S. Web Design System (USWDS) as a foundation, adapted for the specific content needs of the repository. Key design decisions included:

• Resource listing format that surfaced source, keywords, and format at a glance without requiring a click-through

• Resource detail page structure supporting both quick scanning and deeper reading, with consistent left-hand anchor navigation

• Distinct 'Examples' and 'Policy references' sections giving complex, multi-part resources a predictable shape

• Glossary integration providing in-context definitions to build shared vocabulary across agencies

What it taught me

This project deepened my conviction that the hardest design challenges in government aren't interaction design problems — they're organizational and political ones. A beautiful interface on top of a broken process or an unsustainable ownership model helps no one. The most durable design work in this space happens when you're willing to engage with the full complexity: the stakeholders, the incentives, the policy context, and the politics of who owns what.

It also required constant advocacy for design itself — for user research, for careful IA, for a coherent visual language — within a context where policy and technical concerns dominated. I had to earn that space by demonstrating that I understood the domain, and then showing what good design could add to it.

And it reinforced something I believe about federated systems specifically: the challenge of collecting and exchanging data across organizational boundaries is fundamentally a coordination problem, and coordination problems require trust. Design can build that trust — by making systems legible, reducing burden, and demonstrating to data providers that the system is working for them, not just extracting from them.

What I'd do differently

• More usability testing of the resource detail page with practitioners new to the Federal Data Strategy — the IA decisions were research-informed, but the proof is always in how real people navigate real content under real conditions

• Earlier governance documentation — who owns what, how content gets added and maintained, what the editorial process looks like. That infrastructure matters as much as the design for long-term product health

What I'm proud of

The thing I'm most proud of in Phase 4 is what it took to make it happen: leading a cross-functional team — engineer, strategist, content designer — making real progress across genuinely parallel workstreams, all at once. While the design work was underway, the team was simultaneously identifying and cataloguing resources, drafting new ones, and prototyping the editorial process by which the repository could be sustained and grown over time. Getting those workstreams to move together, without letting any one block another, required constant coordination and clear-eyed judgment about sequencing.

But the thing I'm proudest of strategically is the Federal Data Strategy move. The Federal Data Strategy wasn't something we invented — it was an OMB-led initiative that agencies were already required to engage with. By finding a way to weave the Data Federation's work into that mandate, and securing co-maintenance from partner agencies, we gave the work an institutional home that would outlast the 10x funding. That's what it means for a government digital product to survive.

See more case studies from 18F