A design toolkit for digital public infrastructure: 40 questions before you build

Guides · Published 2026-09-12

A row of wood-carving chisels and gouges with wooden handles laid out beside a sharpening stone — Carving tools laid out before work begins. Photo: Tomomarusan, CC BY 2.5, via Wikimedia Commons.

Most failures in public digital systems are decided before any code is written: an unclear purpose, a missing legal basis, a procurement that hands the architecture to one vendor. This toolkit groups forty questions into eight stages. It is meant to be printed, argued over and annotated.

How to use it: work through each stage with the people who will run, regulate and use the system, not only the technical team. A question you cannot answer is not a failure; a question nobody thought to ask usually is. The principles behind the checklist are set out in nine design principles.

Stage 1: Purpose

What specific problem will the system solve, for whom, and how is that problem measured today?
Which existing systems (public or private) already partly solve it, and why are they insufficient?
Is a shared platform really needed, or would a common standard that existing systems adopt be enough?
Which three to five use cases will be live in the first year, and who has committed to build them?
What will the system deliberately not do?

Stage 2: Legal basis and governance

Which law authorises the system, its data processing and its operator? If none, what is the plan and timeline to create one?
Who owns the platform, who operates it, and who sets the participation rules? Are these the same body, and should they be?
Which independent body oversees data protection and can sanction misuse?
How can a person or organisation challenge a decision made using the system, and how long does it take?
How will civil society, the private sector and local governments be consulted on rule changes?

Stage 3: Architecture

What is the minimal set of shared functions, and what is left to participants?
Which open standards will the interfaces use (for example OpenID Connect for authentication, ISO 20022 for payment messages, HL7 FHIR for health data)? See interoperability and open standards.
Will data be federated, with each authority keeping its own records, or centralised? Why?
How will the system connect to existing identity, payment and data exchange layers rather than duplicate them?
Can each component be replaced independently?

Stage 4: Data protection and security

Has a data protection impact assessment been carried out and published, at least in summary?
What is the minimum data needed for each use case, and how is everything else excluded?
Will people be able to see who accessed their data, when, and for what declared purpose?
How are identifiers protected from becoming a universal tracking key (tokenisation, sector-specific numbers)? See digital ID privacy safeguards.
What is the incident response plan, and who must be notified of a breach, within what time?

Stage 5: Inclusion

Who is likely to be excluded: people without documents, with disabilities, without smartphones or connectivity, with low literacy, or in remote areas?
What is the fallback when a digital check fails (for example a biometric mismatch), and is it written into the rules?
Are interfaces available in the main local languages and tested against accessibility standards such as WCAG?
Are assisted channels (agents, counters, helplines) funded for the long term, not just the launch?
Will exclusion and failure rates be measured and published?

Stage 6: Procurement and technology choices

Does the state get the rights to the source code, documentation and data it needs to change supplier?
Have open-source and digital public goods options been assessed (for example X-Road, MOSIP or GovStack building block specifications)? See open source versus proprietary.
Is there in-house capacity to manage the architecture, or will the vendor effectively own it?
Are hosting and data location requirements defined, and justified by law rather than habit?
What is the total cost of ownership over ten years, including operations, upgrades and support for participants?

Stage 7: Operations and the ecosystem

How do new participants join: published criteria, test environment, certification, timelines?
What are the service levels (availability, response time), and are they published?
How will fees, if any, be set and reviewed?
How will developers get support, documentation and advance notice of changes?
How will the operator avoid competing unfairly with participants?

Stage 8: Measurement and review

Which outcome indicators matter (time saved, cost per transaction, inclusion), beyond adoption counts?
Which data will be published regularly, at what level of detail?
Who will evaluate the system independently, and when?
What would count as failure, and what would happen then?
When will the rules and architecture be formally reviewed?

Our article on measuring DPI impact develops stage 8.

Running a toolkit session

The questions work best in a structured half-day or full-day session rather than as a form to fill in alone. A format that tends to work:

Invite beyond the project team: the legal adviser, the data protection officer, a frontline service manager, someone from finance and, where possible, representatives of the intended users or civil society organisations that work with them.
Answer in writing, with owners: for each question, record a short answer, the evidence behind it and the person responsible for closing any gap, with a date.
Mark three states: answered, partly answered, unknown. The unknowns are the most valuable output; they become the project's risk register.
Repeat at milestones: before procurement, before the pilot and before national rollout. Answers that were acceptable on paper often change once real users and real data are involved.

Publishing a summary of the answers, even a partial one, is itself a test of the governance stage: a team that cannot explain its choices publicly may not have settled them.

Open resources worth knowing

GovStack: specifications for reusable "building blocks" such as identity, payments, consent, registration and messaging.
Digital Public Goods Alliance: a registry of open-source software, open data and open standards that meet its DPG Standard.
World Bank ID4D: guidance and assessment tools for identification systems.
Interoperable Europe: the European Interoperability Framework and reusable solutions.
X-Road and MOSIP documentation: two mature open-source platforms whose documentation is useful even if you do not adopt them.