OmniSecure Growth Strategy
Project A family location and safety app, offered with SiriusXM, rebuilt around the moments where people decide to trust it: the first permission, the first invite and the first upgrade.
Role Design Lead, Research lead
Methods User and expert interviews, competitive analysis, journey and lifecycle mapping, service blueprint, prototypes on a phone, agentic design system
Outcome Build trust and growth through uncovering the moments that matter to safety app subscribers.
Platforms iOS and Android
Building Growth into the Product
Trust is the growth lever. Every ask has to earn it.
OmniSecure is a family location and safety app offered to SiriusXM PVIP customers and their families. It competes in a category with a trust problem: the market leader had been reported selling precise location data, and teens campaigned against it as surveillance.
Our own onboarding made it worse. It asked for a name, address and phone number, showed two legal screens, then stacked location and motion permissions, all before anyone saw a reason to share.
Our business model was the way out. OmniSecure is funded by SiriusXM subscriptions and upsells, not by advertising or selling data, so we could promise never to resell location or driving data and mean it. The work was to make that promise visible at every moment where someone decides whether to trust us, and to turn that trust into growth.
Research pointed at where growth could come from. People valued location apps most when coordinating groups around special events, like concerts, festivals and trips, and the apps they already used fell short there. A circle of one is useless, so an event circle grows by invitation, and every guest is a possible organizer.
Research and process
I started from feedback we couldn't act on the first time, and treated every working prototype as a way to test what we'd learned.
Revisiting early feedback. Conversations from before OmniSecure existed pointed at needs we couldn't build for then. I turned them into new research topics with growth in mind.
User and expert interviews. Users told us coordinating groups at events was among the most valuable things a location app did. Travel insurance partners asked about coverage for exactly those events.
Competitive analysis. The category leader's low-rated reviews centered on wrong or stale locations, nagging permissions and data sales. Each complaint became a pattern we had to answer.
Journeys and a lifecycle model. I mapped every journey onto the same few states, from invitee to organizer to Premium. Each transition is a moment that matters and an event we can measure, which gave design, product, engineering and data one shared picture.
Prototypes on a phone. Our agentic design system held the patterns this work relies on, so I could compose a working prototype of any moment with Claude Code, publish it as a link and open it on a phone. Product and engineering reviewed the same prototype on their own phones.
The lifecycle became a service blueprint. For each state it shows what the person does and sees, their tier, the lifecycle campaign that meets them, and the functions and systems that deliver it. Lifecycle marketing was designed with the product, against the same states and events, under one set of guardrails and one frequency cap.
Key solutions
The invite comes before the permission.
Location requested with no one to share it with reads as tracking. Requested so Alex can see you're safe, it reads as care. So the new onboarding asks who you want to keep safe first, then asks for location with that person in the sentence.
The address left signup and came back as Home, the first alert, so the same data became a feature. Location arrives in two stages, each with a primer, and Android has its own path because it sends people to Settings for background location. Motion permission moved to the start of a Premium trial, where crash detection needs it.
Impact
For people
Onboarding now leads with someone to protect, and every ask follows its reason. Families see how fresh each location is, who can see them, and how to step back. Friends at a festival can find each other, and the circle ends on its own.
For the business
Event circles bring in new people through use rather than paid acquisition, and each guest is a possible organizer. Free members became an audience for first-party offers across SiriusXM, Pandora and Premium, without an ad network. Our north star was weekly protected circles: circles with two or more members sharing in the background and at least one alert that week. Trust got its own rung, so a downgrade from Always to While Using flagged someone at risk weeks before they cancelled.
For the team
I led a team of [number] designers with [product, engineering and data partners]. Reviews started from a moment on the journey, not a screen, with everyone holding the same prototype. I held the trust guardrails, because they're easy to erode and hard to win back, and the designers who owned each pattern made the calls inside the system. [One sentence on how the team grew.]
The honest limit
Background location is ultimately the operating system's call. On Android 12 and later, "Allow all the time" lives in Settings, and some people never come back from that detour. The design explains the step and recovers when someone says no, but it can't remove the step. And event circles grow in bursts around event seasons, not as a steady curve.
What's next
The same temporary-circle pattern extends to neighborhood safety groups during disasters, carried by SiriusXM's satellite network when cell service fails. Trips and places come next: route history, driving insights and up to five places per person, each with its own alerts.
(Outcome stats)
What I'd do differently
I'd put the lifecycle events in place before the redesign shipped, not alongside it. We designed a trust rung, but the downgrade event arrived with the new onboarding, so the old flow had no baseline to compare against. Every moment we redesign should have its before number first.