Model-driven products face a question deterministic software never asks.
What does the interface do when the system is probably right rather than definitely right?
Overstate the confidence and you break trust permanently the first time it is wrong — and it will be wrong. Understate it and the product feels like it is hedging, which reads as useless.
This is not a copy problem. It changes what screens exist.
Design the failure case first
A product built on a model is judged on its worst visible output, not its average one. That makes the low-confidence state the most important screen in the app.
I worked backwards from the moments where trust breaks.
With the founders and the ML engineer, I mapped where the model's output could be wrong, how wrong, and what the user would be doing at that moment.
That map, rather than a feature list, became the basis for the interface.
Wrong once, distrusted always
A confident-looking suggestion that turns out to be wrong does lasting damage, because it teaches the user that the confidence signal means nothing.
Users want the reasoning
People accepted imperfect suggestions readily when they could see what the suggestion was based on, and rejected identical suggestions offered without explanation.
Low motivation is the normal case
A focus product is opened precisely on the days when the user has the least energy for it. A loop that only works when someone is enthusiastic does not work.
An AI feature is only as good as its worst output looks.
That principle decided the build order. The empty state, the low-confidence state and the plainly-wrong state were designed before the happy path.
When the model has nothing useful, the app says so in plain language rather than generating something to fill the space. Saying nothing is a designed outcome, not a gap.
A trust layer underneath a deliberately small daily loop.
The product does a few things and is honest about all of them. Everything the model produces is legible, attributable and correctable.
Suggestions that show their working
Every recommendation carries its basis and its confidence.
Rather than a single confident answer, the interface presents what it noticed and what it concluded, in that order.
This costs a small amount of space and buys the thing the product cannot function without.
Failure as a designed screen
When the model has nothing, the app says so.
Low-confidence and no-result states were designed as first-class screens with their own copy, layout and next action — not as an error toast on top of an empty container.
Correction in one gesture
Disagreeing is as fast as accepting.
Every suggestion can be dismissed or adjusted inline. The feedback this produces is real signal, because rejecting is not more effort than complying.
A loop that survives a bad day
The daily session is short enough to complete when motivation is low.
The core loop was deliberately kept small. A product used on low-energy days has to be designed for those days rather than for the demo.
A product that stays credible when it is wrong.
Which is the only condition under which people keep using it when it is right. The trust patterns — provenance, honest confidence, one-gesture correction — became the foundation the rest of the product was built on.
The same patterns have carried into other AI work since; they generalise far better than any individual screen does.
What this project taught me about AI interfaces
The instinct with a model-driven product is to design the impressive case. It is the wrong instinct. Users calibrate their trust on the failures, and they encounter those early.
Designing the worst case first is not pessimism — it is the fastest way to a product people keep.