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