When: 14:00-16:30 Dakar
Where: OpenTalk (link in invite)
Survey: https://kyc20-data-lineage-production.up.railway.app/
| Time | Block | Key point |
|---|---|---|
| Open | Benefits for all cities and all years | This helps everyone, everywhere, over time — not only Ziguinchor today |
| 5 min | Kblock demo | Existing map data can support real decisions when combined with federation data |
| 25 min | Data survey online | Document what you have and what you plan — we ask, we do not assign |
| 5 min | Break (after survey) | Pause and connect the next blocks to what you actually heard |
| 15 min | Use cases on whiteboard | Name real problems in real work — not features or technology |
| 15 min | Connect survey to use cases | Every priority use case needs data behind it — or an honest gap |
| 10 min | Break (before personas) | Reset before empathy work — review notes from survey and use cases |
| 15 min | Personas | A good persona is someone you can picture: name, job, goal, frustration, data need |
| 30 min | Persona user stories | One concrete story per role, tied to data from the survey |
| Close | Conclusion | Read back what we agreed — no new topics |
Key point: The value of this project is for all programme cities and across years — include data you already hold, not only what this project will collect.
Today we focus on Ziguinchor, but the platform is meant to help all seven programme cities. It should also hold data from different years — old maps and surveys matter as much as new ones. When you document what you have and what you plan, you are helping your city and the wider network. The survey is not only about data from this project; include anything your federation already holds from earlier work.
Key point: This demo shows what is possible when map layers are used for local decisions — it is motivation, not the final product.
Show Kblock as a real example of what good use of map data can look like. OpenStreetMap is one input; the point is turning existing map layers into something useful for local decisions (for example seeing patterns block by block). Say clearly this is a motivation demo, not the final product. OpenStreetMap on its own is not enough — it works best when combined with federation data such as settlement boundaries and field surveys. After the demo, ask: which layer do you already have, which is missing, and who in your team looks after it?
Key point: The survey is a shared picture of your data landscape — we capture what exists, what is planned, and who is responsible, only when you are ready to say.
Walk through the lineage survey together. People sign in, pick Senegal, and fill what they know — they do not need to finish everything today. For each dataset: does it exist now, is it planned, or not applicable? If something is missing, ask gently whether they plan to collect it, roughly when, under which project, and who would be responsible — only if they are ready to answer. Note to confirm where they are unsure. Fix any wrong or placeholder rows (for example copied example text on OpenStreetMap). Drone flights were not allowed in Ziguinchor for law-and-order reasons; street-level mapping was discussed as an alternative — if they confirm, add it as a possible new dataset type.
Key point: Use this pause to turn survey answers into useful input for the whiteboard — not to start the next block cold.
Pause the session. Tell participants you will be back in five minutes.
For you (internal): use this time to gather lessons from the survey block — what was filled, what is still missing, who owns what, any surprises or blockers. Jot quick notes before moving to the whiteboard so use cases and personas connect to what you actually heard, not what you assumed.
« On fait une pause de cinq minutes. On reprend dans un instant pour la partie tableau blanc. »
Key point: A good use case starts with a problem someone faces this month — not a wish for a better system.
Ask what problems the city platform must help with in real life: preparing for a meeting with the mairie, showing service gaps on a map, linking a story to a place, exporting numbers for a report. Write 4-6 use cases as short sticky notes. Do not debate technology. Pick the 2-3 that feel most urgent for Release 1.
Key point: If a use case cannot point to data you have or plan to collect, it stays a wish — mark the gap honestly.
Draw lines on the whiteboard from each priority use case to the datasets in the survey that support it. If a use case has no data behind it, mark the gap — do not treat it as ready to build. If survey data has no use case yet, note it as available but unused or purpose unclear. This step stops wishlists: every important use case should point to data you have, plan to collect, or honestly lack.
Key point: Persona work needs empathy — take a breath and review what you learned before asking people to describe users.
Pause again before the persona block. Use the time to skim your survey and use-case notes so the examples you put on the board reflect Ziguinchor, not a generic template.
« Petite pause avant la partie personas — on reprend dans dix minutes. »
Key point: A good persona is someone you can picture — if you cannot name their job, goal, and frustration, it is still too vague.
Name the people who will actually use the platform or decide what others see. Avoid vague labels like community or government — rename into something concrete. Aim for up to five roles for the first release.
Checklist for a good persona:
- A name or clear role label (not "the community")
- Who they are and what they do day to day
- One goal and one motivation (why they care)
- One urgent need and one frustration today
- What data they rely on and what access they need
- What success looks like for them
Example persona (put on the board as a template — then ask the group to adapt or replace):
Aminata Diallo — community organiser, UrbaSEN Ziguinchor
| Who she is | Aminata is 34. She works with savings groups in two settlements in Ziguinchor. She is not a GIS expert; she uses a phone and sometimes a laptop at the UrbaSEN office. |
| What she does day to day | Visits settlements, supports enumerators, prepares federation members for meetings with the city authority, and turns survey results into simple maps and talking points. |
| Goal | Keep residents from losing their homes without evidence. Get the mairie to listen with dated maps and counts, not only stories. |
| Motivation | Her aunt's settlement was cleared without warning. She does not want that to happen again without the federation being able to show who lives where and what services exist. |
| Urgent need | Before the next council meeting in six weeks: one map with settlement boundaries, household counts, and water points — all from the same date, easy to show on a tablet. |
| Frustration today | Data sits in different places — someone's Drive folder, paper notes, an old shapefile on one laptop. She spends days copying numbers into slides instead of organising. |
| Data she relies on | Settlement boundaries, household enumeration, infrastructure (water, toilets), photos or stories linked to places. |
| Access she needs | Read and export for meetings; she does not upload raw surveys herself — she asks the data manager. |
| What success looks like | She opens the platform on her phone, picks her settlement, and has a map and summary she trusts enough to take into the mairie office. |
| Privacy concern | Household names and phone numbers must not appear on anything the public or the council sees without explicit approval. |
Ask the group: Who in your team is like Aminata — or different? Give them a name, a job, one goal, and one frustration.
Key point: A good user story names one action on the platform and one outcome in real work — and points to data you documented in the survey.
For each priority persona, write one user story in plain language: As a [role], I want to [do something on the platform], so that [outcome in real work]. One story per role is enough in the room. Optionally rewrite one story in Given / When / Then form if the group finds it helpful. Keep stories tied to data you documented in the survey — if the story needs data that does not exist, note that as a gap rather than pretending it is there.
Key point: End with clarity — what we captured, what is still open, and how people can follow up if they want to.
Read back what you captured: main use cases, which data supports them, top personas, one story each, gaps and to confirm items. Mention who decides publish rules (controller vs day-to-day data manager) only at a high level if time allows — full rules come later. Offer a WhatsApp group for anyone who wants to continue the survey or clarify names after the session. Confirm you will send a short written summary within 48 hours. Thank people and stop the recording.
Ask; do not assign. Capture plans only when participants share them. Personal data does not go on the public map by design — note sensitive cases for later governance discussion.