Problem definition

Basics

Before anyone picks a tool, the team should be able to say what problem it is solving, for whom, and how they know. The problem should be one specific, observable difficulty in people's lives or work, not a broad aim such as "better health" src-007 p14; src-028 p14. The people who live with the problem should have helped name it, and should recognise the description src-007 p14; src-027 p36; src-037 p13. Only once the problem is clear does it make sense to ask whether AI, or any technology, has a part in solving it src-007 pp6, 10; src-039 p45; src-004 p10.

Why it matters for AI tools

How a problem is framed decides which solution looks right. A team that frames a problem as missing information will build an information tool, even when the real cause is social, economic or about unequal power src-027 p18. Many AI tools in development deliver tailored information, so they are open to this trap src-015 p16.

Information only changes behaviour when it fixes a real gap in what people believe and removes the barrier that stops them acting. In Rwanda, girls already overestimated HIV risk, so researchers advised against scaling an information programme that had cut teenage pregnancy in Kenya src-015 p16. A personalised AI messaging tool built on the wrong problem will not help, however well it performs.

Vague problems also make AI risks hard to see. A narrow, well-defined task makes the benefits and harms of an AI system simpler to trace src-024 p74; src-028 p14. And a clear problem statement lets the team check whether the tool is worth building at all src-024 p63.

A separate page covers non-AI alternatives: whether something other than AI could solve the same problem src-012 p22; src-024 p63.

What good evidence looks like

• A short problem statement naming who is affected, where the difficulty arises, what people do now to cope and what that costs them src-007 p14.
• The problem statement has been tested with people who face the problem, and they recognise it src-007 p14.
• The problem was explored openly with communities before objectives were fixed, not only checked against goals already set by the funder or implementer src-027 p32; src-039 p27.
• Evidence that the intended users see this as a problem, and that local actors are involved in driving the work src-037 p13.
• An analysis of root causes, not only symptoms, for example by repeatedly asking why the problem happens src-025 p37; src-027 p36.
• What the audience already knows and believes, so the team can tell whether lack of information is really the barrier src-015 p16; src-006 p74.
• A focus on one problem, or a closely related set, rather than many at once src-028 p14; src-006 p38.
• A theory of change (a stated chain from activities to results, with the assumptions behind each link) that names the problem, what the AI will do, and what must be true for people to reach and use it src-015 p7; src-030 pp10-11; src-004 pp27-28.
• Stakeholders, including less powerful groups, agree on the changes the project seeks src-030 pp10-11.

How to find out

Several methods can help, and the right mix depends on the setting. Desk research and interviews with subject experts build an early picture src-028 p14. Survey data can show how widespread the problem is, and qualitative research can explain why it happens and who holds decision-making power src-028 p14. Participatory assessment opens a conversation with communities about their own priorities before objectives are set src-027 pp31-32. Working sessions with users and others in the system can turn many views into one problem statement src-007 p14. Mapping a theory of change, and marking where information and communication flows matter, shows where a tool might fit src-004 pp27-28; src-030 p11. Root-cause questioning with field teams can show which problems several programmes share src-025 p37. Context mapping looks at the setting, users, possible harms and cultural norms, ideally in or close to the real setting and with community groups src-024 pp62-63. No checklist on its own will diagnose the right technology; these methods are ways to test the team's assumptions src-032 p6.

Limits and disagreements

Needs first or tools first. Most sources say to start from the problem. Plan Finland names a real tension: setting goals too tightly around known tools can shut out useful innovation, so ideas from what technology makes possible still have a place src-039 p27. NetHope goes further the other way: it suggests matching field problems to models the organisation already has src-025 p37. That approach risks a solution looking for a problem, which Girl Effect warns against src-037 p13.

How much participation. The World Bank guide sees full participation in defining the problem as the ideal, and treats an assessment that starts from fixed objectives as only partly participatory src-027 p32. The AI-focused sources describe involvement as working sessions with users or collaboration with community groups, and leave open who sets the objectives src-007 p14; src-024 p62.

Mostly non-AI evidence. Most of the support comes from communication for development and ICT for development (using information and communication technology in development work) guides written before generative AI, the oldest from 2009 src-027 p18; src-039 p27; src-004 p10; src-006 p37. Only a few sources address AI directly src-007 p6; src-015 p7; src-024 p62; src-028 p14. The evidence on information and behaviour comes from non-AI studies in Kenya, Rwanda, Madagascar and the Dominican Republic src-015 p16. The crop example from Africa, where a drought-tolerant variety was abandoned because farmers needed long stems for roofs, has no reference src-027 p31.

Shared authors. Girl Effect (src-012, src-037), the Plan Finland report (src-039) and SIMLab's monitoring framework (src-030) have MTI-linked authors. Their agreement with each other is less independent than it looks.

Little rigorous evidence. Nearly all support is practitioner advice. Only the J-PAL point on information and behaviour rests on evaluations src-015 p16.

Practitioner detail

To judge whether a tool aimed at behaviour change addresses the real problem, ask what people gain quickly, what it costs them in time, effort, status or money, how others will see them, and whether they have the skills and means to act src-006 p74. If any of these is the binding barrier, more information will not move it src-015 p16.

When objectives are already set, as with most funded projects, an assessment can still feed back risks and blind spots to management, so long as the findings are open to negotiation src-027 p32. Dalberg's playbook asks teams to record what they still do not know before moving to design src-007 p14. For tools built on large language models, PATH puts naming the users and their problem before team building or data collection src-008 pp13-14.