Sparking the next Slack app revolution with new surfaces: App Home and Modals
At Spec, the Slack Platform team made a call to revolution with the new Slack App Tool Kit. The new granular permissions, block kit enhancements, and actions are all extremely important. But based on our experience over the past several months, the new surfaces APIs, specifically App Home and Modals, lay the foundation for the next user-centered Slack app revolution.
We shifted our entire backlog to App Home and Modals after that first day at Spec. It’s been an intense six weeks since then. We’re launching our new, re-architected app today.
Here’s why I think Slack’s new surfaces will change how the world thinks about Slack apps, how we came to the decision to re-architect our app around the new App Home and Modals surfaces, and what we learned while building our new Slack app experience.
The End Of App Fatigue
The new App Home and Modal surfaces move Slack apps from a command-line “type-and-read” interface paradigm to a mobile-like “tap-and-go” experience. And the ratio of people who prefer typing to tapping is probably something like 1 to 1,000,000. That’s a big deal.
But there’s something even bigger going on here. Slack is ending app fatigue.
I’ve worked on communication, collaboration and workflow apps for a couple of decades, and I think everyone had it wrong until now.
In the old view, people communicate in channels like email and chat. People collaborate on artifacts like documents. And apps are like islands, places people go to do whatever special thing the app does. In the natural course of this thinking, collaboration patterns get built into apps, communication comes out of apps, and APIs connect separate apps together.
The result: people feel overwhelmed by all the apps they have to deal with.
The new surfaces in the Slack API upend this by finally giving people a personal, useful and simple context for the key apps they need to get their job done. Personal because apps become features built into each person’s Slack workspace, where all their inter-personal work gets done. Useful because the new surfaces provide the right UX for core app workflows. Simple because Slack apps are highly constrained to usable patterns.
That simplicity extends to how multiple apps are organized in Slack. The handful of core apps people use regularly are as easy to access as people and channels. Other apps that people use once in a while can reach out with messages when needed. And the rest are just a search away.
Based on our experience, people LOVE the simplicity of an “apps are just Slack features” world.
Cloverpop is an app to keep track of decisions with decision polls, announcements and approvals. We used to get app fatigue objections from prospects all the time. Worse, without the context of Slack, my elevator pitch sometimes required a ride to the moon. People had a hard time seeing exactly how software could help with their decision-making. We also had to do fairly extensive user training, and adoption was slow.
Now I say, “We help keep track of decisions in Slack,” and business people say, “Oh, that makes sense.” Even better, they then actually go use our app, with ZERO training.
Our app features are mostly the same. Our app context has totally changed. And that makes all the difference.
Our Path To App Home And Modals
Our path to this new world paralleled the journey the Slack API was on this year.
In February, the launch of Block Kit first drew our attention to building a standalone app for Slack. We’d had a table-stakes Slack notification integration for a couple of years. It was useful, and it was enough at the time because we didn’t believe that a chatbot interface could solve the core challenges of decision-making at work. Then with Block Kit and the roadmap promise of multi-step modals, we started believing it was now possible to keep track of decisions without ever leaving Slack.
So we went all-in, and essentially bet the company on building a killer Slack app.
It took us until August to build out the MVP feature set using Block Kit messages. Our first beta and usability testers loved the idea of the app but gave us some fairly devastating feedback about our Slack app experience:
- People kept wondering, “Where did the app go?”
- People hate walls of text (from bots).
- Almost nobody likes /slash commands.
- Data entry grates on people.
Yikes!
That’s why, when Modals came out in September, we immediately re-architected our Block Kit messages, using Modals to address some of these issues, and betting that multi-step modals would come soon. We soft-launched the spiffed up app on the Slack App Directory on the first day of Spec. Our usability sprint results and active use improved dramatically — the app was easier to understand and use — but those four fundamental problems still remained.
Then, the Slack Platform team presented the new Slack App Tool Kit at Spec. We were blown away. By the end of the second day, we had already thrown out our backlog and focused all our efforts on re-architecting our app around an amazing App Home and Modal experience. Our goals:
- Give our app a persistent home.
- Tear down the walls of text.
- Move /slash commands to the background.
- Make data entry incredible.
The result six weeks later? Done, done, done, and done
What We Learned About App Home and Modals
As a preface to this section, I want to point out two things.
First, during nine intense months building a sophisticated Slack app, we have been continually amazed at how rapidly and on target the Slack APIs have improved. As a recent example, we had intense internal conversations about how to support mobile users…and now, voila, App Home works on mobile. In another example, we were grumbling about radio buttons not working in modals (radio buttons, hello 1988!)…and now, they work. When you are making plans for a multi-month Slack app project, remember this: at the beginning of this year there was no Block Kit!
Second, we were very confident in our re-architecture decision based on our years of customer research (e.g. How Humble Leaders Unblock Team Decision-Making) and the results of our continuous usability testing. The Slack App Toolkit was like Christmas in October for our product designer — we knew we needed App Home before we knew what App Home was.
Let’s get into the details of what we learned.
Giving People A Persistent Home
Before App Home, our app-home-opened message was a combination app tour and launchpad for our key features: decision polls, announcements, approvals, results and search. People loved it…but it was also the source of our hardest usability problem.
We called it the “persistent-button problem,” and it was summed up by a usability tester this way: “Wait, where did the app go?”
For that person, the message had just scrolled out of view above the fold, but in their eyes, it may as well have vaporized. Other users dismissed or deleted the message in various ways and couldn’t figure out how to type /cp help to get it back. We tried a few different message-based UI hacks to solve this problem, and none of them really worked. We even had the dreaded “Maybe we can make a video or help doc to teach people how?” conversation.
Now with App Home, people always know where our app is, and every major app action is just a click away.
Moving /Slash To The Background
In our usability tests, most Slack users are somewhere between “meh” and “ick” when it comes to text-driven bot interfaces. Of course, many people reading this article probably love the efficiency and control of the command-line…but you are not normal 😉. Because of this, we made sure that people could use our Slack app successfully without ever typing a /slash command. I think that is a good goal for almost every app. We still support /slash commands, and even plan to implement a few advanced features as /slash command shortcuts so they don’t clutter up the App Home user interface. But the core of our Slack app experience is now button and modal workflows, not /slash commands and messages.
Tearing Down Walls Of Text
People hate getting too many messages from bots. Luckily, the new modal surfaces let us do some massive message trimming. First, we were able to move all data entry out of messages (ick) and into modals (ahhhh). This eliminated all of our data entry ephemeral messages, which was a huge win.
Before
After
We were able to dramatically shorten messages by putting extra details into modals. This also let us use the same non-ephemeral message to give different experiences to people with different roles, e.g. a decision contributor could click Show Results to see a modal more decision details, and a decision owner could also edit those details in the modal.
Before
After
Finally, when a message is generated by a specific decision-maker action, such as a decision announcement sent by a decider to multiple channels, we send that message FROM THE PERSON, not from our bot. This requires the chat:write:user permission scope, but it’s appropriate for the use case, makes the message more personal, eliminates another bot message, and even makes the message deletable (nice).
Incredible Data Entry With Multi-step Modals
Any task feels easier if you break it apart into smaller steps, and this is especially true when it comes to data entry tasks. We tried as best we could with messages, but multi-step modals let us really advantage of this design principle.
First, we made sure the first step for every workflow was as friendly and streamlined as possible. This is especially important to give first-time users a friendly experience, but I also believe it gives apps a lighter feel and reduces cognitive load for everyone. Second, we hid optional fields behind buttons so they were there for advanced users but didn’t get in the way for everyone else. Finally, we grouped and ordered the fields to minimize cognitive load, while cutting anything we could along the way.
Let me use our Decision Announcement workflow as an example. We use it to gather the details of a decision before announcing it to all the teams who need to know. Here is what our old message-based workflow looked like:
In a way, the experience was broken into steps because the button opened a modal for text entry that was separate from drop-down controls for selecting people and channels. But the user was still confronted with everything at once, and the steps were disjointed.
Now here are the steps in our Decision Announcement modal — it just feels right!
In Step 1, we put the two required fields right up top with some helper text, used a button to hide two optional fields, and used a multi-select control for an optional field for entering the names of people who contributed to the decision. We show that optional field as a best-practice nudge, because our research shows it dramatically improves the effectiveness of decision communications. And we included “Type to search” helper text because we’ve found that some people are confused by how Slack’s multi-select drop down works. All of it fits in a standard modal without scrolling.
In Step 2, we put the destination of the announcement as a multi-select, and we added another optional field, the Buy-In rating. Although it is optional, we default it to ‘yes’ as another nudge based on our research into the importance of getting rapid feedback from people who are impacted by our decisions.
This Step 2 grouping of the people who need to know with a nudge to get feedback from them seems subtle but has a major impact on the user experience. This happens thanks to a powerful usability trick that Nobel Laureate behavioral scientist Daniel Kahneman called WYSIATI, or “What You See Is All There Is.”
Before, our old message-based UI had all the steps laid out together, and people in usability tests would often say something like, “Yeah, we don’t need people’s feedback. That’s not how our company works. We made the decision, it’s done, they just need to go do it.” They saw their decision together with the nudge to get feedback, they knew that other people’s feedback might run counter to their decision, and their emotional brains said fuhgeddahboudit.
After, in Step 2 of the multi-step modal, people usually say something like, “Yeah, I like that. Getting quick feedback is really important to get everybody’s commitment and make sure we didn’t miss something.” Now, the decision is hidden but the people and channels are front and center, so the WYSIATI trick works — the decision-maker sees the value of that nudge to get feedback and their emotional brains never trigger resistance.
The New Frontier: User-Centric Slack App Surfaces
It’s clear to us that the new App Home is not just for welcome tours and dashboards — together with modals, it’s a way to build more user-centric Slack app experiences. For most people using Slack, it just makes sense to have a place to go where they can use simple workflows to do what they need to do.
App Home might not be as transformational for your app. The best way to find out is to get user input early and often.
We’re still learning a lot every day about building to the new Slack app surfaces. We’ll keep sharing what we learn on the Cloverpop blog as we go. If you think I’ve missed anything or have any questions, let me know on Twitter, @erikdlarson.
