Trust is not a feature. You cannot add it in a sprint.
That sounds obvious when you say it out loud, but a surprising amount of UX work treats trust as something to be designed in — a friendly tone, a reassuring progress bar, a confirmation email. These things matter at the margins. But they are not trust. They are polish applied over whatever the actual experience is.
What trust actually is
Trust, in the context of a government service or any high-stakes product, is the accumulation of kept promises. The system said it would do something. It did it. Repeatedly. At scale. Without exception for people who don't know how to complain.
That's it. Everything else is brand.
When I joined the USCIS project, the instinct from stakeholders was to fix the perception of the system. Better copy. Cleaner UI. A friendlier error message. And look — those things can reduce friction, which matters. But the deeper problem was that the system genuinely didn't do what it said it would do. Cases went missing. Status updates were wrong. Letters referenced decisions that hadn't been made.
No amount of friendly copy fixes that. In fact, friendly copy on top of a broken system is actively corrosive — it signals that the organization thinks the problem is your feelings about the failure, not the failure itself.
The trust debt problem
I've started thinking about this as trust debt, analogous to technical debt. Every time a system fails to keep a promise — a case status that doesn't update, a letter that contradicts the portal, a process that works differently than it was described — it accumulates trust debt. And like technical debt, it doesn't go away on its own. It compounds.
What makes trust debt especially difficult is that it's invisible to the people who own the system. The USCIS team could look at their portal and see a well-designed interface. They couldn't see the forty-seven moments in the case lifecycle where what the system said had no relationship to what was happening.
Part of my job was to make that debt visible. Journey mapping is useful here — not as a deliverable to present to stakeholders, but as a tool for locating the gaps between the promised experience and the actual one.
Designing for truth over comfort
The hardest design decisions on that project weren't about color or layout. They were about honesty.
Do we show a status that we can't actually guarantee is accurate? Do we surface an estimated processing time we know is often wrong? Do we tell people their case is "in progress" when "in progress" is a black box that could mean anything from three days to three years?
The comfortable answer is to be vague enough to not be wrong. The honest answer is to tell people what you actually know — even if what you know is that you don't know.
People can handle uncertainty. What they cannot handle is uncertainty presented as certainty, because then they can't plan around it. The design work was often just: stop lying. Stop using language that implies precision you don't have. Stop designing for how you wish the system worked.
What this means for craft
None of this is an argument against polish, or against friendly interfaces, or against reducing friction. All of those things matter.
It's an argument for sequencing. Before you work on how the system feels, make sure it does what it says. Before you optimize the onboarding flow, audit whether the thing people are being onboarded to actually works.
Trust comes from truth, delivered consistently, at the right time. Design can shape how that truth is communicated. It cannot substitute for it.