You have an app idea, and no design team that understands children
You have the goal and the technical team, and what is missing is someone who turns that into screens a child actually understands and enjoys.
A Dawani service
Children's app design and development in Saudi Arabia
We design and build apps a child uses themselves, for government bodies, brands and companies that want a digital product the child opens with their own hand, not only their parents. We start with a plain gray prototype tested with real children, with their parents' consent, and design the app itself around collecting as little data as possible.
What you get
- A written scope document naming the app's screens and features, and what stays out of this version
- A plain gray prototype of the app, tested with real children with their parents' consent before any final build
- A design for every sign-up screen and data field that collects as little as possible
- A success indicator and a guardrail indicator agreed before launch
How we work
Every decision in building the app passes through our design laws, and before any final interface we test a plain gray prototype with real children. To read a session of use we reach for the Screen Value Score, and to review the whole app we return to the Dawani Child-Safe Design framework.
When you need this service
Three situations before a first conversation with us
An existing app you want reviewed from the child's angle
The app already works, but you want an independent eye to review its sign-up screen, its permissions and its design against a child-safety standard.
You want an Arabic-first app, not a translated foreign interface
The goal is an app built in Arabic from its first screen, not a foreign interface with only its words translated.
How the service runs
Four stages, a gate after each
1 Understanding the goal
We start from your app's goal as you describe it, and from the child who will use it, by age and context.
Gate: The goal leaves this stage once we agree on a specific aim for the app, not a general description of its idea.
2 Written framing
We write the app's scope: its screens, its data fields, and what stays out of this version.
Gate: The framing leaves this stage once the app's scope is written and agreed, instead of staying a verbal understanding.
3 Gray prototype and testing with children
We build a plain gray prototype of the app's screens, and real children test it with their parents' consent.
Gate: The prototype leaves this stage once it works with children as intended, not once the internal team is pleased with it.
4 Delivery and measurement
We deliver the app, and measure it against the success indicator and the guardrail indicator we agreed on from the start.
Gate: This last stage is never left behind; the guardrail indicator stays with the app for its whole life, not only at launch.
In scope and out of scope
| Aspect | In scope | Out of scope |
|---|---|---|
| Designing and building the app | The screens, the usage flow, the gray prototype, and the built version parents can try. | Marketing the app after launch, or managing its account in app stores. |
| The app's data | Designing every data field to collect as little as possible, with a clear reason for every field that stays. | A legal compliance certificate for data protection; that stays with your own legal adviser. |
| Timeline and price | A proposal built on your app's own case once we understand it, naming what is out of scope as clearly as what is in it. | A time or price announced in advance, before the request is understood. |
| The outcome for the child | A success indicator and a guardrail indicator agreed before we start. | A guaranteed outcome for the child, or a download or usage number we commit to. |
Before you write to us
A tool, a post and a reference
Screen Value Score
A tool that runs in your browser: it reads a session of use and says what raised or lowered its value, before you describe your app's goal to us.
Open the toolDoes a children's app actually need an account?
A post explaining the decision tree we apply to every data field in a child's app, before asking how to protect it.
Read the postThe Dawani Child-Safe Design framework
The reference the screens of every app we design are measured against: axes, each with a good pattern and an anti-pattern.
Open the frameworkBefore a first conversation
Questions often asked about this service
What if we already have an existing app, not an idea from scratch?
We review an existing app by the same safety standard we use to design from scratch, and propose changes starting from the highest risk first.
Do you design only the child's screens, or the parent's screen too?
We design the parents' role inside the app whenever the product needs it, from supervision settings to a periodic report on the child's use, not the child's screen alone.
Do we get a written design document if we choose another team to build it later?
Yes. The scope document and the prototype we tried with children are both handed to you in writing, and another team can build on them if you choose to.
Start here
Have an app idea a child will use themselves?
Describe your situation plainly, and we will get back to you within a few working days.
Your path: brand or company
Your idea arrived.
A real person from the Dawani team will read it and reply within a few working days. Thank you for thinking about kids.
Updated: