Government isn’t a startup

So why would we design our digital public services like one?

There’s been a lot of talk recently about what’s going on with our digital public services. A certain new task force with its Silicon Valley vibes, resumes stacked full of fortune 100 brands and exactly zero experience designing for government services has reminded me of why we must treat public digital services differently. 

In August of 2025, the White House announced the creation of a new office called the National Design Studio and tasked it with rebuilding some of the most sensitive websites across the federal government.

Recently, the Guardian published an investigation that found that four of those sites had been quietly running commercial visitor-tracking software configured to slip past the privacy tools many people install specifically to avoid this kind of tracking. None of them had filed the public disclosures federal privacy law requires. Around the same time, other agency redesigns coming out of the same modernization push were drawing criticism from accessibility advocates for shipping AI-generated interfaces that failed basic usability standards.

These aren’t unrelated stories about a couple of wobbly rollouts, they’re symptoms of a bigger problem: treating digital public services like a product built to move fast and wow buyers. 

But designing for public services is fundamentally different from designing a commercial product, in ways that have nothing to do with taste or polish and everything to do with what the service owes the people who have no choice but to use it.

None of this is a new lesson. It's one the federal government had already learned the hard way over a decade ago, and apparently needs to relearn because the new administration decided it can skip the parts that don't move fast enough. 

Let’s start out with what a digital public service is: typically an online service that helps people do something they’re legally entitled, or required, to do. Think apply for benefits, pay taxes, register to vote, renew your passport or enroll in healthcare.

Designing a digital public service is fundamentally different than designing a commercial marketing website or product. Those products or services designed for the private sector often begin with a narrow target market, or subset of people they want to reach, but digital public services must serve the widest possible eligible audience from the start. 

Public sector design teams base decisions on trust-building, human interaction, and ensuring fair and stable access for all users while operating in tightly constrained systems.

There are policy and security considerations, legal mandates and laws that need to be followed, such as Section 508 compliance and plain language guidelines, and many agencies have monolithic legacy systems that need to either be integrated with or modernized (often both!). 

A lesson we already paid for

The clearest example of what happens when these best practices get ignored is HealthCare.gov. Its infamous 2013 launch with websites that wouldn't load, users who couldn't create accounts to access new health plans and seriously bad press, is civic tech lore at this point. What's less remembered is that a simpler version had already launched successfully in 2010; the 2013 relaunch was a much bigger lift, adding identity verification, eligibility determination, benefit calculations, and live integrations with federal and state systems, serving millions of people from day one^[1]. Fragmented ownership across contractors, thin integration testing, and no one with a clear view of the whole system meant that even the parts that worked well couldn't save it because if users couldn’t finish their task, nothing else mattered.

The Obama administration's response is the part worth remembering: they treated it as a process failure, not just an engineering one, and built cross-functional, multi-disciplinary teams including user researchers, policy experts, and engineers working together instead of a single monolithic contractor. That response became the foundation for public service teams like USDS, 18F, and shared infrastructure like the U.S. Web Design System and the Technology Modernization Fund along with a decade-plus of hard-won practice in how to build public services people can actually trust.

What we’ve learned after more than a decade

Not every recent example is a cautionary tale, however. In 2024, the IRS launched Direct File, a free government-run tool that let eligible taxpayers file directly with the IRS instead of going through commercial software. It started as a pilot in 12 states and expanded to 25 by 2025, and unlike most large-scale digital government launches, it didn't stumble: taxpayers in the pilot's first year claimed over $90 million in refunds with a 90% satisfaction rate, and by its second year, 86% of Direct File users said the experience increased their trust in government^[2]. 

Direct File didn't succeed by accident. It was free, it was simple, it asked users for information the IRS already had instead of demanding they re-enter it, and it was built by 18F and IRS technologists working together using that same cross-disciplinary model the healthcare.gov recovery made possible a decade earlier. 

Designing for trust

If you asked a private sector executive what their most important success measures were, you’d get answers like: engagement, growth/retention, revenue. 

Now ask that same question of any public sector agency director and you’ll hear responses like: our services are easy to use, people are getting the help they need, taxpayer dollars are being used efficiently, all of which point back to one thing: trust. 

Trust that the information is safe and reliable, trust that benefits determination is fair, trust that tax dollars are spent responsibly. 

People don't choose whether to file their taxes, renew a passport, apply for disaster relief, register to vote, or enroll in public benefits because they enjoy the experience. They use these services because they need to and because society has decided everyone who is eligible should be able to access them.

Trust isn’t a feeling, it’s an outcome. And it’s earned when users understand why you’re asking for their information, what you’re doing with it and with whom it’s being shared, how long their process will take (with real-time updates!), how they can appeal a decision and who they can contact if they have an issue. 

But, how do you design for that? Foundational work^[3] from past digital public service teams tells us it starts with something basic like: does this look and read like it was made by people who know what they’re doing? Clear navigation, copy written with plain language, a modern visual design are all signals to a user that the agency has its act together. 

From there, it’s about transparency; who owns this information, what happens to user data when it’s handed over, how to contact someone if they need help. Sites that bury contact or privacy policy information are actively making users do the trust-verification work that the agency should have done up front.

It also means the content needs to be FRESH, not just present. If a benefits page hasn’t been updated since the last policy change, there’s a good chance no one’s actually watching the store. 

Lastly, it means services need to be situated honestly within the rest of the government ecosystem, instead of isolated in stand-alone applications. Cross-and deep-linking into related services or next steps or cross-agency guidelines rather than pretending this service is an island. Trust, as it turns out, is earned through predictability, transparency, consistency and reliability.

To build for trust, aim for easy

Easy doesn’t mean simple, though. It means removing access barriers and unnecessary burden from users^[4]. 

Things like asking for information only once, explaining steps in plain language instead of technical or legal jargon and making vital things like forms and information accessible to everyone including those using assistive technology.

Each confusing error a user encounters, or frustrating user flow or inaccessible interaction takes a tiny bite out of a user’s trust, until it’s gone; death by a thousand cuts. 

Bolder typography, pretty buttons and big hero images won’t fix broken trust. Repairing or regaining that lost user trust is a long and tedious journey that’s well documented^[5] in thousands of hours of user research conducted over the last decade, made possible by building multi-disciplinary teams including policy experts, content and service designers, accessibility specialists, researchers, security engineers and product managers who can understand the full spectrum of user wants and needs. 

There’s no such thing as an edge case

Public digital services must serve and work for everyone. That means there’s no such thing as an edge case. While commercial marketing websites can pick and choose their ideal user personas and specifically model their offerings towards them, government agencies don’t have that luxury. 

Every service we build must work for someone using a screen reader, or someone with limited access to high-speed internet, an on-the-go parent filling out a form from their smart phone or someone recovering from a natural disaster. It needs to work for older users who prefer paper to online services, veterans navigating sensitive disorders, immigrants whose first language is not English. 

Each of these users demand the same care and respect and the same attention to detail. Designing for everyone isn’t a stretch goal, it’s the job.

In the private sector, accessibility is often treated as a ‘could do’ or something that’s done when you have time. But for federal agencies it is a ‘must do’; Section 508 of the Rehabilitation Act requires that all information and communications be fully accessible to people with disabilities, which has also been upheld by the DOJ with the ADA (Americans with Disabilities Act) and the newer 21st Century IDEA (Integrated Digital Experience Act), both of which establish critical accessibility requirements for modern digital services.

And when it comes to accessibility compliance, commercial products often just ‘tick the box’ without considering the spirit of the law – ensuring that everyone can use the service equally. An inaccessible button isn’t a bug or a lower priority, it’s a barrier to users exercising their rights, and staying in compliance is a public obligation.

Good design systems matter

In 2015, 18F and USDS founded the U.S. Web Design System to help government teams align, design, and keep their websites and services up to date. It exists precisely so teams don't have to reinvent trust and compliance from scratch on every project. It bakes in accessible color contrast, tested form patterns, and 508-compliant components, so hundreds of separate teams across agencies can still show up looking and functioning like part of the same trustworthy government, instead of each one redesigning from a blank canvas and re-learning the same lessons poorly.

That's also why many AI-generated interfaces built outside that system, by inexperienced civic technologists, are so risky. A model trained on commercial UI patterns has no idea it's supposed to prioritize a screen-reader user over a hover animation. Design systems encode institutional memory; a generic AI layout starts over from zero every time.

Innovating within constraints

Everything about a public service’s experience is shaped by policy before even a single pixel is placed. Policy is the foundation that shapes both what we deliver and how we deliver it, whether we happen to agree with a given policy or not. Our job is to ask, within the constraints we’ve been handed, how do we build the best possible product for the people who have no choice but to use it? 

Some policy dictates what gets built from the start. Federal policy establishes the service: this program exists, here’s who’s eligible, here’s how they can apply, and here are the rights and responsibilities that come with it. In a state-administered program, that means states can sometimes also make their own policy choices on top of that. The agencies administering the benefits often must decide the process they’ll follow to execute that policy. Together, those policy and process decisions define what the end-to-end experience is for the user, and what products we must build.

For example, the H.R.1 legislation significantly expanded SNAP work requirements and established Medicaid work requirements^[6,7]. More recipients have to document that they’re working enough hours, or that they qualify for an exemption, in order to keep their benefits. This new policy introduced a whole new set of ways a person can lose food or medical assistance over a missed deadline, as well as new requirements a product team has to build for. Where we can’t alter the policy or process to better suit user needs, the work becomes making compliance verification as clear, forgiving, and low-burden as possible for the users on both sides of the system.

Other policies dictate how the service gets delivered, and it usually applies across all government services. These are mostly the kind of guardrails we’ve collectively decided are worth having, that ensure protections for civil rights, privacy and safety, and government accountability.

For example, the Paperwork Reduction Act (PRA) makes agencies prove that the information they’re about to collect from the public is actually necessary and worth peoples’ time. Plain Language guidelines set the tone and structure of what we write, including sentence length, reading level, and how information is ordered. Agency privacy and record retention rules determine how long someone’s data can be stored and what needs to be disclosed before any information is collected. Civil rights laws determine what appeal rights people have, and protect them from discrimination in how the service treats them.

None of that is going to show up in a figma file or an AI design rendering. It shows up in how long a form takes to complete, whether a user has to call someone to fix a mistake, and whether they can trust that the answer they got is the one they're actually entitled to. The best civic tech teams bring in policy experts from the beginning as part of the product team, not as stakeholders reviewing mockups at the end of a project.

We may not always agree with every aspect of every policy we’re building within – in fact, we’re often the ones who most clearly recognize a policy’s operational flaws. Our job is to build the best possible product inside a constraint we don’t control. That’s what responsible innovation looks like. 

Where we go from here

The last several months have made the stakes crystal clear. One federal redesign effort produced AI-generated layouts that accessibility advocates said failed basic usability and compliance standards. Another quietly built visitor tracking into some of the government's most sensitive websites — passports, voter registration, prescription drug pricing — without the legal disclosures required to tell people it was happening. Different failures, same root cause: treating a public service like a product to optimize, instead of a promise to keep.

That distinction sounds abstract, until you follow it home: a parent who can’t tell if the childcare savings account is safe to use, a voter who has no idea if their registration data was tracked, a person with disabilities who’s locked out of an inaccessible vibe-coded benefits portal. 

Civic technologists have already been building a distinct discipline around digital public services; it’s not some new mystery to be solved. It’s decades of hard-won knowledge, researched, tested and largely available to anyone willing to use it. 

Just bring policy in from day one, design for the most vulnerable users instead of the easiest to please, bring transparency with you along every step of the way and treat your design system as infrastructure instead of a visual style guide. 

NDS isn’t failing because the tools didn’t exist or the process wasn’t ready. It’s failing because it doesn’t seek to earn its users trust. 

REFERENCES

[1] Mullen, Ed (2022). Twelve years of Healthcare.gov. https://www.navapbc.com/insights/twelve-years-of-healthcare-dot-gov

[2] Coforma (2025). Democratizing Tax Filing in the Digital Age. https://coforma.io/case-studies/irs-direct-file

[3] digital.gov. An introduction to trust. https://digital.gov/resources/an-introduction-to-trust

[4] Dean, Amanda (2022). To build trust, aim for easy. https://digital.gov/2022/12/13/to-build-trust-aim-for-easy

[5] Pew Research (2025). Public Trust in Government 1958-2025.  https://www.pewresearch.org/politics/2025/12/04/public-trust-in-government-1958-2025/

[6] Bleich, PhD, Sara N.; Plata-Nino, JD, Gina (2026). Changes to SNAP Under HR 1 and the Implications for Food Insecurity. https://jamanetwork.com/journals/jama-health-forum/fullarticle/2844675

[7] Aussenberg, Randy Alison; Baumrucker, Evelyne P.; Falk, Gene (2025). Work Requirements: Comparison of Medicaid and Supplemental Nutrition Assistance Program (SNAP) After P.L. 119-21. https://www.congress.gov/crs-product/R48755