Recommendations

Problem Context

• The product has enough content, products, records, services, or actions that manually browsing every option is inefficient.
• The system has useful signals such as current item context, similar-item attributes, aggregate behavior, purchases, saved items, search activity, editorial rules, or user feedback.
• Recommendations can affect user trust, privacy, commercial outcomes, safety, fairness, or task completion, so users need to understand and control what is being suggested.

Selection Rules

• Choose recommendations when the system ranks a small set of likely useful items from behavior, context, similarity, popularity, rules, or model output.
• Use related links instead when the current page only needs a curated, maintained set of onward destinations and no ranking or personalization is involved.
• Use recently viewed instead when the list should contain only items the current user actually opened, ordered by recency.
• Use browse by category instead when users need to inspect a stable taxonomy and choose their own path.
• Show a reason for each recommendation, such as Because you saved this, Frequently bought together, Similar to this product, Trending in this category, or Curated by editors.
• Provide item-level feedback such as Not interested, Don't recommend this source, hide, remove, or tell us why, and make the immediate effect visible.
• Expose personalization scope and controls when recommendations use watch history, search history, saved items, purchases, account activity, location, team behavior, or other personal data.
• Label sponsored, promoted, manually selected, editorial, and model-generated recommendations separately before the click.
• Use cold-start fallbacks honestly, such as popular, trending, category-based, or editorial picks, instead of fabricating personalized explanations.
• Filter or mark unavailable, out-of-stock, permission-restricted, already completed, already in cart, already saved, duplicate, stale, and repeatedly dismissed items.
• Cap repetition, diversify the set, and avoid sensitive or protected-attribute inferences unless the product has an explicit, user-benefiting, compliant reason.
• Measure recommendation quality with user outcomes, feedback, availability, diversity, and trust, not only impressions or clicks.

Required States

• Default recommended state with labelled section, item identity, reason, source, and action controls.
• Personalized state that identifies the activity or preference category used without exposing private raw history unnecessarily.
• Generic or cold-start fallback state labelled as popular, trending, category-based, or editorial.
• Dismissed or Not interested state that removes the item and confirms the feedback effect.
• Feedback reason state for already watched, not relevant, don't like this source, duplicate, sensitive, or wrong category.
• Sponsored or promoted state with visible disclosure separate from organic recommendations.
• Manual or editorial recommendation state when a human has pinned, selected, or overridden model output.
• Unavailable or filtered state for out-of-stock, permission-lost, completed, already-in-cart, stale, or unsafe items.
• Personalization off or reset state that stops using selected activity and explains what fallback remains.

Interaction Contract

• Opening a recommendation navigates to that item or action and records the event according to the disclosed analytics and personalization rules.
• Dismissing a recommendation hides that item immediately from the current set and updates future ranking or feedback data within the stated scope.
• Feedback controls affect recommendation behavior only; they do not delete the underlying item, saved item, or recently viewed history unless that action is separately labelled.
• Turning off personalization stops using the selected activity source and switches to a clearly labelled generic or editorial fallback.
• Reason labels must match the actual source of the recommendation and must update when personalization, category, cart, current item, or availability changes.
• Sponsored or promoted recommendations remain distinguishable even when they are also relevant.
• The system must not reinsert dismissed, unavailable, permission-restricted, or sensitive recommendations as if they were new suggestions.

Implementation Checklist

• Define the recommendation source for each slot: current item similarity, frequently bought together, trending, saved-item affinity, user activity, editorial rule, sponsored placement, or fallback.
• Store enough metadata to explain each recommended item in user-facing language without revealing private raw history or unsupported model claims.
• Apply eligibility filters before rendering for availability, permissions, stock, price, cart membership, completion state, safety, duplication, and policy restrictions.
• Add item-level dismissal, feedback reasons, and source-level suppression where users naturally need control.
• Provide personalization settings for the activity sources the recommendation system uses, including reset, history deletion, or turning history off when supported.
• Design cold-start and low-confidence states with honest labels and enough quality guardrails to avoid empty or fake personalized rails.
• Separate generated, manual, editorial, sponsored, and promoted items in the data model so the UI can disclose them consistently.
• Limit count, repetition, and carousel depth; avoid auto-advancing rails that hide feedback controls.
• Log recommendation impressions, opens, dismissals, source labels, availability filters, and feedback outcomes so quality can be audited beyond click rate.
• Test signed-out, new-user, returning-user, personalization-off, dismissed-item, unavailable-item, sponsored, sensitive-topic, and mobile keyboard states.

Common Generated-UI Mistakes

• Counting schema-valid recommendation cards as complete without reasons, controls, or source disclosure.
• Calling promoted or sponsored content recommended without visible disclosure.
• Pretending generated suggestions are recently viewed, saved, or required steps.
• Using vague labels such as For you or You might like without explaining the basis.
• Ignoring dismissals and repeatedly showing the same item under new wording.
• Using personal data for recommendations without a visible control surface.
• Showing stale, unavailable, out-of-stock, permission-restricted, or already completed items.
• Optimizing only for clicks and creating repetitive, sensational, or narrow recommendation loops.

Critique Questions

• What exact signal or rule caused this item to be recommended?
• Can users tell whether the item is organic, sponsored, manual, editorial, personalized, trending, or fallback?
• What happens when the user says Not interested, and how quickly does the list change?
• Can users turn off or reset the activity source used for personalization?
• How are cold-start users handled without fake personalized copy?
• Which unavailable, sensitive, duplicate, completed, or repeatedly dismissed items are filtered before rendering?
• Is this really a recommendation, or would related links, recently viewed, saved items, or browse by category be more honest?