A portfolio screen told me I was up 13.2 percent. It looked precise. It was not.
One price was delayed. The cash balance had not settled. A foreign listing had moved but the EUR conversion was stale. The real answer was not 13.2 percent. It was somewhere around 12 to 15 percent. The app was not lying. It was estimating and presenting the estimate as a fact.
The interface performed certainty. That performance cost me a decision I should not have made yet.
Most software pretends to know things it does not know. The weather app says “rain at 3pm” when it means “60 percent chance of rain sometime this afternoon”. The analytics dashboard shows “1,247 visitors” when it means “approximately 1,200 to 1,300 based on our sampling method”. The AI assistant says “the answer is 42” when it means “I generated something that looks like an answer”.
The performance of certainty is seductive. Users expect answers, not ranges. A return that says “about 12 to 15 percent” feels broken. A forecast that says “maybe rain” feels useless. The software that sounds confident gets used. The software that sounds careful gets ignored.
I think we have this backward.
The theater of precision
Precision and accuracy are not the same thing. Precision is the number of decimal places. Accuracy is whether the number is right.
A portfolio tracker that shows “13.2%” is precise. It is also inaccurate if the real number is somewhere between 12 and 15 percent. The precision creates false confidence. The user makes decisions based on a number that looks right but is not.
A tracker that shows “about 12 to 15 percent” is less precise. It might also be more honest. The range tells the user what the system actually knows. The user can decide whether to act on a range or wait for better data.
The same problem exists in banking. A current-account balance that shows “3,247.12 EUR” looks exact. But that number might not include a card transaction that has been authorized but not settled. The real available balance is somewhere between 3,100 and 3,247 EUR. The app picked the optimistic number and displayed it to the cent.
The same problem exists in AI. A language model that says “Paris is the capital of France” sounds certain. A language model that says “the most likely answer is Paris, with high confidence” sounds careful. Both might be right. Only the second one tells you what the system actually knows about its own output.
The problem becomes dangerous when the underlying model is wrong. The AI that says “the answer is 42” with full confidence and the AI that says “I am not sure, but 42 seems plausible” are both wrong. But only the second one tells you not to trust it.
What honest design looks like
I have been experimenting with honest interfaces. I make a point of showing ranges instead of points when the system is estimating.
For a portfolio tracker, I show “approximately 12 to 15 percent return” instead of “13.2 percent”. The precise number implies knowledge the system does not have. The range tells the user what is actually known.
For a task estimation tool, I show “2 to 4 days” instead of “2.5 days”. The 2.5 is a fabrication. The range is the truth.
For an AI feature, I added a confidence label: high, medium, low. The label is generated by a simple heuristic. It is not perfect. But users report that they trust the system more, not less, because it tells them when to double-check.
The UX cost is real. Ranges feel less satisfying. Confidence labels add noise. But the alternative is a system that sounds certain and is wrong. I would rather have a system that sounds careful and is right.
The suspension of disbelief
There is a concept in theater called the suspension of disbelief. The audience knows the stage is not real. The actors know the audience knows. They both agree to pretend. The performance works because everyone understands the contract.
Software has the same contract. Users know the system is estimating. The system knows the users know. But the system pretends anyway. The return is exact. The forecast is certain. The AI is confident. The performance holds until the number is wrong. Then the contract breaks and the user loses trust.
An honest system says: “I am estimating. You know I am estimating. Let me tell you what I actually know.” That is a different contract. It is less theatrical but more durable.
I would love to test this with a small feature. Instead of showing “projected return: 13.2%”, I would show “projected return: about 12 to 15 percent, depending on settlement timing and FX rates”. Users would certainly click the breakdown more often and spend more time understanding the number. Ideally, no complains that the number is imprecise.
It even makes them ask follow-up questions. “What happens if the EUR/USD moves 2 percent?” That is a better conversation than “why is my return 1.8 percent different from what you said?”
When to be precise
Not everything should be a range.
Some numbers are known. The number of items in a cart is known. The date of a last login is known. A settled balance after all transactions clear is known. Show those precisely.
The question is: does the system actually know this number, or is it predicting? If it is predicting, show the range. If it is known, show the number.
The category error happens when software treats a prediction like a fact. A projected return is not a realized return. A forecasted delivery date is not a guaranteed delivery date. An AI-generated answer is not a verified answer.
I started a rule: if the number comes from a model, it gets a confidence label or a range. If the number comes from a database, it gets a decimal point. The user can see the difference.
The business case for honesty
Honest interfaces create fewer support tickets.
When a banking app shows “89 EUR” and the real available balance is “3,247.12 EUR” because of a pending transaction, the user files a ticket. The support team investigates. The answer is “the system was not showing pending transactions”. The user feels lied to.
When the system says “approximately $4,000 to $4,200” and the real balance is $4,012, the user nods. The range was right. No ticket. No investigation. No support cost.
When a system says “about 12 to 15 percent” and the realized return is 13.1 percent, the user nods. The range was right. No ticket. No investigation. No support cost.
The same logic applies to AI. A system that says “I am not sure about this” gets fact-checked by the user. A system that says “here is the answer” with full confidence gets trusted until it is wrong. The wrong case is more expensive than the uncertain case.
I am not saying every interface should be vague. I am saying interfaces should be honest about what they know. A prediction should look like a prediction. A measurement should look like a measurement.
The portfolio screen told me a guess. The banking app did the same. Neither was wrong to estimate. Both were wrong to estimate and pretend they were not.
The software that admits uncertainty is the software you trust when it matters. The software that performs certainty is the software you stop trusting the first time it costs you.