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:
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.
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.
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.
After initial ideation, we came up with two directions, which we discussed with our development team:
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.
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:
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.
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.
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.
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.