Applied AI
Design AI output as a proposal rather than a decision
When AI output resembles a final decision, users can act before checking its assumptions. Design proposals that expose evidence, missing inputs, and alternatives, while preserving a clear boundary between generated advice and authorized business decisions.
A recommendation screen shapes how people use AI output. A fluent sentence displayed beside a prominent action button can feel more settled than the evidence warrants. Design the output as a proposal that a responsible person can inspect, amend, or reject. The distinction should exist in both the wording and the workflow.
Give the proposal a defined job
Specify what the output helps a person do: compare options, identify missing information, or prepare a draft. Avoid presenting an open-ended generated judgment as the organization’s final position. NIST calls for documentation of knowledge limits and how humans may use and oversee AI output.[7] Make those limits available where the proposal appears.
Separate source-backed facts from inferred suggestions. If a recommendation depends on an assumption, show the assumption alongside the recommendation. Do not use an unexplained confidence label as a substitute for supporting evidence. A reviewer should be able to understand what information would change the proposal.
Design for inspection and disagreement
Place relevant evidence beside the claim it supports. Show missing inputs before the user reaches the acceptance control. Let the reviewer edit the proposal, compare a reasonable alternative, or decline to use AI assistance. These are interface recommendations intended to support review, not a claim that a particular layout guarantees careful judgment.
Avoid preselected acceptance and language that implies the system already decided. Preserve the reviewer’s edits separately from the generated version where the workflow needs a decision record. If a user chooses a different option, allow a short reason without requiring a long justification for disagreeing with the model.
Proposal design checklist
Review the screen with the person accountable for the eventual decision. Ask that person to explain the recommendation and its limits without assistance from the implementation team.
- Label the output as a proposal or draft rather than an approved decision.
- Distinguish cited facts, assumptions, and unresolved questions.
- Provide visible edit, reject, and request-more-information options.
- Keep accepting a proposal separate from sending, posting, or modifying a record.
- Show the result of any later action instead of treating acceptance as proof of execution.
Hypothetical example: a replenishment suggestion
A hypothetical office supplier uses AI to suggest a replenishment quantity from a stock summary and an upcoming promotion brief. The proposal lists the source stock figure but notes that confirmed inbound shipments are missing. A buyer can request that information before selecting a quantity.
The interface does not label the suggestion an approved purchase. Creating an order follows a separate authorized process. OWASP recommends human approval for high-impact actions and enforcement of permissions outside the model.[4] Until the missing shipment information is resolved, the suggested quantity remains conditional rather than ready for ordering.
Keep usefulness without false finality
Showing assumptions and alternatives adds reading effort. Too much detail can obscure the main issue, so prioritize information that could change the decision. Test whether users can identify a deliberately unsupported suggestion and find the underlying source. If they cannot, simplify the proposal or narrow the task before giving the output more authority.
