My Role
UX Writer / Content Designer responsible for:
Writing push notification copy
Mapping triggers and push notification timing strategy
Aligning messaging with user value and product behaviour
Problem
User research revealed two key issues:
Users knew how frequently music was updated but not when, with 88% “listening out for updates”
Engagement with the app was low. 75% of managers relied on “verbal feedback” over the Insights page.
Ambie was working hard in the background but we weren’t telling users when updates and improvements were happening. This led to low engagement in-app, and a perception of the product as static over interactive.
Solution
Reposition Ambie from a "background tool" to an "active partner" by designing notifications that surface hidden value without causing user fatigue. Notifications would:
Reveals meaningful insights about music performance, venue by venue
Highlight product updates
Encourage users to engage in-app by performing certain actions
Strengthen trust and sentiment toward the brand
Challenge - identifying key moments to communicate
With team meetings, we decided we wanted notifications to 1) inform and 2) drive specific behaviours. Our first challenge was prioritising which notifications to send and when, based on the actions we wanted users to take and which insights were most valuable to them.
Solution
We carried out surveys with users to find out which insights they were most interested in. Research showed they valued music and playlist updates, site-by-site feedback, and information about repeats.
We split potential notifications into two categories: triggered by us and triggered by them. Then, rather than sending notifications at timed intervals, we identified high-value moments where they would feel useful rather than intrusive:
Notifications triggered by Ambie
When Ambie updates a user’s library
Monthly performance summaries
Actions users could take to optimise their experience
Keep notifications to a maximum of 1–2 notifications per week, unless user-triggered
Notifications triggered by the user
When a “Team” user “likes” or a song or playlist
When a “Team” “Manager” or “Admin” submits a playlist request
When a playlist hasn’t been used in (x) time
When a user over schedules a playlist for its length
I made a note not to notify users when
They chose a playlist to play in a venue (they know what action they’ve taken, it’s the impact that’s important)
They “disliked” a song (we already had a toast notification telling them “we won’t play this again”.
They built a new schedule (it’s not a material change to playback unless they set that schedule to play).
Challenge - turning backend activity into user-facing value
We discussed how to communicate our background processes into user-friendly updates that users would understand and care about.
Content strategy
Rephrase system activity as user outcomes, not internal processes
Focus on what changed for them and why it matters
Example
Instead of: “Playlist updated”
Suggested copy: “Your new tunes are ready! Here’s (150) fresh tracks now in the mix. The user can then immediately review the playlist and feedback via that CTA.
Writing for engagement
Push notifications can compete for attention and we wanted to avoid them feeling disruptive or being overused.
Content decisions
We kept messages concise and scannable
Used action-oriented language
Used emojis to break up copy and in keeping with Ambie’s friendly, informal voice
Voice
Playful but not irreverent
Informal but not unprofessional
Friendly but not overfamiliar
Challenge - designing role-based messages
During team meetings, we agreed that we wanted each user type to receive updates relevant to their position in the business. I approached the content by drafting messages specific to user types or personas, relevant to their level of responsibility e.g.
Location-level notifications to “Teams” and “Managers”
Monthly performance updates and business-level notifications to “Admins”
By showing updates relevant to what each user controls, we would make the product feel intuitive, build user trust and serve their specific needs.
Collaboration & Validation
Although we had team meetings to scope this project, to save time I mocked the content and wireframes independently as part of a personal project. To take this from concept to launch, I would have worked with product, data, and marketing teams to ensure the messaging was well-timed and effective.
I’d partner with product to:
Define which user actions or system events should trigger notifications
Align messaging with product goals
Test and validate copy and UI
This would ensure we’re validating our hypothesis and solving the right problems.
I’d work with analytics to:
Identify high-value touchpoints (e.g. meaningful changes in performance)
Set success metrics such as open rate, CTR, and downstream engagement
Analyse behavioural patterns to iterate timing and frequency e.g which notifications actually drive action
I’d work with marketing to:
Align on brand voice and tone across channels
Ensure consistency between push notifications and in-app messaging
Balance engagement with brand perception (avoiding overly promotional language)
This would ensure the experience feels cohesive
Validation
Before launch, I’d:
Run internal reviews with teams to sense-check clarity and relevance
Prototype notification flows and review them in context (timing, frequency, sequencing)
Sense-check messaging against example use cases
After launch, I’d:
Track key metrics (open rate, CTR, engagement)
Monitor drop-offs or disengagement signals
Iterate on wording, timing, and triggers based on user behaviour
Outcome
I presented this persona project internally for review. It was received well, but unfortunately not implemented due to competing priorities. Had we rolled it out, I’d expect the impact to be increased engagement, improved understanding of product value, and higher retention from value reinforcement.