Design the uncertain moments in an AI experience

The easiest AI screen to design is the one where everything goes well. A person asks a clear question, the system has the right information, and the answer arrives quickly. The result looks useful, the demonstration feels convincing, and everyone can imagine what comes next.

The more interesting design work starts when one of those conditions changes. The request is ambiguous. The source is incomplete. The answer is plausible but needs correction. A person wants to understand what happened before deciding whether to continue.

I think those moments should shape the interface from the beginning. An AI feature is an interaction over time, with expectations, interruptions, and repairs. Its quality depends partly on how comfortably someone can recover when the system's first attempt is not useful.

Explain what the feature is for

A large empty text box creates a surprisingly broad promise. Without useful framing, people have to guess what the product can do, what information it has, and which requests are appropriate. A few suggested prompts can help, but examples alone may not establish the boundary.

Imagine an assistant inside a project management product. It could summarize selected tasks, draft a project update, or recommend what to do next. Those are different levels of responsibility. The first two might work from a clearly defined set of records. The last might require business context the product does not have.

I would describe the available task in concrete terms: summarize these selected tasks, using their current status and notes. I would also show the selection before generation. That framing helps the person understand both the input and the intended output. It gives them a way to notice that something important is missing.

Microsoft Research's Guidelines for Human-AI Interaction offer a useful starting point for considering expectations and recovery. My design interest is in turning those broad concerns into visible behavior for a particular workflow.

Show progress without inventing confidence

Waiting is part of the experience, especially when the system is producing a longer response. A blank panel can make someone wonder whether the request was received. An animated sequence can reassure them that something is happening, but it should not claim work the system cannot verify.

I would rather show a straightforward state such as preparing a draft than a theatrical series of messages suggesting the product has checked every fact. If the system actually retrieves a defined set of documents, it may be useful to show those documents. If it does not perform a review, the interface should not imply that it has.

The next question is whether the user can leave. A task that requires waiting in one place has different requirements from a task that can finish in the background. The product should preserve the request, explain where the result will appear, and make it possible to cancel when appropriate. These decisions affect perceived control as much as visual polish does.

Make correction cheaper than starting again

When an AI output is almost right, a product should help the person fix the specific issue. Requiring them to rewrite the entire prompt can turn a small correction into another round of uncertainty.

For a draft project update, someone might need to remove an unsupported conclusion or change the audience. A useful interface could let them edit the text directly, inspect the underlying task selection, and regenerate only a section. Those options preserve the work that was useful while exposing the decisions that affected the result.

I would test the language of correction carefully. A feedback control labeled inaccurate may help the product team collect data, but it does not necessarily help the person finish their task. An action such as exclude this source or revise this section is closer to their immediate need. Product feedback and user recovery can support each other without becoming the same interaction.

Avoid making a percentage do all the explaining

A confidence score can look precise while leaving the practical question unanswered. Does a high number mean the system found a relevant document? That the answer matches the document? That the recommendation is appropriate for this person's situation? These are different claims.

I would be cautious about exposing a number without a meaningful explanation and a sound basis. Often the more useful design is to show the evidence and the missing context. A person can act on a statement that the answer uses two named documents but does not include recent changes. They cannot easily act on a percentage whose meaning is unclear.

The interface can also distinguish an unsupported request from a system error. If the source does not contain an answer, trying again may not help. The next action might be to open a document, add information, or contact the responsible person. Good recovery begins by making that difference understandable.

Keep consequential actions separate from suggestions

Generating text and changing a live record should not look like the same event. A suggested update may be worth reviewing even when the system is uncertain. Applying that update to an account, sending it to a customer, or removing information introduces a different responsibility.

My MessagePay work involved connecting borrower convenience with institutional controls and visibility. That experience reinforces a product principle I would bring to AI: the simple interaction still needs a clear account of what happens behind it. Convenience does not remove the need to understand the action.

In a hypothetical AI-assisted payment support tool, I would keep an explanation separate from any transaction action. The interface would need to show which record is affected, what the person is confirming, and how they can review the outcome. This is a design example, not a claim that MessagePay included that AI capability.

Prototype a difficult conversation

I would include uncertain states in a prototype review rather than leaving them as notes under a polished screen. Give a participant a request with missing information. Let the system provide an incomplete result. Ask them to correct it, inspect a source, and continue.

The useful observations will often be about expectations. Does the person think their feedback changed the current result or trained future behavior? Do they know whether their draft was saved? Can they tell when the product is suggesting an action and when it has completed one? These questions can reveal a mismatch that a happy-path demonstration never reaches.

The prototype does not need a sophisticated model to explore every concern. Carefully written sample states can expose terminology, navigation, and control problems. Live behavior becomes important when the uncertainty itself depends on actual system responses. The prototype should be honest about which part it is testing.

A clear recovery path is part of usefulness

I do not expect an AI feature to be free of uncertainty. I expect the product to help people work with it. That means a useful starting point, understandable boundaries, and a way to recover without guessing what the system is doing.

When the interface supports those needs, the person can remain an active participant in the task. They can inspect, revise, stop, and choose another route. That control is a practical design quality. It belongs in the requirements alongside the speed and quality of the first answer.