Block / mute

Problem Context

• Targets may be people, accounts, comments, posts, profiles, DMs, group conversations, channels, threads, apps, bots, words, hashtags, topics, repositories, workspaces, or organizations.
• Effects may include hiding posts, hiding names/photos/messages, suppressing notifications, preventing contact, preventing profile visibility, blocking repository collaboration, preserving badge-only alerts, or limiting only one conversation.
• The target may or may not be notified, and the current user may still see mentions, badges, shared-context replies, huddles, hidden-message reveal prompts, or existing content.
• Block and mute often sit next to report abuse, notification preferences, follow or subscribe, unfollow, leave conversation, restrict, remove, and permission controls, but each has a different owner and consequence.

Selection Rules

• Choose block / mute when the user needs a personal boundary that changes visibility, contact, notification, or interaction from a specific target.
• Use block when the intended effect is stronger interaction prevention, such as blocking contact, profile interaction, repository participation, tagging, list addition, or collaboration actions.
• Use mute when the intended effect is reducing visibility or notifications while preserving follow, membership, access, or contact relationships.
• Use hide or restrict when content or identity is visually suppressed but the target may still be present, join spaces, or have messages revealed deliberately.
• Use report abuse when the user wants policy, safety, legal, privacy, or moderation review; offer it adjacent to block or mute without implying block or mute enforces platform rules.
• Use notification preferences when the user is configuring broad event types, channels, quiet hours, digests, OS permissions, or workspace delivery rules.
• Use follow / subscribe when the user opts into future updates from one target; use mute to reduce or pause exposure from one target.
• Use permission denied state when access is unavailable because of authorization, role, policy, or owner decisions rather than personal boundary settings.
• Show the exact target and scope before activation: account, channel, one DM, group DM, app, bot, word, thread, story, repository, organization, or all conversations with a person.
• Show exceptions such as mentions, badges, DMs, huddles, shared conversations, existing replies, protected posts, Slackbot, admin policy, or organization blocks before users assume silence is total.
• Provide unblock, unmute, unhide, manage list, undo, or temporary-duration controls close to the activated state.

Required States

• Block entry point from profile, post, comment, message, repository, or account settings.
• Mute entry point from profile, post, channel, DM, app, bot, thread, word, or notification menu.
• Confirmation state for high-impact block with target identity and consequences.
• Mute without notification to target state.
• Blocked state with visible status, hidden content, and View anyway or profile warning where relevant.
• Muted state with timeline, sidebar, channel, DM, app, bot, or notification scope label.
• Hidden person or hidden message state with reveal one message and unhide paths.
• Restrict or limited-interaction state with who can comment, mention, DM, or see activity.
• Temporary mute state with duration such as one hour, until tomorrow, or custom end time.
• Exceptions state for mentions, badges, DMs, huddles, shared conversations, Slackbot, or repository contributor warnings.
• Undo, unblock, unmute, unhide, manage blocked list, and manage muted list states.
• Report abuse adjacent action, emergency help route, failed action, offline pending, permission-limited, admin-managed, and mobile compact states.

Interaction Contract

• The control identifies the exact target before activation and does not infer a broader scope than the visible label states.
• Block, mute, hide, restrict, report, unfollow, unsubscribe, remove, and leave are separate commands with separate confirmation copy.
• High-impact block actions require confirmation and describe consequences that affect contact, profile visibility, collaboration, repository actions, or shared spaces.
• Mute actions state whether they affect posts, stories, channel notifications, DMs, group DMs, apps, bots, words, topics, or one conversation, and whether the target is notified.
• The resulting state is visible near the target and in a management list, with unblock, unmute, unhide, or undo available when policy allows.
• Exceptions are disclosed before or immediately after activation so users know what still appears or notifies them.
• Failed or offline actions preserve the chosen target and intended action and do not claim the boundary applied.
• Private notes, block reasons, hidden-person state, and safety choices are not exposed to the blocked or muted target.

Implementation Checklist

• Inventory target types, available boundary actions, effect scope, notification effects, target-notification behavior, exceptions, undo windows, and management surfaces.
• Model block, mute, hide, restrict, report, unfollow, subscription, notification preference, and permission states separately.
• Write consequence summaries for each action, including what still appears, what still notifies, whether contact is blocked, and how to reverse it.
• Add confirmation for high-impact block or organization-wide actions and immediate status for lower-impact mute or hide actions.
• Provide management lists for blocked accounts, muted accounts, muted words, muted channels, hidden people, and temporary mutes where the product supports them.
• Handle deleted users, renamed channels, blocked-by-target relationships, protected content, shared group conversations, repository ownership, admin-managed blocks, offline failure, and cross-device sync.
• Test screen-reader labels, keyboard activation, mobile overflow menus, long names, private notes, undo, hidden-message reveal, temporary expiry, and report-abuse handoff.

Common Generated-UI Mistakes

• Using one command for block, mute, hide, report, and unfollow.
• Failing to explain whether the target is notified.
• Hiding the unblock or unmute route after activation.
• Letting muted conversations still produce unexplained badges or mention alerts.
• Claiming the user is safe when the setting only hides posts from one timeline.
• Making report abuse the only way to stop seeing someone.
• Showing private block notes, reasons, or hidden-person state to the target.
• Treating admin-enforced restrictions as if the current user can reverse them.

Critique Questions

• What exact person, account, conversation, channel, app, bot, word, or thread is affected?
• Is this action reducing visibility, suppressing notifications, preventing contact, hiding identity, restricting interaction, or reporting abuse?
• What still appears or notifies after activation?
• Does the target know, and is that expectation stated honestly?
• Where can users undo, unblock, unmute, unhide, or review the list later?
• How does this differ from notification preferences, follow / subscribe, report abuse, and permission denial?
• What happens in shared group conversations, mentions, huddles, repository collaboration, and offline failure?