Spam Reporting

Designing for Emotion and Experience



The Preamble

Spam activity was a growing concern during my time at Kik. Spam was measured through various metrics, one which is the amount of support tickets coming in from our Reporting feature.

The amount of spam support tickets coming in at the time was growing, and it was becoming problematic for both our Customer Support team and users. We needed to take action and reduce the amount of spam support tickets in.

To tackle this problem, I was responsible for improving the design of the existing Reporting feature.

The Problem

Why do we need to solve this problem?

The problem is increasing amount of support tickets. It was a problem that had a domino effect:

  1. The Customer Support team could not address the tickets quickly or efficiently

  2. The end users’ needs were not addressed correctly or quickly

  3. An extra layer of frustration was added to the end users’ existing frustration


How did this problem arise?

Before I tackled on improving the existing design, I spoke to our Customer Support team to ask them what they saw in the support tickets and how they addressed them.

Therein lied the answer to how the problem came about: The Customer Support team could not handle the support tickets effectively because the users’ report was not always in agreement with their experience. For instance, if the user had a negative experience with another user, the user would report them as a spam bot.  As a result, the Customer Support team could not tackle the tickets effectively, because of poor quality and inaccuracy of the reports.


Reframing the problem

Upon learning the Customer Support team’s experience, I reframed the problem I had to tackle:

How might we improve the quality and accuracy of the support tickets coming in from the Reporting Feature?


The Solution

Initial explorations

Initial explorations

1. Improving the User Flow

The existing design had the “Include Chat History” option coupled with the Report option. This caused friction in the user flow, and it was unclear to the user whether they selected the Report option or “Include Chat History.”

“Include Chat History” was moved to be more visible to the user. It is deselected by default to protect the user’s privacy


2. Remove The Icons

Emotions and Salient Cues

When users use the Reporting Feature, they are in a negative headspace. Thus, I removed the icons to prevent users from reporting based on the visual indicator that is the most salient to them.

Focus on Copy

In design, icons are used over copy to communicate features, functionality, or ideas in a quick and recognizable manner to many users. I decided against using icons and removed them from the feature. Copy became the focus to slow down and nudge the user into reporting the most accurate experience.

Representing Emotions

The existing design of the Reporting Feature used icons to communicate and represent feelings and emotions- both of which are abstract ideas and are experienced differently by each individual. I removed the icons, because it was ultimately a disservice to represent feelings and emotions to a single icon.


The Result

The changes to the Reporting Feature improved the quality and accuracy of the support tickets. As a result, the Customer Support team was able to address tickets correctly and more quickly This lead to significant decrease of spam activity on Kik, and a better experience for our users.

Additionally, the design introduce a new design pattern for Kik’s design system, and it was used a guideline for similar feature, Reporting for Group Chats.

Principles Learned

Design within context. It’s easy to get caught up on using visual design as a way to quickly communicate an idea, thought, or concept. You need to go against a pattern sometimes if it doesn’t apply to the problem you’re solving.