UX Patterns Guide
UI + UX Collaboration And Social Interaction established

Presence

Provide presence badges and co-viewing summaries with explicit status labels, availability hierarchy, recency, source, manual or automatic origin, privacy boundary, unknown and stale states, and action behavior that respects busy, do-not-disturb, offline, and restricted visibility.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users need to understand current or recent availability before messaging, calling, assigning, routing, or joining.
  • A shared object needs to show who is viewing, recently active, hidden, anonymous, or unavailable.
  • Actions should adapt to busy, do-not-disturb, offline, privacy, or stale presence state.
  • Presence can reduce interruption, duplicate work, or uncertainty when paired with clear labels and recovery paths.

Avoid when

  • The product needs a durable audit trail or compliance record.
  • The UI only needs a notification inbox, mention target, assignment owner, or profile identity.
  • Presence cannot be sourced, refreshed, labelled, or privacy-limited reliably.
  • The signal would encourage surveillance, attendance inference, or coercive monitoring rather than collaboration.

Problem it prevents

Collaboration becomes disruptive or misleading when availability is represented as an unexplained dot, stale activity, hidden privacy state, or surveillance-like signal instead of a contextual, fresh, labelled, and action-aware presence indicator.

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 Presence in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

Users are deciding whether to message, call, assign, review, wait, join, follow up, or interpret another person's current availability in a workspace, document, channel, dashboard, issue, or task.

Pattern promise

Provide presence badges and co-viewing summaries with explicit status labels, availability hierarchy, recency, source, manual or automatic origin, privacy boundary, unknown and stale states, and action behavior that respects busy, do-not-disturb, offline, and restricted visibility.

Required state

Available, active, away, busy, in a meeting, in a call, presenting, focusing, do not disturb, out of office, offline, unknown, and hidden states where supported.

Recovery path

Color-only dots make busy, away, offline, and unknown states indistinguishable to some users.

Access contract

Expose presence state as text, such as Dana Lee, Busy in a meeting until 14:30, not just a colored dot.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A reviewer row shows Priya as Busy in a meeting until 14:30, disables Call, keeps Message available, and offers Notify when available.
  • A document header shows three current viewers, one anonymous viewer, last updated recency, and a privacy note explaining that external viewer activity is hidden.
  • A user sees that Dana is in Do not disturb, sends a message without a banner interruption, and schedules a reminder to follow up when Dana is available.
  • A file owner sees who has viewed the document within the same domain, respects hidden view-history settings, and uses the signal for follow-up rather than audit proof.
Weak implementation

Vague, hidden, hard to recover from

  • A green dot appears next to every name with no label, timestamp, or meaning.
  • A stale active badge remains after the user has gone offline and the call button still looks primary.
  • A manager treats Away as an attendance record even though it came from device inactivity and privacy-limited activity data.
  • A co-editing page shows that someone is present but gives no accessible name, role, location, or privacy reason for unknown viewers.
UI guidance
  • Render presence as a labelled availability signal near the person, team, object, or conversation it describes; pair color, shape, text, timestamp, and source so users can distinguish active, away, busy, do not disturb, offline, unknown, viewing, and recently active states.
  • Show presence controls and explanations where users act on the signal: status menu, status duration, last updated time, working-hours note, privacy restriction, stale value, co-viewer list, and action changes such as call disabled, message allowed, or notify later.
UX guidance
  • Use presence when users need to decide whether to interrupt, wait, route work, join a session, assign follow-up, or understand who is currently viewing or recently active in a shared space.
  • Treat presence as a transient, privacy-bounded signal, not a proof of productivity or accountability; expose freshness, source, manual overrides, notification effects, and privacy limits before users rely on it.
Implementation contract

What the implementation must handle

States

  • Available, active, away, busy, in a meeting, in a call, presenting, focusing, do not disturb, out of office, offline, unknown, and hidden states where supported.
  • Manual status, automatic status, status duration, status message, working-hours state, paused-notification state, and calendar-derived state.
  • Fresh, stale, reconnecting, delayed, last-updated, last-seen, and source-unavailable states.
  • Single-person presence, group summary, co-viewer list, anonymous viewer, external viewer hidden, same-domain activity visible, and privacy-restricted states.

Interaction

  • Presence badges identify the person or group, status label, recency, and source in text, not color alone.
  • Selecting or focusing a presence indicator reveals more detail such as status message, last updated time, working-hours note, privacy reason, current object viewers, or action options.
  • Actions that depend on presence respect do-not-disturb, busy, offline, privacy, and priority rules; they explain whether messages, calls, banners, or routing will behave differently.
  • Stale or delayed presence values show last updated time and fallback behavior rather than staying visually equivalent to live status.

Accessibility

  • Expose presence state as text, such as Dana Lee, Busy in a meeting until 14:30, not just a colored dot.
  • Use shape, label, and text detail in addition to color for available, away, busy, do-not-disturb, offline, unknown, and restricted states.
  • Make presence detail reachable by keyboard and touch without hover-only tooltips.
  • Announce meaningful presence changes only when they affect the current task or selected person.

Review

  • What exact person, group, file, channel, task, or object does this presence signal describe?
  • What status is shown in text, and when was it last updated?
  • Is the signal automatic, manual, calendar-derived, device-derived, activity-derived, or co-viewing-derived?
  • What privacy setting, external access rule, or permission boundary controls whether the signal is visible?
Evidence trail

Source-backed claims behind this guidance

Microsoft Graph: presence resource type

Microsoft Learn - checked

Microsoft Graph models presence as availability plus activity, supports change notifications, and exposes values such as available, busy, doNotDisturb, focusing, in a call, in a meeting, offline, presenting, out of office, and unknown.

Google Workspace Help: Let users see file activity

Google Workspace Help - checked

Google Workspace documents file activity visibility, viewer names and view times, edit-access and same-domain limits, follow-up use, privacy controls, and the warning that Activity Dashboard is not an audit record.

Full agent/debug reference

Problem Context

  • Users are deciding whether to message, call, assign, review, wait, join, follow up, or interpret another person's current availability in a workspace, document, channel, dashboard, issue, or task.
  • Presence may be calculated from app activity, device activity, calendar events, active calls, focus time, working hours, manual overrides, notification pause, file views, or current co-viewing sessions.
  • The signal may be delayed, stale, privacy-limited, hidden for external users, unknown, or suppressed by user preference, admin setting, domain boundary, or object permission.
  • Presence may affect actions such as call routing, notification delivery, assignment timing, follow-up reminders, co-editing awareness, and escalation paths, but it is not automatically an audit record.

Selection Rules

  • Choose presence when the user needs a transient availability, co-attendance, last-seen, or active-viewer signal attached to a person, group, file, channel, task, or conversation.
  • Use mentions when the task is to address or notify someone inside authored content; mentions can consult presence but they create an attention event rather than display availability.
  • Use notification center when the user needs retained inbox triage, unread state, preference controls, and notification history across objects.
  • Use activity log when the product must preserve durable evidence of who viewed, changed, routed, or was notified about something.
  • Use comments or threaded discussion when the collaboration unit is authored conversation; presence can show who is reading or available but should not replace conversation state.
  • Use profile setup for stable identity and work details; presence should only show time-bound state, recency, and availability source.
  • Use settings management for configuring status defaults, working hours, privacy visibility, external sharing, and notification behavior.
  • Show restricted, unknown, stale, or hidden presence states instead of guessing when privacy, domain, permission, stale sync, or API limits prevent a reliable signal.

Required States

  • Available, active, away, busy, in a meeting, in a call, presenting, focusing, do not disturb, out of office, offline, unknown, and hidden states where supported.
  • Manual status, automatic status, status duration, status message, working-hours state, paused-notification state, and calendar-derived state.
  • Fresh, stale, reconnecting, delayed, last-updated, last-seen, and source-unavailable states.
  • Single-person presence, group summary, co-viewer list, anonymous viewer, external viewer hidden, same-domain activity visible, and privacy-restricted states.
  • Action-aware states such as call available, call blocked, message allowed, banner suppressed, notify when available, route to next available, and follow-up scheduled.
  • Mobile condensed badge, expanded presence detail, tooltip or popover detail, accessible text label, and screen-reader-only state summary.
  • Permission denied, external access hidden, user view-history hidden, admin privacy mode enabled, and activity-dashboard-not-audit states.
  • Presence conflict, multiple devices, manual override, automatic reset, and presence unknown fallback states.

Interaction Contract

  • Presence badges identify the person or group, status label, recency, and source in text, not color alone.
  • Selecting or focusing a presence indicator reveals more detail such as status message, last updated time, working-hours note, privacy reason, current object viewers, or action options.
  • Actions that depend on presence respect do-not-disturb, busy, offline, privacy, and priority rules; they explain whether messages, calls, banners, or routing will behave differently.
  • Stale or delayed presence values show last updated time and fallback behavior rather than staying visually equivalent to live status.
  • Privacy settings, external access rules, hidden view history, and domain restrictions are honored before showing viewer names, last-seen times, or status details.
  • Presence changes update without moving focus, stealing attention, or rewriting user intent; screen-reader users receive concise state changes only when relevant.
  • If presence is used for routing, escalation, or assignment, the system records the actual decision event separately from the transient presence value.

Implementation Checklist

  • Define presence states, source priority, stale thresholds, privacy boundaries, external sharing rules, status duration, user override behavior, and action implications before drawing badges.
  • Design badge, label, expanded detail, co-viewer list, unknown state, hidden state, stale state, and action affordances for desktop, mobile, keyboard, and screen-reader access.
  • Map presence to actions such as call, message, notify later, route, assign, join, or wait without assuming every available-looking person can be interrupted.
  • Show status freshness and source when the value comes from calendar, device activity, manual override, co-viewing, file activity, or API updates.
  • Respect privacy controls for view history, external access, same-domain limits, hidden users, anonymous users, and admin privacy mode.
  • Test delayed updates, multiple devices, manual overrides, do-not-disturb, out-of-office, offline fallback, anonymous viewers, hidden activity, and stale API data.

Common Generated-UI Mistakes

  • Using only color dots without text labels, source, or recency.
  • Treating presence as employee monitoring or audit evidence.
  • Leaving stale active states on screen after disconnects or sync failures.
  • Ignoring do-not-disturb, busy, call, meeting, or priority rules when offering interruptive actions.
  • Showing viewer names or last-seen times across privacy, domain, guest, or external organization boundaries.
  • Conflating presence with unread notifications, mentions, assignments, comments, or activity history.
  • Hiding unknown or restricted presence and making users think nobody is present.
  • Letting presence animations distract from the primary task or cause layout shifts.

Critique Questions

  • What exact person, group, file, channel, task, or object does this presence signal describe?
  • What status is shown in text, and when was it last updated?
  • Is the signal automatic, manual, calendar-derived, device-derived, activity-derived, or co-viewing-derived?
  • What privacy setting, external access rule, or permission boundary controls whether the signal is visible?
  • Which actions change when the person is busy, in do-not-disturb, offline, away, or unknown?
  • Can users tell the difference between live presence, last-seen activity, file view history, and audit history?
Accessibility
  • Expose presence state as text, such as Dana Lee, Busy in a meeting until 14:30, not just a colored dot.
  • Use shape, label, and text detail in addition to color for available, away, busy, do-not-disturb, offline, unknown, and restricted states.
  • Make presence detail reachable by keyboard and touch without hover-only tooltips.
  • Announce meaningful presence changes only when they affect the current task or selected person.
  • Label co-viewer lists with names, roles, and privacy-limited counts where allowed.
  • Keep badges, labels, and status messages from wrapping over primary actions or changing row height unpredictably.
Keyboard Behavior
  • Tab reaches presence indicators only when they reveal details or actions; decorative status text remains in the reading order.
  • Enter or Space opens presence detail for the focused person and Escape closes it without moving focus away from the row or composer.
  • Arrow keys can move through co-viewer or team availability lists when they are presented as selectable rows.
  • Notify later, message, call, route, and privacy controls are reachable in the same logical order as the visible layout.
  • Presence updates do not steal focus from the user's current form, editor, message, or selected row.
  • Screen-reader users can discover stale, hidden, unknown, or privacy-restricted state without relying on hover.
Variants
  • Availability badge
  • Do not disturb badge
  • Last seen indicator
  • Co-viewer list
  • Document viewer presence
  • Team availability summary
  • Out of office presence
  • Working-hours presence
  • Status message
  • Presence-aware routing

Verification

Source trail checked:

Saved items