Close your eyes and imagine yourself using Slack. What are two phrases you’d use to describe that experience?
Whatever your phrases are, hopefully they’re at least somewhat synonymous with “Don’t make me think” and “Be a great host.” These are the two of five organizational product principles that we live by when it comes to defining Slack’s product experience.
If you’re a frequent reader of Slack’s design blog, you might remember Ethan Eismann, our Slack SVP of Product Design, telling you why your organization needs product principles. It’s a goodie; if you haven’t read it yet, I definitely recommend it. Ethan shows how organizations benefit from setting up product principles, what product principles are, and how to create your own.
But the closer you get to a specific product area, the harder it is to turn to broad conceptual principles for actionable guidance. That’s why, in addition to the organizational level, we also create and apply the magic of product principles to increasingly specific product areas. These sub-principles add the specificity needed to create alignment, clarity, and focus across teams and over time. Here’s how they’ve helped us strategize and collaborate to bring new life into Slack notifications.
Rejuvenating Slack’s notifications strategy with product-area principles
Let’s be honest: Notifications are inherently rude. They’re one of the only ways a product can intrude in your life and demand your attention. At Slack, our team prides itself in delivering empathetic, human experiences. When life shifted to working from home, we realized that notifications were suddenly far more distracting than they were previously. Rather than let our users down, we turned to creating product principles to align on a strategy for Slack notifications.
The first thing we did was consider how Slack’s organizational principles applied specifically to notifications. Embodying “Be a great host” we started by processing volumes of customer feedback. What stuck out to us the most was the fact that even though notification systems are complex, people hardly think about them — notifications should just work. Keeping this in mind and expanding on “Don’t make me think,” we came up with our first two product-area principles: 🧠 intuitive and 🕹 actionable. By these, we mean that interacting with notifications should be a breeze and people can easily get what they need done. Another takeaway from our customer feedback was the overwhelming number of super-specific customization requests. Continuing to “Be a good host,” we derived a third principle, ❤️ personal, to ensure we respect each user’s unique situation.
🧠 Intuitive, 🕹 actionable, and ❤️ personal: These three single-word (and emoji) principles were designed to be both easy to remember and widely applicable to our many notification products. In fact, we chose words that we found ourselves already using when describing the ideal notification experience. From a week-long design sprint for notifications centered around these principles, our team emerged with an idea to prototype a product to streamline the notifications you care about (❤️ personal) into a single predictable place (🧠 intuitive) for easy processing (🕹 actionable). We’re still prototyping these directions, so I’ll stop here before I spill too many beans.
With the principles in place, we could better define what we needed to do. From a roadmap perspective, we prioritized projects to make notifications more 🧠 intuitive, by helping new users better understand notification mechanisms; 🕹 actionable, by making notification troubleshooting more seamless; and ❤️ personal, by expanding what you can choose to be notified about.
On a more grassroots level, folks on the team have also been inspired to improve notifications even further during self-directed hack weeks. Through these individual efforts, notifications have become more 🧠 intuitive with iOS notifications clearly stating the sender and recipient, 🕹 actionable with the flexibility to address mobile notifications on desktop, and ❤️ personal with more control around what in a channel can notify you. As we continue to push the product forward, these principles help us strategize where and how to do it.
Cross collaboration with individual-product principles for Slackbot
If you use Slack, you’ve probably noticed that Slackbot—the sometime- helper, sometime-messenger, always bot—is a prominent source of notifications. But we didn’t want it to become an over-utilized, overly eager virtual assistant, so we created another set of three principles to address the even-more-specific needs of this notifications product. In addition to being 🧠 intuitive, 🕹 actionable, and ❤️ personal, Slackbot also “helps the user, not the company,” “supplements, not mandates,” and “always represents Slack.”
As a third-tier subset of product principles (organizational→product area→individual-product), these individual-product principles are really specific. Notice how, unlike the notification product-area principles’ emoji-and-single-word pairing, these more detailed principles employ a do-and-don’t language structure? This is because they’re designed to act as more granular product guardrails for what Slackbot messages should and shouldn’t do. People often think messages from Slackbot are also messages from Slack and the principles keep us deliberate about what we choose to send.
By establishing Slackbot’s individual-product principles, we’ve also democratized who decides what messages are appropriate for Slackbot to deliver. It becomes every designer’s responsibility to make these considerations. Here are some examples of our considerations:
- For a designer on our growth team, how might sending a promotional Slackbot message to download the Slack app “help the user, not the company”?
- For a designer on our core product team, how might we allow Slackbot to “supplement, not mandate” when it comes to managing reminders?
- For a designer on our developer platform team, will Slackbot “always represent Slack” if we allow 3rd party integrations to send messages via Slackbot?
Because no designer can be there for any product into perpetuity, product-specific principles are a handy way for product designers to collaborate across time. We distribute the responsibility of maintaining a product like Slackbot among everyone on the team. Not only does this keep Slackbot from becoming the victim of a tragedy-of-the-commons scenario, it also empowers each designer to ensure a product behaves the way it’s intended to.
Because no designer can be there for any product into perpetuity, product-specific principles are a handy way for product designers to collaborate across time.
Layering principles builds a stronger product
The layered product principles for notifications helped us guide a general strategy and maintain a product area here at Slack, but other products may have different needs for their product principles. The trick to layering product principles is to make sure they work together and have a clear purpose. If you can achieve both of these conditions, you’ll find that layered product principles are a great tool to drive not only product development, but also product character and identity. So give it a spin — I think you’ll be pleased with the results! ✌️
—
Kristin Au is a Senior Product Designer at Slack and design mentor on ADPList.