Most automated Slack messages get ignored. Not because people are busy (though they are) but because the messages themselves are poorly designed. Wall-of-text alerts, missing context, no clear action: these are learned behaviors for skipping.
This post covers the core principles behind Slack messages that actually get read and acted on.
Structure before content
The first thing to get right is structure. A well-structured message communicates hierarchy at a glance:
- What happened: bold, top line, no decoration needed
- Why it matters: one or two lines of context
- What to do: a single button or link, not three
When you reverse this (or bury the headline in context), people have to read to figure out whether the message is even relevant to them. Most won’t.
Block Kit gives you the tools to make this visual: header blocks for the headline, section blocks for context, actions blocks for buttons. Use them in that order.
One message, one action
The most common design mistake in automated Slack messages is adding multiple CTAs: “View in Jira | Assign to me | Snooze | Mark resolved.”
Every option you add reduces the chance someone picks any of them. If a message truly requires multiple actions, make one primary (a button) and demote the rest to links in a context block below. The primary action should be the thing you most want someone to do 80% of the time.
Emoji: signal, not decoration
Emoji at the start of a message serves a real purpose: it creates a visual anchor that makes the message scannable in a busy channel. A 🔴 for critical, 🟡 for warning, ✅ for resolved: these patterns train people over time.
What doesn’t work: emoji scattered throughout body text as decoration, or inconsistent use that doesn’t carry meaning. If you’re going to use emoji as signal, be consistent. If you’re not, leave them out entirely.
Context blocks are for secondary information
Slack’s context block renders smaller grey text: it’s designed for metadata, not primary content. Use it for things like: who triggered the event, which environment, the timestamp, a link to related docs.
Don’t put important information in a context block hoping people will read it. If it matters, it goes in a section. If it’s truly secondary, context is appropriate.
Plain text vs. mrkdwn
Every section block has a type field: plain_text or mrkdwn. Use plain_text for labels, button text, and anything that should be literal. Use mrkdwn when you need formatting: bold with *asterisks*, links with <url|label>, or code with backticks.
A common mistake is leaving type as mrkdwn everywhere and then having asterisks render literally because you forgot the field carries meaning. Be intentional.
Don’t fight the channel
A message that makes sense in #on-call-alerts may be totally wrong in #general. Before you design a message, think about where it lands and who will see it there.
In a high-volume alert channel, brevity matters above everything. People are scanning, not reading. In a lower-volume team channel, slightly more context is fine because people will actually see it. In a DM, you can be more conversational.
The channel shapes the appropriate density and tone.
Message length
There’s no hard rule, but a useful heuristic: if someone has to scroll in the message preview to see your CTA, you’ve written too much. The summary of what happened and what to do should fit in the visible area of the channel feed.
For genuinely complex messages (deployment summaries, incident reports, approval requests with details) use a collapsed overflow menu or link out to a full view rather than packing everything into the Slack message.
Test with real data
Templates always look reasonable with placeholder text. They often fall apart with real data: a 200-character service name, a null field, a number that wraps awkwardly.
Before shipping an automated message, test it with the actual edge cases your data will produce: long strings, empty fields, very small numbers, very large numbers. Slack’s Block Kit Builder makes this easy to do without deploying anything.
Getting message design right starts with actually seeing the message — not guessing from JSON. LithoBlocks gives you a visual canvas for building Block Kit messages: drag in blocks, write real content, and preview the rendered output instantly. When you’re testing with real data, the template compiler shows you exactly how your message looks with long strings, empty fields, or unexpected values — before anything reaches Slack. Try it free →