The hardest onboarding in mobile: connecting a parent's and a child's phone. What we changed at Findmykids
Alla Kuchynskaya · Senior Product Designer
· 6 min read
Short answer: Two-device onboarding loses people because the value appears only after two phones, two people and several system permissions all line up. To reduce drop-off, define the first moment of value, split setup into clear steps with visible feedback after each one, explain every permission before the system dialog, build a way back from every failure, and measure drop-off per step on each device.
I worked on this problem at Findmykids, a family safety app with 55M+ downloads. Here is why this kind of onboarding is unusually hard, what we changed, and the checklist I now use for any setup that depends on permissions or a second device.
Why is connecting two devices the hardest onboarding in mobile?
Most onboarding has one person, one phone and one moment. A parent-child app has none of that.
Two people with different motivation. The parent installed the app because they are worried. The child did not ask for anything, and may not even be in the room when setup starts.
Two devices, two apps. The child's phone usually gets its own companion app. For Findmykids it is Pingo, connected by installing it on the child's phone and entering a code from the parent app. So the parent switches between their phone and someone else's, often holding both.
The permissions live on the other phone. Location, notifications, background work: all of it is granted on the child's device. Background location is the strictest of them. On Android 11 and higher the system dialog doesn't offer "Allow all the time" at all; the user has to find it on a settings page. Later the OS sends a reminder that the app can see location all the time. Platforms are built to make people hesitate here. That's fair, and your flow has to plan for it.
Trust and privacy. Tracking a child is emotionally loaded. The parent wonders if this is too much. The child may feel watched. A vague screen at this moment reads as "something shady is going on".
Value is delayed. The parent's first real reward is seeing their child on the map. Everything before it is pure cost, and every extra step stands between the parent and the one thing they came for.
What did we change at Findmykids?
I worked with Findmykids as a contract Senior Product Designer at two stages: first on a major redesign of the core experience, later when they invited me back for new features.
The parent-child connection setup was complex and caused drop-offs. We redesigned it into a simpler step-by-step connection flow with clear visual feedback at each stage. The idea behind that feedback is simple: a parent should never have to guess whether the last step worked. Together with other onboarding improvements, this contributed to +18% retention.
The rest of the redesign was about what happens after the connection. We reworked the map, profile and reports screens (contributing to +22% engagement), added personalized tips and behavioral insights, and I contributed to the strategy for multi-role profiles: parents, partners, relatives.
That last point matters for onboarding more than it seems. The person who installs the app is rarely the only adult who cares. If a second parent or a grandparent can't join easily, the family's safety depends on one person's phone. In my view, "invite the next adult" belongs to activation, not to a settings menu.
A note on honesty: I say "contributed to" because retention moves with many changes at once. But a connection flow is the natural place to look first. It sits right before the first value moment, so everyone lost there never sees what the product does.
A framework for permission-heavy and multi-step onboarding
This is the checklist I use for family apps and for any product where setup involves permissions, a second device or a second person.
1. Define the first value moment and count the steps to it
Write down the moment the user gets what they came for. For a family locator: "I see my child on the map". Then list every step before it, and make each one justify itself. Nielsen Norman Group is blunt about it: avoid onboarding whenever possible and make the UI more usable instead. Welcome carousels and tutorials before the value moment are the first things I cut.
2. Map who does what, on which device
Draw the flow as two lanes: parent's phone and child's phone. Mark every handoff ("now pick up the other phone", "now come back"), because that's where people get lost. Each handoff screen should say in one sentence what to do on the other device.
3. Prime every permission before the system dialog
The system dialog is a one-shot moment, so prepare for it. Apple's guidelines say to request access only when your app clearly needs it, and a screen shown before the system alert should have one button that clearly opens it, with a neutral label like "Continue". Android recommends asking in context, when the user starts to interact with the feature, and notes that people are more comfortable with requests when they know why the app needs them.
For location, follow the platform's order: foreground first, background later and separately. Explain the benefit in human words, something like "so you can see when your kid gets to school", rather than "the app needs location access".
4. Show progress and feedback at every stage
In a two-device flow, uncertainty is the main enemy. Did the code work? Is the other phone connected? NN/g found that people who saw a progress bar were willing to wait about three times longer than those who saw nothing. Each step should end with a visible confirmation, and the flow should always show where you are in it.
5. Design recovery paths, not just the happy path
Every step needs an answer to "what if it fails?". This is where I start:
| Step | What usually goes wrong | What the flow should do |
|---|---|---|
| Install on the second device | Child's phone isn't nearby | Let the parent pause, send a link, remember where they stopped |
| Enter the code | Typo, expired code, wrong account | Name the exact problem, offer a new code in one tap |
| System permission | User taps "Don't allow" | Show what won't work without it and how to enable it later. On Android, after two denials the dialog stops appearing, so you need a path to settings |
| Background location | The option is hidden in settings | Show the exact label to choose and where to find it |
| Waiting for the first signal | Child's phone is offline or saving battery | Say "waiting for the first location" honestly and what to check, never an unexplained empty map |
6. Measure drop-off per step, on both sides
"Pairing completed: X%" tells you nothing. Track every step as its own event on each device and join both sides with a shared pairing ID. Then separate "the user gave up" from "the user is waiting for the other phone": they need different fixes. Time between steps matters too. A long gap at one handoff shows you exactly where people get stuck.
7. Write the words last, test them first
On permission and pairing screens, text does most of the work. A good button says what happens next. A good error says what went wrong and what to do now. "Something went wrong" leaves a worried parent with nothing to do.
FAQ
How do I reduce onboarding drop-off in a mobile app?
Find the first value moment and remove or postpone everything before it that isn't required. Track drop-off for each step separately, fix the worst step first, and end every step with clear feedback that it worked. Most drop-off comes from uncertainty and unexplained requests, not only from the number of screens.
When should an app ask for location permission?
When the user starts using the feature that needs it, not at launch. Explain the benefit on your own screen first, then show the system dialog. Ask for foreground location first and background location later as a separate step, because platforms treat it as a stronger permission (on Android it's a separate request by design).
What is permission priming, and is it allowed?
It's a screen shown before the system dialog that explains why you need access. Apple allows it if the screen has one button that clearly leads to the system alert and doesn't imitate it. Android recommends an educational screen, especially after the user has declined once.
How do you design onboarding for an app that connects two devices?
Draw it as two lanes, one per device, and design every handoff on purpose. Give feedback after each step, let people pause and resume, and track each side separately in analytics. Treat "waiting for the other device" as a real state with its own screen.
Alla Kuchynskaya is a Senior Product Designer with 12+ years in startups, focused on onboarding, activation and retention in AI, health, social and family safety apps. At Findmykids (55M+ downloads) her redesign of onboarding and the parent-child connection flow contributed to +18% retention; at Intch her onboarding redesign improved activation by 20%. She works part-time, full-time or per project, remotely from Bali. Portfolio: alla.studio · Telegram: @aladesigner
About the author
Alla Kuchynskaya · Senior Product Designer
alla.studio · LinkedIn · Telegram · Resume