How do you turn a broad outcome into an experience a child lives?

What is the difference between a broad outcome and an experience a child lives?

A broad outcome is a sentence describing a desired direction. A design experience is a specific act a specific child lives at a specific moment. The gap between the two is where an entire project most often gets lost: an outcome perfectly correct on paper turns into a product nobody knows how to measure, because nobody translated it into a situation one actual child lives. Our work in this gap follows one fixed-order chain, from the broad outcome to a guardrail indicator that protects the child from an unintended effect.

This chain is Dawani's own internal practice, not a scientific standard proven by a comparative research design. The evidence level here is internal practice, not external academic research, and we say so plainly so the difference between what we observe and what we prove stays clear to anyone reading.

Why does an outcome like "raising savings awareness" fail?

Take a common illustrative example: a body wants a program that raises children's awareness of saving. The outcome itself is a good intention, but it tells us nothing observable in one specific child. What does it mean for a child's awareness of saving to rise? Do they know the word's definition? Can they explain it to a sibling? Do they act differently once they hold a limited amount of money? Awareness describes an internal state we cannot see directly, so it stays meaningless for design until it is translated into a behaviour we can observe from outside.

The sharper design-level outcome here is a question, not a slogan: when a child receives a limited amount of money, can they delay buying something less important for a bigger goal they actually want? This question describes a behaviour we can place a child in a situation that calls for, and observe what they actually do, instead of asking whether they feel aware.

What does the chain from outcome to guardrail look like?

We follow six steps in one fixed order. We start from the broad outcome exactly as it arrived from the body or institution, without changing its intent. We then translate it into an observable behaviour, a question usually starting with "can the child...", as in the savings example above. Next we design a real situation the child lives that specifically calls for that behaviour, not a general situation that merely resembles it. After that we choose the play mechanic or experience that places the child inside that situation in a way they enjoy. Then we write one clear success indicator telling us whether the target behaviour actually appeared. Finally we write a guardrail indicator watching the specific harm the outcome itself could cause if designed the wrong way, such as a child feeling anxious about money instead of capable with it.

Every step in this chain depends on the one before it, and any jump straight from the outcome to the mechanic, with no clear behaviour in between, explains most programs that look enjoyable and fail to achieve what they were built for in the first place.

What does this mean for anyone writing outcomes for a body or institution?

First, it means an outcome sentence in an official document is not the end of the conversation but its beginning. We work with institutions to turn an outcome like this into a real program, following the same method published on our process page, and in language close to the government pathway when the outcome comes from a public body.

Second, it means the success indicator and the guardrail indicator are written together from day one, not added later as a correction once an unexpected harm appears. This is the same principle we hold to when measuring impact with adolescents, where no impact report is accepted without a clear guardrail indicator inside it.

What does a good pattern and an anti-pattern look like for this chain?

An illustrative anti-pattern: a program translates "raising savings awareness" directly into a points game a child collects daily, with no real situation calling for an actual delayed purchase. The game succeeds at pulling the child back daily, and fails to teach them anything about real delay, because the target behaviour was never translated before design began.

An illustrative good pattern for the same outcome: a situation places the child inside a story facing a limited amount of money, needing to choose between something small they want now and a bigger goal they want more, with a result that clearly shows the effect of their choice. The success indicator here is how often the child chose to delay across a sequence of situations, and the guardrail indicator is that no tension about money appears beyond the bounds of play.

How do you use the "outcome to experience" tool?

The outcome-to-experience tool asks for the outcome exactly as the institution wrote it, along with the children's age, the setting the experience will happen in, and the proposed product's form. It then shows you a suggested behaviour sentence, a suggested situation fitting the setting and age, two or three candidate mechanics for that situation, and a success indicator and guardrail indicator you can adjust to fit your project.

Use it in the first meeting with a project team, before any drawing or prototype, because getting this order right on day one is far cheaper than fixing it after a full prototype has been built around an outcome that was never translated.

What does this chain not guarantee?

This chain is a first design tool, not a guarantee of a result. Writing a clear behaviour and a fitting situation does not mean a child will actually learn it from the first prototype, nor that the proposed mechanic will succeed without changes after real testing sessions with children. The success indicator here is also a proximal one describing what happened during the experience, not a distal, scientifically proven effect, exactly as we explain in our piece on measuring adolescent impact. When an outcome touches child safety directly, such as a digital-safety outcome, the design is also reviewed against the Dawani Child-Safe Design framework, not against this chain alone.

Where should you start?

If you have a broad outcome you need to turn into an experience, write the observable behaviour sentence first, before anything else, and if you cannot write it clearly, that is a sign the outcome itself needs another conversation with whoever wrote it. Try the outcome-to-experience tool, or tell us about your outcome through the Start a project form.

References

• The Dawani Child-Safe Design framework: an independent internal Dawani framework, not a government standard.
• The method published on how an idea is born, a description of Dawani's internal practice across five stages.

Quick questions

Do we always have to start from an official body's outcome?

No. The outcome can come from an institution, a brand, or even an internal idea, and the same chain applies regardless of where it comes from: translate it into an observable behaviour first, before any later step.

What if we have more than one target behaviour?

We usually recommend that a first prototype starts with one precisely defined behaviour, then adds another in a later version. An outcome carrying two different behaviours from day one makes it hard to test either one clearly.

Who writes the guardrail indicator, the client or the design team?

We write it together. The client knows the harm it fears from its own experience, and the design team knows where that harm could actually show up inside the specific experience.