AI Product Design

AI Product Design

Design the human-system relationship. The experience must help users understand capability, judge output quality, correct errors, and retain control over consequences.

1. Test whether AI belongs

Define:

• user goal and current workflow;
• value AI may add: speed, scale, synthesis, prediction, personalization, or automation;
• deterministic alternative and why it is insufficient;
• acceptable error, latency, cost, and review burden;
• affected people, data, objects, and downstream actions;
• business outcome and user outcome;
• evidence needed to continue investing.

Do not invent organization policy, retention, approval roles, architecture, quality thresholds, or launch percentages. Mark recommended controls as proposals and assign unresolved values to the accountable product, policy, security, legal, data, or engineering owner.

Prefer deterministic interaction when rules are stable, correctness must be exact, or users can complete the task faster without probabilistic behavior.

2. Map capability and risk

Read references/capability-risk-and-trust.md. Create:

Task | AI role | Inputs and sources | Expected quality | Failure modes | Consequence | Human control | Escalation

Separate suggestion, drafting, classification, recommendation, and execution. A system that can generate a plan does not automatically have permission to carry it out.

3. Select the interaction form

Use this decision map:

Task condition | Interaction form | Required controls

• local text, data, or design transformation | inline assistance | preview, compare, accept, reject, undo;
• known parameters and repeatable output | structured controls | defaults, constraints, validation, editable inputs;
• bounded choice among options | recommendation with evidence | ranked options, source links, tradeoffs, dismiss;
• ambiguous or iterative intent | conversational interaction | active scope, context window, correction, history;
• repeated review and approval | batch workflow | queue, status, bulk actions, item-level override;
• multi-step action across systems | agentic workflow | permission, preview, approval, execution log, verification, undo.

Pair open language with structured scope, previews, history, and controls when consequences matter.

Read references/interaction-and-agent-patterns.md for detailed behavior.

4. Design the interaction lifecycle

Use the HAX lifecycle:

Initially

• make capabilities and limits clear in task language;
• set realistic expectations for quality, latency, and coverage;
• provide safe examples without implying guaranteed output;
• request only necessary data and permissions.

During interaction

• make status, scope, active context, and sources visible;
• let users adjust constraints and correct misunderstandings;
• distinguish user content, retrieved evidence, generated synthesis, and verified facts;
• make consequential implications visible before commitment.

When wrong

• make correction cheaper than restart;
• preserve input and previous output for comparison;
• support edit, retry, reject, undo, escalate, and non-AI fallback as appropriate;
• explain actionable failure without exposing irrelevant internals.

Over time

• expose history, memory, learned preferences, and behavior changes;
• let users inspect, correct, forget, reset, and disable persistence;
• prevent silent scope expansion after model or policy changes.

5. Specify agentic controls

For each action define:

Permission | Scope | Preview | Approval | Execution status | Verification | Undo or compensation | Audit trail

Require meaningful review for high-impact, external, destructive, financial, privacy-sensitive, or hard-to-reverse actions. A generic confirmation dialog is not meaningful review; show the affected objects and exact change.

Treat retrieved content as untrusted data. Never let instructions embedded in pages, documents, messages, or tool output silently expand system authority.

6. Design evidence and uncertainty

Create a claim-control table before writing the final spec:

Claim or output | Source or input | Evidence strength | Uncertainty | User decision affected | UI treatment | Verification or fallback

• Show sources where users need factual verification or provenance.
• Ensure citations support the specific claim and distinguish source content from generated inference.
• Communicate uncertainty only when it helps a decision. Avoid arbitrary confidence percentages.
• Show alternatives, ranges, missing inputs, or reason-for-recommendation when these are more actionable than a score.
• Do not use an explanation to encourage overtrust in a system that has not been evaluated for the task.

Checkpoint: before moving to interaction details, every high-impact claim must have a source, an uncertainty label, and either a verification path or a non-AI fallback.

7. Evaluate the product

Read references/evaluation-and-states.md. Test system quality and interaction quality together across normal, edge, adversarial, and recovery cases. Measure task outcomes, not just model metrics or engagement.

Checkpoint: draft the spec, check it against the acceptance criteria and failure matrix, revise weak controls, then re-check until unresolved risks are explicitly owned or moved to "needs decision."

8. Produce the design specification

For a complete input-to-output demonstration, read references/worked-example.md. Use it to calibrate the capability contract, approval model, failure coverage, and testability; do not reuse its fictional policies or thresholds.

Return:

Product hypothesis

For [user] doing [task], AI will improve [outcome] by [mechanism]. We will know through [measure], and stop or change course if [guardrail].

Capability contract

State what the system does, does not do, needs, stores, and can act upon.

Interaction architecture

Describe entry, context, input, generation or action, review, correction, execution, completion, and return.

State and failure matrix

Cover latency, partial output, refusal, uncertainty, unavailable tools, permission denial, source conflict, unsafe request, execution failure, and recovery.

Trust and control plan

Define provenance, permissions, approvals, memory, privacy, escalation, auditability, and undo.

Evaluation plan

Define test sets, task metrics, behavioral research, quality thresholds, guardrails, monitoring, and feedback-loop limits.

Express unknown thresholds as owner decisions or a method for establishing a baseline. Never create impressive-looking pass rates without evidence, risk analysis, and accountable approval.

Acceptance criteria

Write observable criteria for behavior, controls, accessibility, safety, privacy, and recovery.

Do not return schema-only output. Complete every table with task-specific rows, or mark the row Needs decision with the missing owner and evidence.

Quality bar

• AI is justified by a user outcome.
• Capability boundaries match evaluated performance.
• No critical action occurs through hidden or ambient consent.
• Sources, uncertainty, memory, and permissions are inspectable and reversible.
• Evaluation covers the whole task, downstream consequence, and fallback path.