Ushahidi Guide: Build a Useful Community Map Without Turning Reports into Unchecked Facts

A public map can make scattered community reports easier to understand. It can also give an unverified claim an undeserved appearance of certainty. A useful Ushahidi project therefore begins with a reporting purpose, a verification process and a decision about what should remain private.

Ushahidi is a Kenyan-origin open-source platform for gathering and visualising information. This guide draws on its official user manual and deployment guidance, checked on 27 October 2026. ITBank has not installed a deployment or collected reports for this article. The example below is hypothetical and deliberately avoids sensitive incident reporting.

Start with one question people can answer

Imagine a community group documenting broken public water points. “Tell us about water problems” is too broad: submissions could describe billing, rainfall, quality, queues or damaged equipment. A more useful initial question is whether a named public water point was usable at a stated time.

Define who will use the information and what action it should support. If nobody has agreed to inspect or escalate reported faults, a visually impressive map may collect expectations that the project cannot meet. Explain that submitting a report is not a request to an emergency service and does not guarantee a repair.

Design the survey before designing the map

Ushahidi’s manual describes a survey as the structure governing a post’s fields and permissions. That makes survey design a practical data-quality decision. For the water-point example, useful fields could include a public asset identifier, observation date, broad location, condition category and a short explanation.

Make categories understandable to contributors. Distinguish “no water observed” from “equipment visibly broken”; they imply different follow-up questions. Ask for only the information needed for the project. A phone number, exact household address or identifiable photograph should not become compulsory simply because the platform can hold additional fields.

Separate observation from confirmation

Build a workflow for incoming reports, items needing clarification and information judged suitable for publication. Check the controls available in the actual platform version and deployment rather than assuming every installation shares the same settings.

A report submitted by one person is an observation with a source and time. It should not silently become a verified fact. Where possible, compare it with a second observation, an inspection record or a responsible organisation’s response. Keep a private record of what was checked. If conflicting reports remain unresolved, communicate that uncertainty instead of choosing the version that makes the map look complete.

Decide what the public really needs to see

Publishing every collected field is rarely necessary. Contributors may include names, contact details, photographs of bystanders or other information that is useful only for follow-up. Determine which fields can be public and which should remain restricted before inviting submissions.

Use approximate locations where precise coordinates could expose someone to harm. Even apparently ordinary infrastructure reporting may reveal where a vulnerable person lives or travels. Discuss the project’s data practices with appropriate local expertise, and give contributors a practical route to request correction or removal. Platform permissions support that work; they do not replace it.

Keep the map from becoming stale

A water point reported broken in March may be working in June. Record when a report was observed, checked and last updated. Decide how old reports are labelled and how a restoration is connected to the original issue. An undated marker is difficult to use responsibly.

Assign an owner to routine review. A small group can begin with a limited area and a manageable reporting period, then assess whether contributors understand the form and whether follow-up actually occurs. Keep copies of the project’s field definitions and reporting procedure so new volunteers can apply the same standards.

Measure useful action

Count more than submissions. Ask how many reports had enough detail to investigate, how many duplicates were resolved and how many issues received a documented response. A quieter project with dependable follow-up can be more useful than a busy map that nobody maintains.

ITBank’s practical assessment

Ushahidi is worth exploring when a group needs structured community reporting and mapping, and has people available to manage the information responsibly. The first deliverable should be a clear survey and review process. Build the map around that process, with honest uncertainty labels and a plan for maintaining what readers see.