Trust is the make-or-break factor for government and civic technology, and it is built both through user experience and data security & architecture. That was the through line of our "Building for Impact in Gov & Civic Tech" panel at Sacramento Tech Week, and it shaped nearly every answer in the room.
We brought together people who build for the public sector from very different angles: Andrea Nguyen, product designer and cofounder of Koi Studios; Conner Johnston, a former campaign-software founder (WarChest) who's now building legislative advocacy software; and Jim Schuett, VP of Technology at Polco, a company that helps local governments understand their communities. You can watch the full panel recording here.
Below are the biggest lessons for anyone designing, building, or buying gov tech and civic tech products—especially products that use AI.
TLDR; Key takeaways for building gov tech products people trust
- Start with the problem and the user, not the technology.
- Scope AI to one repeatable, painful task and keep a person in the loop.
- Treat trust as a UX outcome: show what the system is doing, let people edit and undo, and handle mistakes gracefully.
- Don't mistake required usage for adoption. Measure whether the work got easier.
- Design for every tier: procurers, administrators, and end users.
- Keep talking to real users, and keep revisiting your assumptions as the technology changes.
Why building for the public sector is different
AI has created an unique opening here. Many agencies are dissatisfied with legacy technology that has been failing for decades, so they are eager to try something new. That eagerness raises the stakes for getting the experience right.
But the public sector changes the rules of product design and development. Here are five differences that show up on almost every project:
- The customer can't walk away. In the private sector, buyers choose between competing tools. In government there are usually three tiers: the people who procure the product, the people who implement or administer it, and the end users. The last two rarely made the buying decision, and everyone is spending tax dollars they didn't get to allocate.
- The legal structure is different. Contracts with public entities are harder to win and to enforce, and work product can be subject to public records requests, so you can't assume privacy.
- The margin for error is much smaller. "Move fast and break things" doesn't work when software serves everyone. Government is driven by service rather than headcount reduction or revenue, so stability, predictability, and reliability matter more than speed.
- Everything moves slower. Meetings, approvals, and user feedback all take longer, so you have to plan for patience.
- No two governments are alike. Some agencies still rely on fax machines while others are leading edge, yet teams like Jim's have to find ways to meet the needs across all 50 states and roughly 5,000 communities.
Where AI helps and hurts in gov tech and civic tech
The strongest AI use cases in the public sector share three traits:
- Purpose-built. They start with a real problem and build a solution around it, instead of building the solution first and retrofitting a problem.
- Narrowly scoped. They take over the repeatable, painful parts of a process rather than the whole process.
- Keep a human in the loop. Users can review, edit, and undo what the AI does on their behalf, which builds confidence over time.
On the other hand, AI deployed irresponsibly or irrelevantly can create new risks for users and product teams:
- Building AI for AI's sake. Building used to take enough time and money to force strategic thinking. Now that it's cheap and fast, teams skip it and throw spaghetti at the wall. Shipping and testing is a valid strategy, but doing it too often erodes trust and brand reputation.
- Underestimating and overestimating AI at the same time. There are some agencies that won't touch AI out of fear and others who expect it to save the world. Setting honest expectations early is part of the work.
- Feature creep. Adding features is now as easy as pressing a button. A product with many good features and a handful of bad ones is a bad product, because users fixate on what's broken. Conner's advice: kill your darlings if users aren't using them.
- Automating support too early. Early on, a fast, human response to a problem can be the strongest trust-builder you have.
"Just because you can build something, doesn't mean you should. Start with who your users are and what problem you're solving for them." - Andrea, Design Director @ Koi Studios
Why designing for trust is a UX problem, not just a security problem
Most gov tech conversations about trust focus on data security and backend architecture. Andrea made the case that user experience matters just as much, for two reasons.
- If people can't figure out your product or it doesn't solve a real problem, they'll find a workaround.
- With AI specifically, users are intolerant of mistakes: it isn't about the thousand times the product works, it's about the one time it doesn't, and how you handle that moment is a UX question.
At a high level, designing for trust and adoption comes down to a handful of principles:
- Visibility, transparency, and control. Show users what data is being used, how it's being used, and what is being done on their behalf, and let them edit it.
- Fit into existing workflows. Meet people in the behaviors they're already comfortable with instead of asking them to learn a new system.
- Start small. An AI that does one part of a benefits claims process really well, every time, will be adopted far more than one that automates the whole thing and mishandles nuance.
- Pay attention to the small steps. Jim pointed out that trust accumulates through small moments: pressing a button, seeing feedback, and watching the system respond as expected. Edge cases deserve the most attention.
The stakes are higher in government because people didn't choose the product. When the product doesn't work, they don't blame the vendor; they blame their government and wonder what their tax dollars paid for.
Want the practical version? We put the UX patterns, case studies, and psychology principles behind them into a guide: UX patterns for designing for trust and adoption in gov tech products.
Adoption in the public sector isn't the same as usage
When people have to use a system, high usage tells you very little. Jim put it plainly: in the public sector, usage is not a success measure, because users can't walk away. Going from five users to 5,000 is a win for a consumer app, but it doesn't mean a government tool is working.
The better question is whether you understand what each group needs. That includes the staff who administer the system and want to do right by their constituents—not only the end user.
Software's job is to make something that is difficult, expensive, or time-consuming faster, easier, or cheaper. If it doesn't do that, it isn't good software. - Jim, VP of Technology @ Polco
Habits that help teams know they're building the right thing
- Keep a trusted core group of users. Conner's team relied on about half a dozen people who knew their field and gave honest feedback, neither yes-sayers nor reflexive critics. Watch them use the product rather than relying on written feedback.
- Start from design thinking fundamentals. Andrea's team answers three questions honestly before building anything: who are the users, what problem are we solving, and what are the ideal outcomes we're trying to achieve?
- Keep revisiting discovery. Jim once helped design survey software with founders who were sure they had the answer, and six months later the right solution had changed. With AI shifting what's possible every few months, what you'd build today isn't what you'd have built a year ago. Adaptability is the skill.
Thanks to everyone who joined us at Sacramento Tech Week, and to our panelists for their candor. To put these ideas into practice, download our guide, UX patterns for designing for trust and adoption in gov tech products.
Need more help? Let's talk
.svg)
.svg)
