ai-trust-design

---
name: ai-trust-design
description: >-
  Designs the trust arc for AI products: from first wow moment through
  production-grade reliability. Covers the three trust types users need to
  cross before they rely on an AI product, specific mechanisms for each, and
  how to make limitations a trust signal rather than a liability. Use when
  designing AI onboarding, diagnosing why trial-to-paid is low despite high
  engagement, or building transparency documentation.
triggers:
  - /ai-trust-design
  - user is designing onboarding for an AI product
  - trial-to-paid conversion is low despite high engagement
  - user wants to build trust signals into an AI product
  - user is writing a limitations page or transparency doc for an AI product
role: workflow
version: 1.0.0
sources:
  - "ai-trust-design (growth-skills v1.0)"
feeds:
  - pmm/content-review
  - pmm/positioning
related:
  - pmm/DOMAIN.md
  - pmm/ai-product-gtm/ai-benchmark-distribution
  - pmm/ai-product-gtm/ai-output-virality
---

# AI Trust Design

## Role / Purpose

**AI Trust Architect.** Every AI product faces the same structural problem: users are impressed before they trust, and they trust before they pay. "Wow" is free. Trust is earned. This skill designs the bridge between them.

Note: capability claims precision, limitation statement requirements, and the demo edge-case principle are in `pmm/DOMAIN.md` (AI product content section). This skill covers the product and onboarding design layer — the mechanisms that build trust inside the product experience itself.

---

## Contract

This skill guarantees:
- The three trust types are identified and distinguished — interventions are matched to the specific trust type blocking conversion
- The distrust spike is treated as a designed stage, not an accident to avoid
- Limitation statements follow the specific/contextual format — vague legal disclaimers are flagged
- Output identifies which trust type is the actual conversion blocker before recommending a mechanism

---

## Before starting

Confirm (ask or infer):

- **Conversion problem** — which transition is failing? Discovery → trial / trial → active / active → paid / paid → enterprise?
- **ICP** — developer trialist / business user / enterprise buyer? (different trust types block different ICPs)
- **Current onboarding design** — does the product have a first-run experience? A playground? A limitations page?
- **Available evidence** — what capability evidence exists? (benchmarks, case studies, usage data)

---

## Inputs

**Required before proceeding:**
- Description of the AI product and its primary use case
- Which conversion step is underperforming
- Current onboarding or first-run design (if any)
- ICP or user type experiencing the drop-off

---

## The three trust types

Most AI products conflate these and address none of them properly:

| Trust type | User question | When it blocks conversion |
|---|---|---|
| **Capability trust** | "Can it actually do what it claims?" | Prevents first trial; users won't start if they don't believe |
| **Reliability trust** | "Will it work consistently, not just in demos?" | Blocks production adoption after initial trial |
| **Safety trust** | "What happens when it's wrong, and is that recoverable?" | Blocks enterprise purchase and high-stakes use cases |

**Decision logic:**
- Discovery → trial drop: capability trust gap
- Trial → active/paid drop: reliability trust gap
- Active/paid → enterprise drop: safety trust gap

Do not apply reliability mechanisms to a capability trust problem, or vice versa.

---

## Decision logic — matching mechanism to trust type

### Capability trust mechanisms

These establish "it actually works" before the user invests time:

```
CAPABILITY TRUST DESIGN

Curated first-run experience:
  The first output should be as close to perfect as possible.
  Do NOT show the full capability range in onboarding — show the
  highest-reliability use case first. Broad capability claims attract;
  high-quality first output converts.

Social proof from technical peers:
  An engineer's benchmark result is worth 100 marketing claims.
  Surface case studies and community results from users with similar
  technical contexts — not generic testimonials.

Live playground with real inputs:
  A locked demo that always works is weaker than a playground where
  users see the model working on their own inputs — even if the output
  is imperfect. Imperfect real output > perfect scripted demo.
  (This is the playground-as-trust-signal principle.)
```

### Reliability trust mechanisms

These address: "will this work consistently for production use?"

```
RELIABILITY TRUST DESIGN

Accuracy / confidence indicators:
  Show the model's certainty where meaningful.
  An AI that says "I'm not confident about X" is more trustworthy than
  one that asserts everything with equal confidence.

Failure mode documentation:
  Explicitly describe when the model fails, under what conditions, and
  what the user should do. "This model struggles with X" builds more
  trust than silence about X — users will discover it anyway.

Regression testing visibility:
  If accuracy metrics are tracked, publish them. Users who know you
  measure reliability trust you more.

Version consistency:
  For API products, version pinning is a reliability trust feature
  as much as a technical one. Users need to know that a prompt that
  worked last week still works today.
```

### Safety trust mechanisms

These address: "what happens when it's wrong?"

```
SAFETY TRUST DESIGN

Explicit use case scoping:
  State clearly what the product is and is not appropriate for.
  "This is not suitable for [high-stakes use case]" is a trust signal —
  it tells the user you've thought about where the product breaks.

Human-in-the-loop design:
  For high-stakes actions, the user must always have a review step.
  AI products that skip this to feel more autonomous lose enterprise trust.

Error transparency:
  When the model is wrong, acknowledge it clearly. Products that make it
  hard to identify AI errors lose trust faster than products where errors
  are visible and recoverable.

Data handling transparency:
  Where does user input go? What is it used for?
  For enterprise, this is a prerequisite, not a nice-to-have.
```

---

## The trust arc

```
FIRST CONTACT → WOW → DISTRUST SPIKE → TRUST BUILDING → RELIABLE USE → ADVOCACY
```

**The distrust spike is not a bug — it is the natural response to seeing a powerful demo.** After the initial wow, users think: "That was impressive in a controlled setting. Will it work for MY situation? What if it's wrong?" Products that acknowledge this spike design better onboarding. Products that pretend it doesn't exist lose users who experience it alone.

| Stage | What the user needs | Design response |
|---|---|---|
| **Wow** | Understand what is possible | Curated demo path with high success rate |
| **Distrust spike** | Acknowledgment that their skepticism is valid | Explicit limitations page; "when to trust this output" guidance |
| **Trust building** | Evidence of reliability in their use case | Examples from users like them; sandbox with their own data |
| **Reliable use** | Consistency signals over time | Usage history; accuracy indicators; error transparency |
| **Advocacy** | A story to tell colleagues | Output shareability; benchmark results to reference |

---

## Making limitations a growth asset

The counterintuitive principle: **stating limitations increases conversion for serious users.**

Serious users (the ones who will pay and stay) are evaluating whether they can trust the product. A product that acknowledges limitations credibly signals:
1. The team understands the product well enough to know where it breaks
2. The product is honest — which implies the claims it does make are real
3. The user won't be surprised in production

**Limitation statements that build trust:** specific, contextual, with guidance.

```
Good: "This model performs poorly on [specific input type] — for those cases,
try [alternative approach]."

Bad: "Outputs may not be accurate." (tells the user nothing useful)
```

**Gate:** any limitation statement that uses only a general disclaimer without specifying the failure condition and the user action is flagged. Require a specific version before publishing.

---

## Output format

```
## AI Trust Diagnosis

**Product:** [Name]
**Conversion step underperforming:** [Discovery→trial / Trial→active / Active→paid / Paid→enterprise]
**Trust type blocking conversion:** [Capability / Reliability / Safety]
**ICP:** [Developer trialist / Business user / Enterprise buyer]

### Trust arc stage assessment
Current stage where users drop: [Stage name]
Evidence: [What signals indicate this stage?]

### Mechanisms to implement
Priority 1: [Mechanism — specific design action]
Priority 2: [Mechanism — specific design action]
Priority 3: [Mechanism — specific design action]

### Limitations content audit
Current limitation statements: [Specific / Vague / None]
Required rewrites: [List any vague disclaimers with specific replacement]

### Validation
[ ] Trust type correctly identified before mechanism selection
[ ] Limitation statements are specific (failure condition + user action)
[ ] Distrust spike is designed for, not hoped away
```

---

## Brain reads / writes

**If a companion brain repo is connected:**

Before starting:
- Read `knowledge/icp-map.md` — ICP segment determines which trust type is typically the conversion blocker (enterprise buyers need safety trust; developer trialists need capability trust)
- Read `playbooks/messaging.md` — capability claims must be consistent with approved messaging

**Brain not connected:** proceed normally.

---

## Anti-patterns

| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Applying reliability mechanisms to a capability trust problem | Users who don't believe the product works won't stay long enough to experience consistency | Diagnose the trust type first; match mechanism to the specific gap |
| Showing full capability range in onboarding | Users experience edge cases before they've built baseline capability trust; they leave | Show the highest-reliability use case first; expand after trust is established |
| Vague limitation disclaimers | "Outputs may not be accurate" tells the user nothing; they assume the worst | Replace with: "This model performs poorly on [specific case] — for those cases, [action]" |
| Hiding the distrust spike | Users experience doubt alone; product feels like it promised something it didn't deliver | Acknowledge skepticism explicitly in onboarding; give users language to evaluate the product |
| Treating "wow" as the conversion moment | Users who are impressed are not yet converted; the gap between wow and trust is where most churn happens | Design the trust-building stages as explicitly as the wow stage |
| Enterprise pitch without safety trust established | Enterprise buyers have safety objections that capability and reliability evidence cannot address | Build safety mechanisms before entering enterprise sales conversations |

---

## Validation criteria

- [ ] Conversion step identified before trust type is named
- [ ] Trust type correctly matched to ICP and conversion stage
- [ ] Mechanisms are specific to the diagnosed trust type — not generic "build trust" recommendations
- [ ] Limitation statements are specific (failure condition stated + user action given)
- [ ] Distrust spike addressed with a design response, not ignored

---

## References & Sources

**Tier 2 (operator source — adapted, not authoritative):**
- ai-trust-design (growth-skills v1.0): three trust types, trust arc model, capability/reliability/safety mechanism taxonomy, limitations-as-growth-asset principle