Workflow management through Slack messages
What we learned about conversational UX and smart message design
If your product facilitates workflow in some way, you likely want to enable these workflows through Slack messages. This article will walk you through the process of designing interactive Slack messages to support your product vision and enhance your user experience.
Why would my app need interactive Slack messages?
Not everyone needs a high degree of interaction between Slack and their app, but we absolutely do.
VictorOps is an incident management service which alerts engineering teams to outages and related service issues (like the server going down at 2AM) and guides them through the process of resolving these issues. We centralize data coming from over 100 different monitoring tools and alert your team if something critical happens. On top of this, we also provide a workflow to help you remediate issues when they happen.
A few years ago, VictorOps built a two-way Slack integration which posted messages to Slack and listened to Slack for new messages. Many of our customers were using and enjoying this integration, but told us they also wanted to action on VictorOps incidents directly from Slack.
VictorOps contains a lot of specialized functionality through our own UI, but we decided to embed our core functionality into our Slack app (for instance, viewing incident detail or acknowledging incidents.)
A brief introduction to Slack message attachments
Slack messages can be as simple as a text field with some basic formatting. But the real power of Slack messages are in attachments. Attachments provide a wealth of versatility, including support for basic markdown, message collapsing (and expanding), color striping, buttons, and of course, image previews.
At first blush, Slack message attachments seems pretty simple, but there’s a lot clever information hierarchy and progressive disclosure going on behind the scenes. For one, long messages will be collapsed under a “show more” link, but other sections (like title and message fields) do not. Almost any part of the message can make use of Slack’s version of markdown. The color at the left is often used to represent state within Slack, and can be updated (along with any part of the message) at any time.
Slack’s message builder, your new best friend
Slack not only provides a robust framework for creating messages using JSON, but gives us access to a WYSIWYG editor called the message builder. The message builder lets us preview exactly how our messages will look and behave when they arrive in Slack.
You can use it to:
- Preview exactly how your messages will appear and act in Slack
- Hot-reload messages you design as you’re designing them, and be presented with specific error messages if they are found
- Perhaps most importantly, the JSON with which you designed your messages can be used directly by your development team, so there’s no gap between design and implementation
Our four big takeaways from designing interactive Slack messages
ICYMI: Sample code for the message builder example.
1. Put your most important information in “title” and “field” sections, and secondary in “text”
If the “text” field in a Slack attachment message is too long, Slack will automatically collapse the message after a few lines. The exceptions are the title and fields sections, which are shown regardless of message state.
We show a basic description of the incident (with a link back to VictorOps) in the title. In the message fields, we include who is being paged and for what policy.
Our “alert body”, which includes details about the problem in question, lives in the text field, where it is collapsed by default.
2. Use Slack’s native colors to represent state
Slack message attachments will display a stripe of color alongside the message. By default, this is gray, but you can customize this however you want. Slack provides some default color options to represent state, “danger”, “warning”, and “good”. Slack suggests that you make use of these color names to represent state, and don’t start introducing new state colors unless absolutely necessary.
We make use of these colors to represent incident criticality and resolution. Our critical incidents come in as red (“danger”), our warnings yellow (“warning”). When incidents are resolved, a new resolved message is posted, but we also update the original message and change its stripe color to green (“good”).
3. Show meta details in the message footer
Message footers may seem forgettable, but you can use them to provide relevant meta information. We use them as a means to show who actioned on an incident when it changes state, and display when that change happened. You can optionally add an image alongside any footer to act as a visual anchor.
4. Link to related messages with “jump”
Sometimes, an actionable message will get buried in the Slack timeline. If your app posts new messages related to the original (actionable) message, you can add a link to “jump” back up the timeline to the original message. We attach jump links to repeated paging and alert notifications so our users don’t have to go hunting to acknowledge or resolve an incident.
You can also utilize threaded messages to more closely associate follow-up posts to the original message. We’re exploring threaded messages in our next iteration of our Slack integration, but you can learn more about utilizing threads on Slack’s platform blog.
Where to go from here?
If you’re designing an integration with Slack, check out Slack’s User Experience Guide and Guidelines for building Slack messages, which provide do’s and don’ts for Slack message design. Also check out Building an interactive Slack app with message menus for an in-depth guide to Slack message menus (not discussed in this article)
If your team is looking for an incident management solution, definitely check out our demo and give VictorOps a spin. We will be doing even more with our Slack integration in the future, and doubling-down on our existing ChatOps features, so if you’re a Slack user you will not be disappointed.
