AI Product Design Principles
Rule 1: Use AI Where It Adds Genuine Value
AI should make users more capable, not more dependent. Apply AI to tasks that are inherently ambiguous, personal, or variable. If the right answer is deterministic, a rule or a search index outperforms a language model every time.
| Good fit | Poor fit |
|---|---|
| Drafting personalised outreach | Calculating a subtotal |
| Summarising a long document | Looking up a postcode |
| Surfacing anomalies in data | Sorting a list |
| Answering free-form support questions | Navigating a fixed menu |
Decision test: Could a rule handle 95% of cases reliably? If yes, start there. Use AI where rules break down or where variety is the point.
Rule 2: Set Honest Expectations
Users form mental models of AI the moment they first interact with it. Over-promise and they will over-trust; under-promise and they won't engage. Aim for calibrated confidence.
| Pattern | Where to use it |
|---|---|
| "AI-suggested — please verify" label | High-stakes summaries, financial or medical context |
| Hedging language ("Based on available information…") | Conversational interfaces answering factual questions |
| Source attribution with links | Research assistants and knowledge tools |
| Capability boundary statement | Onboarding and first-run experience |
When the model is uncertain, the product should reflect it — not smooth uncertainty over with polished prose.
Rule 3: Design for the Wrong Answer
AI will be wrong. Treating failure as a special case guarantees a bad experience. Three tiers need different design responses:
| Failure tier | Design response |
|---|---|
| Subtle error (one wrong detail) | Structured output so errors are visible; easy inline editing |
| Significant error (misses intent) | Regeneration, alternatives, or a correction flow without starting over |
| Catastrophic failure (no usable output) | Graceful degradation to a non-AI experience |
Before/after: A travel assistant showing one itinerary gives no recourse when it lists a closed restaurant. Redesigned with three options, items flagged "not verified in real time," and per-item swapping — the wrong answer becomes a minor edit.
Rule 4: Keep the User in Control
Autonomy is the line between AI that empowers and AI that patronises.
| Dimension | What to provide |
|---|---|
| Override | Ignore, dismiss, or undo any AI output |
| Adjustment | Tune tone, length, or scope |
| Visibility | Show what data produced the result |
| Pause/disable | Turn off AI without losing the underlying feature |
| History | See and delete what the AI has learned |
Start with AI suggesting, humans approving. Move toward automation only after strong evidence of trust, and always keep a path back to manual control.
Rule 5: Make Feedback Effortless
Friction is the biggest barrier to feedback. Design the smallest interaction that is still actionable.
| Effort | Signal | Examples |
|---|---|---|
| Zero friction | Low, high volume | Acceptance rate, edit distance, feature return rate |
| One tap | Medium | Thumbs up/down; "Was this useful?" |
| Short form | High | 2–3 radio buttons + optional free text |
A thumbs-down with a category picker ("Wrong / Unhelpful / Too long") beats a star rating for actionability and an open text field for participation. Show impact: "Your feedback improved this for thousands of users."
Rule 6: Personalise Transparently
AI personalisation can feel like magic or surveillance. The difference is transparency. Progressive personalisation: (1) Generic defaults for new users. (2) Observed adaptation from what users actually do. (3) Explicit preferences — users see and edit what the AI knows. (4) Persistent profile reflecting real working style.
The creepiness line: personalisation reveals data the user didn't know was tracked, or narrows options rather than expanding them.
| Transparent | Anti-pattern |
|---|---|
| "Suggestions tailored to your feedback" | No explanation for why recommendations changed |
| "Edit your preferences" link | Personalisation with no visibility or override |
| "Why am I seeing this?" tooltip | Quietly filtering results based on inferred attributes |
Rule 7: Measure Real Value, Not Usage
High usage is a vanity metric. A user who regenerates a summary five times before abandoning it has high engagement and zero value.
| Metric | What it signals |
|---|---|
| Task completion rate | Did the AI help users accomplish their goal? |
| Time-to-value | How quickly do users get a useful output? |
| Error correction rate | How often do users significantly edit AI output? |
| Return rate | Do users come back to this feature? |
| Unassisted fallback rate | How often do users abandon AI and do it manually? |
Track guardrail metrics too: error rates, harmful outputs flagged, support tickets. Rising guardrail numbers should halt rollout even when headline metrics look healthy.
Rule 8: Disclose AI-Generated Content
Users have a right to know when they are reading AI-generated content. The label should be clear without disrupting reading flow.
| Context | Label pattern |
|---|---|
| AI-drafted document for editing | Banner: "AI-generated draft — review before sending" |
| AI-summarised article | Small inline label: "AI summary" |
| AI-assisted support reply | Agent sees "AI suggested — edit or send" |
| AI-generated recommendation | "Recommended based on your history" |
Do not use AI-generated content where users assume human authorship — expert opinions, testimonials, personal messages.
Rule 9: Preserve Human Judgment for High-Stakes Decisions
Some decisions should not be delegated to AI even when accuracy is high. The question is accountability, consent, and the reversibility of the consequence.
Require a human in the loop when a decision has hard-to-reverse consequences, the affected person has a right to human review, or the AI's error mode harms specific groups disproportionately. Automation should increase human capability, not remove accountability.
Rule 10: Build Ethically Throughout the Lifecycle
Ethics reviews at launch are too late. By that point the feature is built and changing core behaviour is expensive.
| Phase | Ask |
|---|---|
| Problem framing | Who benefits? Who might be harmed? |
| Data sourcing | Is the data representative? Any consent issues? |
| UX design | Does it manipulate or deceive? Does it preserve agency? |
| Testing | Does accuracy vary across user groups? |
| Launch | Are users informed? Is there a recourse path? |
| Post-launch | Are guardrail metrics tracked? Is rollback ready? |
Watch for dark patterns: AI that manufactures uncertainty or dependency erodes trust faster than it builds short-term metrics.
Further Study
| Resource | What it covers |
|---|---|
| Google PAIR People+AI Guidebook (pair.withgoogle.com) | UX patterns and exercises for AI product design |
| Microsoft Human-AI Interaction Guidelines (Amershi et al.) | 18 empirically-validated design guidelines for AI features |
| Nielsen Norman Group "UX for AI" series | Usability research and design recommendations |
| "The Alignment Problem" — Brian Christian | Accessible context on building AI that behaves as intended |
Related: Course home · UX patterns · Glossary