A reliable AI experience makes uncertainty visible.
AI product experience is not a prompt field and a stream of text. It is how people understand system recommendations, correct mistakes, approve actions and recover when information is incomplete.
Can a person see what changed, and reject it safely?
Design evidence, correction and refusal alongside the ideal answer. The useful interaction may be a document comparison or action queue, rather than another conversation.
A review surface should expose the decision.
An illustrative contract-review moment separates the source, proposed change and unresolved question. This is a design specimen; it makes no legal recommendation and changes no document.
Located source
The service term renews unless either party gives notice before the renewal date.
Proposed change
Add an explicit notice period to the renewal clause.
- Supporting evidence
- The located clause states that notice is required but does not specify a period.
The unresolved decision
The relevant notice period has not been supplied. The system cannot determine the intended term from this clause alone.
Supply the missing term
Return to the proposal with an explicit user-provided input.
Show the resulting change and its source before asking for approval.
Reject this suggestion
Keep the original clause and retain the rejection in the review history.
Rejection must not apply a hidden edit or make the original harder to recover.
Send for human review
Preserve the source, suggestion and unresolved question together.
Make ownership and pending status clear; do not imply the issue is resolved.
Inspect the interaction states
- Generating
- Expose a stable status without moving focus or repeatedly interrupting a screen reader.
- Needs information
- Name the missing input and keep the existing work available.
- Ready to review
- Show exact changes, evidence and explicit approval scope.
- Failed or rejected
- Preserve the original, explain recovery and prevent a false completion state.
Illustrative interaction specimen with synthetic contract text; controls are described, not connected to a document system.
Inspect a correction, not only a happy path.
- A task map comparing conversation with structured review.
- A revision trail showing source, proposal, correction, approval and rejection.
- Keyboard, screen-reader and failure-state tests, including wrong references and hidden changes.
The interface cannot promise what the backend cannot enforce.
Only present undo, approval, history or completion when the underlying system supports those guarantees. Prefer a simpler form or comparison view when it makes the user's judgment clearer.
The AI interaction argument
For CTO, CIO, CPO, COO
The situation behind the request
An agent suggests three contract changes. The user needs to understand which clauses were found, what was changed and where the risk lies before accepting the result.
Where the obvious solution falls short
Fluent natural-language output can hide missing evidence. Chat interfaces often lack stable structure, replayability and clear states. Accessibility can degrade when content streams without usable focus updates.
How we would approach the work
Map the task and decision points, introduce structured review and evidence patterns, design no-answer and escalation, and verify what the backend can actually guarantee.
What the engagement may include
- User task mapping and AI/non-AI interaction comparison.
- Review, correction and provenance components.
- Accessible state transitions and recovery patterns.
- Usability and failure-mode tests tied to product analytics.
The choices worth making explicitly
Choose form, table, side-by-side document, action queue or conversation based on task. Chat is not the default visual primitive.
What we would test before calling it ready
Test screen reader behavior, hidden changes, revision history, wrong references and user ability to reject proposed actions.
A sensible first step
Design the refusal and correction flows at the same time as the ideal response.