Does a children's app actually need an account?

What question comes before protecting a child's data?

The usual question is how to protect a child's data once it is collected. The question that should come first is why it was collected at all. Any data field never collected in the first place needs no encryption, no retention policy, and no breach response plan, because it does not exist anywhere it could leak from. This is not a substitute for information security; it is a step that comes before it: what we do not hold, we do not need to guard.

We ask this question of every data field we request in any sign-up aimed at a child: a real name, an exact birth date, a phone number, a precise location. One question settles it: what actually breaks in the product if we do not collect this field? If the answer is nothing, this is a field collected for a purpose other than serving the child, and it should be removed from the sign-up screen regardless of how easy it is to add.

Why isn't protecting data alone enough?

Data protection is a downstream measure that reduces harm if a breach or misuse happens, but it does not prevent the root problem: a child's data collected with no real need for it. We hold, in everything we build, to collecting as little data as possible in every experience, because what we never collect needs no protection and cannot leak, a direct extension of our published safety stance.

The evidence level here is internal Dawani practice, built on the data-minimisation principle widely known in privacy engineering, not on a specific legal text we are quoting word for word here. The law that applies in any given market imposes additional duties specific to children's data, and reviewing them needs a qualified legal adviser who knows the market the product launches in, not a general piece like this one.

What does the decision tree look like for each data item?

We put every data field in front of one question first: what breaks in the product if we do not collect it? Four possible answers. The first: nothing breaks, and the field is removed from sign-up with no further discussion. The second: a convenient feature breaks, but it is not essential, such as remembering a child's name to greet them warmly, and here we ask a second question: can we achieve the same purpose with a coarser value, or a temporary one deleted after use? The third: a core product feature breaks, such as saving a child's progress between sessions, and here we look for the least detailed value that still achieves the save without a real name or a personal email. The fourth: a safety duty or legal obligation breaks, such as verifying a parent's consent itself, and here the field needs an explicit legal opinion before any final design.

This tree turns an open-ended discussion that could go on forever into a specific decision for each field on its own, instead of settling everything at once with a general sentence like "we collect as little data as possible" that stays without practical effect unless applied field by field.

What does this mean for designing a sign-up screen?

First, it means a sign-up screen is not an administrative step copied from a previous project, but a design decision built from scratch around what this specific product actually needs. Second, it means having no personal account for the child is a legitimate choice, not a missing feature: many early- and middle-childhood experiences work completely with no account at all, on a device shared by more than one child, or with one parent account managing all their children.

Third, it means fields that look small, like an email box "to send useful alerts," need the same question with no exception. If the alert itself can appear inside the app when a parent opens it, that is an email field to remove, not to justify by how it is expected to be used.

What does a good pattern and an anti-pattern look like for requesting data?

An illustrative anti-pattern: a learning app asks a parent for the child's full name, exact birth date and phone number from the very first screen, in the name of "personalising the experience," while the app actually only uses a broad age band to show suitable content. Precise data is collected for a purpose that needs nothing more than a general category.

An illustrative good pattern for the same app: a first screen asks only for the child's broad age band from a list, with no real name and no exact birth date, and one parent account is created by email only if the product genuinely needs to save progress across multiple devices. Every feature added afterward is measured by the same question before it is added.

How do you use the Data Minimisation Canvas on your product?

The Data Minimisation Canvas shows you ten data items common in children's products, from a full name to voice recordings, and asks you to answer the decision tree above for each one on its own. It then summarises what can be dropped entirely, what can be collected more lightly, what needs explicit parental consent, and what needs a legal opinion before any final design decision.

Use it before drawing a first sign-up screen, not after building one, because removing a field from a sheet of paper is far cheaper than removing it from a database already full of real data about real children.

What does this canvas not settle?

This canvas is a design tool that organises the discussion and sets its priorities; it does not replace a legal adviser who knows the law that applies in the market the product actually launches in and the specific parental-consent details required there. The final decision on any item classified as a legal duty must come after an explicit legal review, not from this canvas alone. The canvas also describes sign-up and direct-use data, and does not cover everything a third party embedded inside the product might collect, such as an analytics or advertising service, which needs a separate review with the same question. This topic intersects directly with the data axis inside the Dawani Child-Safe Design framework, where data collection is examined alongside other axes such as content and advertising, not in isolation from them.

Where should you start?

Open your current product's sign-up screen, write down every field it asks for on a separate sheet, then ask the same question of each one: what actually breaks if we remove it? Try the Data Minimisation Canvas to organise the answers, and read also how we translate safety principles into concrete design decisions and how parents themselves can check any app's data aimed at their child. You can also tell us about your product through the Start a project form.

References

• Our safety stance, and the detail of its data-minimisation commitment: our safety page, an internal Dawani publication.
• The Dawani Child-Safe Design framework: an independent internal Dawani framework, not a government standard.

Quick questions

Does having no personal account mean no data about the child at all?

Not necessarily. Some products need to save progress or preferences, but they can do that with the least possible detail, or tied to a parent's account rather than a separate account for the child.

What do we do when the marketing team asks for an extra data field?

We apply the same question to their request: what breaks in the product, not in the marketing plan, if we do not collect this field? A purely marketing need is not enough on its own to justify collecting a child's data.

Does the answer differ for a teenager rather than a young child?

Yes, some teenagers need a degree of independence in their account that differs from a young child, but the same founding question still applies: what actually breaks if we reduce this specific field?