Protect minors through layered defaults, controls, and recourse
A companion app used by minors needs layered protection across the full product journey, not a single age gate or parental-consent screen. The baseline includes age-appropriate language and features; high-privacy, low-contact defaults; collection limited to what the current feature needs; clear boundaries for content, public interaction, persuasion, and spending; a guardian route that is visible rather than covert; and reporting, human review, appeal, and account transition states that both the minor and guardian can understand. Age assurance should collect the least information compatible with the chosen method, and uncertainty should lead to more protective settings rather than broader access. Official codes and rules below are used as design benchmarks only: age thresholds and product obligations vary by service and region.
Start with an age-adaptation state, not an invasive identity archive
The app should decide which experience to show through a documented, proportionate age-assurance method and display the resulting age band, confidence or unresolved state to the account holder. It should not retain an identity document merely because it was once checked if a less detailed result can serve the feature. When age is uncertain, begin with private discovery, no public contact, no targeted personalization, no location sharing, and restricted purchase paths. Explain in plain language what is being checked, which provider handles it, what result returns, how long each element remains, and how to correct a mistake. Never infer age from private conversation content without a disclosed, reviewed purpose. A harmless test uses a deliberately inconsistent birth-date entry and checks whether the app pauses sensitive setup instead of silently choosing the least protective route.
Make privacy and data minimization the default state
A minor account should open with profile discovery, contact permissions, search visibility, precise location, voice or image reuse, advertising personalization, and cross-device sharing off or at the most restrictive available state. The setup should list each data category beside its immediate purpose and omit fields that are merely convenient. Ask for a permission only when the related feature is invoked, and offer a route that does not require the optional input. Retention has a visible period or event, while deletion and correction are reachable from the same account area. The ICO design code treats privacy by default and minimisation as central standards. Test by declining contacts, location, and microphone access: core private functions should remain understandable, and the app should not repeatedly pressure the minor to enable them.
Separate content, contact, and sharing boundaries
Protection is not one content filter. The app needs distinct rules for AI-generated replies, public profiles, group spaces, direct contact, uploads, links, and sharing outside the service. Younger or unresolved-age accounts should not be discoverable or contactable by default. Requests from unknown accounts, migration to another channel, bulk sharing, and repeated contact need friction, clear block and report controls, and a preserved evidence receipt. Content rules should use age-appropriate examples and state what happens after a match: blocked before display, softened, placed behind a choice, or sent for review. Moderation must not require the minor to keep engaging. A negative test blocks an account and then checks search, recommendations, old threads, new accounts, and notifications for unwanted reappearance.
Put firm boundaries around spending and persuasive design
A companion relationship must not be used to turn attention, affection, progress, limited-time pressure, or social comparison into a purchase cue. Minor accounts need prices in ordinary currency, a pre-purchase summary, separate guardian authorization where the product requires it, receipts, cancellation or dispute routes, and a clear state when a purchase is unavailable. Loot-like uncertainty, auto-renewal ambiguity, default add-ons, disguised advertising, and repeated prompts after refusal belong in the design review. Separate earned in-app items from paid items and disclose whether a character response changes because of payment. Test an unavailable purchase, a declined request, an interrupted checkout, and a refund inquiry. None should remove ordinary access, shame the user, or produce a misleading success state.
Give guardians support without creating invisible surveillance
A guardian route should show which controls exist, what the minor can see, which events create a notification, and which private areas remain private. Avoid a dashboard that silently exposes every conversation or turns ordinary use into continuous monitoring. Use graduated controls for account setup, contact permissions, public sharing, purchases, connected devices, and schedule windows; explain the reason and scope at the point of use. Both sides need notice when a control changes and a route to correct an incorrect age band, mistaken restriction, or compromised guardian link. Recovery must verify the guardian relationship without asking the minor to reveal unnecessary conversation content. The child-facing interface should never imply that a report or correction is secret when the configured flow will notify a guardian.
Close reports and appeals with human-readable states
Reporting should be available from a message, profile, purchase, privacy setting, and guardian-control screen. It records what was submitted, what extra evidence is optional, whether immediate blocking occurred, who may review, and where status appears. Terminal states include action taken, no action with a reason, unable to reproduce, more information requested, restriction lifted, or appeal accepted or declined. Provide human review for consequential account or access restrictions and make both the minor-facing and guardian-facing explanations age appropriate. eSafety’s Safety by Design principles support user empowerment, accountability, and continuous assessment. Test one harmless, reproducible mismatch from report through acknowledgment, status, decision, appeal, and closure; silence or a support promise is not a terminal state.
Audit transitions, processors, and failures over time
Protection can fail when an account crosses an age band, changes guardian link, adds a device, joins a public feature, installs an update, or moves between text, voice, image, and notification surfaces. Keep a matrix of feature, default, data used, processor, guardian visibility, minor control, report route, failure state, and last test date. Re-consent or re-confirm only the controls that materially change; do not unlock a broader profile merely because a birthday passed. Test age-band transition in both directions, loss of guardian access, offline use, a delayed review, and a processor outage. Publish a plain change note and preserve a route to challenge migration errors. No protective disclosure compensates for a default or backend state that behaves differently.
Common questions
Is a parental-consent screen enough protection?
No. Protection also needs age-appropriate defaults, minimal data, interaction and spending boundaries, reporting, appeals, and tested transitions.
Should a guardian see every conversation?
Not by default. The product should disclose the scope of guardian visibility and use proportionate controls rather than covert continuous access.
What happens when age cannot be confirmed?
Use a documented unresolved state with more protective defaults and a clear correction route instead of silently granting broader access.
