UX Patterns Guide
UI + UX Collaboration And Social Interaction established

Activity feed

Provide a typed activity feed with actor-verb-object event anatomy, source and timestamp, meaningful preview, filters, unread or clear behavior, grouping, deep links, retention limits, and boundaries that route conversations, audit evidence, notifications, and live status to the right surfaces.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users need to catch up on recent collaboration, app, repository, channel, project, meeting, reminder, or task activity.
  • The product can represent activity as actor-verb-object events with source, timestamp, preview, type, and destination.
  • Users need filters, clear or read state, grouping, custom views, or direct action from recent work activity.
  • The feed complements notifications, comments, audit logs, and timelines without replacing their stronger lifecycle guarantees.

Avoid when

  • The surface is primarily content consumption, media browsing, or article-like stream reading.
  • Users need legal, compliance, security, or operational evidence with export and retention guarantees.
  • The item requires urgent current-task interruption or blocking inline status.
  • The surface is a bounded object history for one case or workflow.
  • The product cannot deep-link to the source work or keep feed state synchronized with notification and object state.

Problem it prevents

Teams need a lightweight way to catch up on what happened, but products often blur activity feeds with broad content feeds, notification inboxes, audit logs, timelines, and live presence streams, causing noisy, unactionable, or misleading activity surfaces.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Activity feed in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

Events may come from people, channels, repositories, projects, tasks, apps, bots, automations, meetings, reminders, comments, mentions, reactions, shares, merges, deployments, assignments, or approvals.

Pattern promise

Provide a typed activity feed with actor-verb-object event anatomy, source and timestamp, meaningful preview, filters, unread or clear behavior, grouping, deep links, retention limits, and boundaries that route conversations, audit evidence, notifications, and live status to the right surfaces.

Required state

Default feed state with actor, verb, object, timestamp, source, type icon, preview, scope, and destination for each activity item.

Recovery path

A user opens an activity item and lands on the wrong message, repository, task, or app page.

Access contract

Give the activity feed a heading and expose the current filter, layout, and unread or cleared state in text.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A team activity feed shows Priya mentioned you in #refunds, Build bot marked release-128 failed, Maya reacted to your handoff note, and Rahul merged PR #742, each with icon, timestamp, preview, type filter, and Open action.
  • An organization repository feed shows who opened, closed, merged, commented, pushed, or released, grouped by repository and filtered to issues, pull requests, branches, releases, comments, or pushes.
  • A user filters Activity to mentions and replies, answers one thread inline, clears low-value reactions, saves a custom view for VIPs, and opens a deployment failure in the source app.
  • A developer opens an organization activity feed, filters to pull-request activity, sees who merged and commented, and jumps to the relevant repository without using the audit log.
Weak implementation

Vague, hidden, hard to recover from

  • A page titled Activity shows Update happened cards with no actor, object, type, timestamp, or destination.
  • A feed includes every presence heartbeat and typing event, making mentions and failed deployment events impossible to find.
  • A user clears a notification in Activity but the notification center badge stays out of sync and the same event reappears as unread.
  • A compliance analyst exports an activity feed expecting audit proof, but it lacks immutable event IDs, IP addresses, retention policy, and complete actor data.
UI guidance
  • Render activity feed as a typed event stream where each item names the actor or source app, action, object, workspace or channel, timestamp, preview, event type, read or cleared state when supported, and a stable destination for follow-up.
  • Expose activity-type filters, unread or cleared state, dense and detailed layouts, grouped repeated events, retention or expiry limits, notification settings, and suppressed/noisy-source controls instead of treating all work events as identical feed cards.
UX guidance
  • Use activity feed when users need to catch up on recent work or collaboration activity across channels, projects, repositories, tasks, apps, or people without opening every underlying object.
  • Protect attention by grouping low-value repetition, preserving meaningful actors and destinations, distinguishing mention/reply/reaction/app/reminder/project-change types, and routing audit evidence, long-form content, and live status elsewhere.
Implementation contract

What the implementation must handle

States

  • Default feed state with actor, verb, object, timestamp, source, type icon, preview, scope, and destination for each activity item.
  • Unread, read, cleared, selected, replied, opened, muted, hidden, grouped, collapsed, and expanded item states.
  • Filters for all activity, unread, mentions, replies, reactions, channel or project activity, app events, reminders, repository events, and cleared items where supported.
  • Dense layout, detailed layout, custom saved view, and mobile compact states.

Interaction

  • Each item represents one meaningful work activity or a grouped set with stable actor, action, object, source, timestamp, type, preview, scope, and destination.
  • Opening an activity routes to the underlying channel, message, thread, repository, task, meeting, app, file, or object and updates read or cleared state according to product policy.
  • Reply, clear, mark read, set reminder, mute, and open-source actions apply to the named activity item or group only.
  • Filters change visible items without deleting events; clear and mark-read actions provide immediate feedback and preserve recoverability where supported.

Accessibility

  • Give the activity feed a heading and expose the current filter, layout, and unread or cleared state in text.
  • Name each item with actor, verb, object, source, timestamp, and type so screen-reader users can decide whether to open it.
  • Do not rely on activity icons or avatar color alone to communicate mention, reply, reaction, app, reminder, repository, or meeting types.
  • Make filters, layout toggles, reply, clear, mark-read, mute, reminder, open-source, and saved-view controls keyboard reachable.

Review

  • What events are meaningful enough for catch-up, and which belong only in audit logs, notifications, comments, or live presence?
  • Can users tell who did what, to which object, in which source, and when?
  • Which activity types can users filter, clear, mark read, mute, or save as views?
  • What happens when the user opens the underlying object from another route?
Evidence trail

Source-backed claims behind this guidance

WAI-ARIA APG: Feed Pattern

W3C Web Accessibility Initiative - checked

WAI-ARIA APG defines feed behavior for dynamically loaded article content, useful for accessible activity stream reading when article-like semantics apply.

Full agent/debug reference

Problem Context

  • Events may come from people, channels, repositories, projects, tasks, apps, bots, automations, meetings, reminders, comments, mentions, reactions, shares, merges, deployments, assignments, or approvals.
  • Users open the feed to catch up, triage, scan, reply, clear, mark read, filter, jump to source objects, or personalize which activity types deserve attention.
  • Events may be personal to the user, workspace-wide, organization-scoped, repository-scoped, channel-scoped, object-scoped, or app-generated.
  • The surface may overlap with notification center, feed, timeline, activity log, comments, mentions, presence, and following/subscription behavior, so event ownership and lifecycle rules must be explicit.

Selection Rules

  • Choose activity feed when the primary task is catching up on recent collaboration or system activity across work objects rather than reading broad content or managing audit evidence.
  • Use feed when the stream is primarily article-like posts, stories, media, recommendations, or content consumption.
  • Use notification center when the item lifecycle depends on unseen badges, unread state, mark-read, preferences, cleanup, and retained notification history.
  • Use activity log when users need searchable, exportable, retained evidence of actor/action/object records with compliance or investigation detail.
  • Use timeline when the user needs a bounded chronological history for one case, process, project, object, or order.
  • Use comments, mentions, and threaded discussion for the underlying conversation; activity feed should preview and route to them rather than becoming the conversation system.
  • Use presence for current online, viewing, typing, or availability state; only surface presence in activity feed when it becomes a meaningful event such as joined, assigned, or started presenting.
  • Include actor, verb, object, source, timestamp, event type, preview, scope, and destination before adding visual density or ranking controls.
  • Offer filters for meaningful activity types such as unread, mentions, replies, reactions, channel activity, app events, reminders, repository events, and cleared items.
  • Suppress, group, or collapse noisy repeated events such as many reactions, automated sync churn, duplicate app posts, cursor movement, and frequent status changes.

Required States

  • Default feed state with actor, verb, object, timestamp, source, type icon, preview, scope, and destination for each activity item.
  • Unread, read, cleared, selected, replied, opened, muted, hidden, grouped, collapsed, and expanded item states.
  • Filters for all activity, unread, mentions, replies, reactions, channel or project activity, app events, reminders, repository events, and cleared items where supported.
  • Dense layout, detailed layout, custom saved view, and mobile compact states.
  • New activity waiting, live refresh paused, refresh failed, stale feed, offline, loading, empty, no matching filter, and retention-expired states.
  • Inline reply, open in source, set reminder, mute thread, turn off noisy type, mark all read, clear one, clear selected, and restore cleared states.
  • Grouped repeated activity, bot activity, external app activity, VIP or priority activity, private/no-disclosure activity, and permission-limited activity states.
  • Synchronization state with notification center so cleared, read, and opened events do not contradict the badge or inbox.
  • Responsive state where actor, verb, object, type, timestamp, and action destination remain readable.

Interaction Contract

  • Each item represents one meaningful work activity or a grouped set with stable actor, action, object, source, timestamp, type, preview, scope, and destination.
  • Opening an activity routes to the underlying channel, message, thread, repository, task, meeting, app, file, or object and updates read or cleared state according to product policy.
  • Reply, clear, mark read, set reminder, mute, and open-source actions apply to the named activity item or group only.
  • Filters change visible items without deleting events; clear and mark-read actions provide immediate feedback and preserve recoverability where supported.
  • Dense and detailed layouts preserve the same activity identity and actions, only changing how much preview context is shown.
  • Saved views preserve filter combinations and do not silently change notification eligibility or underlying subscription settings.
  • Activity feed state synchronizes with notification center, mention surfaces, thread views, and related-object state when the same event appears in multiple places.
  • No-disclosure and permission-limited events hide restricted object names, previews, or actors while still explaining why the item cannot be opened.

Implementation Checklist

  • Define event schema for actor, actor type, verb, object, object type, source app, workspace, channel or project, timestamp, event type, preview, destination URL, read state, clear state, priority, grouping key, and retention.
  • Separate activity-feed records from notification records, audit-log records, timeline milestones, comments, mentions, reactions, presence heartbeats, and broad content feed items in the data model.
  • Build activity-type filters, unread filter, cleared filter, source filter, custom saved views, dense/detail toggle, mark-read, clear, bulk clear, inline reply, reminder, mute, and open-source actions.
  • Group repeated reactions, bot updates, deployment churn, bulk repository events, and high-volume channel posts without hiding high-priority mentions or failures.
  • Model retention and expiry, stale feed refresh, offline fallback, permission-limited destinations, deleted objects, private channels, blocked users, and external app failures.
  • Synchronize activity state with notification center, thread views, mentions, related object pages, and preferences so items do not reappear unexpectedly.
  • Test mobile compact layout, keyboard navigation, screen-reader item names, long actor names, localization of actor-verb-object text, grouped event expansion, filter empty states, and deep-link return behavior.

Common Generated-UI Mistakes

  • Using activity feed as an audit log without evidence fields, export, or retention guarantees.
  • Using activity feed as a notification center without clear unread, badge, preference, or cleanup semantics.
  • Dumping every low-level system event, presence update, typing event, or cursor movement into the feed.
  • Hiding actor, object, event type, source app, or timestamp until users open the item.
  • Making clear, reply, or mute actions affect a thread or channel different from the visible item.
  • Mixing algorithmic content recommendations with work events without labels.
  • Letting private or permission-limited activity reveal object titles, channel names, or actors.
  • Providing filters that only hide items visually while badge and saved-view state still count them.

Critique Questions

  • What events are meaningful enough for catch-up, and which belong only in audit logs, notifications, comments, or live presence?
  • Can users tell who did what, to which object, in which source, and when?
  • Which activity types can users filter, clear, mark read, mute, or save as views?
  • What happens when the user opens the underlying object from another route?
  • How are repeated reactions, bot events, deployment churn, and noisy app updates grouped or suppressed?
  • Which items expire from the activity feed, and where can users find durable evidence afterward?
  • How are permission-limited or private-channel events represented without leaking restricted context?
Accessibility
  • Give the activity feed a heading and expose the current filter, layout, and unread or cleared state in text.
  • Name each item with actor, verb, object, source, timestamp, and type so screen-reader users can decide whether to open it.
  • Do not rely on activity icons or avatar color alone to communicate mention, reply, reaction, app, reminder, repository, or meeting types.
  • Make filters, layout toggles, reply, clear, mark-read, mute, reminder, open-source, and saved-view controls keyboard reachable.
  • Announce new activity, mark-read, clear, filter result count, grouped expansion, and failed refresh through polite status messaging.
  • Avoid moving focus when activity arrives; provide a reachable new-activity or refresh control.
  • For grouped items, expose group count and expansion state programmatically.
Keyboard Behavior
  • Tab order moves through feed filters, layout or saved-view controls, activity items, item actions, bulk actions, and settings in a predictable order.
  • Enter opens the selected activity's source destination; Space activates buttons such as clear, mark read, mute, or expand group.
  • Opening inline reply moves focus to the reply editor and Escape returns focus to the activity item.
  • Changing filters or saved views keeps focus on the changed control and announces result count.
  • Clearing an item moves focus to the next visible activity or the empty-state summary.
  • Bulk selection exposes selected count and keeps bulk actions reachable without requiring pointer hover.
  • Keyboard users can switch between dense and detailed layouts without losing the current item.
Variants
  • Team activity feed
  • Workspace activity feed
  • Organization news feed
  • Repository activity feed
  • Project activity feed
  • Channel activity feed
  • Personal activity view
  • Mention and reply activity
  • App activity feed
  • Dense activity layout
  • Detailed activity layout
  • Custom activity view

Verification

Source trail checked:

Saved items