Most interfaces are designed for the state where everything is known. The data has loaded, the answer is correct, the user did what was expected. That state is the minority of the time a real system spends in front of a real person.
The other states — loading, partial, stale, uncertain, wrong — are usually inherited from a component library rather than designed. That is where trust is won or lost.
Confidence is information
A forecast of 412 megawatt hours is less useful than a forecast of 412 with a band of 380 to 450 and a flag saying today resembles no day in the training data. The second one tells a trader when to override it.
We built exactly that for Lumen. The headline accuracy figure was 93%; the feature the desk actually relies on is the low confidence flag, because it converts a number into a decision about whether to trust the number.
A system that shows its confidence is not weaker than one that does not. It is just honest about something the user will find out anyway.
Four states worth designing
- Not yet. Loading, with an honest sense of how long. A spinner that has run for eight seconds is a lie about progress.
- Partially. Some of the data arrived. Show what you have and mark what is missing, rather than holding the whole screen hostage.
- Probably. The answer has a confidence attached. Render it.
- Stale. This was true at 09:14. Say so, and say how to refresh it.
The cost of hiding it
Hidden uncertainty does not disappear; it relocates to the user's judgement, uninformed. Someone makes a decision on a number they believe is exact, discovers later that it was not, and then discounts every number the system produces after that.
You cannot recover that cheaply. It is far less expensive to look slightly less confident on day one.
Where to start
Take the three screens your users spend the most time on and list every state the underlying data can be in. Most teams find between six and eleven. Most design files contain two.
