Human–AI interaction

Principles for Designing Human–AI Interaction

An applied framework for designing AI interfaces that support appropriate reliance, user control, transparency, and responsible autonomy.

39 principles
Practical rules for suggestion, review, refusal, and recovery when the same input can produce different outputs.
Nine categories
From probabilistic foundations to sustained reliance — a map for the whole AI product surface.
Appropriate reliance
The job is not maximum trust. It is helping people rely on AI only as far as the system deserves.
Human at the helm
Accept, edit, undo, and escalate stay first-class. Autonomy is bounded by stakes and reversibility.

The framework

Nine categories. One practice.

Traditional interfaces assume predictable behavior. AI systems return a distribution. These categories help teams decide when to suggest, ask, or act — and how to keep people responsible for the result.

01 / 09

Probabilistic Foundation

Treat the model as a probabilistic service. Design for inference, generation, and the spread of possible outputs — not a single fixed function.

Principle 1
Use AI only where it has a comparative advantage
Reach for AI where inputs are messy, intent is ambiguous, or synthesis is the job. Keep deterministic controls for work that must be exact, repeatable, and auditable.
Principle 2
Design for generative variability — don’t fight it
The same prompt can yield more than one good answer. Offer drafts, regenerate, compare, and save alternatives so variation becomes a choice, not a defect.
Principle 3
Choose the interaction pattern based on the task
Not every feature should be a chatbot. Match the pattern to risk and openness: inline suggestion, conversation, or a planned multi-step flow with checkpoints.

02 / 09

Expectation Setting

Users form a mental model before they read the first result. Clarify capability, limits, and AI involvement early.

Principle 4
State what the system can do — and where its limits are
A capability claim is incomplete without boundaries. Say what the system is for, and where accuracy, coverage, or access may fall short.
Principle 5
Solve the blank-canvas problem
An empty prompt box hides what the product is good at. Use examples, templates, and starter actions to reveal range and make the first move easy.
Principle 6
Frame output as a starting point
Labels teach users how to treat a result. “Draft,” “suggestion,” and “review” invite inspection. “Answer” or “done” can imply more finality than the system earned.
Principle 7
Signal the AI’s role explicitly
People should know when content was generated, summarized, ranked, or recommended. Hidden involvement creates false attribution to sources or authors.
Principle 8
Adapt explanation and control to user expertise
Novices need wayfinders and guardrails. Experts need inspection, override, and configuration. Auditors need logs, provenance, and repeatability.
Principle 9
Represent the AI’s nature honestly
Do not imply feelings, lived experience, or human judgment the system does not have. Give it a useful role, not a false identity.

03 / 09

Calibrated Trust

Match reliance to reliability. Reduce overtrust in weak output and underuse of useful help.

Principle 10
Provide provenance for claims, tools, and data
A claim with a source can be checked. Show the documents, tools, and inputs behind an output so users can move from synthesis back to evidence.
Principle 11
Prefer provenance over confidence scores
A number can raise trust even when it is meaningless. Prefer the source passage, the diff, or the retrieved record over a lone confidence meter.
Principle 12
Make output cheap to verify
Appropriate reliance depends on cheap checking. Highlight what changed, link the source, and keep verification to a glance rather than a second investigation.
Principle 13
The system must not run its own agenda
The assistant should serve the stated task, not a hidden upsell, engagement, or retention goal. Secret objectives corrupt reliance at the root.
Principle 14
Don’t be sycophantic — design for honest pushback
Agreement that exists to please the user inflates trust where it should fall. Give the product a way to flag weak premises, missing evidence, and likely error.
Principle 15
Respect creators and attribution
Do not present borrowed phrasing, distinctive ideas, or licensed material as if the system invented them. Make the relationship to source content visible.

04 / 09

Transparency

A black box cannot be trusted appropriately. Make reasoning and evidence inspectable without drowning the workflow in noise.

Principle 16
Answer the five intelligibility questions
Users ask what the AI did, what it used, why this result, why not another, and what would change the outcome. Answer those questions at the right depth.
Principle 17
Use progressive disclosure for explanations
Keep the shortest useful cue in the main flow. Put methodology, traces, assumptions, and logs one step away for people who need them.
Principle 18
Show plans and traces for multi-step work
When an agent plans and acts across steps, render the plan. Show progress, tools, and pending approvals — never hide consequential work behind a silent spinner.

05 / 09

Control & Agency

Human and system share the wheel. Accept, reject, edit, undo, and override should stay one gesture away.

Principle 19
Make AI assistance easy to accept — and easier to ignore
Suggestions should not steal momentum. Accept, dismiss, edit, undo, or regenerate in one keystroke. Rejection should be nearly free.
Principle 20
Ask, don’t guess, when uncertain
When ambiguity would change a consequential result, ask a specific question. If the risk is low and recovery is easy, continue and make the assumption visible.
Principle 21
Give global and granular controls
Granular controls shape one result. Global controls define standing behavior: memory, data access, autonomy, and defaults that should not be restated every time.
Principle 22
Time interventions to attention
A correct suggestion at the wrong moment is an interruption. Weigh the cost of breaking focus against the value of the help, and stay quiet when the math says so.
Principle 23
Make AI assistance accessible and inspectable
Generated edits, citations, warnings, and traces must work with keyboards, readers, and varied cognitive load. Announce changes. Do not hide the work in a visual-only layer.
Principle 24
Show whose rule the system is following
When behavior is shaped by a setting, admin policy, safety rule, or commercial placement, make that influence visible and distinguishable.

06 / 09

Graceful Failure

Error is the default case, not the edge case. Make uncertainty, recovery, and escalation first-class paths.

Principle 25
Contain the damage when the AI is wrong
Limit how far an error can travel. Preview before send, keep history for records, and offer rollback for agents that change a working system.
Principle 26
Reduce precision when the evidence is weak & surface the parts that need review
Do not pretend to be exact when the evidence is thin. Offer ranges, options, or partial answers, and mark the pieces that still need a human look.
Principle 27
Design the human handoff
When the system hits its limit, escalate with context: what was tried, what is uncertain, and what to do next. A cold restart is its own failure.
Principle 28
Design the refusal path with good intent
Assume a legitimate goal, then apply a safeguard only where risk is clear. State the limit, explain it briefly, and offer the nearest safe next step.

07 / 09

Co-Creation

Keep the artifact malleable. Treat generated work as a draft the user can shape, not a verdict they must accept.

Principle 29
Keep generated output malleable
Let people edit in place, revise a selection, regenerate a section, and continue from the current state. Generated work should behave like material, not a sealed deliverable.
Principle 30
Use friction to improve judgment, not to slow exploration
Keep exploration fluid. Add a review moment before the user chooses, approves, publishes, or commits — not while they are still trying ideas.
Principle 31
Help users specify intent
Users should say what they want, not learn hidden prompt tricks. Expose controls, examples, and structured inputs so intent is visible and refinable.

08 / 09

Responsible Autonomy

The more the system acts on its own, the more the interface is a governance surface. Bound action by stakes, reversibility, and permission.

Principle 32
Bound autonomy by reversibility and stakes
Auto-run low-stakes reversible actions. Notify for moderate ones. Require explicit approval where harm is material or the change is hard to undo.
Principle 33
Make data use explicit, permissioned, and revocable
Show what data the system can access and why. Ask before expanding that access, and let people inspect, limit, or revoke it.
Principle 34
Protect third-party privacy
The previous rule governs the user’s data. This one governs everyone else’s. Do not assemble, infer, or surface private context about people who are not in the room.
Principle 35
Separate instructions, data, tools, and actions
Define the trust boundary: what the system may read, obey, call, and change. Retrieved content must not silently become instructions.

09 / 09

Sustained Reliance

Keep the conditions of healthy use intact over time: wait states, cost, quality, drift, ownership, and change.

Principle 36
Design the wait, not just the result
An unexplained pause weakens confidence. Stream when useful, show staged progress, and give a safe way to cancel or continue in the background.
Principle 37
Make compute effort visible where it affects behavior
When a design encourages repeated generation, long agents, or expensive tools, show cost, time, or limits clearly enough to guide the next choice.
Principle 38
Measure reliance, not just usage
High acceptance can mean value or overtrust. Regeneration can mean exploration or poor first-pass quality. Measure whether reliance is healthy, not only frequent.
Principle 39
Design for model and data changes
Models and data will change. Version the experience, pin behavior with evaluations, and treat a swap like a dependency upgrade — not a silent break.