An independent Dawani framework, not a government standard
Twelve axes for reviewing any digital product a child uses, in one language shared by the product team, the buyer and the independent reviewer. Each axis carries a question, a good pattern, an anti-pattern, and a way to test it with children. It is not a legal compliance assessment, not a certification, and not a government standard.
A checklist answers yes or no, but it does not tell two different teams that they are talking about the same thing. A review needs a shared language before it needs a checklist: a name for each axis, one question asked inside it, and a line below which the axis counts as unmet.
There are twelve axes: the child's best interest, data, attention, interaction between users, content, commerce, the parent's role, artificial intelligence, moderation, accessibility, measurement, and ending and exit. Their order is fixed on this page and in the score alike, so that two results for two versions of the same product stay comparable.
These axes extend what we hold ourselves to: four design decisions on the safety page, and six lenses we check every decision against on the expertise page. For a sorted result rather than a continuous read, open the score and answer the axis questions inside your own browser.
The axes were written from reading international documents named in the sources list at the foot of this page. We read them and claim conformity with none of them: the wording, the order and the limits are Dawani judgments, and the responsibility for them is ours alone.
A Saudi reading adds two more references: the Personal Data Protection Law with its Implementing Regulations, and the Child Protection Law. We name them as context to read, not as duties we settle on anyone else’s behalf; what is legally required is decided by the text itself and by your own legal counsel.
The twelve axes
The same format in every axis: the question it asks, what it protects, and what it actually changes in the design.
It asks: when the child’s interest and the usage numbers disagree, which one wins? It protects: one real decision taken for the child, and a person with the authority to refuse a feature that harms them. It changes: it turns "for kids" from a general description into one age band that is actually designed for.
It asks: what breaks in the product if we do not collect this field? It protects: the child from the leak of what the product never needed in the first place. It changes: it runs the product on a pseudonym, and gives every data type a retention period that is actually acted on.
It asks: does the child come back to learn, or to protect a streak they do not want to break? It protects: intrinsic motivation from mechanics that keep a child busy for no reason. It changes: it drops daily streaks and random rewards, and lets progress pause and resume with no penalty.
It asks: who can the child reach inside the product, and who can reach them? It protects: the child from contact nobody decided to open. It changes: it turns contact off by default, and puts blocking and reporting on the screen where the conversation happens.
It asks: was what reaches the child reviewed against their age, or against the team’s taste? It protects: the child from a scene unsuited to their age, and from a message that makes them feel they fell short. It changes: it gives every age band a written review standard that comes before publishing.
It asks: can the child tell a play moment from a sales moment? It protects: the child from a purchase that lands in a moment of frustration or suspense. It changes: it separates the purchase path from the play path, and keeps targeted advertising and tracking tools out of a child’s product.
It asks: what does the parent learn in under a minute, and what can they change? It protects: the family partnership from turning into covert monitoring the child discovers later. It changes: it cuts the parent dashboard to three answers, and tells the child what is visible.
It asks: what does the generating component say about itself to the child, and what happens on a sensitive disclosure? It protects: the child from a companion they take for a person, and from an answer left with no follow-up. It changes: it says it is not a person at the start of every session, and opens a clear path to a human.
It asks: does a human see what users publish before a child does? It protects: the child from content that arrives ahead of any review, and from a report nobody answers. It changes: it states the report response time inside the product, and gives every report a named owner.
It asks: are the child who cannot read yet, and the child who uses assistive technology, inside the target group? It protects: the child’s right to finish the same task in their own way. It changes: it makes instructions heard as well as read, and measures contrast and keyboard operation before launch.
It asks: what do you measure, and which harm does a second indicator watch? It protects: the next version from improving in the wrong direction. It changes: it writes the guardrail indicator before the success indicator, and takes time in the product out of the definition of success.
It asks: how does the session end, and how does the child leave the product altogether? It protects: the child’s right to stop at a point they can find, rather than where a try was cut in half. It changes: it designs an ending screen that actually ends, and puts account and data deletion inside the product.
From principle to decision
The third column is the difference between an opinion and a decision: what we put in front of children themselves to check the axis before launch.
| Axis | Good pattern | Anti-pattern | How we test it with children |
|---|---|---|---|
| The child’s best interest | A written decision in which the team gave up a usage number for the child, with the name of who took it. | A principle declared in the deck, with the team unable to name one decision when asked for an example. | We sit with children in the target band and ask what annoys them in the product, with nobody from the team explaining. |
| Data | Every field has a written purpose and a retention period, and the product runs on a pseudonym with no real name and no precise location. | A full account before the first moment of play, then data kept with no period and no stated reason. | We ask a parent to find, unaided, what is collected about their child and where to delete it, and record how long it took. |
| Attention | A goal with an end the child reaches and feels, and progress that can pause and resume with no penalty. | A daily streak lost by missing one day, and a random reward that keeps the next try open. | We watch a child leave a session: do they leave at ease, or with a message telling them they let someone down? |
| Interaction between users | Contact between children is off by default, and blocking and reporting sit on the screen where the conversation happens. | A public room open by default, and a report button in a settings menu far from where the trouble is. | We ask a child to block an annoying user in a test build, and count the steps and the time. |
| Content | A written review standard for each age band, which every item passes before it reaches a child. | Review by taste alone, with no standard a reviewer outside the team could apply and reach the same result. | We show the hardest scene in the product to children in the youngest band, and ask them what they felt. |
| Commerce | The purchase path is separate from the play path, and gated behind a deliberate parent decision. | A purchase offer surfacing in a moment of frustration, and targeted advertising learning from the child’s behaviour inside the product. | We ask a child to explain what costs money and what is free, and compare their answer with what the product does. |
| The parent’s role | One page answering the parent: what is my child doing, what can I change, and when should I pay attention. | A detailed monitoring dashboard the child does not know exists, and discovers after months of use. | We sit a parent and child together, and ask them to read the parent dashboard in front of each other. |
| Artificial intelligence | The component says it is not a person at the start of every session, and keeps no personal details between sessions. | A companion claiming friendship and remembering the child’s secrets, with no path to a human on a sensitive disclosure. | We test it with real children’s questions about sadness and fear, and review every answer with a specialist. |
| Moderation | Human review of what users create before a child sees it, and a stated response time for every report. | Automated filtering alone, and a report going to an inbox nobody opens on any regular basis. | We file a test report from a child account, and record what the child saw and what came back. |
| Accessibility | Instructions heard as well as read, full operation by keyboard and screen reader, and measured colour contrast. | Written instructions alone for a band that cannot read yet, and touch targets too small for a child’s hand. | We test the product with a child who cannot read yet, and with a child who uses assistive technology. |
| Measurement | A proximal success indicator that does not measure time in the product, alongside a guardrail indicator watching one specific harm. | Time in the app and session count as the only success indicators, with nothing that would expose harm. | We ask five children what they learned, with no test, and compare their answers with what the team assumed. |
| Ending and exit | An ending screen telling the child what they finished today and stopping there, with account deletion available inside the product. | An open ending with a cliffhanger pulling into another round, and account deletion possible only by email. | We ask a child to stop now, and see whether they found a stopping point or had a try cut in half. |
From brief to after launch
Five steps, each with a gate that reads as the condition for leaving it rather than a description of it.
We write down who the target child is by age band, which parts are inside the review, which are outside, and why.
Gate: One agreed age band, and a written scope both the team and the client know.
We walk the axes one by one, recording for each what actually exists in the product, not what is intended in the plan.
Gate: Every axis has an answer backed by a screen, a setting or a document, or a not-applicable mark with its reason.
We take the weakest axes into a session with children in the target band, with their parents’ consent and their own right to stop whenever they want.
Gate: The children’s notes are written as spoken, and turned into changes on the work list.
We sort what gets fixed before launch from what is deferred with its written reason, and name an owner inside the team for each item.
Gate: No protection axis sits below the line agreed in the first step.
We repeat the review after every substantive change, and follow the guardrail indicator and the reports as an early signal rather than a late report.
Gate: A report naming what changed, what is still open, and when the next review happens.
What we read before writing
We read from these sources and claim conformity with none of them. What could not be opened on the retrieval date is named without a link and without a quotation.
Personal Data Protection Law (English version, April 2023)
From it, on the data axis, we take that collection is limited to the minimum necessary for its purpose (Article 11). We also take that a privacy policy is available before collection (Article 12).
Implementing Regulations of the Personal Data Protection Law
From it we take privacy information given in appropriate language where the data subject lacks legal capacity (Article 4). We also take verification of the guardianship, and enabling the data subject to exercise their rights once they attain capacity (Article 13).
The Child Protection Law, issued by Royal Decree M/14 of 1436H
From it, on the content axis, we take that exposing a child to scenes unsuitable for their age counts as abuse (Article 3). On the axis of the child’s best interest, we take that their interest is considered in every measure taken concerning them (Article 16).
OECD Recommendation on Children in the Digital Environment (OECD/LEGAL/0389, 2021)
From it we take that a child in the digital environment is addressed by one overarching policy framework, not by rules scattered across parts of a product.
UNICEF Policy Guidance on AI for Children (version 2.0, November 2021)
From it, on the AI axis, we take three of its nine requirements: protect children’s data and privacy, ensure safety for children, and provide transparency, explainability and accountability.
Responsible Data for Children (RD4C) principles
From it we take the Proportional and Purpose-Driven principles: aligning the breadth of collection and the retention period with the intended purpose, and naming why the data is needed before collecting it.
The Age Appropriate Design Code (the Children’s Code)
A UK code on the design of digital services children are likely to access. Its pages could not be opened on the retrieval date, so it is named without a link, and nothing is quoted from it on this page.
General Comment No. 25 on children’s rights in relation to the digital environment
An international reference whose subject is children’s rights in the digital environment. Its text could not be opened on the retrieval date, so it is named without a link, and nothing is quoted from it on this page.
Druin, A. (2002). The role of children in the design of new technology. Behaviour & Information Technology, 21(1), 1-25.
From it we take the four roles a child can hold in design (user, tester, informant, design partner), and that choosing the role is a decision made before the session.
Stoilova, M., Nandagiri, R., & Livingstone, S. (2021). Children’s understanding of personal data and privacy online: a systematic evidence mapping. Information, Communication & Society, 24(4), 557-575.
From it we take that what a child understands about their data and privacy is studied rather than assumed, which makes explaining privacy in a child’s language a design decision rather than legal drafting.
Deci, E. L., & Ryan, R. M. (2000). The What and Why of Goal Pursuits: Human Needs and the Self-Determination of Behavior. Psychological Inquiry, 11(4), 227-268.
From it, on the attention axis, we take the distinction between intrinsic motivation that stands on its own and external incentives added on top of it.
Before you use the framework
No. It is an independent Dawani framework, not a government standard and not a certification. The axes here are design decisions under review; what is legally required is decided by the text of the law and by your own legal counsel, not by a page on our site or a tool result.
The axis leaves the calculation entirely, and the reason it left is written down. A product with no contact between children is not marked down for having no blocking flow, and a product with no generating component is not credited for a safeguard it never needed.
Not on its own. A self-review exposes the gaps and puts them in order; what remains is testing with children in the target band and an independent review. Even the top band of the score means readiness for a final review, not a verdict that the product is safe.
The questions run inside your browser; your answers are never sent to any server and never stored.
Updated: