Interaction guidelines for Slack apps
You've storyboarded your app, given thought to the calibre of your communication, and mapped a trail through a myriad of Slack APIs.
When you start putting all of this together, it's helpful to consider some evergreen tips that will keep interactions with your app pleasant and productive. In this doc, we've collated some basic interaction guidelines for apps.
Be upfront about communication
When your app is first installed, allow the installer to easily set preferences that relate to communication. Think about settings like the rate of messages, the channel they should be posted to, and if applicable, the type(s) of notifications your app should send.
Avoiding large-group mentions
There are very few cases where your app should send broad mentions like @channel, @here, or @everyone. One exception might be if your app sends a notification for immediate action when a critical system or service goes down. Even then, you should get explicit permission from the installer before your app uses one of these mentions.
Keeping modals meaningful
Modals are intended for short-term interaction. Their popup, attention-grabbing nature makes them a mighty weapon that should be wielded only at truly appropriate moments.
Your app can't invoke a modal without a trigger_id from a user interaction, which creates a certain amount of intentional usage. But it should be as obvious as possible to users that particular actions will cause modals to appear.
Once invoked, a user can cancel a modal at any time. Handle these cancellations with grace. Don't try to force the user to proceed through the same process again.
Being considerate with messaging
Messages that alert users can be incredibly useful. Many Slack apps exist primarily to pipe notifications from external services into relevant channels. Here are some specific considerations that can help ensure the messages your users want don’t turn into noise.
Pick the right frequency of notifications
Consider how frequently your messages are generating notifications for a user. When it makes sense, offer the user an option to get a digest of these messages rather than being alerted for individual events. This is especially important when the events are coming from an automatic source like service logs. In extreme cases, sending too many messages can get your token revoked due to rate limits.
When your app generates a lot of notifications, users will notice (and might grow annoyed). This can lead them to remove your app from a channel or even to uninstall the app from the entire workspace. One way to mitigate this is by surfacing messaging preferences often. Make it simple and intuitive for people to use your app how and when they want.
Here's an example of an app that builds a preferences link into the actual messages:
Match message types and channels
You may already be segmenting or categorizing the types of messages that users can receive. If your service already does this, you can make the Slack notification experience even better by giving people the option to pipe different message types into different channels.
For example, an HR tool might want to pipe messages about a candidate’s background check only into #hr-team, but after an offer has been accepted and signed, maybe a #new-hires channel wants to be notified so they can celebrate.
Don’t post to a workspace’s #general channel by default. You’ll likely be unnecessarily disrupting many users and there is probably a more relevant channel for your app to post in.
Make messages that notify actionable
Some messages are best as simple text that alerts a channel that something happened in a 3rd party system. But what if that user wants to dig into your service after receiving your message? Or what if you send a system status that requires immediate action?
You can save people work by adding action elements directly into your app’s Slack messages. Buttons, select menus, and dialogs let people react in the moment and get work done faster. If your app is considerate with alerts and saves people time, they’ll likely find your app an essential part of their workday.
Your actionable messages don’t need to be complex to be helpful. Just think about what action the receiver most likely wants to take. For example, if your app sends expense approval messages, the receiver probably wants to approve or deny the expense — interactive buttons are perfect for this.
Learn more about sending messages in our messaging docs.
Sending direct messages to users
First, consider when and whether you should send direct messages (DMs) to specific users. Remember that DMs generate push notifications for mobile users and badges on desktop and mobile. These are useful but also disruptive and can be unexpected, so be cautious with your use of DMs. You should only DM a user when:
- The user sends you a DM first.
- The user is the only one you’re providing a service to, rather than the team.
- Your app is sharing confidential interactions or information.
Users will assume that information shared back and forth with your app in DM is private. Be aware of any sensitive information that’s being shared, and don’t surprise users by announcing results of DM conversations in channel without letting them know first.
By default, apps are set up with a messaging tab that allows the app to broadcast messages only, without needing to anticipate or respond to human interaction.
Need to send a DM? Read our guide to finding conversations via the Web API and then about sending messages.
Responding to users in channel
Whatever you post in channel is going to be long-lived and add to the group conversation that people are reading, both in the moment and later when they may look back at what was shared.
In response to a user action, an app could publish an in-channel message, or an ephemeral message. In-channel response will be visible to all channel members where the user invoked the action. Ephemeral responses will only be visible to the invoking user.
Remember that a chatty app is not necessarily a good thing, so only pick responses that are important to the entire team when posting in-channel.
If the response only needs to be displayed to the user, it’s a better idea to use an ephemeral message than it is to generate a DM.
