Web & Mobile

Improving Notifications


Howl is a consumer app whose mission is to keep suburban neighbors informed without distracting them from their busy lives. Notifications are an integral tool for informing users of important events.


Product Designer


Problem definition, competitor benchmarking, user testing, design, handoff.


2 sprint cycles


Problem definition

The team had initially assumed that location alone was a good determinant of relevancy and urgency for every post. We validated this assumption using three metrics:

  1. Users don't interact with the notifications.
  2. Users turn off their notification permissions.
  3. Users don't return to the app.

Too many push notifications distract and annoy users causing drop-off. Not only do these results have negative growth and value impacts, but they indicate that we are not living up to Howl's mission. These metrics served as benchmarks for any ongoing effort to improve them.

Competitor benchmarking

How do our competitors solve for similar problems?

We needed to understand the problem in a deeper way, and so we looked at our competitors for any overlap. Use cases helped us to see how their solutions worked, or didn't, for their users. At a minimum, it helped us to glean insights into how other products in the market served prospective users.

We also interviewed a handful of users from competitor platforms to understand how the current solutions were working for them. We discovered that competitor platform push notifications weren't serving users well. Either there were too many or too few. When there were too many, users would turn them off completely, and then miss out on important community updates.

problem framing

Identifying points of intervention

Journey maps, touch points, task flows and user flows helped us to isolate areas of opportunity and clearly present the problem to stakeholders. This kickstarted ideation.


Technical constraints

After initial ideation, we came up with two directions:

option 1

Allow users to customize notification preferences.

option 2

Allow users to send and receive urgent notifications.

It was important to understand the technical and time constraints early. For group posts, the membership would be informed. For public posts, the notification would be hardcoded on the backend. We would check if the post is urgent or not. If it was based on whether the specific user wanted to see a notification, then it would take longer to implement and require backend work, which already had a full plate.

Research Insights

Testing assumptions

We conducted broad discovery research with users and prospective users. We got back in contact with users of competitor platforms and defined those users as "prospective". This helped us to gauge how users felt about our current notification system and check our assumptions surrounding the following ideas:

How they feel

Users think of them as a nuisance, not important communication.
People become overwhelmed by too many notifications. When they become overwhelmed, they turn off their notifications. When they turn them off, they miss important events and points of communication.

How they interact

Users don't bother to customize their notifications.
When given the option, people don’t want to do the work to find and adjust their notification preferences. They're either on or off.

How they define "useful"

"Useful" is in-step with their day and needs.
This produced stories, both positive and negative, about the role push notifications played in their day-to-day lives. The takeaway: people would rather too few than too many.


Measuring implementation

We plotted the two ideas on an impact effort matrix. Creating a new category of post empowered users to judge their own posts based on their content and context. Its implementation was also quicker, which enabled the team to address feature improvements that were discovered during the framing, testing, and design phases.

Design considerations

Recognizable and actionable

The 'on'/'off' feel and recognizability of a switch made it immediately appealing as a way to address this design challenge. The switch had to be easily accessible and immediately easy to understand. We assumed that the user in need of this feature was in a hurry to post. Therefore, the added value of augmenting the post needed to be worth any extra time required to make it 'urgent'. Prompting the user made the switch actionable. By posing a question, the functionality meets the user where they're at on a human level. The question also invites them to learn more if they are dazed or need more context, which we discovered during testing was appreciated.

How to create an urgent post

Mobile app: Creating a post

Note: For group posts, the membership receives a push notification regardless of their proximity to the location of the post. The explanatory text reflects this action.

Web app: creating a post

Urgent post access points

Mobile app: access points

Note: iOS and Android handle push notifications differently. Since iOS enables two title lines, while Android only enables one, we had to create a hierarchy of information from the data of a post. To create this hierarchy, I looked at how news publications decide when to send breaking news alerts, especially when the event triggering the push notification happens on an international scale or at odd hours of the day. This also helped strengthen our philosophy around the push notification as a way to make users aware of important, time-sensitive issues and less as a retention mechanism.

Web app: Access points

Feature improvements

Identifying low-hanging fruit

Usability bugs were found during user testing. Building the lower effort solution allowed us to prioritize them. We grouped these insights into two categories based on impact and effort, immediate improvements and future considerations.


Better informed users with less distraction

The results were promising, producing a notification structure that was more in tune with our mission.

  • We saw an increase in positive qualitative feedback, with users citing specific examples of how the urgent post helped inform them of flooding due to recent stormwater buildup.
  • We discovered that we were not able to compare the initial data with the data after implementation because the variables had changed.
  • Going forward, the team continues to monitor the feature to decide whether to invest further in it (e.g. timed expiry, visibility settings), tweak it (e.g. change the radius of the alert), or sunset it.