Designing for doubt

A purchase is completed or fails. A product is available or out of stock. A form is submitted successfully or displays an error. We are used to designing interfaces that provide clear answers, with well-defined states and messages that leave little room for interpretation.

And that makes sense. Clarity is one of the foundations of a good user experience. We need to know what is happening and what the outcome of our actions has been.

However, not all digital processes work according to that same logic. When a navigation app indicates that we will arrive at 18:30, is it giving us certainty or an estimate? And when an online shop announces that we will receive an order the next day?

The problem is not using clear states, but presenting as definitive something that is, in fact, a prediction.

Traditional models are still necessary, but we are increasingly working with systems whose outcomes depend on probabilities, changing data or incomplete information. And that requires us to broaden the way we design and communicate.

When systems start responding with probabilities

Not all uncertainty has the same source. A weather app may estimate the likelihood of rain, an e-commerce platform may calculate a delivery date, and an artificial intelligence assistant may generate an apparently convincing answer without having enough information to guarantee its accuracy.

In other cases, the issue is not the prediction but the data: incomplete information, outdated sources or results that depend on variables the system cannot control.

These are different situations, yet we often present them in the same way: through a specific answer, without explaining how reliable it is or what its limitations are.

The introduction of artificial intelligence makes this issue even more relevant. A well-written answer is not necessarily a correct answer, and the confidence with which it is presented can affect how much we trust it.

That is why, before deciding how to communicate uncertainty, we need to understand where it comes from. Warning that a forecast may change is not the same as acknowledging that we do not have enough information to answer.

Designing for that difference is also designing a better user experience.

How to design for doubt

Communicating uncertainty does not mean filling an interface with warnings, error messages or confidence percentages. The real challenge is to provide the information users need to understand how far they can trust a result.

Language is a good starting point. ‘Your order will arrive tomorrow’ does not convey the same thing as ‘Estimated delivery tomorrow’. A single word can change expectations without complicating the experience.

We can also use contextual explanations, visual indicators or alternatives when the system does not have enough information. For example, instead of showing only ‘We found no results’, an interface could suggest broadening the search criteria or exploring other options.

And what about confidence percentages? Showing that an AI is 87% confident in its answer may seem transparent, but does the user really know what that number means? Without context, such figures can create a false sense of precision.

The key is to communicate uncertainty in a proportionate and understandable way, without passing all the system’s technical complexity on to the user.

Because designing for doubt is not about making people distrust everything, but about helping them recognise when an answer needs more context.

Not all decisions require the same level of certainty

What happens if a music platform recommends a song we do not like? Probably nothing important. We can skip it and carry on listening. But what happens if a financial app recommends an investment based on incomplete information?

Uncertainty exists in both cases, but its consequences are very different.

That is why the way it is communicated should be proportionate to the risk of each decision. For a music recommendation, a detailed explanation might be unnecessary. By contrast, when we are talking about money, health or sensitive information, knowing the system’s limitations may be essential.

The ability to correct a decision also matters. Accepting a suggestion that can be undone immediately is not the same as making a decision with consequences that are difficult to reverse.

Context, therefore, should determine how much we explain, when we ask for confirmation and which alternatives we offer the user.

A good user experience does not eliminate every doubt; it helps people make decisions with the right level of information. And that means recognising that not all interactions need the same safeguards.

Trust is not about appearing infallible

Do we trust a system more when it always seems to have the answer, or when it acknowledges that it might be wrong?

In digital design, trust is often associated with confidence, precision and the absence of errors. However, an interface that conveys too much certainty can create expectations that the system itself is not prepared to meet.

This is where an important concept comes into play: well-calibrated trust. It is not about getting users to trust more, but about ensuring that they trust to the appropriate degree, understanding both the capabilities and limitations of the technology they use.

Think of an AI assistant that acknowledges it cannot verify certain information and suggests consulting an additional source. Far from necessarily representing a weakness, that response can help the user make a more informed decision.

Transparency, then, should not be understood as a threat to a product’s credibility, but as an opportunity to build more reliable relationships.

A good interface does not need to pretend it never makes mistakes. It needs to help users recognise when they can trust it and when it is worth checking before acting.

Designing for uncertainty: from concept to practice

How do we bring all of this into interface design? The first step is to identify which information may be uncertain and how it affects users’ decisions. Are we showing confirmed data, an estimate or a recommendation? What would be the consequences of interpreting it as a certainty?

From there, we can introduce small design decisions that make a difference: using precise language, explaining limitations when they are relevant, and offering alternatives when the system cannot provide a reliable answer.

But adding a message saying ‘estimated result’ is not enough. We must also check whether people interpret it correctly. Usability testing can help us discover whether users understand a prediction, confuse a probability with a guarantee or overlook an important warning.

And when uncertainty exists, it is worth offering a useful next step: verify the information, review the data, consult another source or ask for help.

The aim is not to design interfaces that explain absolutely everything, but experiences that allow people to move forward even when we do not have all the answers.

Because good UX does not only make straightforward decisions easier. It also supports users when the answers are less obvious.

Conclusion

Uncertainty is not a flaw we should hide. It is part of many of the digital systems we use every day and, especially, of those that incorporate artificial intelligence, predictions and automated decisions.

The real design challenge lies in finding the balance between clarity and transparency. We do not need interfaces that constantly remind us they might be wrong, but neither do we need ones that present every answer as an absolute truth.

Designing for doubt is, ultimately, about designing a more honest relationship between people and technology. A relationship in which recognising a system’s limits does not weaken trust, but helps to build it.

And perhaps the time has come to ask ourselves a question: are we designing interfaces that help people make better decisions, or simply interfaces that always seem to be right?