UX Patterns Guide
UI + UX Collaboration And Social Interaction established

Reactions

Provide item-anchored reaction chips with clear emoji names, counts, own-state highlighting, add and remove paths, who-reacted disclosure, picker and policy rules, grouped overflow, notification and activity behavior, and explicit boundaries for workflow triggers or consequential decisions.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users need quick, lightweight feedback on an existing message, comment, issue, document selection, or work item.
  • The response can remain informal and reversible.
  • The product can show counts, own-state, who-reacted disclosure, and add/remove behavior clearly.

Avoid when

  • The response needs written reasoning, evidence, or a reply thread.
  • The decision is formal approval, assignment, voting, legal consent, audit evidence, or status transition.
  • The product cannot expose reaction meaning, count, own-state, and accessible names.
  • Reaction automation would surprise users or cause consequential side effects.
  • The target item is too sensitive to reveal reaction identities or sentiment.

Problem it prevents

Reaction systems become misleading when products hide who reacted, make reactions hover-only, treat informal emoji as approvals or assignments, trigger automations without disclosure, flood activity streams, or fail to expose counts and selected state accessibly.

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

What a strong implementation has to make clear

User need

Reactions can appear on chat messages, comments, pull requests, issues, discussions, document selections, canvas text, meeting chats, posts, files, and work items.

Pattern promise

Provide item-anchored reaction chips with clear emoji names, counts, own-state highlighting, add and remove paths, who-reacted disclosure, picker and policy rules, grouped overflow, notification and activity behavior, and explicit boundaries for workflow triggers or consequential decisions.

Required state

No reactions state.

Recovery path

A reaction chip has no text alternative, so screen-reader users hear only a count.

Access contract

Give each reaction chip an accessible name that includes emoji meaning, count, selected state, and target item context.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A message row shows 👍 6, 👀 2, and Add reaction; the user's 👍 is highlighted, clicking it removes their reaction, and opening the count reveals who reacted.
  • A Docs selection shows an emoji reaction anchored to highlighted text as a lightweight alternative to a comment, while full comments remain available for written feedback.
  • A teammate adds 👀 to show they are looking at a message, sees their reaction highlighted, removes it after replying, and the activity feed groups the reaction event with other low-priority reactions.
  • A team configures ❗ as a Teams workflow trigger and the reaction picker warns that the emoji will create a helpdesk escalation only in selected channels.
Weak implementation

Vague, hidden, hard to recover from

  • A thumbs-up chip is styled like a formal Approve button and commits a release without approver route, audit, or version context.
  • A reaction count appears with no accessible name, no user list, no selected state, and no keyboard path to add or remove a reaction.
  • A user adds ✅ as casual acknowledgement, but an automation silently closes the task.
  • A message receives thirty custom emoji and the important comment underneath is pushed out of view with no collapse or grouping.
UI guidance
  • Render reactions as compact chips or controls attached to a specific item, showing emoji or reaction name, count, the current user's selected state, add-reaction access, remove behavior, and a way to inspect who reacted.
  • Keep reaction controls distinct from comments, mentions, approvals, assignments, votes, and status tags by naming reaction intent, showing whether reaction counts are informal, and disclosing any workflow automation tied to a specific emoji.
UX guidance
  • Use reactions when users need a fast, low-friction way to acknowledge, support, celebrate, flag lightly, or express sentiment without creating a new reply.
  • Protect interpretation by making add/remove reversible, avoiding overloading one emoji with hidden meaning, grouping noisy reactions in activity feeds, and routing consequential decisions to stronger patterns.
Implementation contract

What the implementation must handle

States

  • No reactions state.
  • One reaction added by current user state.
  • Existing reaction by others state.
  • Multiple emoji reaction chips with counts.

Interaction

  • Each reaction attaches to one named source item and does not create a separate conversation by itself.
  • Selecting an existing reaction chip adds the user's reaction if absent or removes their reaction if already selected, according to product policy.
  • The count represents unique reaction records for that emoji and updates after add, remove, sync, or server rejection.
  • The picker exposes searchable emoji names, recent or suggested reactions, custom emoji policy, and skin tone or identity preferences where supported.

Accessibility

  • Give each reaction chip an accessible name that includes emoji meaning, count, selected state, and target item context.
  • Do not rely on emoji glyph, color, or highlight alone to identify reaction type or own-state.
  • Make add reaction, remove reaction, open picker, inspect reactors, and close disclosure keyboard reachable.
  • Expose custom emoji names and skin tone choices as text.

Review

  • What exactly does each reaction mean in this product, and what does it not mean?
  • Can users add, remove, and inspect reactions with keyboard, touch, and assistive technology?
  • Can users tell which reactions they personally added and who else reacted?
  • Does any emoji trigger notifications, activity feed events, workflow automation, assignment, or status changes?
Evidence trail

Source-backed claims behind this guidance

Slack Help: Use emoji and reactions

Slack Help - checked

Slack documents add reaction, remove own reaction, current-user highlighting, one-click reactions, mobile long-press, and who-reacted disclosure.

Slack Developer Docs: reactions.add method

Slack Developer Docs - checked

Slack developer docs document reaction target parameters, skin tone modifiers, already-reacted errors, access errors, and reaction_added event broadcast.

GitHub REST API: Reactions

GitHub Docs - checked

GitHub documents creating and managing reactions on comments, issues, pull requests, and discussions with allowed reaction content values.

Full agent/debug reference

Problem Context

  • Reactions can appear on chat messages, comments, pull requests, issues, discussions, document selections, canvas text, meeting chats, posts, files, and work items.
  • Users may react to acknowledge, vote lightly, show sentiment, celebrate, signal that they are looking, avoid adding a reply, or trigger a product-defined workflow.
  • Emoji choice may include default emoji, custom workspace emoji, skin tone modifiers, gender modifiers, one-click suggestions, recent emoji, restricted emoji, or admin-managed defaults.
  • Reaction events may affect activity feeds, notification centers, workflow automation, moderation, analytics, accessibility output, and content density.
  • The same emoji may carry different team conventions, so products must avoid implying stronger semantics than the system can enforce.

Selection Rules

  • Choose reactions when lightweight feedback can safely remain attached to an existing item and does not require a written reply.
  • Use comments when users need text, rationale, evidence, questions, moderation, edit history, resolve state, or a reply thread.
  • Use mentions when the job is to notify or route attention to people or groups.
  • Use approval workflow when the decision is governed, versioned, audited, and made by eligible approvers.
  • Use assignment when someone becomes responsible for doing work; a reaction should not create accountability unless the product explicitly models that side effect.
  • Use activity feed to summarize reaction events across work; group repeated low-value reaction activity so it does not hide mentions or failures.
  • Use notification center only for reaction events that should create durable unseen or unread items with user preferences.
  • Show the current user's own reaction state separately from total count.
  • Provide a way to see who reacted and handle privacy or permission-limited names honestly.
  • Support add, remove, already-reacted, not-reactable, disabled-by-policy, offline, sync-failed, and custom-emoji-unavailable states.
  • Disclose workflow triggers for specific emoji, including trigger scope, frequency, and who can trigger them.
  • Collapse or summarize high-volume reaction sets without hiding the user's own reaction or important workflow-trigger emoji.

Required States

  • No reactions state.
  • One reaction added by current user state.
  • Existing reaction by others state.
  • Multiple emoji reaction chips with counts.
  • Current user's reaction highlighted or selected state.
  • Remove own reaction state.
  • Add reaction picker open state.
  • Who reacted disclosure state.
  • Custom emoji, skin tone, and inaccessible emoji name states.
  • Reaction overflow or collapsed count state.
  • Reaction disabled, not-reactable, already-reacted, or permission-limited state.
  • Workflow-trigger reaction warning state.
  • Reaction notification or activity-feed grouping state.
  • Mobile long-press reaction state.
  • Offline or sync-failed reaction state.

Interaction Contract

  • Each reaction attaches to one named source item and does not create a separate conversation by itself.
  • Selecting an existing reaction chip adds the user's reaction if absent or removes their reaction if already selected, according to product policy.
  • The count represents unique reaction records for that emoji and updates after add, remove, sync, or server rejection.
  • The picker exposes searchable emoji names, recent or suggested reactions, custom emoji policy, and skin tone or identity preferences where supported.
  • Who-reacted disclosure lists visible people or explains hidden/private reactors without leaking restricted identities.
  • Reaction events synchronize with activity feed and notification center only when configured by product policy.
  • Workflow-trigger emoji require a visible warning or configuration surface before casual reactions start automation.
  • Keyboard and touch users can add, remove, inspect, and dismiss reactions without hover-only affordances.

Implementation Checklist

  • Define reaction target types, allowed emoji set, custom emoji policy, user identity, duplicate prevention, reaction count model, and remove behavior.
  • Separate reaction records from comments, mentions, approvals, assignments, votes, statuses, presence, and notification records in the data model.
  • Build add picker, one-click suggestions, selected state, remove action, count update, who-reacted disclosure, overflow grouping, and moderation or policy-disabled states.
  • Model API errors such as already reacted, item not reactable, access denied, invalid target, deleted item, offline queue, and sync failure.
  • Handle workflow-trigger emoji with explicit configuration, scope, frequency, eligibility, preview, and audit or activity output.
  • Synchronize reaction events with activity feed, notification preferences, unread rules, analytics, and source-item rendering without flooding catch-up surfaces.
  • Test keyboard controls, touch long-press, screen-reader names, custom emoji labels, skin tone modifiers, high counts, overflow collapse, permission-limited reactors, deleted users, and localization.

Common Generated-UI Mistakes

  • Using reactions as formal approvals without approver eligibility, audit trail, or version context.
  • Treating reactions as assignments or commitments with no responsibility record.
  • Hiding add reaction behind pointer hover only.
  • Showing counts without who-reacted disclosure or privacy explanation.
  • Using color or emoji shape alone without accessible names.
  • Triggering workflow automation from a reaction without warning users.
  • Letting reaction storms dominate message layout or activity feeds.
  • Allowing custom emoji that undermine moderation, privacy, or accessibility policies.

Critique Questions

  • What exactly does each reaction mean in this product, and what does it not mean?
  • Can users add, remove, and inspect reactions with keyboard, touch, and assistive technology?
  • Can users tell which reactions they personally added and who else reacted?
  • Does any emoji trigger notifications, activity feed events, workflow automation, assignment, or status changes?
  • How are custom emoji, skin tones, hidden reactors, deleted users, and permission-limited items represented?
  • How are high-volume reactions grouped so they do not bury comments, mentions, or important work events?
Accessibility
  • Give each reaction chip an accessible name that includes emoji meaning, count, selected state, and target item context.
  • Do not rely on emoji glyph, color, or highlight alone to identify reaction type or own-state.
  • Make add reaction, remove reaction, open picker, inspect reactors, and close disclosure keyboard reachable.
  • Expose custom emoji names and skin tone choices as text.
  • Announce reaction added, removed, failed, already present, disabled, and workflow-trigger warnings through status text.
  • Provide touch and keyboard alternatives for hover-only one-click reaction controls.
  • Keep high-count and overflow layouts readable at high zoom and on mobile.
Keyboard Behavior
  • Tab moves to existing reaction chips, add reaction control, picker search, picker categories, emoji options, who-reacted disclosure, and close controls.
  • Enter or Space toggles the focused reaction chip according to selected state.
  • Arrow keys may move inside the emoji picker when it implements grid or listbox semantics.
  • Escape closes the picker or who-reacted popover and returns focus to the invoking reaction control.
  • Removing a reaction keeps focus on the chip if it remains visible or moves to Add reaction if the chip disappears.
  • Workflow-trigger warnings keep focus inside the confirmation or configuration disclosure until dismissed.
Variants
  • Message reactions
  • Comment reactions
  • Issue reactions
  • Pull request reactions
  • Document text reactions
  • One-click reactions
  • Custom emoji reactions
  • Skin tone reactions
  • Workflow-trigger reactions
  • Collapsed reaction overflow
  • Anonymous or permission-limited reactions
  • Mobile long-press reactions

Verification

Source trail checked:

Saved items