A product case study by an aspiring product manager.
Up on the stage today is one of the rising workplace collaboration platforms — Slack.
For those who are less familiar, Slack is a messaging application focused on allowing users to connect via chat, phone or video calling. The platform is mainly targeted at connecting users within an organization, hence allowing for users to organize in groups called “channels” to work collaboratively on projects and exchange information.
As a SaaS company, Slack’s business model remains simple by charging its users with a subscription based fee. Although you can still use Slack for free, the unpaid version has significantly limited features available.
Although Slack is rising in popularity, there are several competitors that also offer similar services. Some notable players include Skype for Business, Facebook Workplace, and Microsoft Teams.
Personally, I have been using Slack in my current organization, and have come to love a lot of the features it has to offer.
1.Threads
I mean, who doesn’t love to start a separate conversation with a colleague while the rest of the team is engaged in a heavy debate?
All jokes aside, I love this feature because it reminds me the most of an in-person interaction that I would experience when I am physically with my team. It is common for side conversations to begin while the team is brainstorming, and threads has seamlessly facilitated that experience on a digital platform. Slack’s consideration of these in-person experiences when developing features is also key to forming a product that truly embraces its users’ need.
2.Emojis
Although most messaging platforms now tend to have a variation of an emoji feature, there was an aspect of Slack’s emojis that drew me in as a user. That aspect is the ability to create your own emoji.
By having this creative component, I was able to add significant personalization to the way I communicate with my team. Not only did the feature allow me to express my personality, it also created a sense of culture to a text based communication system.
While there is lots to love about Slack, it was important for me to turn a critical eye to the product and see what are some current user problems that Slack has not yet addressed.
For this portion of my blog, I reached out to several colleagues and friends who use Slack on a regular basis to conduct user research.
Through this exercise, I led Satisfaction Oriented 1:1 Interviews to understand what current users liked and didn’t like about the product.
Learning: I find these types of interviews can be tricky to conduct without accidentally anchoring your user to a specific portion of the app. For me, it was helpful to begin with asking open ended questions such as “What should Slack stop doing?” and “What is one thing Slack can do to make the experience better for you?”. Although users did not always comment on areas I had expected, it was important to follow the direction of their answer when continuing the conversation to avoid injecting my own bias into the feedback.
To highlight a few of the insights that I discovered:
1.Lack of notification customization
This insight was specifically related to users often missing notifications in a group chat or channel environment. For most users, the group/channel name appears bolded if the conversation has been updated, but when users are part of multiple channels, notifications are easily missed as many channels all become bolded.
Users wanted to have the ability to set how notifications looked for specific channels, and customize which ones they receive alerts. For example, users may only want to be notified of new messages for smaller, more intimate channels, compared to channels created for cross organization announcements with constant activity throughout the day.
2.Slack has become too “social”
Sending messages in Slack has become easier and more seamless on all devices, and now many users find slack to be a similar messaging platform to products like Facebook messenger and WhatsApp. Having an abundance of features such as Emojis and GIFs has shifted the culture around workplace communication to be more casual.
The ease of hitting send on a Slack message often leads to incorrect spelling, grammar and use of slang, making conversations not nearly as structured as they would be in an email. Due to this growing perception of Slack being a social platform, the sense of work life balance has also begun to diminish. A lot of user feedback pointed towards their need to check their work channels even if they are outside of working hours as there is a lot of pressure for instant replies. Even with the ability to turn off notifications, users still describe their need to open the app on their phone or laptop every few hours.
Although this feedback pointed towards a need to evaluate Slack’s strategy to improving work-life balance, I recognize that the solution may not be a one for all. The perception of work-life balance can vary significantly based on the organization, its size, and its culture.
3.Sending messages at the right time
An interesting point that was brought up in some way by many users was the idea of wanting to save a message to send later. The cases were unique to the individual where some wanted to draft a message and send it the next day, while others wanted to write down a message so they wouldn’t forget to reply.
4.Too many notifications
Many users mentioned that Slack was becoming similar to a social messaging platform, both due to the amount and length of messages being sent. One user said “I have people who no longer speak full sentences, and break up one thought into multiple messages like they would over text. But this is a workplace and I don’t want to receive 5 notifications for one sentence”
An interesting frustration that would be exponentially worse if the individuals had more than one thing to communicate.
Can you imagine getting 20 notifications that piece into one message?
I have only highlighted some of the user insights I found to be interesting, but there was so much more that came out of my conversations with current users. Its truly eye-opening to see the differences in perspective just by asking users what they like and don’t like after using the product.
I think 1:1 Satisfaction Interviews or Focus Groups are a great exercise to perform on a regular basis with users so that key user challenges, emotions and perceptions are brought forward.
With Slack, I decided to dive deeper into Insight #3, and performed some additional interviews to try and form a few user stories for the pain points that were mentioned.
The second portion of this post will be about my personal ideas on how to research, design and measure success for a potential solution.
First off, we started with consolidating all the user problems that fell into the theme of “sending messages at a later time”.
“I want to send this person a message, but it is after work hours now and I don’t want to bother them”
“I don’t need this person to do this task now, but I worry that I will forget tomorrow, so I will send him a message today”
“I work a lot with teams in the U.S and I always forget our time zones are different. Sometimes I realized I sent my message at an off hour, and feel bad later”
Taking these insights, I transformed them into the following user stories:
User Story #1:
As a user, I want to send out reminders to my team on upcoming deadlines at a different time so that they are not pressured to complete the work immediately after receiving the message.
User Story #2:
As a user, I want to write down and save my messages for later so that I do not disturb others if I am working before or after regular hours.
User Story #3:
As a user, I want to get on top of responding to various stakeholders so that I do not forget to reply to someone.”
After compiling, I could see a similar trend emerge from the user stories, which was that users wanted to be able to draft and save a message to be sent at a later time. Not to mention, many users are currently using alternatives such as e-mail when they need to send a delayed message.
In order to meet these user needs, I began to form the feature of Scheduled Messages.
It was important for me to consider what design system Slack has already implemented, and to leverage existing components to reduce inconsistencies in the user experience.
Click to see the full flow for Version 1 of my design:
Now that my prototype was ready, I needed to collect some user feedback and to do so, I ran some virtual usability tests.
Virtual usability tests can feel a bit limiting because users’ expressions and body languages when using the product can’t be fully captured. However, watching where users click on the screen to complete the task can still be insightful.
I ran a total of 7 usability tests across users with differing levels of familiarity in Slack.
I gave each person the task to create a scheduled message and carefully watched to see if the design I had built was understood intuitively by the users.
I definitely learned a lot from this exercise, but I wanted to highlight some key insights below.
1.Limited use case for Repeats
The ability to set repeated reminders or messages was seen on similar products, but my testing revealed that Slack users did not see a frequent use case in which they would schedule repeat messages.
Learning: Sometimes less is more. By having extra settings such as “Repeat Frequency”, it added confusion to the user experience and caused hesitation in whether they had performed the correct task. Although there may be edge cases where scheduled repeat messages are useful to the user, having it bundled with the scheduled messaging feature added more complexity and made it less intuitive.
2.Thread style pop-up was disorientating
Many testers expressed confusion when the message they were typing moved from the main screen into the side panel after selecting to begin a scheduled message. Users often ended up double checking the complete message that had moved over, disrupting the flow of the task and adding time to the process. In addition, because the design was similar to the experience of using threads, users were unsure if they could click away to other conversations while continuing to multitask on the scheduled message.
Learning: If you are leveraging the design of an existing feature to build something new, remember that users will likely interact with it based on their previous knowledge of the original feature. Hence, unless the new feature can function properly under the same UX as the existing feature, do not try to use the same design and flow.
3.Reminder and Send Automatically are different features
It became clear during testing that users were thrown off when faced with the decision to set a reminder or to send the message automatically. Although the choice to add these options had been clear for me, I realized that users saw the action of setting a reminder and sending a scheduled message as two separate features.
Learning: If I wanted to group reminders and scheduled messages together, I would need to present this choice to the user at the beginning of the process. In this case, users had started the journey under the assumption that they were setting up a scheduled message, and so when a reminder option appeared at the end, it added confusion to the flow. To keep the feature simple, it would be best to have a singular action for the user to complete.
On top of these insights, usability testing also highlighted areas of weakness in my design. Issues ranging from having unclear CTAs (Call to Actions), to using too many different button sizes were all aspects I noticed were causing minor disruptions to the user experience.
Taking all of the learnings I gathered during testing, I went back to my MVP and re-designed the feature.
Click to see the flow of Version 2 of my design:
In the real world, this new version of the MVP would move into the next phase of product development and find its own slot in the roadmap for when it will be prioritized and developed.
However, before I wrap up my study, I wanted to take a look at what measures of success I would have analyzed if this feature had been created and deployed.
Some metrics I would have tracked to determine success include:
Delayed Messaging Completion Rate — How many users opened and used the feature?
Usage Frequency — How many users re-used the feature more than once? What was the time between each use?
I had also considered “Time Spent on Slack” as an initial metric, but after some consideration I realized it would have been a counter-intuitive measure of success. One of the aims with creating features like scheduled messaging is to make Slack the predominant workplace tool for users, and to reduce the opportunity for a user to click away to complete a task they could have done in Slack. An increase in time spent in Slack would have been a good metric on the surface level — more time spent in app means less time spent using other products, right?
However I decided this wouldn’t be a good measure after considering the goal of Slack. Spending more time in Slack could also mean that users are confused or struggling to complete tasks within Slack, which goes against the product’s aim to provide quick and convenient communication tools for its users.
If you have made it to the end of this post, I want to extend a huge thank you for taking the time to read through my thoughts as I performed this exercise.
Please don’t hesitate to reach out if you have any comments or suggestions, I am always happy to discuss.
Email: lisachencal@gmail.com
