How to check a design agency before you sign: reviews, references and results
Check a design agency like an investor: verified reviews, client calls, who does the work, real results, returning clients and contract basics.
22 Dec 2026
HealthTech onboarding: consent, permissions and trust in the first 60 seconds
How to ask for health data, location and notifications without losing users. GDPR Article 9, Apple and Google prompt rules, and a 60-second framework.
Short answer
Ask for each permission when the feature needs it, not at launch. Put a plain-language screen before every system prompt that says why, what you keep, who sees it and how to undo it. Under GDPR Article 9, health data needs a legal basis, often explicit consent, so make each choice separate, specific and easy to withdraw.
A new user opens your health app. Within a minute they’ve been asked for notifications, location, health data and their contacts. They tap Don’t Allow four times, and your product is now a very expensive calendar.
That second tap matters more than it looks. On Android, if someone taps Deny for the same permission more than once, the system treats it as a permanent “don’t ask again” and stops showing the dialog (Android Developers). You don’t get a third try. You get a settings screen they’ll never visit.
Trust is also why some people never install a health app at all. In a US survey of 1,604 phone owners, 15.4% of those who had never downloaded a health app gave lack of trust in apps collecting their data as a reason (Krebs and Duncan, JMIR mHealth and uHealth, 2015). The data is ten years old. The feeling isn’t.
At Dtail Studio, a Barcelona design studio working with HealthTech and renewable energy startups, we think about this most on Elli Cares (case study), an app for people living with cognitive impairment and their families. An app that holds someone’s location, mood and messages from their carer has to earn trust before it asks for anything.
Why do people say no at the permission prompt?
Because the system dialog tells them what the app wants, not why. Google’s own documentation says it plainly: the permission dialog “says what permission your app wants, but doesn’t say why” (Android Developers). It’s a stranger at the door asking for your keys, with no uniform and no clipboard.
Apple’s guidance points the same way. Request permission only when your app clearly needs it, ideally when people use the feature, and avoid asking at launch unless the app can’t work without it (Apple Human Interface Guidelines).
In health, the stakes feel higher to the user. “Allow location” in a maps app means directions. In an app for someone living with dementia, it means another person can see where they are. Same toggle, very different question.
What does GDPR ask of a health app before it collects data?
Health data is a special category under GDPR Article 9. Processing it is prohibited unless one of the listed exceptions applies, and the one most consumer apps reach for is explicit consent “for one or more specified purposes”.
Three design consequences follow:
One purpose, one choice.
“Specified purposes” rules out a single “I agree to everything” box. Mood tracking, location sharing and research use are separate decisions.Withdrawal has to be as easy as agreeing.
Article 7(3) says exactly that. If consent took one tap, withdrawing shouldn’t take an email to support.Scrolling isn’t saying yes.
The EDPB’s consent guidelines say swiping or scrolling past a notice isn’t a clear affirmative action, and that blocking access unless people accept isn’t freely given consent (Hunton, summarising EDPB Guidelines 05/2020).
One thing founders often mix up: the iOS or Android permission isn’t your GDPR consent. The operating system prompt grants technical access to a sensor. Your lawful basis for processing health data is a separate thing you record yourself. Think of the phone as the bouncer and GDPR as the licence on the wall. You need both, and one doesn’t stand in for the other.
Explicit consent also isn’t the only Article 9 exception, and which one fits your product is a question for your data protection counsel. This post is design guidance, not legal advice.
Should you show a screen before the system prompt?
Yes. Both Apple and Google describe one, with slightly different rules.
Apple says a custom screen before the system alert should have one button, labelled something like “Continue” or “Next”, and make clear it opens the system alert. It also warns against an “Allow” button on that screen, because “people don’t allow anything in a pre-alert screen” (Apple Human Interface Guidelines). Google calls it educational UI and asks for the opposite courtesy: always include a “No thanks” option, and don’t block people from using the rest of the app if they decline (Android Developers).
It’s worth the effort. Airship’s 2026 benchmarks put the median push notification opt-in rate at 48.85% on iOS and 53.3% on Android, so roughly half of people say no by default. Airship also reports that apps running onboarding campaigns see opt-in rates “as high as 40% above their category average” (Airship). That’s a vendor’s own figure, so treat it as a direction, not a promise.
The copy on these screens does most of the work. A good pre-prompt screen is a polite knock. A bad one is the same knock, followed by a sales pitch through the letterbox. We wrote more about why words matter in UX writing: small words, big impact.
The 60-second onboarding framework
Answer four questions in order, roughly 15 seconds each. The timings are illustrative. The order is the point.
0 to 15.
The question in the user’s head: Why are you asking?; What the screen does: Names the benefit in one sentence, tied to a feature they chose; Example copy (illustrative): “Reminders work best when we know your routine.”15 to 30.
The question in the user’s head: What will you keep?; What the screen does: Lists the data types in plain words, one toggle per purpose; Example copy (illustrative): “Your mood check-ins. Not your messages.”30 to 45.
The question in the user’s head: Who will see it?; What the screen does: Shows real people or roles, not “third parties”; Example copy (illustrative): “Only you and Maria (carer) can see your day.”45 to 60.
The question in the user’s head: How do I undo it?; What the screen does: Shows where to change it and confirms it takes one tap; Example copy (illustrative): “Change this any time in Sharing. One tap.”
Two rules make the framework work in practice:
The 60 seconds is a conversation, not four system prompts back to back.
Most prompts should still wait until the feature is first used. Onboarding sets the expectations; the prompts arrive later, in context.Design the “no” path first.
If someone declines location, the app should still be useful, and it should say what they’re missing in one line, once. Google’s guidance is blunt about it: persistent nagging “is not respectful of their choice”. Nobody was ever nagged into trusting anyone.
How do you handle consent when there’s a patient and a carer?
Give each role its own setup, and let the person whose data it is make the sharing decisions. The carer’s onboarding is about what they can see and do. The patient’s onboarding is about what they’re willing to share, and with whom.
A sharing screen titled “Who can see your day?” with one toggle per person and per data type (location, mood, schedule) is easier to understand than a policy page, and easier to change later. Nobody reads a privacy policy for fun. A list of names with switches takes five seconds. It also gives you a clear record of who agreed to what.
Capacity is the hard part. Some users of health apps may not be able to consent for themselves, and the rules on who can decide for them vary by country. Founders should confirm their approach with counsel before designing the flow. We covered the wider design side of this in designing for patients and caregivers.
What we learned on Elli Cares
Elli Cares helps people living with cognitive impairment and their families with reminders, mood tracking, scheduling, location and caregiver communication. The problem we were asked to solve was high cognitive load, low contrast and unclear hierarchy. Our work focused on simpler flows, a high-contrast UI and a calm visual language.
Those same principles carry straight over to consent: one decision per screen, toggles you can read without squinting, and language that doesn’t make anyone feel they’re sitting an exam.
The Elli App is now used in 19 countries and was joint winner of the 2024 Future of Ageing Award (Technology Consumer). Those results belong to the Elli Cares team. As Angela Edwards, CEO of Elli Cares, put it: “Working with Dtail felt like having a senior team that truly cared about results and users.”
For more on the cognitive side, read designing apps for dementia. For the accessibility rules that now sit alongside privacy, see our guide to the European Accessibility Act for health apps (coming soon). And if users are dropping off after week two rather than in the first minute, see why patients stop using health apps after week two (coming soon).
FAQ
Is an iOS or Android permission the same as GDPR consent?
No. The system prompt grants access to a sensor or service on the phone. Your legal basis for processing health data is separate, and you need to record it yourself. Confirm which basis applies with counsel.
When should a health app ask for location?
When the user first uses a feature that needs it, with a short screen first explaining why. Apple advises against asking at launch unless the app can’t function without it.
Can we make consent a condition of using the app?
Be careful. The EDPB’s guidance says blocking access unless people accept isn’t freely given consent. If a core feature genuinely can’t work without certain data, talk to counsel about the right legal basis.
How easy does withdrawing consent need to be?
GDPR Article 7(3) says as easy as giving it. In practice: the same screen, the same number of taps, inside the app.
What happens if a user denies a permission twice on Android?
Android treats it as permanent and stops showing the system dialog. The user has to change it in system settings, so ask only when the feature is needed.
Try this today
Install your app on a clean phone and start a timer. Count every system prompt before you reach the first useful screen. For each one, ask a colleague who has never seen the app why it appeared.
If there’s more than one prompt, or one blank look, move it to the moment the feature is used.
Onboarding asking for more than it explains? Let’s talk.
About the author: Slavena Vasileva is a partner and Brand Strategist at Dtail Studio, a senior brand and product design studio in Barcelona with 16+ years and 300+ projects behind it.
Sources: GDPR Article 9 (gdpr-text.com) · GDPR Article 7 (activeMind.legal) · Hunton Andrews Kurth, EDPB publishes updated guidelines on consent under the GDPR · Android Developers, Request runtime permissions · Apple Human Interface Guidelines, Privacy · Airship, Mobile app push notification benchmarks for 2026 · Krebs and Duncan, Health app use among US mobile phone owners (JMIR mHealth and uHealth, 2015) · Elli Cares case study
Should you rebrand after your Series A?
Leave it, refresh or rebrand? A decision framework for startups after a Series A, with the signals for each and lessons from the Cubee brand.
Why patients stop using health apps after week two, and how design keeps them
Most health apps lose their users within two weeks. The research on why patients drop off, and a design framework to keep them, with lessons from Elli Cares.
