General design guidelines for Slack apps

Storyboarding your app will give a rough idea of the visual composition of your app's workflows. Now is the time to refine those sketches into fully-realized designs.

This guide contains a non-exhaustive series of tips and best practices to keep in mind when composing your app's surfaces.

Keep it glance-able

Layout blocks allow you to compose visually rich layouts with interactive elements such as buttons, menus, and date pickers. With the ability to use so many different blocks in different ways, it’s easy to overload. For example, take a look at this message:

App message featuring too many buttons

While all of those actions are valuable, it’s difficult to intuit the most important action to take on the message.

Interactions should focus on what members are trying to do right then and there. Focus on the simple, common tasks that make sense to complete inside Slack. In this case, we could use the overflow menu to de-emphasize the less important actions:

A refined version of the earlier example showing only confirm/reject buttons and an overflow menu button to hide extra options

Keep text segments bite-sized and conversational

People don’t read big blocks of text. They do read short ones.

Pictures are worth a thousand words

Sometimes faces can be better than names, or maps better than addresses. Sprinkle image elements into blocks to remove some of that text.

This message is okay:

App message featuring a text list of tagged users

But this version is more interesting, without losing any vital information:

App message featuring the tagged users as profile photos instead of text

The example above is using a context block, which is great for storing information that may be helpful in a message, but isn’t primary content. Context blocks can store text, images, and emoji.

Use interactivity to reduce complexity

The workflow within apps might be complex, with many options along the way, but the face they present doesn't have to be. Use interactive components to break workflows into steps, and only show what’s needed for the current step. Let interaction choices reveal further information or options when they’re necessary, not before.

For example, this calendar app has a lot of information and interactive options to display:

Calendar app message featuring lots of text and interactive options

But it could achieve the same functionality by keeping advanced options tucked away until they're needed. Here's the same app using context blocks to better organize info, and an overflow menu to store lesser-used options:

Calendar app message where options have been hidden behind interactivity, and other elements turned visual

Choose sensible default options

Save people work wherever you can by minimizing the choices they have to make. When you give select menus and buttons good default values, you decrease the number of choices they have to make from many to a simple one - yes or no.

Coffee ordering app message showing previous order and asking whether to reorder it with yes or no buttons

Say your app helps people buy coffee. Instead of presenting a full menu of choices every time someone orders, you could make the user’s last order the default option. In the best case scenario, this reduces the coffee order to a single click.

Cleaning up after your app

Visually rich messages are great in the moment you receive them: they’re easy to read, nice to look at, and simple to interact with. They also take up a lot of space on a person’s screen:

Lunch group app message showing text and a couple of buttons

Think about what a person will need to remember about their interaction with your app when they come back to it later, at the end of the message’s life—or after an exchange of several messages. Do those buttons and menus need to stick around, or can you condense the message down to a simple text record of what happened?

Be considerate and update your message after the interactive flow or the conversation expires:

Lunch group app message after cleanup, with the buttons gone

Read our guide to updating messages to see how you can cleanup after your app has done some work.

Use the right surface for the task

When workflows are directly invoked by users, your app will need to use a bit of contextual knowledge to figure out the best place to respond.

Just because the invocation happened in a channel doesn't mean that the other members of that channel need to see the rest of the process, or even the end result.

Perhaps the right thing to do is to take things to a modal, where information can be collected, decisions made, and workflows finalized, quietly and privately.

Was this page helpful?