Research for playbook
This document aims to explore what we know and what we need to know to best iterate the implementation playbook.
How to contribute:
Highlight content that you think is priority or important / not priority or not focus
Add any missing questions to resolve in this period
Comment answers to questions or what we can do in the next week to answer them
1. Problem framing
1.1 What problem are we trying to solve?
Why does the playbook need to be iterated now?
Nico: “Now” is relative. I started the process one year ago I did already one new version with Puja in beginning of 2025. The reason: After couple of workshops, I realized, it doesnt give a clear guidance how to design services. Second reason: Kristo wrote it into GovSpecs strategy - not sure about his reasoning.
What prompted the review (feedback from countries, implementers, partners, internal frustration, gaps)?
What evidence do we already have of confusion, duplication, or misalignment?
Is the current issue about content accuracy, structure, findability, practical usability, or conceptual alignment (e.g. DDD)?
Nico: Gaps in content/guidance. It doesn’t recommend the right things. You wouldn’t be successful in following the current service design chapter.
1.2 What goals should the revised playbook serve?
What is the job the playbook must help people do (e.g. plan a national implementation, write a TOR, commission suppliers, design/iterate services, build capability)?
Nico: minimum: design one gov. service, ideally: plan and conduct full digital transformation of all gov. services
Puja: minimum: best practice guidebook for digital transformation of gov services.
What must it enable that it cannot today? Puja: At the moment it is a bit out of date.
2. Users, scenarios & stakeholders
2.1 Who are the core users?
National digital leads
Implementing partners (secondary)
Designers in-country
Nico: In-country implementation teams (PM, UX designer, dev, architect,…)
Product teams
Policy teams
Procurement teams
Vendor/developer teams
Donor organisations
GovStack building block owners
Puja: GovStack Global training participants
Which of these groups currently uses the playbook, and which should it serve in future? Puja: In the future, when fully updated, GovStack Global training participants could use it.
2.2 What capabilities do they have?
Which users have design capability?
Who has delivery capability?
Who has no engineering capability?
Who will always outsource development?
2.3 What are the key user scenarios?
Example scenarios we should validate with research:
A government team needs to write a TOR or tender.
A delivery/implementation partner needs to interpret requirements and build a product/service.
An implementation partner needs to interpret requirements to advise on digital transformation.
A country team needs to prioritise services and create an architectural vision.
A digital team needs to align political strategy, change management, and technical delivery.
A designer needs practical, use-case-level guidance.
A team needs to ensure inclusion, accessibility, and citizen engagement.
A technical partner needs guidance for aligning with GovStack building block standards.
What scenarios are missing?
2.4 What are users’ biggest pain points today?
Brainstorming of questions from the users Questions the chapter must/should answer
What have we heard from implementations (EAC, Ukraine, Kyrgyzstan, Rwanda, etc.)?
Nico: Most times the objective is: How to deliver gov services fast. Quantity as priority. The problem: How to keep a good quality and how to follow a sustainable, scalable architecture?
Where do country teams struggle with sequencing, understanding, or misinterpreting GovStack guidance?
Nico: We dont advertise it that much (in GIZ), since we are not convinced yet. There might be feedback from the online trainings “Architects training” and “WiGTC” where it was used. @Puja Raghavan might know more.
Puja: Because even the templates are out of date and sometimes the examples are not upto date, in the global trainings, we barely use the Playbook. When we invite experts, they now insert the updated version of templates for identfying as is and to be etc.
Which guidance feels duplicative, unclear, overly “template-heavy,” or not grounded in real practice?
Nico: I dont think that’s currently a problem
Are teams overwhelmed, under-informed, or confused about where to start?
Where do people struggle to access things
3. Alignment with domain-driven development (DDD)
3.1 What does DDD mean in the context of digital government?
What parts of DDD are relevant: ubiquitous language, bounded contexts, domain modelling, aggregates, event flows, service boundaries, etc.?
Nico: Dont know what aggregates, event flows are. But all the others seem relevant.
Mira: I assume that aggregates (a group of related data that must stay consistent together, e.g. in an application the applicant’s address, uploaded documents & application status) and event flows (I believe e.g. document uploaded, application submitted, …) are also relevant. Additionally I think prioritization in core/supporting/generic domains to cater to limited budgets is important, see the next point.
How might DDD help to define architects/developers which parts of a service to fulfil with generic Building Blocks and which need custom backend applications/micro services?
3.2 How can the playbook embed DDD thinking at the right level?
Where should domain language and ubiquitous language appear?
Nico: I assume that to be ground work in the discovery stage
Should service definitions be linked to domain maps?
Nico: Can you explain what that means?
How do we support teams to identify domain boundaries, not just service catalogues?
Nico: My assumption is that domain boundaries are related to topics/sectors (e.g. health). But most likely a domain spans across various services. Bounded context on the other side are a lot smaller. A service will be cut into several bounded context. Maybe a bounded context can appear in another service as well. That might be how new BB are formed → a bounded context appears often? Consider turning it into a generic BB.
How do we ensure the design, architecture, and implementation sections reinforce DDD rather than duplicate or contradict each other?
Mira: Tricky, but I suggest starting with:
Defining a purpose/goal for each section and enforcing regular cross-checks across sections
Using the repository with glossary etc. as reference throughout the sections
3.3 What is the minimum viable DDD guidance the playbook should include?
How complex should the DDD content be for government stakeholders with no dev capability?
Nico: As simple as possible as complex as necessary. For example, we could say, as minimum DDD shall be used to 1) understand a domain and 2) lead developers to scope their applications/micro services.
4. Content audit, duplication & prioritisation
4.1 What content already exists across GovStack resources?
Guides include:
Sandbox methodology
Service Design Best Practice | sandbox
Sandbox use-case examples
Implementation playbook
Design patterns (including service catalogue content)
What else?
4.2 Where are the overlaps and contradictions?
Where do guidelines share concepts (e.g. service design, service catalogues, journeys, blueprints)?
Are definitions inconsistent?
Are processes repeated across documents?
Are maturity assessments duplicated?
4.3 What can be merged, removed, or relocated?
Which content belongs in the core playbook?
Which belongs in reference appendices or external resources?
Which content is not needed at all?
What is the minimum that must stay?
What belongs only as links rather than full sections?
5. Structuring the playbook
5.1 Should the playbook be structured by:
Phases of work (strategy → planning → design → test → procure → implement → iterate), or
Note Mira & Lea: Mira and I agree with Nico - we prefer a structuring according to "phases of work", as it provides a good overview of the planning & implementation process and helps to cater to the different needs & interests of stakeholders/roles. Mira an I just brainstormed and we suggest the following levels for structuring:
Recommended structuring approach
Themes (design, architecture, inclusion, testing, procurement), or
User jobs (e.g. ‘before you start’, ‘testing ideas’, ‘moving to beta’, ‘launching a platform’), or
Betty - For the design chapter we can adopt such as a structure:
Specifically the design process section can be further modelled after the 'phases'.
We ought to ensure the guide supports design of new services or a redevelopment of existing services. So less focus on the naming of the phase by phase approach but their values, activities and outcomes.
Understanding user needs for new services, review or updating of exiting services (discovery)
Testing assumptions before major changes (alpha)
Launching small scale (private beta)
Scaling and maintenance (public beta)
Capability areas (discovery, architecture, delivery, governance, procurement, change management)?
5.2 Which structure helps users actually do their work?
Which structure reflects real implementation workflows experienced in country?
Does the proposed "To-Be" structure support or complicate user journeys?
5.3 Is the proposed structure missing critical topics or sequencing logic?
If we align with DDD, should domain mapping appear earlier?
Should the sequencing more clearly reflect cyclical/iterative work rather than a linear waterfall?
Lea Note: The playbook currently lacks:
An introductory section at the beginning that clearly explains the recommended approach for implementing GovStack in the correct chronological order. This would provide essential context and guide readers through the timeline and dependencies.
Section-level introductions for each major part of the playbook (e.g., Introduction, Strategy, Implementation - as shown in Mira’s graphic in the Slack channel Implementation Playbook https://govstack.slack.com/archives/C09TPJ6L49Y/p1764157304955289?thread_ts=1764102289.494289&cid=C09TPJ6L49Y ).
These introductions should first outline what generally happens in the specific stage.
After that, they should describe the specific Level 1 and Level 2 phases within that section to give readers a clear roadmap.
6. Governance, ownership & contribution model
6.1 How do we decide what goes into the playbook?
Who is the content owner?
What criteria do we use to accept or reject content?
When do we maintain references to other documents rather than copy/pasting?
How will content be updated? In phases? By chapters?
Lea: Who is responsible for the review process? Which specific individuals make up the “reviewing committee,” and how are these committees assigned to different sections? It’s likely that we will need separate committees for different parts of the playbook.
Lea: We need to define how review decisions will be made - whether by consensus, voting, or a designated lead reviewer - and establish a clear timeline for review cycles.
6.2 How do we align globally but allow context-specific variation?
Should country examples (EAC, Ukraine, etc.) be case studies or embedded guidance?
Should they be in an appendix or integrated into each relevant section?
7. Success criteria & evaluation
7.1 What does success look like for the revised playbook?
Country teams can quickly understand how to start.
Teams can write better TORs with fewer misunderstandings.
Implementers can align on design, architecture & delivery principles.
Less duplication, more cohesion.
Shorter time to onboard new partners.
Teams in-country report fewer “pain points” when using GovStack guidance.
7.2 What does failure look like?
The playbook is too long.
The structure is confusing or overly complex.
It duplicates existing content without reducing cognitive load.
No measurable improvement in implementations.
Country teams ignore it in favour of more practical documents.
8. Immediate next steps (research & assessment)
8.1 Evidence gathering