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


Product Designer


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


2 sprint cycles, 2021


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 I 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.

I also interviewed a handful of users from competitor platforms to understand how the current solutions were working for them. I 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 important community updates.

problem framing

Identifying Points of Intervention

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

I mapped the push notification structure for posts. It helped identify a lever that could be reconsidered: the Is the post near their home address? check.


Technical Constraints

After initial ideation, we came up with two directions, which we discussed with our development team:

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.

This was a concept flow for option 1. It shows how group members would customize notifications.
I re-mapped the push notification structure for posts, this time considering option 2, replacing the Is the post near their home? check with the Is the post urgent? check.

Research Insights

Testing Assumptions

I conducted broad discovery research with users and prospective users. I got back in contact with users of competitor platforms and defined those users as "prospective users". This helped me 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

I 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.

Creating an Urgent Post

Mobile app

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

Urgent Post Access Points

Mobile app

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

Feature improvements

Identifying Low-Hanging Fruit

Once I validated the usability of the design through testing, I looked to address insights we learned along the way. I grouped insights into 3 categories based on impact and effort: improvements we could implement in the current sprint, improvements that we wanted to prioritize but that required an epic, and future considerations. We determined that solving for usability bugs offered the most value with the least effort. Building the lower effort solution from the beginning allowed us to prioritize these items.

Improvement #1

Left: The original design had two key issues. 1. The dropdown wasn't a clear access point for users who wanted to change the audience of their post. 2. Users didn't understand that their current location was being used by default as the location of the post. Often users would realize their current location was being used for the post after they posted. This was confusing and disgruntling to users. Right: The redesign solves for both issues by labeling the dropdown and requiring users to customize the location of the post.

Improvement #2

Left: The original design features map markers which represent posts in an area. Users overlooked them due to the lack of post saturation in a network or area, sometimes mistaking map markers for points of interest embedded in the map. Right: Enlarging the map markers reduced confusion when retesting the designs with a new set of participants.
Original: The original design features map markers which represent posts in an area. Users overlooked them due to the lack of post saturation in a network or area, sometimes mistaking map markers for points of interest embedded in the map. Iteration: Iteration during solutioning. Shipped: The shipped solution. Enlarging the map markers reduced confusion when retesting the designs with a new set of participants.

Improvement #3

Left: The original design used a check to indicate a selected group or audience for the post. Right: Changing the check to a radio button brought familiarity to the selection flow.


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. 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.