Notification Settings Case Study

My Role

Senior UX Designer and UX Researcher

Project Overview

After releasing the notifications center application, we monitored feedback from our sentiment survey for 3 months. Immediately, we saw a trend from those who had negative sentiment and left feedback. Approximately 76% of these users wanted to have more control over notifications.

Problem Statement

How might we provide a way for users to control the delivery method for notifications, the timing of notifications and they type of notifications they receive?


Goals & Objectives

I immediately began to reach out to the users who left feedback through our survey to interview them. Most expressed the desire to:

  • Select how they receive notifications
  • Specify what types of notifications they receive
  • When they receive notifications
user feedback

Ideation & Workshop Facilitation

I facilitated a series of workshops with a cross-functional team where we began to ideate ways to empower the user to have more control over notifications. We had ideas about expanding the notifications center UI to accommodate more features. Eventually, we landed on creating a place for notification settings and preferences.


Information Architecture Questions

Coming out of the workshops, we had an idea of how we wanted to approach the UI and how we wanted to structure the API. However, we needed to run these ideas by our users. One outstanding question was how to access the settings and preferences.


Using a Moderated Cardsorting Exercise to Help with Navigation

From a UX perspective, we had questions about the information architecture. I used a moderated card sorting exercise to determine the best way to handle the navigation to the settings.

flow chart

Unmoderated A/B Testing to Help with Interaction Design

We also had questions about controls. Should we use a checkbox verses a switch to enable the communication settings? I then used an unmoderated A/B test to determine whether to use checkboxes or switches. The control group used checkboxes while the variable used the switch. I surveyed approximately 379 users over a 7 day period, which met my statistical significance criteria at 90% confidence level. Both options performed well, but I found that checkboxes were slightly better for the users.

AB Test


I ended up expanding the current accounts application to allow for several different settings and preferences for the platform. There was a little redesign that needed to occur because the current settings application had only one screen and had no navigation.

Account Landing Page Communications Settings Notifications Settings


Lessons Learned

In the end, the client decided to postpone the launch of the new dashboard and go a different direction. However, I learned a lot of great things from this project.

Lessons Learned

Users want to be included in the process. When I contacted users about their feedback, they offered even more ideas than what we initially considered and wanted to take part in future usability tests.

Introducing new controls to users can be difficult, time consuming and may not be worth the effort. Most of the applications on this existing system utilize checkboxes. There are only a handful of instances where a switch is used and most users never encountered them. Sticking with a checkbox was just easier for us and the user.

Giving users more control over their experience can lead to more engagement. When users found out that they could set communication preferences, more power users began to encourage others on their team to use the functionality, which led to more engagement numbers.

Even the best designs need time to grow on users. After releasing the updates to the account area, we realized that more work should have been done to communicate these updates to users prior to launch. Many users complained about disorientation because things had moved or changed.