June 2026 • 6 min read
Tags: UX Design, Trust, Product
TL;DR: Bugs in an interface are not only a usability problem. Sometimes they are a breach of a small agreement between the system and the user. When a system sends me a verification code and then says the code is wrong, it does not only prevent me from logging in. It damages my trust in it. And in a world where more interfaces are becoming automated, personalized and AI-based, trust is no longer a finishing layer. It is a core part of the product.
This week I tried to log in to the Israeli Tax Authority website. I entered my details, received a verification code by email, entered the code, and got this message in response: “One of the details is incorrect.”
Beyond the fact that only one detail appeared on the screen at that moment, it was also the same detail they had sent me.
So I tried again. And again. And it kept happening. Then I remembered that this was not the first time this had happened to me there. And probably not the last.
You can compare it to a small agreement between two people. I tell you: come by to pick something up from me, I will leave you a key. You arrive, and there is no key. Or there is a key, but it does not fit the door. Or there is a key, but I tell you it is not the right key.
Beyond the frustration and momentary helplessness, something like this mainly breaks trust.
Because when the system says, “We sent you a code,” it is essentially promising something: this code is your way in. If you enter it correctly, we will let you in.
And when it does not keep that promise, and then tells you the detail is wrong, it is not only showing a bad error message. It is undermining the small agreement the entire action is built on.
In the 1990s, Byron Reeves and Clifford Nass coined the term The Media Equation: our tendency to treat computers, television and media as if they were real people and places.
Their argument was that people respond to computers and interfaces as if they are social actors. This does not mean we actually believe the computer is a person. It means that many of our responses to it use the same social mechanisms we activate with people.
And interaction involves trust.
If I tell you I will leave you a key and I do not, you will probably remember that next time. If it happens once, maybe you will think it was a mistake. If it happens again and again, you will build a different model around me: you cannot rely on her promises.
The same thing happens with digital systems.
Just as you would not necessarily believe me in the future if I commit to something, our trust in systems that promise one thing and deliver something else also erodes. And when someone, or something, does not keep its agreement with us again and again, we remember it.
There are also studies on trust in automation showing that when automated systems make mistakes, especially in tasks perceived as easy, trust and reliance on them are damaged. In a study on automation failures in tasks that are easy for humans, the researchers found that when a system misses precisely the things people perceive as easy, trust in it is especially harmed.
And that is exactly the point here.
A verification code is not a complex feature from the user’s perspective. It is a very basic contract: you sent me a code, I enter it, you let me in.
If even that does not work, why would I trust you with more complex actions?
Just like with people, nice words are not enough.
A pleasant-looking interface is not enough either.
You can write friendly microcopy, design a beautiful error message, add animation, polish the buttons and explain to the user what to do now. But if the system breaks its basic promise, none of that really solves the problem.
Because trust is not built only through tone. It is built by the system doing what it said it would do: consistently, on time, and without making the user feel that they are the problem.
The world is changing, and interfaces are changing with it. It is unclear how many forms we will still fill out ourselves, how many daily tasks will be performed through agents, and how many actions that currently require us to navigate an interface will move into conversation, automation or behind-the-scenes execution.
But until we live in a world where no human touches a computer and all the agents manage everything among themselves, the trust problem only becomes more important. As interfaces take on more responsibility - explaining, recommending, filling, sending, deciding or executing - the importance of accuracy, consistency and the ability to admit limitations grows.
In a regular interface, a breach of trust may be an incorrect error message or an action that does not happen as promised. In an AI-based interface, the problem can be more complex: the system can formulate a persuasive answer, with full confidence, even when it is wrong. From the user’s perspective, it does not matter whether behind the scenes it is a model hallucination, a data issue, a broken integration or imprecise wording. The experience is the same: the system said something that was not true.
And this changes the level of responsibility for anyone designing these interfaces. It is not enough to ask how to make the system answer. We need to ask how it behaves when it is uncertain, how it explains the source of the information, how it allows the user to check or correct it, and what happens when there is a gap between what the system promised and what it can actually do.
We often talk about trust as if it is something we can add at the end: more transparency, another explanation, a better error message, more reassuring microcopy. But trust is not built only by how we explain to the user what happened. It is built through the alignment between what the system says it does and what it actually does.
If the system sends a code, the code needs to work. If it says a detail is incorrect, it needs to be able to point to the relevant detail. If it cannot complete an action, it needs to give the user a real recovery path. And if it does not know, especially in the age of AI, it needs to be able to say that clearly instead of pretending it has an answer.
In the end, an interface does not need to be perfect for us to trust it. Mistakes happen, systems fail, and people know how to handle errors when they are explained well and there is a way out. But when the system breaks its small agreement with the user again and again, it not only creates local friction. It teaches the user to be careful with it next time.