Users generate an answer, inspect it, then do the work themselves. Others accept the same output without checking it. Your feature has both underuse and overreliance, and a better model may not fix either. Trustworthy AI defaults start with the behavior users get before they change a setting: what context is included, what gets changed, what requires approval and what carries into the next task.

The PM’s job is not to maximize acceptance. It is to make the untouched path appropriate for the task, including when users are distracted or unfamiliar with the feature.

Diagnose a default failure before calling it a trust problem

A default is a decision the product makes when the user makes no explicit choice. That includes a preselected audience, a checked permission, an output destination or a remembered preference.

Look for friction before users customize anything. These signals suggest a default problem, but they are not proof:

Observed symptom	Possible default failure	Check before changing it
Users repeatedly remove information from outputs	Context includes material they did not intend to use	Compare included sources with the task they described
Users immediately undo changes	The feature applies output before they expect it to	Observe whether they expected a suggestion or an edit
Users accept unsuitable outputs quickly	The starting state encourages unexamined reliance	Check whether they noticed assumptions and consequences
Users configure the same setting every session	A useful preference is not retained	Confirm that the preference should carry across tasks
Users abandon setup	Too many decisions precede a useful result	Identify which choices can safely wait

Ask users to complete a real task without explaining the interface. Then ask what they expected the feature to see, change and remember.

If those expectations match the product but the output is still unusable, investigate relevance or quality instead. Do not label every abandoned answer a defaults problem.

Choose trustworthy AI defaults by consequence

Do not use one automation setting across every AI task. A private suggestion and a message sent to a customer have different consequences, even when both use the same generation capability.

For each task, assess who can be affected, whether the action can be reversed and whether mistakes are reasonably detectable. A starting policy might look like this:

Task	Candidate default	Reason
Generate private headline options	Show options without an approval dialog	The user still chooses what to use
Rewrite a selected paragraph	Preview the replacement before applying it	Meaning can change despite fluent wording
Draft a customer response	Keep it unsent and show relevant source context	Incorrect claims can create external commitments
Change billing or access permissions	Require explicit authorization for the action	Consequences extend beyond the generated text

These are starting points, not universal rules. A headline for a regulated claim can need more scrutiny than an internal paragraph rewrite.

Use task risk to calibrate the required level of trust, rather than treating approval as an all-or-nothing product philosophy.

Low friction should mean fewer unnecessary decisions, not fewer meaningful boundaries. Users should not need to open settings just to prevent an external action they never intended.

Write the default specification before designing settings

A settings page does not compensate for an unsafe starting state. Specify what happens when the user does nothing, then decide which choices belong in the main workflow.

For a support-response assistant, a concrete default specification could include:

Context: Use the current ticket and approved support material. Do not silently include unrelated customer conversations.
Destination: Create a draft in the reply composer. Do not send it or change the ticket status.
Missing information: Mark an unresolved policy question instead of inventing a refund promise.
Approval: Require the user’s send action. A request to draft is not permission to communicate externally.
Persistence: Remember a writing preference within its stated scope. Do not carry permission to act into a different customer conversation.
Failure behavior: If required policy material cannot be retrieved, leave the relevant claim unresolved and explain what is missing.

Assign an owner and an acceptance test to each rule. “Use only the current ticket” becomes testable when another ticket contains information the assistant must not incorporate.

Separate preferences from permissions

Tone, length and formatting are preferences. Access to private information and permission to publish are boundaries. Do not save them under one ambiguous “remember my choices” control.

Where organizational controls exist, user preferences should operate inside them, not override them. Also define what happens when a saved preference becomes invalid. A changed role or revoked permission should not leave yesterday’s access active.

Microsoft’s Guidelines for Human-AI Interaction address expectations, correction and user control. For defaults, turn those principles into observable product behavior rather than explanatory copy alone.

A support reply draft uses the current ticket as context, flags an unresolved refund-policy question, and leaves the separate send control for the user to approve.

Test the untouched path, not just the configured experience

Teams often evaluate a feature after someone has selected the right sources, adjusted the tone and learned its quirks. That tests the configured experience, not the default.

Run the same task with a fresh account and no setup guidance. Include an ordinary case, a case with missing information and a case where the user switches projects or audiences.

Watch for expectation mismatches. Does “generate” sound like “apply”? Does a private draft unexpectedly become shared? Does a remembered instruction survive into a context where it no longer belongs?

Then test failure deliberately. Remove a required source, revoke access or interrupt generation. Check whether the product leaves a safe, legible state or quietly proceeds with less information.

An approval dialog alone is not a passing result. Users must understand what they are authorizing. A generic “Continue?” can produce clicks without informed approval.

A useful acceptance criterion: A user who leaves settings untouched can predict the action’s scope and destination before committing it.

Measure appropriate reliance, not just acceptance

A higher acceptance rate can mean better defaults. It can also mean users stopped checking. Pair usage metrics with evidence about the completed task.

Track immediate reversals after application, repeated setting changes and downstream corrections. Define each event precisely. An edit made to match personal style is different from correcting a fabricated commitment.

For repeat use, measure the next eligible task rather than an arbitrary daily return. A weekly reporting assistant should not be judged by daily activity. Check whether the user chooses it again when that reporting job recurs.

When experimenting with trustworthy AI defaults, state the expected behavioral change and a guardrail before launch. For example: preview-by-default should reduce immediate reversals without materially increasing abandoned drafts. Use a task-quality review to determine whether accepted outputs remain appropriate.

For higher-consequence actions, test the proposed default in a non-executing environment first. Do not relax an established safety boundary merely to measure whether it increases clicks.

Frequently asked questions

Should AI features always require approval? No. Generating private options may need no additional gate. Actions that affect other people, money or permissions usually need stronger authorization. Match the gate to the consequence, not to the presence of AI.

Should defaults become more automated as users gain experience? Only with explicit permission for a defined task scope. Repeated acceptance does not establish consent for broader access or new external actions.

How do you distinguish a bad default from poor output quality? Compare the user’s expected context, action and destination with what happened. If those match but the result fails the task, investigate quality. If they differ, the starting behavior needs attention.

Make one default decision this week

Choose the earliest point where users abandon or blindly accept output. Write down the current default, the user’s likely expectation and the consequence of a mismatch. Specify one alternative and its acceptance test.

If the failure is still unclear, use the free AI adoption Triage tool to start with the symptom. For a deeper working process, the AI Product Adoption Deck provides 12 diagnostics, 80 action cards across 10 stacks and 12 workshops with fillable deliverables.

The immediate deliverable is a testable decision about what happens when the user changes nothing.