Reactions

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?