#PretendProduct : Slack Improvement - “Mark as read when”
Pretend Product is a series of product improvements or inventions based on my everyday problems.
I am writing this from my own perspective with the assumption that others can relate. That may be a wrong assumption but I hope you enjoy reading my thought process if the problem itself doesn’t resonate with you.
Every good product starts with a user problem to solve
User problem: I forget to respond to a message that I clicked into or briefly read but did not actually think about answering/actually answer.
Business problem: Slack’s mission: Make work life simpler, more pleasant and more productive.
Slack’s current solution to the user problem: mark unread feature or remind me feature.
I had been using the remind me feature in order to get reminded. It’s not a bad feature but it does inconvenience me when I get a notification at a time that I can’t do anything about it. Yes, I can tell you to remind me in 3 hours but we both don't really know where I’ll be or what bandwidth I’ll have to address this in 3 hours.
I’d be reminded only to have to click into the same message and select to be reminded once again later since I am procrastinating or just cannot attend to the message at the moment. This accumulates Slackbot messages which add busyness and noise to the interface which can be overwhelming if you utilize this often or just generally have a lot else going on within Slack.
The other option is to mark unread. I only recently discovered this.
This is great and all but, alas, busy bees like me forget to mark unread what they see. Fast forward to follow up messages from others asking me if I did, read, or sent something when in reality I had never truly registered the original outreach or request!
So how do we get around this, Slack? Clearly, you are already trying very hard to help me, but I am a mess. In my defense, any good designer knows that all that can go wrong will go wrong and users can be stupid.
Proposed Solution
You can maintain current default functionality while allowing users in preferences to customize what behavior constitutes a message as read.
I imagine the flow to state “Mark a message as read when” followed by checkboxes of options:
“a message has been opened for x seconds”
“Mark as read when a message has been opened for x seconds” where x defaults to whatever the value is in your system at present, let’s say 2 seconds. I can then adjust this between 0 and 60 seconds. 0 at the lowest end because users can read a message in the notification pop up already before clicking into it. 60 seconds because I am making the assumption that the users who need messages to remain open for any time frame longer than an entire minute are a negligible user base.
A future iteration of this would involve the default value in the unselected checkbox field being the most commonly selected number of seconds across users to reduce friction in the user experience.
“I react to a message”
“Mark as read when I react to a message” A reaction being any emoji reaction to a message. Users who begin to react by opening the emoji menu will not be considered a reaction because that behavior indicates that you may have changed your mind and will come back to it later (which is the behavior we are trying to support with this feature improvement).
“I start typing a response”
“Mark a message as read when I start typing a response” is an option for those users who can consume a message in varying amounts of time so customizing a time threshold may not make the most sense. They may also not use reactions all that much because they want to keep it all ~professional~. This option is for them.
Edge cases
What if you selected to mark unread after 4 seconds and you spend 6 seconds on the emoji menu but never pick an emoji? In those cases, it will be marked read upon whichever condition is reached first.
4 seconds have elapsed. Therefore, a criterion for marking as read has been met and the message will be marked as read.
Tradeoffs: The beauty of customization is that I am less likely to have issues with the user experience when I design it for myself, AKA customize it. A user may grow irritated that things that they read are not being marked as such but then it is on them to adjust their own customizations. Your design did not box them into a poor experience; they did that for themselves and you have allowed them the freedom to change those choices with this checkbox of options.
You could also argue that even with these customizations, I still am forgetting messages. In that case, you could ideate some design solutions around nudging. Gmail gives nudges when I haven’t received a reply to an email that I sent or when I do not reply to an email that was sent to me. However, for Slack, that would be a difficult venture given that conversations just end. It would be challenging to know which conversations are worth nudging and which would just be a nuisance of nudges. Slack is a more conversational environment than Gmail so you cannot blanket transfer nudging into Slack despite it being a communication playground for organizations just as email is.
Rollout: Slackbot. Our handy little friend Slackbot can send us a message to let us know we now have the option to customize this (else how will we know? I personally don’t browse the preferences menu to see if there are new updates. I hope you don’t either.).
Measuring success: I’d measure success by a decreased use of “remind me in” and “mark unread” features and an increased measure of messages sent since users are now remembering more to reply to things that they receive.
Does this matter?
Let us return to the basics.
User problem: I forget to respond to a message that I clicked into or briefly read but did not actually answer.
Since technology has not advanced enough for us to enter one’s head and cure forgetting via a software product, this solution tackles the “briefly” part of the user problem in a couple of different ways; utilizing behaviors that already exist on the platform to act as markers for whether a message should be marked unread or not. yet.
Business problem: Slack’s mission: Make work life simpler, more pleasant and more productive.
This solution is simpler in that it reduces visual crowding from Slackbot messages which the current “remind me in” feature adds to. It would lead to increased productivity as people remember to do the things they need to get back to more easily.
Furthermore, I believe this would have a secondary effect of increasing revenue because as people increase messages sent as a result of actually remembering to reply to each other, a workspace approaches the storage threshold faster. For those that have surpassed the free threshold, more messages would mean more messages getting deleted-which users do not want-and that leads to more incentive to subscribe to the paid tiers of Slack’s product.
Thoughts?
I’d love to hear your feedback on this idea. Is this something that you’ve thought about? Disagree with? Have improvements for my suggested improvement?
Let me know on LinkedIn or write your own proposal for a feature change and send me the link to the post!
