Civic tools and the trust problem
Why public-good digital tools need visible source attribution, honest uncertainty, and careful error states.
Public digital tools fail for a specific reason that almost nobody building them talks about. It’s not the data. It’s not the technology. It’s that the person using the tool doesn’t believe it.
They land on the page. They get a result. And before they act on it - before they leave the house at the right time, plan the route, check the appointment - they hesitate. The number looks right but they’re not sure. They open a second tab to verify. If they can’t verify, they close the first one entirely.
That hesitation is a design failure. And it’s fixable.
The two civic tools I’ve built that I’m most proud of - a rubbish and recycling calendar for NZ/AUS addresses, and a public toilet accessibility map - both had the same core engineering challenge. The data was messy, inconsistently updated, sourced from councils who were doing their best with systems not designed for public access. The data was good enough to be useful. It was not pristine.
The design job was to make imperfect data feel trustworthy. Not to overclaim its accuracy. Not to paper over the gaps. To communicate, clearly and honestly, what the data was, where it came from, when it was last updated, and what to do if it looked wrong.
That sounds like an information architecture problem. It is. It’s also a psychological one.
The research on trust in digital products is consistent: users form a trust judgment in seconds, and they form it primarily from visual signals before they’ve read a single word. A cluttered layout, an inconsistent colour palette, a misaligned element - these read as carelessness, and carelessness reads as unreliability. “If they didn’t bother to fix that, did they bother to check the data?”
This is why visual quality matters for civic tools in a way that’s hard to quantify but very easy to feel. It’s not about aesthetics for their own sake. It’s that every design decision is a trust signal. A clean timestamp (“Last updated: Tuesday 14 May, 8:03am”) communicates something different from a missing one. An explicit source attribution (“Collection data sourced from Auckland Council”) communicates something different from a bare result with no provenance.
The tool that doesn’t explain itself asks users to extend faith they haven’t been given a reason to extend. Most won’t.
There’s also a specific problem with public-good tools that doesn’t exist in commercial products: the cost of a wrong result is often higher than the cost of no result.
If a rubbish collection app gives you the wrong pickup day, you miss the collection. That’s annoying. It’s also the kind of mistake that makes people stop trusting the whole product - permanently. “I used it once and it was wrong” is the review that kills a civic tool. Word of mouth among neighbours, in community groups, in local Facebook pages - it travels fast and it stays.
This means the error states matter as much as the success states. What does the tool show when it can’t find an address? When the data hasn’t been updated in a while? When the result is ambiguous? These states need to be designed with the same care as the happy path, because a graceful failure builds trust in a way that matters just as much as a correct result.
Most prototypes I see have no error states at all. The assumption was that the data would always be there. It isn’t, and the tool falls apart silently when it isn’t.
The access problem is the other layer. Civic tools exist to serve everyone - including people on slow connections, people with screen readers, people on older devices, people who don’t navigate digital products with the fluency of someone who builds them. WCAG AA isn’t a compliance checkbox for a public tool. It’s the minimum commitment to the population the tool is supposed to serve.
This takes longer to build. It requires thought about every interactive element - what it looks like with keyboard navigation, what it sounds like with a screen reader, whether the touch targets are large enough for people who don’t have steady hands. It requires testing beyond the desktop Chrome window.
I build this way because I think it’s the correct way to build something that’s supposed to be useful to the public. Full stop.
The tools I’m most interested in building are the ones that solve a problem that council websites used to solve badly, or that no one solved at all, because the people who needed the tool weren’t the people in a position to commission it.
That’s a specific kind of work. It requires caring about the outcome more than the scope. It requires being honest when the data isn’t good enough, and knowing how to design around that honestly rather than hiding it.
If you’re building something like that, I’d like to see it.
← AI didn’t replace me - it made the case for me The prototype that tells you everything →