Slack Ephemeral Message UX Patterns Prompt
Decide when to use ephemeral vs in-channel vs DM messages, and design ephemeral-first flows that keep channels quiet while still guiding users through actions.
- Target user
- Bot builders deciding how their app talks to users
- Difficulty
- Beginner
- Tools
- Claude, ChatGPT
The prompt
You are a Slack app designer obsessed with keeping channels uncluttered while still being genuinely helpful.
I will provide:
- What my bot currently posts and where (channel, DM, ephemeral)
- Complaints about noise or confusion
- The interactions involved (commands, buttons, errors, confirmations)
Your job:
1. **The decision rule** — give me a crisp heuristic for choosing the surface:
- Ephemeral (`response_type: ephemeral` / `chat.postEphemeral`): feedback only the acting user needs — validation errors, "you're not authorized," intermediate steps, previews before posting.
- In-channel: results the whole channel should see — the final approved deploy, the incident summary.
- DM: long-lived personal context the user revisits — digests, reminders, onboarding.
2. **Ephemeral gotchas** — they can't be updated after the trigger response window the same way channel messages can, they vanish on reload, they can't be threaded, and you can't fetch them back. Show how to work within these limits (e.g., use `response_url` for follow-ups within 30 minutes).
3. **Preview-then-post pattern** — show an ephemeral preview with "Looks good, post it" / "Edit" / "Cancel" buttons so users confirm before anything hits the channel.
4. **Error UX** — turn raw failures into ephemeral, actionable messages ("Couldn't find service `paymets` — did you mean `payments`?") instead of channel-visible stack traces.
5. **Progressive disclosure** — start ephemeral, escalate to a modal for complex input, and only post in-channel on success.
6. **Accessibility + clarity** — concise copy, clear button labels, and a consistent visual language (emoji prefixes for status) across all messages.
Output: (a) a one-page decision table (surface × use case), (b) Block Kit JSON for an ephemeral error message and a preview-then-post flow, (c) the `response_url` follow-up snippet, (d) a before/after rewrite of one noisy interaction I describe.
Bias toward: ephemeral-by-default, confirm-before-broadcast, and human-readable errors over raw failures.