Participatory Design in ICT4D: Principles, Methods, and Field Practice

Participatory design (PD) is an approach to technology design that involves the people who will use a system as active co-designers, not merely as informants or end-users to be consulted after key design decisions have been made. In ICT4D contexts, PD represents a deliberate effort to address the power imbalances that have historically characterized technology development for communities in the Global South — where systems are designed in high-income-country offices for use by communities in low-income-country contexts, often without meaningful input from those communities.

This article covers the intellectual foundations of PD, its adaptation for ICT4D field practice, the specific methods used in the field, and the persistent tensions and critiques that practitioners must navigate.

Foundations: Where PD Comes From

Participatory design originated in Scandinavia in the 1970s, growing out of the labor movement’s concern with workers’ rights to participate in decisions about workplace technology. In the original PD model, workers — not management or technology designers — were recognized as having legitimate expertise about their own work processes, and therefore as proper co-designers of the systems that would affect them.

This political origin is important: PD was not just a methodological preference for better information-gathering, but an ethical and political commitment to the democratic right of people to shape the technologies that affect their lives.

When PD was adopted by ICT4D researchers in the 1990s and 2000s, it was adapted to address a different power asymmetry — not between workers and managers, but between external development organizations and the communities they claimed to serve. The political commitment translated to: communities in the Global South have legitimate expertise about their own needs, resources, and constraints; technology designed without that expertise will often fail or harm.

PD Principles for ICT4D

1. Equality of participation: All stakeholders — including those with limited formal education, limited technical knowledge, or marginal social status — are recognized as having legitimate knowledge contributions to the design process.

2. Situated knowledge: Knowledge about what is needed, what is feasible, and what is appropriate is located in the community, not in the designer’s office. Designers are experts in design processes; community members are experts in their own lives.

3. Iterative learning: Design is not a one-time event followed by deployment. PD emphasizes cycles of design, testing, reflection, and redesign — with community members participating throughout.

4. Attention to power: PD requires explicit attention to whose voices are heard in design processes, whose are not, and why. In communities with significant internal power differentials (by gender, class, ethnicity, age), a PD process that includes “the community” without attention to who speaks for the community may simply replicate existing inequalities.

5. Appropriate outputs: PD does not always result in software or apps. Sometimes the most appropriate output is a protocol, a process, a service design, or a recommendation that no new technology is needed.

Core PD Methods

Workshops and Brainstorming Sessions

The most accessible PD technique: bring community members together in facilitated sessions to identify needs, evaluate options, and generate ideas. Effective PD workshops use visual and tactile materials — paper prototyping, card sorting, role cards — to make participation accessible to people with varying literacy levels.

Adaptation for low-literacy contexts: Replace text-heavy materials with visual representations. Use local cultural objects and metaphors as design materials. Work through local interpreters when the facilitation language differs from the community language.

Future Scenarios

Participants are asked to describe their vision for how a technology-supported activity might look in the future — not necessarily using current technologies, but imagining what would be ideal. This technique helps surface underlying needs and priorities without anchoring discussion to existing solutions.

Example in practice: In a study of agricultural information needs in rural Tanzania, future scenario exercises revealed that farmers prioritized weather information and market prices, but the ideal scenario they described was voice-based (they could call a service) rather than text-based (they could not all read well). This redirected the design toward IVR (interactive voice response) rather than SMS.

Paper Prototyping

Physical paper mock-ups of interface designs allow community members to interact with proposed systems before any software is built. Participants can physically rearrange, cross out, and add elements — making design a tangible, hands-on activity.

Paper prototyping is particularly valuable in ICT4D contexts because it removes the assumption that participants need to know how to use a computer or smartphone to participate in design. Anyone can move paper.

Experience Sampling and Diary Studies

Rather than bringing community members into a design session, experience sampling asks participants to document their information and technology practices in their own environments over time — through voice memos, simple diaries, or structured SMS responses. This reveals usage patterns that structured sessions might miss.

Technology Probes

Technology probes are early, intentionally incomplete technology deployments — not finished products but platforms for learning. They are deployed in communities to generate data about how people actually use them, what they do with them, and what problems they encounter. The probe is less about testing the technology and more about learning about the community’s practices.

Challenges in ICT4D PD Practice

Language and translation: PD requires communication across potential language barriers. Working through translators slows the process and can introduce interpretation gaps. Investing in PD facilitators who share the community’s language is a substantial practical commitment.

Power within communities: Communities are not homogeneous. Gender, age, ethnicity, religion, and class create power differentials that affect who speaks, whose ideas are taken seriously, and whose needs are designed for. A PD process that recruits “community representatives” without attention to who those representatives represent can systematically exclude the most marginalized.

Research capacity vs. design capacity: Universities and research organizations conducting PD in ICT4D contexts often have strong research skills but limited design capacity — they can analyze community needs but cannot build the systems that would address them. Partnerships with technical teams are necessary but introduce new power dynamics.

Timeframes: Meaningful PD takes time — time for trust-building, multiple design iterations, and sustained community engagement. Development project timelines are often too short for genuine PD, leading to “consultation” processes that are labeled PD but do not meet the substantive participation standard.

Exit and sustainability: PD processes that end when the research grant ends leave communities with partial designs and no support for implementation. Planning for sustainability and transition from the start of a PD engagement is a genuine ethical obligation.

PD and Feminist ICT4D

A growing body of work within ICT4D applies explicitly feminist perspectives to PD practice. This scholarship draws attention to:

The gendered dimensions of which community members are recruited into PD processes
The ways design assumptions embed gender norms (e.g., assuming that the “farmer” who needs agricultural information is male)
The additional barriers women face in participating in design processes (time constraints, social norms, safety concerns around expressing views in mixed-gender settings)

Feminist PD approaches include running single-gender design sessions, working through women’s organizations and networks as recruitment channels, and explicitly analyzing design outputs for gendered assumptions.

Evaluating PD Outcomes

One of the ongoing challenges in PD research is defining and measuring success. Traditional technology evaluation focuses on system adoption and functional performance. PD research has developed additional evaluative dimensions:

Process quality: Did the process genuinely include diverse community voices? Were power differentials addressed?
Capability enhancement: Did participation in the design process itself build skills, confidence, or social capital for community members?
Fit between design and need: Does the resulting system address the needs that community members articulated?
Sustainability: Does the system persist and remain used after the initial design team’s involvement ends?

Frequently Asked Questions

Is participatory design the same as user testing? No. User testing involves showing a designed system to users to evaluate its usability — design decisions have already been made. PD involves users in making design decisions from the beginning, before core choices about what the system will do are finalized.

Can PD work in communities with limited ICT experience? Yes — PD is particularly appropriate in such contexts because it does not assume prior ICT familiarity. Paper prototyping, scenario exercises, and voice-based methods are specifically designed to be accessible to people without technology background.

Does PD always produce better outcomes than expert-led design? Not automatically. PD processes that are poorly facilitated, that include unrepresentative “community representatives,” or that are artificially compressed into short project timelines can produce worse outcomes than thoughtful expert design. The quality of the process matters enormously.

How do you handle disagreement within a community during PD? Disagreement is expected and valuable — it reveals that the “community” has diverse needs and priorities that cannot be resolved by a single design choice. PD facilitators should document these disagreements rather than forcing consensus, and use them to develop designs that accommodate multiple needs or to make trade-offs transparent.

What happens to PD outputs when the research project ends? This is one of the most persistent critiques of academic PD work in development contexts: research teams design with communities, then leave when the funding runs out. Best practices include involving local organizations (NGOs, government departments, local companies) who will maintain relationships with the community after the research project ends.

Development Informatics