UX Patterns Guide

Decision guide · Collaboration And Social Interaction

Activity feed UX: catch-up, notifications, and audit history

By UX Patterns GuideWorked decision updated Editorial method

Use the feed to make recent changes understandable and actionable. Define unread and clearing behavior when attention management is part of the task, and provide a separate evidence contract when someone needs an audit trail.

Try the live example →Compare alternatives →

Worked decision · constructed example

Is the person catching up, managing attention, or investigating evidence?

A release reviewer returns after an hour away. The stream includes a failed build, a mention requesting review, a handoff reply, and repeated reactions. The reviewer needs to find the failed run and the decision requiring attention, rather than inspect every reaction individually.

Try Activity feed →Try Activity log →Try Notification center →
An event needs context and a destination
Feed itemUseful presentationPromise to keep explicit
Build bot marked release-128 failedShow the release scope, event time, and an Open run destination.The item routes to the actual failed run rather than a generic project page.
A teammate requested reviewShow who asked, what needs review, and enough preview to decide the next action.Opening, marking read, and resolving the underlying request can be different states.
Repeated reactionsGroup related noise while retaining a way to inspect relevant detail.Grouping must not conceal the event that changes the review decision.
Cleared activityExplain what clearing changes in this feed.Clearing attention items must not imply deletion of the underlying work or audit record.

Why this choice

A timestamped list is not automatically an audit log. Evidence work needs stated retention, completeness, access, and export behavior. Conversely, a lightweight catch-up surface can be useful without making those guarantees.

Where the decision changes

Products combine feed and notification behavior. Microsoft Teams is one example, not a universal taxonomy. Decide which promises your surface makes, especially around unread counts, clearing, retention, and deep-link access.

Try these checks

  1. Find a mention, a failed run, and a handoff from the stream.
  2. Follow each destination and confirm its object and scope.
  3. Group reactions and verify that important events remain findable.
  4. Clear an item and inspect the distinction between feed state and the underlying record.

What the sources support

These source claims were checked on . The scenario and decision analysis are illustrative; the checks are a test plan, not reported results from a user study.

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.

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.

Problem it prevents

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

Test the behavior

Try strong and weak versions of the interaction

Open the working example, try its controls, and compare the behavior against the decision guidance.

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.

Failure to inspect

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.
Weak implementation

Vague, hidden, hard to recover from

  • 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.
  • A user opens an activity item and lands on the wrong message, repository, task, or app page.
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.
  • Dense and detailed layouts preserve the same activity identity and actions, only changing how much preview context is shown.

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.
  • 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.

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