Skip to content
UX Atlas
Case studyCraft conventionAdvanced

Designing an AI Suggestion Feature People Would Use

An accurate suggestion feature went unused until it explained itself and became easy to reject.

Definition

A decision case about AI features: how presentation and reversibility mattered more than model quality for adoption.

Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.

A composite scenario assembled from situations that recur across teams. It is written to teach reasoning rather than to report on a named company, and outcomes are stated directionally rather than as invented measurements.

Problem

A suggestion feature with good measured accuracy had very low acceptance. Users either ignored it or turned it off.

Context

A professional writing tool where the feature proposed edits to the user's text. Suggestions appeared automatically as the user typed, applied on a single click, with no explanation.

Constraints

  • The model could not explain its reasoning in detail, only indicate the category of suggestion.
  • Accuracy was good but not perfect, and errors were sometimes confidently wrong.
  • The audience were professionals whose text carried their name.
  • Latency meant suggestions arrived a second or two after the relevant text was typed.

Decision

Show the suggestion category and a one-line reason, require an explicit accept, make rejection a single obvious action that also suppresses similar suggestions, and never modify text without acceptance. Move suggestions from as-you-type to on-request or at a natural pause.

Rationale

The barrier was not accuracy but accountability. A professional publishing under their own name will not accept an unexplained change to their words. Explaining the category converted the suggestion from an instruction into an argument the user could evaluate. Making rejection cheap and consequential, by suppressing similar suggestions, gave users control over the feature rather than only over each instance.

Evidence used

  • Acceptance rate by suggestion category, which varied enormously and showed users were discriminating rather than ignoring.
  • Interviews in which participants described not knowing why a change was proposed.
  • Observation that interruption while composing was itself a reason for dismissal.
  • Comparison of acceptance before and after the explanation was added.

Trade-offs accepted

  • Explanations take space and are sometimes obvious, which adds visual noise for easy cases.
  • Requiring explicit acceptance means more interactions for users who trust the feature.
  • Suppressing similar suggestions reduces total suggestions shown, which looked worse on a usage metric.

Outcome

Acceptance rose substantially with no change to the model. Opt-out fell. Users described the feature as an assistant rather than as interference, which was the intended relationship from the start.

Alternatives considered

Improve model accuracy first

Why not: Accuracy was already good, and the interviews showed the barrier was explanation and control rather than correctness.

Apply suggestions automatically with undo

Why not: Acceptable for low-stakes reversible actions. Not acceptable for changing someone's professional writing without asking.

Batch all suggestions into a review at the end

Why not: Added later as an option and useful for some workflows, but it removes the in-context benefit for users who want it while writing.

Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.

Applies when you are designing

Concepts behind this decision

What the reasoning in this case rests on.