L6.01.1reason-aided predictabilitydesignresearch

Reasons raise predictability and acceptance

Aliases: recommendation justification · explanation acceptance · why-this

What it is

The extra line under a recommended track — “because you played Blue Train” — is not a click slogan. It changes whether the user can anticipate what the next item will roughly be. Reason-aided predictability is the effect of a reason that points at a concrete basis: the system becomes a rule the person can mentally simulate, and the item is then treated as a legitimate suggestion rather than noise.

Acceptance here means “I grant that this was aimed at me.” It does not mean “I was persuaded to open it.” Opening is a different decision.

Why it happens

People keep an internal model of what the system will do next. Without a reason, the model has only position and artwork to work with, and one miss turns the list into noise. With a reason, the user can run a conditional: if the basis is recent hard bop, the next title should land nearby. Hits on that prediction lower the “is this random?” alarm; acceptance follows the drop in alarm.

The same rule has to hold on the third item and the tenth, or it will not be stored. A one-off elegant sentence does not buy the next prediction. Predictability is trust in a rule, not liking of a caption.

Studying it

Hold the ranking fixed. Show it with reasons or without. Measure how accurately people forecast the type of the next item, whether they treat an item as aimed at them, and whether open/skip matches self-rated relevance. Independent variables: presence of a reason, whether the cited feature is one the user can recognise, list length. Dependent variables: forecast hits, acceptance as a legitimate suggestion, decision time.

Click-through is a bad proxy for acceptance. Position, cover, and title move clicks. Ask separately whether the person thinks the system will reuse the same rule. Faithfulness, post-hoc invention, and boilerplate phrasing are not this question.

Where it stops holding

Closed tasks (next bus, captcha, in-stock or not) do not need reasons to become predictable; the rule is already public. In high-stakes choices, raising acceptance can be the hazard — acceptance arrives before verification. New users have no history to cite; an empty reason wrecks predictability rather than helping it. This entry only argues that a concrete basis makes the rule simulable. It does not require a reason on every row, and it does not treat tracking unease.

Applying it

  • Put a reusable rule beside the item, not a compliment. “Because you have been playing hard bop” supports a forecast; “picked for you” does not.
  • Reasons on one screen should point at the same kind of basis, so the user can check across items. Three hard-bop reasons plus a pop hit bankrupts the forecast immediately.
  • Check: hide cover and title, leave only the reason, ask people to guess the type of the next item. Hit rate should beat a no-reason control. Then ask “was this aimed at you?” — acceptance should rise with forecast hits, not with clicks.

Related

  • Same group: L6.01.2 Reasons must faithfully reflect the ranking basis · L6.01.3 A generic reason is no reason
  • Nearby: L6.07 Presenting Recommendation Reasons · L5.01 Types of Explainability · L5.05 The Moderation Principle of Transparency
  • Search terms: reason-aided predictability · recommendation justification · explanation acceptance

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/L6.01.1