UX Patterns Guide
UI + UX Personalization And Preference established

Pinned items

Provide a bounded pinned-items area with explicit pin and unpin controls, stable order, item identity, pin scope, reorder or replace paths, limit handling, permission states, and recovery messaging that does not delete the underlying item.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users need stable quick access to a small set of known high-priority objects.
  • Workspace owners need to highlight a few important files, folders, links, repositories, records, or profile items.
  • The product can persist pin order and scope separately from the underlying item.
  • Pinned prominence is useful enough to justify limits, permissions, and stale-item handling.

Avoid when

  • The item list should be automatic history, popularity, recommendation, or search ranking.
  • Users only need to express preference or liking without changing placement.
  • The surface cannot explain who sees the pin or who can change it.
  • There is no meaningful limit or ordering, causing pins to lose prominence.
  • The item is too sensitive to expose in a shared, public, or synced pinned section.

Problem it prevents

Users repeatedly need a few important items to stay easy to reach or visible to an audience, but automatic recency, broad favorites, and search results move those items around or hide whether prominence is personal, shared, or public.

Pattern anatomy

What a strong implementation has to make clear

User need

The product has many revisitable objects such as files, folders, repositories, gists, records, reports, channels, dashboards, or project links.

Pattern promise

Provide a bounded pinned-items area with explicit pin and unpin controls, stable order, item identity, pin scope, reorder or replace paths, limit handling, permission states, and recovery messaging that does not delete the underlying item.

Required state

No pinned items state with a path to pin an eligible item.

Recovery path

Pinned items are indistinguishable from favorites or recently viewed items.

Access contract

Use text and accessible state for Pin, Pinned, Unpin, Move earlier, Move later, and Replace actions instead of relying on a pushpin icon alone.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A document library has a Pinned section at the top with three highlighted files, each showing file name, type, modified date, owner, Move left, Move right, and Unpin actions.
  • A developer profile lets the owner choose up to six repositories or gists to pin, previews the public Pinned section, and distinguishes public profile pins from private favorites.
  • A manager pins the Quarterly review folder, moves it before the Benefits checklist, sees the three-item limit, and can unpin it without deleting the folder.
  • A profile owner selects public projects to pin, previews how visitors will see them, and replaces a stale pinned repository with a newer gist.
Weak implementation

Vague, hidden, hard to recover from

  • A pin icon appears on cards with no selected state, no top section, no limit, and no explanation of whether the pin is personal or public.
  • Pinned files, recent files, favorite files, and subscribed files are mixed in one list labelled Important with no way to predict what unpinning affects.
  • A user unpins a file and thinks it was deleted because the item disappears with no status message or recovery path.
  • A team pin can be reordered by anyone, so shared navigation changes unexpectedly for every teammate.
UI guidance
  • Render pinned items in a clearly labelled section, top zone, or fixed order with item identity, type, owner or scope, pin state, and an unpin path visible near each item.
  • When users can edit pins, show pin limit, order controls, add or replace choices, policy-locked pins, and whether the pin is personal, team, public profile, or shared workspace state.
UX guidance
  • Use pinned items when users or workspace owners deliberately keep a small set of high-priority objects, files, links, repositories, records, or widgets easy to return to.
  • Keep pinned items separate from recently viewed, favorites, saved views, subscriptions, and recommendations because a pin changes placement or prominence rather than history, liking, saved criteria, or future update delivery.
Implementation contract

What the implementation must handle

States

  • No pinned items state with a path to pin an eligible item.
  • Pinned section with item identity, type, scope, position, and unpin controls.
  • Pin available, pinned, unpin pending, unpinned, reorder, and replace-at-limit states.
  • Personal pin, shared pin, public profile pin, inherited pin, and policy-locked pin states.

Interaction

  • Pinning creates a durable placement or prominence record for the selected item without duplicating or changing the underlying item.
  • Unpinning removes only the pin relationship and leaves the underlying item, favorite state, recent history, and subscriptions intact.
  • Pinned items stay in the declared section or order until the user, owner, or policy changes them.
  • Reordering pinned items updates visible order, keyboard order, and mobile order together.

Accessibility

  • Use text and accessible state for Pin, Pinned, Unpin, Move earlier, Move later, and Replace actions instead of relying on a pushpin icon alone.
  • Expose pinned section scope and item count in the heading or region label.
  • Keep visible order, DOM order, and screen-reader order aligned after reordering.
  • Announce pin, unpin, move, replace, limit-reached, failed-save, and unavailable-item outcomes through a stable status region.

Review

  • What placement, order, or audience changes when this item is pinned?
  • Is the pin personal, shared, public, inherited, admin-managed, or policy locked?
  • Can users unpin without deleting, unfavoriting, unsubscribing, or removing recent history?
  • What is the maximum useful number of pinned items for this surface?
Interactive lab

Inspect the states before you copy the pattern

Keep selected items prominent

Pin and unpin items, reorder the pinned section, hit the pin limit, switch personal and shared scope, repair stale pins, and compare mixed-recents, delete-confusion, shared-surprise, unlimited-pins, drag-only, stale-dead-link, and privacy-leak failures.

Pinned items
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

No pinned items state with a path to pin an eligible item.

Keyboard / Access

Tab reaches each pinned item, its primary link, pin state control, reorder controls, and replace or remove actions in order.

Avoid Generating

Using a pin icon as a favorite without changing placement or explaining selected state.
Evidence trail

Source-backed claims behind this guidance

Microsoft Office Recently Used Files

Microsoft Support - checked

Microsoft Office recent-files guidance helps distinguish automatic recent lists from deliberate pinned or favorite access.

Full agent/debug reference

Problem Context

  • The product has many revisitable objects such as files, folders, repositories, gists, records, reports, channels, dashboards, or project links.
  • Users or owners need a small set to remain visible even as recents, search results, or activity order changes.
  • Pinned state may be personal, team-owned, public-profile, admin-managed, or policy-locked.
  • A pin may control placement in a list, a top section, a profile showcase, a sidebar, a workspace home, or a document library.
  • Pinned items can become deleted, moved, inaccessible, stale, over limit, duplicated, or controlled by someone else.

Selection Rules

  • Choose pinned items when the user intentionally keeps a small set of known objects in a stable prominent position.
  • Use recently viewed when the list should be automatic personal history ordered by what the user opened most recently.
  • Use favorites when the user marks affinity or saved preference without necessarily changing item placement or order.
  • Use saved view when the saved object is a reusable presentation or criteria state for one data surface.
  • Use follow / subscribe when the user's intent is future update delivery rather than quick return access.
  • Use custom dashboard when users arrange multiple widgets on a canvas rather than pinning individual objects or shortcuts.
  • Expose whether a pin is personal, shared, public, admin-managed, or inherited before users add, remove, or reorder it.
  • Cap pinned items to preserve scan speed and provide replace or reorder choices when the cap is reached.
  • Keep unpin distinct from delete, archive, hide, unfavorite, unsubscribe, and remove-from-recent-history actions.
  • Avoid pinned items when the item set is dynamic, unknown, recommended by an algorithm, or too large to remain meaningfully prominent.

Required States

  • No pinned items state with a path to pin an eligible item.
  • Pinned section with item identity, type, scope, position, and unpin controls.
  • Pin available, pinned, unpin pending, unpinned, reorder, and replace-at-limit states.
  • Personal pin, shared pin, public profile pin, inherited pin, and policy-locked pin states.
  • Pinned item deleted, moved, permission-lost, stale, duplicate, and inaccessible states.
  • Mobile or narrow-screen state where pinned identity, order, and unpin actions remain reachable.

Interaction Contract

  • Pinning creates a durable placement or prominence record for the selected item without duplicating or changing the underlying item.
  • Unpinning removes only the pin relationship and leaves the underlying item, favorite state, recent history, and subscriptions intact.
  • Pinned items stay in the declared section or order until the user, owner, or policy changes them.
  • Reordering pinned items updates visible order, keyboard order, and mobile order together.
  • When the pin limit is reached, the UI asks users to unpin, replace, or reorder instead of silently dropping an existing pin.
  • Shared or public pins require ownership, permission, and audience cues before the pin is changed.
  • Deleted, moved, or permission-lost pinned items remain explainable with remove, replace, or request-access paths.
  • Pin state is announced and reversible from the item context and from the pinned list.

Implementation Checklist

  • Define the pin model with item ID, item type, owner, scope, position, pinned by, pinned time, policy lock, and visibility audience.
  • Separate pin state from favorite state, recent history, saved view criteria, subscription state, and item deletion.
  • Show pin and unpin controls with accessible pressed state or status text wherever pinning is available.
  • Provide move earlier, move later, replace, unpin, restore, and limit-reached handling for pinned sections.
  • Validate permissions and visibility before exposing shared, team, public profile, or admin-managed pins.
  • Refresh pinned item metadata and mark deleted, moved, permission-lost, stale, or unavailable items before navigation.
  • Test keyboard reordering, mobile stacking, long names, duplicate item names, pin limit, failed pin saves, and shared-scope conflicts.

Common Generated-UI Mistakes

  • Using a pin icon as a favorite without changing placement or explaining selected state.
  • Mixing pinned items with automatic recents, favorites, saved searches, subscriptions, and recommendations in one ambiguous list.
  • Letting unpin delete or hide the underlying item.
  • Allowing unlimited pins until the pinned section becomes another noisy list.
  • Changing shared or public pins without owner, audience, permission, or rollback cues.
  • Providing drag-only reorder with no keyboard move controls.
  • Letting stale or inaccessible pinned items become dead links.

Critique Questions

  • What placement, order, or audience changes when this item is pinned?
  • Is the pin personal, shared, public, inherited, admin-managed, or policy locked?
  • Can users unpin without deleting, unfavoriting, unsubscribing, or removing recent history?
  • What is the maximum useful number of pinned items for this surface?
  • How can users reorder pins by keyboard and understand mobile order?
  • What happens when a pinned item is deleted, moved, renamed, archived, or no longer accessible?
Accessibility
  • Use text and accessible state for Pin, Pinned, Unpin, Move earlier, Move later, and Replace actions instead of relying on a pushpin icon alone.
  • Expose pinned section scope and item count in the heading or region label.
  • Keep visible order, DOM order, and screen-reader order aligned after reordering.
  • Announce pin, unpin, move, replace, limit-reached, failed-save, and unavailable-item outcomes through a stable status region.
  • Include item type and location when names are similar so users do not open or unpin the wrong item.
  • Do not use color alone to distinguish personal, shared, public, inherited, or locked pins.
Keyboard Behavior
  • Tab reaches each pinned item, its primary link, pin state control, reorder controls, and replace or remove actions in order.
  • Enter or Space toggles Pin or Unpin only when the action has no destructive side effects.
  • Move earlier and Move later keep focus on the moved item and announce its new position.
  • When the pin limit is reached, focus moves to the replace or manage-pins choice instead of failing silently.
  • Escape closes pin management menus and returns focus to the invoking item.
  • After unpinning, focus moves to the next pinned item or to the empty pinned-section message.
Variants
  • Personal pinned item
  • Team pinned item
  • Public profile pin
  • Pinned file
  • Pinned folder
  • Pinned repository
  • Pinned shortcut
  • Admin-managed pin
  • Policy-locked pin
  • Pinned item with stale target

Verification

Last verified: