This post is a critique of the presentation on the Slack app during CS3216 Application Seminar (Assignment 2).
Key Takeaway 1 – Competition & Unique Selling Points
The presenters have correctly identified some of the competitors of Slack: Discord, Gitter and Zapty. They also mentioned the strength and weakness of each app and how Slack is different from them.
I believe this is a very key aspect to consider when analysing any kind of application. A new application requires unique selling points, features that existing apps do not offer, in order to attract users. As the application grows, it has to consistently watch out for new competitors. If the competitor has a new cool feature, it has to respond by either copying the feature to satisfy users, or justifying why the app would still be useful and competitive without doing so.
In the case of Slack, the presenters have pointed out key features that differentiates Slack from the competitors. Slack was the pioneer in “bot” feature within chat room (not counting IRCs which are too technical in nature). It has various integrations that differentiate itself from traditional team messaging app. However, that does not mean Slack will always win the battle. In some areas like scalability issues and customer engagement, it has already lost to gitter over the Free Code Camp incident where its “unlimited users” turned out to be a false promise.
Key Takeaway 2 – Hitting the Pain Point(s)
This is a really interesting case of “hitting the pain point”. As we have learnt from various entrepreneurship courses and CS3216 itself, the main idea behind an app should be to “kill” a pain point.
Slack does solve a pain in managing team communication by having teams and channels. However, it did not stop there. Instead, Slack went on to introduce a pain, which is the message limit. And that, is the key takeaway here.
After you have successfully solved a problem, the next problem would be how to get back the reward from users for solving that problem for them, i.e. how to monetize the app. This is where different strategies come in: donation, in-app-purchase, subscription, pay-for-usage, etc. This is where I think what Slack has done well. It is engineering the pain for users and asking the users to pay to get rid of it. It creates the message limit artificially and charge the user to remove the limit. Why is this so effective? I think it is because the pain is not immediately felt by the user. Instead, it is revealed much later when the message limit is reached. Hence the overall experience of the user is still good and they will be willing to pay the price to get back the same level of enjoyment before noticing the pain.
So lesson learnt? Hit the pain point, but also create pain points.
Key Takeaway 3 – UI/UX Design
This is also a very interesting topic, because this is where people tend to disagree with each other. Not surprisingly, the team presenting pointed out that some UI/UX Design in Slack is not very good. For example, some functions are not easily accessible, the icons in the menu may be confusing for new users and the permissions for team/channel is messy.
However, I have also heard a lot of praises from people about Slack. The keyboard shortcuts, the sleek UI, the nice little things like custom emoji and loading messages. So why the polarity? It is because people have different perspectives and different focuses.
For a user whose role is primarily receiving information, he/she does not need to know all the permissions and menus, hence the big chat message box is good enough for him/her. As developers, we tend to be more “savvy” than average users, hence we feel the need to organize things logically in a certain manner. However, the same requirements may not apply to other users who have different needs when using the app.
For Slack, since it has only one interface, it has to suit both power users who wants all features accessible quickly, but also normal users who do not care that much. Hence I believe its design may be justified based on user studies. Nevertheless, the presenters offered a very good suggestion, that is to have different UI for different types of users. By customizing UI based on user’s individual needs, everyone can choose their own UI based on their preference and style. There would not be the issue of meeting the needs of certain people in the expense of others.
Thoughts on Application Seminar
Pecha Kucha Means 20*20
We are using this Pecha Kucha format for presentation, meaning each slide has to be exactly 20 seconds with auto-advancement, and the total number of slides has to be exactly 20. After listening to the presentation of all groups, I noticed that some groups are having a really hard time trying to catch up with the slides because it auto-advances before the presenter finishes his/her point.
Is this an inherent flaw of the Pecha Kucha, that you will always be rushing to finish the point? I believe not, and there is a solution.
I noticed that many groups are trying to cover exactly one point in exactly one slide, because it is the most intuitive thing to do when you are giving the normal presentation. However, this can be changed to adapt to Pecha Kucha. As illustrated by the sample video provided on assignment page, you can use 20 seconds to cover more than one small points, or use 40 seconds to cover one big point. So in reality, the format is not as rigid as it sounds. Also, with some help of transitioning phrasing between slides, the presenter can actually start the next point before the slide advances. This is similar to the technique used in cinematic productions where the voice from the next scene begins before the first scene ends on the screen.
Background Research = NIL
Another issue that many groups (including my own) faced was the lack of thorough background research. This is reflected very clearly during the Q&A section. When asked about market share or security/privacy issues, many teams started Googling in real time.
I think this issue needs our attention as students. Although background research was not an explicit part of the requirement for the presentation, it should still be the first thing to do when preparing the presentation. After all, if we are presenting on a product, and we have to be knowledgeable about it in order to qualify as a presenter of it in front of the class.
Maybe it was due to the tight timeline and concurrent assignments, we all seemed to have overlooked that process. For future presentations, I would remind myself and my teammates to conduct a decent background research on the topic before jumping into other sections.
Bonus content:
Read this and this before commenting on other people’s blog to increase your marks!
Cover image from http://thesouthern.com/news/opinion/thumbs/voice-of-the-southern-thumbs-up-thumbs-down/article_9dadfbdf-f1f3-52c4-8b75-b40abd0f87c4.html
Hey! I too liked it when the Slack presenting team mentioned the point about creating a pain point. Also agree with you on that was not the only thing they did, because they did afterall remove a pain point in the first place. Just a random thought – if they made the pain point too painful, do you think users will simply switch to other competitors?
Yes. I do think there has to be a line drawn for how much pain is okay. Otherwise, users would simply look for other alternatives. This was the case for FreeCoderCamp and Slack, and there are many other alternative messaging apps like gitter and Mattermost.
Thank you for critiquing our presentation! You are right in pointing out that the lack of background research — the question on Slack’s security features completely flew over our head as our team was too focused on knocking off each of the assigned presentation questions.
Even though we did criticise the app for it’s UI, I will admit that we also felt that hiding options (for permissions, pinned items, etc) was a double-edged sword because it wouldn’t be too overwhelming for first-time users. It made the barriers to entry to using Slack slow, which I’m sure contributed to its rapidly growing popularity.
We would have brought up this point if we had more time, but unfortunately we didn’t. This supports your point that we might want to rethink the Pecha Kucha format — Indeed, I found myself rushing through the slides myself.
I agree with you that presenting groups should not be googling for information during Q&A. If the question is that simple, the audience can most definitely google it themselves… Most of the time, these “prompt” questions are just to check if the presenters have considered a certain angle. Often, the follow up question would be for the group to present their own opinion on the matter.
Perhaps the teaching staff should make it clear that Q&A will be graded, so that future groups will be prepared for Q&A, thus improving the quality of discussion. It seemed that a number of group did forget about this, and only focused on hitting those 7 listed points.
Unique and useful (to the consumers of course) selling points are definitely the key ingredients needed for products success.
However, I can’t fully agree with you on “creating pain points” unless those pain points are in consistent with the products’ aim. For instance, although blamed countlessly by the consumers, WeChat simple don’t have a easy way of switching between current viewing article and chat screen. And 张小龙 simply don’t want to add extra complexity to WeChat as he believes WeChat is a bit too heavy now, and he doesn’t want all users to stick on WeChat unnecessarily as oppose to what most PM tries to do.
In the case Slack, sure, the developers can delete extra message from DB if the user doesn’t pay for membership. However, when pinned messages are considered, I guess it won’t be a convenient feature for the customers, right? I guess set a separate free pinned message limit could be a better idea — this doesn’t violate their business model, but mean time make the user experience better.
My point is, it is okay to still have imperfection in use experience when your application has addressed most of users’ need, but those pain points shouldn’t be created on purpose, and the team should try their best to improve the product when it’s not going against the business model or company’s culture.
In addition, you are the first blogger who have commented on the presentation style (1/6 I’ve seen so far). Good points. 🙂
Yes, I absolutely agree there should be some way of storing certain messages permanently in a channel. This is a serious issue that would drive people away especially if it was discovered in an unfortunate event where the message is of critical importance to the user.