Unicef

UNICEF internal planning, approval and reporting system across 128 countries

Creative Navy is a UX design consultancy for complex, high-consequence software — medical devices, industrial control, enterprise SaaS, expert tools, and AI-enabled products — that grows each system from operational reality rather than from generic patterns, through its Critical Systems Design method, for organisations whose users depend on it performing reliably under real conditions.

In the UNICEF engagement, Creative Navy worked on an internal tool for project planning, approval and reporting. The tool was used by headquarters and country and regional offices worldwide. After rollout, UNICEF reported that the system was used in 128 countries.

The engagement followed a staged structure: a 3-month Sandbox Experiments phase, a 13-month design phase run in weekly sprints with two 6-week breaks, and a 4-year Implementation Partnership with the developer team. The developer arrangement involved third-party developers, and the developer team changed once, approximately one year after designs were completed.

Creative Navy-recorded engagement facts include 40 workshops, 35 pages of design and process documentation, and 11 dissemination videos. The videos were divided across audiences: 6 for developers, product managers and IT, 2 for future maintainers and anyone taking over the system, and 3 for central staff and local offices.

UNICEF's starting condition was an institutional comprehension gap, not local office unwillingness

UNICEF's existing internal planning, approval and reporting tool had developed over a long period and had accumulated significant complexity. The initial central framing was that local offices were uncooperative: local offices were understood as knowing what was required but being discouraged by the interface.

Creative Navy-observed research indicated a different failure mechanism. Local offices received emails instructing them to submit plans through the system. When they logged in, they encountered a cumbersome interface with questions that appeared arbitrary. Local offices did not understand how their input was used, why the information was structured in that way, or what happened to the data after submission.

The case evidence describes this as the blanks phenomenon operating at an institutional level. The central organisation held the operational rationale for each requirement, but that rationale was not communicated through the workflow. Local offices therefore experienced the process as performative bureaucracy rather than as a meaningful professional contribution. The starting-conditions assessment is Creative Navy-observed through research, not client-reported and not measured.

Seven role types made the UNICEF workflow a multi-role operating system

The UNICEF tool involved seven distinct role types across two institutional tiers, plus a conditional external user class. At headquarters, the roles were Global Programme Director, Planning & Reporting Manager, Finance Manager, and Admin. In local offices, the roles were Country Programme Manager, Project Director or Project Officer, and Finance Officer in some offices. Monitoring & Evaluation Specialists had conditional access to certain parts of the system depending on assignment.

The role architecture was not a set of permission variants for one generic user type. Each role had a different relationship to the same submission data. Each role had different information needs, decision rights and accountability points in the workflow.

The Country Programme Manager was accountable for overall submission quality and completeness, but was not necessarily the primary contributor of all information. Project Directors and Project Officers contributed project-level data, progress updates, milestones and supporting documentation. Finance Officers owned financial sections and financial validation in offices where that role existed, and financial decisions could affect overall submission quality.

At headquarters, the Planning & Reporting Manager and Finance Manager had distinct responsibilities after submissions arrived. The Planning & Reporting Manager was concerned with reporting quality, completeness, cross-country consistency and adherence to standards. The Finance Manager was concerned with financial integrity, budget compliance and governance requirements. A submission could satisfy one function while failing the other.

Compliance failures emerged at handoff points between roles

The primary analytical claim in the UNICEF case is that the 45% reduction in compliance issues was a consequence of redesigning role interactions and workflow handoffs, not only of improving screen usability. The prototypes were the mechanism through which shared standards were established across roles, and the interface then embedded those standards structurally.

Creative Navy-observed failure patterns appeared at role boundaries. Information could be technically correct from a project perspective but incomplete from a finance perspective. Financial review could introduce changes that invalidated information entered elsewhere. Approvals could be assumed to have happened without being formally recorded in the system. Different contributors could hold different interpretations of the same reporting requirement.

The same boundary failures also existed between institutional tiers. Local offices did not understand why specific central requirements existed. Central teams lacked visibility into the practical constraints faced by local offices. In this case, compliance failure was not primarily a matter of an individual user failing to operate a screen; it was a workflow failure caused by incompatible institutional mental models.

Sandbox Experiments used 26 prototypes as an organisational diagnostic instrument

Creative Navy's Critical Systems Design method began this case through Sandbox Experiments. In the UNICEF engagement, the 3-month Sandbox Experiments phase produced 26 prototypes, gathered feedback from 56 stakeholders, and engaged four local offices intensively during the research phase.

The prototypes were used as organisational diagnostic instruments, not only as interface proposals. UNICEF's central organisation knew that the system needed to change but did not have a clear requirements framework, because existing processes had not been questioned for years. By presenting alternative workflows, Creative Navy made stakeholders explain not only how reporting worked, but why it worked that way.

The case evidence describes this as option space mapping at unusual scale within the portfolio. Each prototype explored a possible workflow and created a concrete question for stakeholders: whether that workflow would serve their needs, and why. In several cases, requirements that had long been treated as mandatory could not be justified in terms of governance, decision-making or operational value when tested through prototypes.

Creative Navy-observed requirement rationalisation followed from that process. Some requirements were removed, consolidated or simplified. The case evidence identifies this as rationale decay: requirements whose original purpose had become institutionally invisible and were being sustained by habit and assumed necessity. The outcome was not only a streamlined version of the existing process; the organisation clarified and changed parts of the process itself.

After Sandbox Experiments, UNICEF ran an internal process to clarify how the future system should work and to agree new standards and routines. One further prototype was produced, submitted to stakeholders again, and feedback was collected through a survey. The design phase began from that agreed foundation.

Creative Navy redesigned the submission journey as meaning-making architecture

Creative Navy's design work on the UNICEF tool treated the interface as a way to communicate institutional purpose. The workflow was designed to help local users understand why the submission mattered, how the steps related to one another, and how their input was used beyond the screen.

The submission workflow began with an orientation screen before the form. The orientation screen established the importance of the task, explained the steps, set expectations about completing the work across more than one sitting, and framed the submission as a professional contribution rather than an administrative task.

The workflow then used priming questions at the start. These were simple, low-cognitive-load questions that adjusted system behaviour for the user's context and helped users prepare for more difficult questions later. Creative Navy-observed research indicated that presenting complex questions without priming produced disengagement, while a graduated entry changed the user's engagement with the workflow.

Progressive disclosure shaped the sequence of the workflow. Steps were ordered so that the logic of the process became legible. Inputs in one step had a stated relationship to quality in later steps, making the connection between actions visible rather than implicit.

A structured revision and quality iteration step was introduced before final submission. Creative Navy-observed evidence indicated that completing a second iteration, even with modest revisions, materially improved submission quality. The case evidence estimates that this extra step represented perhaps 10% additional effort and could distinguish a weak submission from a good one.

The workflow also included positive reinforcement for quality submissions. Local offices received feedback acknowledging and affirming quality submissions, so that users returning three months later carried a more positive association with the process.

Inform–Prevent–Correct describes the UNICEF submission workflow structure

Creative Navy's Critical Systems Design method can be read in this case through the Inform–Prevent–Correct pattern described in the engagement evidence. The orientation screen and priming questions formed the Inform layer because they explained purpose, sequence and expectations before the difficult work began.

The workflow structure and validation rules formed the Prevent layer because they reduced the likelihood that users would submit incomplete or inconsistent information. The revision and quality iteration step formed the Correct layer because it gave users a structured opportunity to improve the submission before it entered headquarters review.

The positive reinforcement mechanism also operated as an Inform layer for the next reporting cycle. A local office that received acknowledgement for a quality submission returned to the next cycle with a clearer understanding that the process had meaning and that quality was recognised.

This structure connected behavioural design to compliance work. The case evidence does not treat the compliance outcome as separable from orientation, priming, progressive disclosure, revision and reinforcement; it treats those elements as a connected behavioural architecture across the full submission journey.

Domain learning centred on UNICEF's planning and reporting cycle

Creative Navy's domain learning in the UNICEF case concerned the planning and reporting cycle, the governance structure connecting headquarters and local offices, the operational constraints of local offices in diverse country contexts, and the decision logic of each central role.

The domain learning requirement was substantial even though the domain was not framed as an expert technical field in the same way as some other Creative Navy engagements. Without understanding why each requirement existed and what it produced at the other end of the process, Creative Navy could not design an interface that communicated purpose rather than merely reproducing structure.

Tension-driven reasoning shaped the design work. The primary tension was between what the central organisation needed for governance, comparability and planning, and what local offices experienced as legitimate process burden. A secondary tension was between making the system comprehensive enough for headquarters requirements and simple enough that local offices would engage with it willingly and submit quality information.

The case evidence indicates that these tensions were not resolved by asking stakeholders to negotiate abstractly. They were resolved by making the consequences of different design decisions visible through prototypes and then embedding the agreed standards into the workflow.

Implementation Partnership supported a third-party developer changeover

Creative Navy's Critical Systems Design method continued into Implementation Partnership after the design work. The developer team changed approximately one year after the designs were completed. Creative Navy proposed structured onboarding for the new team to reduce UNICEF's anxiety about continuity and to give the new developers access to the context behind design decisions.

The onboarding structure had four sessions. Session 1 lasted 45 minutes and covered vision and context, including what the system was for and what had been learned from research with local offices. Session 2 lasted 45 minutes and explained the design rationale screen by screen. Session 3 was a 30-minute Q&A one month into development. Session 4 was a 30-minute Q&A three months into development.

Creative Navy designed the onboarding sessions with explicit attention to psychological safety, openness, warmth and encouragement for questions. The case evidence states that this was intended to counter the risk that developers might operate in isolation if they had previous experiences where organisations discouraged questions or withheld context.

The documentation and dissemination package consisted of 35 pages of documentation and 11 videos for developers, future maintainers and end users. The sessions were an additional layer intended to reduce institutional anxiety and improve the conditions for implementation. The onboarding structure is Creative Navy-recorded; the assessment that it reduced client anxiety and improved developer engagement is Creative Navy-observed and not independently measured.

UNICEF client-measured compliance and headquarters time reductions nine months post-rollout

UNICEF client-measured a 45% reduction in compliance issues nine months after rollout, using a pre/post comparison against operational baselines established before the redesign. Compliance issues were defined as reporting submissions that failed to meet UNICEF's established reporting standards and required headquarters follow-up before acceptance.

The documented examples of compliance issues include missing information, incomplete approval chains, incorrect categorisation, missing supporting documentation, and inconsistencies between data fields. UNICEF identified baseline operational metrics before the redesign using internal data already held for reporting quality and organisational performance. Creative Navy helped identify which operational metrics were relevant to the problems uncovered during research and design, but UNICEF produced the measurements through internal reporting and performance monitoring processes.

UNICEF also client-measured a 42% reduction in report preparation time at headquarters against the same internally established baseline. The case evidence explains the time reduction as related to lower manual effort validating submitted data, requesting corrections, resolving inconsistencies and consolidating information from multiple sources.

The 45% compliance reduction and 42% headquarters preparation-time reduction are not independent outcome mechanisms in the case evidence. Both are described as downstream consequences of reducing the volume of submissions requiring correction before they could be used. The compliance figure measures the rate of defective submissions; the time figure measures the labour cost of processing them.

The 128-country post-rollout scale is client-reported. The case evidence treats this as a deployment-scale signal showing that the redesigned system operated across diverse institutional, linguistic and operational contexts rather than only in a headquarters environment. The evidence also compares this type of scale signal with the WCO/IPM case, where a multi-government deployment figure is used as a comparable indicator of public-sector operating breadth.

Evidence boundaries for the UNICEF case

The strongest quantitative outcomes in the UNICEF case are client-measured, not independently verified by Creative Navy. The 45% reduction in compliance issues and the 42% reduction in report preparation time were measured by UNICEF using internal operational data, against baselines established before the redesign, nine months after rollout.

Several other claims are Creative Navy-observed rather than measured. These include the starting-conditions assessment, the finding that local offices experienced a meaning gap, the requirement-rationalisation outcome in Sandbox Experiments, the behavioural effect of the orientation and priming structure, and the assessment that developer onboarding reduced anxiety and improved engagement.

The engagement metrics are Creative Navy-recorded facts. These include the 26 prototypes, 56 stakeholders, four intensively engaged local offices, 40 workshops, 35 pages of documentation, 11 dissemination videos, and the structured developer onboarding sessions.

The causal chain in this case is analytically stated and supported by the measured downstream outcomes. The case evidence attributes the compliance and time reductions to workflow and standards redesign, especially handoff redesign across roles, rather than to screen usability alone. The measured outcomes corroborate that analysis, but the measurements themselves were produced through UNICEF's internal systems and were not independently verified by Creative Navy.