Back to compare picker

Block / mute vs Report abuse vs Notification preferences vs Follow / subscribe vs Permission denied state vs Comments

Choose block / mute when the user wants to stop seeing, hearing from, being contacted by, being mentioned by, or receiving notifications from a person, account, channel, DM, app, bot, word, topic, or conversation by changing a personal visibility and interaction boundary without submitting the item for policy review.

Decision dimensions

Dimension Block / muteReport abuseNotification preferencesFollow / subscribePermission denied stateComments
UI or UX UI + UX - Personal boundary control for reducing or stopping visibility, interaction, contact, and notification exposure from people, accounts, conversations, channels, apps, bots, words, or threadsUI + UX - Reporter-facing safety submission flow for harmful, abusive, illegal, spam, impersonation, or policy-violating content and behaviorUI + UX - User-controlled rules for notification type, channel, frequency, timing, privacy, and exceptionsUI + UX - Per-object opt-in control for future updates from a thread, page, channel, space, repository, saved view, or topicUI + UX - Authorization and access-boundary stateUI + UX - Object-attached comment composer and comment list with authorship, replies, state, permissions, and moderation
UI guidance Render block and mute controls as scoped personal-boundary actions that name the target, effect, scope, exceptions, confirmation need, reversal path, and related report or safety action.Render report abuse as a scoped safety flow that identifies the reported object, selected reason, affected person, evidence or context, privacy handling, submit action, confirmation ID, review expectation, and immediate safety actions.Render notification preferences as a structured matrix or grouped settings surface that shows notification type, source, delivery channel, device, frequency, quiet-time rule, preview privacy, override, and current saved state.Render follow or subscribe as a stateful control attached to the specific object being watched, with current state, target scope, delivery destination, event types, auto-follow reason when present, and an unfollow path.Show the blocked object or action, current account, permission level, required role, owner, and request path when revealing that information is allowed.Render comments as anchored contributions with author identity, timestamp, body, optional attachment or selection context, edited state, reply target, and state labels such as open, resolved, hidden, deleted, or assigned.
UX guidance Use block / mute when users need immediate control over exposure to a person, account, conversation, channel, app, bot, word, topic, or thread without necessarily asking the platform to enforce a policy.Use report abuse when a user needs to flag harmful content or behavior for review, not when they only want to hide someone, request access, resolve a comment, or read a security warning.Use notification preferences when users need to reduce noise without missing important mentions, assignments, security notices, incidents, reminders, or followed-object updates.Use follow / subscribe when users want future changes to a specific object, channel, thread, repository, page, space, saved view, or topic to come to them without repeatedly checking it.Use permission denied state when the system knows the user is authenticated but their role, group, share, license, policy, or approval status blocks a specific object or action.Use comments when users need to discuss, question, annotate, review, or leave follow-up notes on a specific object, selection, file line, record, document, or task without changing the primary content directly.
Good UI A profile menu offers Mute posts, Block account, Report abuse, and Hide mentions as separate actions, each with a short consequence summary before confirmation.A comment menu opens Report abuse with the comment snapshot, author, timestamp, reason choices, affected-person choice, optional context, submit, and confirmation with Block user and View report history actions.A notification preferences page groups Mentions, Assigned work, Followed threads, Security, Digest, and Marketing, with columns for In-app, Email, Push, Banner, and Digest frequency.A thread header shows Following, explains replies will appear in the followed-threads list and Activity feed, and offers Unfollow replies from the same menu.A report page says Quarterly revenue report requires Finance viewer access, shows the current account, names the report owner, and offers Request access and Switch account.A document margin comment shows the selected paragraph, author, timestamp, body text, Reply, Resolve, Assign, and Copy link actions with the composer focused on that selection.
Bad UI A single Silence button mutes posts, blocks DMs, unfollows, and reports the account without naming any effect.A red Report button immediately submits with no reason, no content snapshot, no confirmation, and no path to protect the reporter.A single Notifications off switch disables email, push, badges, and mention banners without saying whether security alerts or approvals still arrive.A Subscribe button changes to Subscribed without saying whether the user subscribed to a page, all child pages, a space, email, push, or in-app updates.A denial page says Something went wrong and shows Retry even though the user lacks a required group.A Notes textarea sits under a record and calls itself comments even though every user overwrites the same field.
Good UX A user mutes a noisy account, sees that the account is not notified and can still send DMs, then uses the muted-account list to unmute later.A user reports a threatening message, selects violent threat, includes two related messages for context, receives a report receipt, gets guidance to contact local emergency services if in immediate danger, and can save a copy for authorities.A user keeps mentions and assigned-work banners on, moves repository watch updates to daily digest, mutes marketing email, and sees a preview of what will still notify them during quiet hours.A user follows a support thread before leaving for a meeting, receives only new replies in the promised destination, then unfollows when the incident closes.A user opens a restricted report, sees which account is signed in, requests viewer access with a reason, then sees that the request is pending with the owner.A reviewer comments on a selected line, adds an action item for Dana, receives a reply, resolves the comment, and can reopen it from the resolved filter.
Bad UX A user mutes a direct message expecting silence everywhere, but the same person keeps triggering alerts in another group conversation because scope was not explained.A user reports spam and sees the reported account instantly marked banned even though the item has only entered review.A user disables email for a noisy project and still receives duplicate push and desktop banners because those channels live in separate hidden settings.A user receives a stream of update emails from a space but cannot tell which page, mention, reply, or watch setting caused them.The app returns a blank screen for a restricted file, so the user cannot tell whether the file is gone, private, or opened with the wrong account.A user writes a long comment, loses network connection, and the draft disappears when the page reloads.
Best fit Users need to reduce exposure to a person, account, conversation, channel, app, bot, word, topic, or thread.Users need to flag content, behavior, an account, conversation, listing, repository, ad, or message for policy, abuse, spam, privacy, legal, or safety review.Users receive enough notifications that they need control over type, channel, device, frequency, timing, or source.Users need future updates from a specific object, thread, channel, space, repository, topic, saved view, or query.A signed-in user lacks permission to view, edit, publish, export, delete, approve, share, administer, or configure a resource.Users need object-attached discussion without changing the primary object content directly.
Avoid when The user is submitting harmful content for policy review; use report abuse.The user only wants to stop seeing a person or thread; use block, mute, hide, or notification controls instead.The product has only a few low-volume notifications that can be handled by defaults and inline controls.The user only needs quick return access without updates.The user is not signed in and the next step is authentication rather than authorization.The user is simply entering a long answer into a form field.
Required state Block entry point from profile, post, comment, message, repository, or account settings.Report entry point near a post, comment, profile, message, conversation, repository, ad, live chat item, or listing.Default notification preferences state.Not following state.Whole-object access denied state.Empty comment list and first-comment composer.
Accessibility burden Give controls target-specific names such as Block @maya, Mute #incidents, Hide messages from Dana, or Unmute app DM.Give Report controls object-specific labels such as Report comment by Maya, Report profile, or Report message in conversation.Group preferences with headings and fieldsets for event type, delivery channel, device, and frequency.Give the control an accessible name that includes target type, target name, current follow state, and destination when space allows.Use a heading that identifies the access boundary and a text description that does not rely on lock icons or red color alone.Label the comments region with the object or selection being discussed.
Common misuse Using one command for block, mute, hide, report, and unfollow.Treating Report as an instant takedown or ban action.Offering one master notification switch for a complex collaboration product.Using Follow as a bookmark with no future update delivery.Treating authorization denial as a generic retryable error.Using one shared Notes field as a comment system and overwriting prior contributors.

Block / mute

UI or UX
UI + UX - Personal boundary control for reducing or stopping visibility, interaction, contact, and notification exposure from people, accounts, conversations, channels, apps, bots, words, or threads
UI guidance
Render block and mute controls as scoped personal-boundary actions that name the target, effect, scope, exceptions, confirmation need, reversal path, and related report or safety action.
UX guidance
Use block / mute when users need immediate control over exposure to a person, account, conversation, channel, app, bot, word, topic, or thread without necessarily asking the platform to enforce a policy.
Good UI
A profile menu offers Mute posts, Block account, Report abuse, and Hide mentions as separate actions, each with a short consequence summary before confirmation.
Bad UI
A single Silence button mutes posts, blocks DMs, unfollows, and reports the account without naming any effect.
Good UX
A user mutes a noisy account, sees that the account is not notified and can still send DMs, then uses the muted-account list to unmute later.
Bad UX
A user mutes a direct message expecting silence everywhere, but the same person keeps triggering alerts in another group conversation because scope was not explained.
Best fit
Users need to reduce exposure to a person, account, conversation, channel, app, bot, word, topic, or thread.
Avoid when
The user is submitting harmful content for policy review; use report abuse.
Required state
Block entry point from profile, post, comment, message, repository, or account settings.
Accessibility burden
Give controls target-specific names such as Block @maya, Mute #incidents, Hide messages from Dana, or Unmute app DM.
Common misuse
Using one command for block, mute, hide, report, and unfollow.

Report abuse

UI or UX
UI + UX - Reporter-facing safety submission flow for harmful, abusive, illegal, spam, impersonation, or policy-violating content and behavior
UI guidance
Render report abuse as a scoped safety flow that identifies the reported object, selected reason, affected person, evidence or context, privacy handling, submit action, confirmation ID, review expectation, and immediate safety actions.
UX guidance
Use report abuse when a user needs to flag harmful content or behavior for review, not when they only want to hide someone, request access, resolve a comment, or read a security warning.
Good UI
A comment menu opens Report abuse with the comment snapshot, author, timestamp, reason choices, affected-person choice, optional context, submit, and confirmation with Block user and View report history actions.
Bad UI
A red Report button immediately submits with no reason, no content snapshot, no confirmation, and no path to protect the reporter.
Good UX
A user reports a threatening message, selects violent threat, includes two related messages for context, receives a report receipt, gets guidance to contact local emergency services if in immediate danger, and can save a copy for authorities.
Bad UX
A user reports spam and sees the reported account instantly marked banned even though the item has only entered review.
Best fit
Users need to flag content, behavior, an account, conversation, listing, repository, ad, or message for policy, abuse, spam, privacy, legal, or safety review.
Avoid when
The user only wants to stop seeing a person or thread; use block, mute, hide, or notification controls instead.
Required state
Report entry point near a post, comment, profile, message, conversation, repository, ad, live chat item, or listing.
Accessibility burden
Give Report controls object-specific labels such as Report comment by Maya, Report profile, or Report message in conversation.
Common misuse
Treating Report as an instant takedown or ban action.

Notification preferences

UI or UX
UI + UX - User-controlled rules for notification type, channel, frequency, timing, privacy, and exceptions
UI guidance
Render notification preferences as a structured matrix or grouped settings surface that shows notification type, source, delivery channel, device, frequency, quiet-time rule, preview privacy, override, and current saved state.
UX guidance
Use notification preferences when users need to reduce noise without missing important mentions, assignments, security notices, incidents, reminders, or followed-object updates.
Good UI
A notification preferences page groups Mentions, Assigned work, Followed threads, Security, Digest, and Marketing, with columns for In-app, Email, Push, Banner, and Digest frequency.
Bad UI
A single Notifications off switch disables email, push, badges, and mention banners without saying whether security alerts or approvals still arrive.
Good UX
A user keeps mentions and assigned-work banners on, moves repository watch updates to daily digest, mutes marketing email, and sees a preview of what will still notify them during quiet hours.
Bad UX
A user disables email for a noisy project and still receives duplicate push and desktop banners because those channels live in separate hidden settings.
Best fit
Users receive enough notifications that they need control over type, channel, device, frequency, timing, or source.
Avoid when
The product has only a few low-volume notifications that can be handled by defaults and inline controls.
Required state
Default notification preferences state.
Accessibility burden
Group preferences with headings and fieldsets for event type, delivery channel, device, and frequency.
Common misuse
Offering one master notification switch for a complex collaboration product.

Follow / subscribe

UI or UX
UI + UX - Per-object opt-in control for future updates from a thread, page, channel, space, repository, saved view, or topic
UI guidance
Render follow or subscribe as a stateful control attached to the specific object being watched, with current state, target scope, delivery destination, event types, auto-follow reason when present, and an unfollow path.
UX guidance
Use follow / subscribe when users want future changes to a specific object, channel, thread, repository, page, space, saved view, or topic to come to them without repeatedly checking it.
Good UI
A thread header shows Following, explains replies will appear in the followed-threads list and Activity feed, and offers Unfollow replies from the same menu.
Bad UI
A Subscribe button changes to Subscribed without saying whether the user subscribed to a page, all child pages, a space, email, push, or in-app updates.
Good UX
A user follows a support thread before leaving for a meeting, receives only new replies in the promised destination, then unfollows when the incident closes.
Bad UX
A user receives a stream of update emails from a space but cannot tell which page, mention, reply, or watch setting caused them.
Best fit
Users need future updates from a specific object, thread, channel, space, repository, topic, saved view, or query.
Avoid when
The user only needs quick return access without updates.
Required state
Not following state.
Accessibility burden
Give the control an accessible name that includes target type, target name, current follow state, and destination when space allows.
Common misuse
Using Follow as a bookmark with no future update delivery.

Permission denied state

UI or UX
UI + UX - Authorization and access-boundary state
UI guidance
Show the blocked object or action, current account, permission level, required role, owner, and request path when revealing that information is allowed.
UX guidance
Use permission denied state when the system knows the user is authenticated but their role, group, share, license, policy, or approval status blocks a specific object or action.
Good UI
A report page says Quarterly revenue report requires Finance viewer access, shows the current account, names the report owner, and offers Request access and Switch account.
Bad UI
A denial page says Something went wrong and shows Retry even though the user lacks a required group.
Good UX
A user opens a restricted report, sees which account is signed in, requests viewer access with a reason, then sees that the request is pending with the owner.
Bad UX
The app returns a blank screen for a restricted file, so the user cannot tell whether the file is gone, private, or opened with the wrong account.
Best fit
A signed-in user lacks permission to view, edit, publish, export, delete, approve, share, administer, or configure a resource.
Avoid when
The user is not signed in and the next step is authentication rather than authorization.
Required state
Whole-object access denied state.
Accessibility burden
Use a heading that identifies the access boundary and a text description that does not rely on lock icons or red color alone.
Common misuse
Treating authorization denial as a generic retryable error.

Comments

UI or UX
UI + UX - Object-attached comment composer and comment list with authorship, replies, state, permissions, and moderation
UI guidance
Render comments as anchored contributions with author identity, timestamp, body, optional attachment or selection context, edited state, reply target, and state labels such as open, resolved, hidden, deleted, or assigned.
UX guidance
Use comments when users need to discuss, question, annotate, review, or leave follow-up notes on a specific object, selection, file line, record, document, or task without changing the primary content directly.
Good UI
A document margin comment shows the selected paragraph, author, timestamp, body text, Reply, Resolve, Assign, and Copy link actions with the composer focused on that selection.
Bad UI
A Notes textarea sits under a record and calls itself comments even though every user overwrites the same field.
Good UX
A reviewer comments on a selected line, adds an action item for Dana, receives a reply, resolves the comment, and can reopen it from the resolved filter.
Bad UX
A user writes a long comment, loses network connection, and the draft disappears when the page reloads.
Best fit
Users need object-attached discussion without changing the primary object content directly.
Avoid when
The user is simply entering a long answer into a form field.
Required state
Empty comment list and first-comment composer.
Accessibility burden
Label the comments region with the object or selection being discussed.
Common misuse
Using one shared Notes field as a comment system and overwriting prior contributors.
Decision rules
  • Choose block / mute when the user wants to stop seeing, hearing from, being contacted by, being mentioned by, or receiving notifications from a person, account, channel, DM, app, bot, word, topic, or conversation by changing a personal visibility and interaction boundary without submitting the item for policy review.
  • Choose report abuse when the user flags harmful content or behavior for platform, community, legal, privacy, or safety review; block and mute may be adjacent personal-safety actions but they are not enforcement outcomes.
  • Choose notification preferences when the user configures broad event-type, channel, frequency, quiet-time, digest, preview, OS, or admin-managed notification rules rather than one target's visibility or interaction boundary.
  • Choose follow / subscribe when the user opts into future updates from an object, thread, repository, page, channel, topic, or saved view; block / mute reduces or stops exposure to a target instead of creating future delivery.
  • Choose permission denied state when access is blocked by role, license, owner, policy, sharing, or authentication; block / mute is a user-controlled personal boundary and should not be used to explain missing authorization.
  • Choose comments when the user is reading, replying, resolving, editing, deleting, or moderating an ordinary discussion; a comment may expose block, mute, hide, or report controls, but those controls change visibility and safety boundaries around the conversation.
  • A block flow should name the account or person, explain contact, mention, profile, content, repository, collaboration, or visibility effects, confirm high-impact changes, and keep unblock or blocked user list management findable.
  • A mute flow should name the target and scope, such as account posts, muted channel notifications, one DM, group DM, app, bot, word, topic, thread, story, or conversation, and state what still breaks through, such as mentions, badges, DMs, huddles, or existing relationships.
  • A hide or restrict variant should state whether the target is notified, what content is hidden, how individual hidden messages can be revealed, and where to manage or reverse the hidden state.
  • Do not treat block, mute, hide, restrict, unfollow, unsubscribe, report abuse, remove from channel, ban, or permission denial as interchangeable; each has a different target, visibility effect, reversibility, and social consequence.
Inspect live examples
Failure modes
  • A Mute action silently blocks DMs, unfollows the account, or reports the user even though the user expected only timeline or notification reduction.
  • A Block button has no confirmation and does not explain profile, mention, direct-message, repository, or collaboration consequences.
  • A muted channel still appears noisy because mentions, badges, thread replies, or sidebar visibility are not explained.
  • A hidden person can be revealed only by deleting the whole conversation, so the user loses control over one-message reveal.
  • A blocked user list is buried, making unblock and review impossible.
  • The UI says the user is protected, but block or mute affects only the current device or one conversation with no scope label.