A conventional form usually has a predictable relationship between input and result. An AI feature may take longer, return an incomplete answer or propose an action the person did not intend. The interface needs to explain these possibilities without turning every interaction into a warning screen.
For designers and developers, the task is to make the system's actual state understandable. That means connecting the language people see to events the software can verify, rather than decorating a model call with a reassuring animation.
Start with the promise
Consider an illustrative assistant that turns meeting notes into a task list. Does it only suggest tasks, save drafts or assign work to other people? These are different promises with different consequences.
State the scope near the interaction: “Create a task-list draft from these notes” is clearer than “Handle the follow-up.” Show which material will be used and whether generated content will remain private until reviewed. The backend must enforce the same boundary; copy alone cannot turn an automatically publishing workflow into a draft-only one.
Microsoft Research's Guidelines for Human-AI Interaction are a useful foundation for setting expectations and supporting correction. Published in 2019, they are not a description of today's agent features. Their value is the interaction responsibility, not novelty.
Report progress you actually know
Separate queued, generating, validating and saving only if the application can observe those stages. Do not display “Checking every fact” when the system is merely waiting for a response. Do not present a precise completion percentage unless there is a meaningful basis for it.
A useful message might be: “Creating a draft. You can leave this panel open while you continue reading.” Whether that promise is appropriate depends on the application's actual background behaviour. Design the message and implementation together.
Streaming text is not necessarily a completed result. Make it clear whether the person is reading an unfinished suggestion, whether actions are available yet and what stopping generation will do. A partial answer should not quietly become an approved final artifact.
Make uncertainty actionable
A generic disclaimer that “AI can make mistakes” does little to help someone review a task list. More useful signals point to specific gaps: an owner was not mentioned, a deadline is ambiguous or the source notes contain conflicting dates.
Offer a way to inspect the supporting source and edit the draft. Do not invent a confidence percentage or imply that fluent wording is evidence of correctness. If a model supplies a confidence value, it should not be treated as calibrated probability without separate validation.
The designer defines how gaps are visible and editable. The developer checks whether those signals are grounded in available data and whether source links lead to authorized material.
Put approval at the consequential boundary
Reviewing a draft and assigning tasks to other people are different actions. Before the latter, show the actual recipients, task content and any deadlines. If the user changes those details, invalidate the previous approval and ask again where appropriate.
Approval should not be buried in an optimistic “Continue” button. The control should describe the consequence. Permissions and final execution checks belong in the application, not only in model instructions.
Design recovery before celebrating success
If generation fails, preserve permitted input and offer a retry. If saving succeeds but assignment fails, show that partial outcome instead of a generic failure. Avoid retries that duplicate external actions. If the system cannot determine whether an action completed, say so and reconcile its status before trying again.
Interaction review checklist
- State what the feature does and does not do.
- Tie progress messages to observable events.
- Distinguish partial output from completed drafts.
- Surface specific gaps with useful review controls.
- Require meaningful approval before consequential actions.
- Explain partial failure and prevent duplicate retries.
Trust comes from accurate promises and recoverable mistakes, not from making AI sound certain. Designers and developers can make that trust concrete by treating feedback, permission and recovery as core behaviour rather than final polish.
Sources
Key takeaways
- Show only progress the system knowsCommunicate observable stages and avoid invented percentages or claims that work is complete.
- Make uncertainty usefulExplain what is unknown and give people a practical way to clarify, correct or continue.
- Design approval and recoveryPlace meaningful confirmation before consequential actions and provide a clear path when an action fails.