Project by Projects

In the last reflection on tech-for-good and civic tech, we challenged by asking a simple but uncomfortable question: who do we serve?

Today, we take that a step further and talk about the how. Because if we are serious about building tech that closes gaps, not widens them, we have to get serious about how we understand the people we claim to be designing for. And that means moving beyond desk research and “good intentions,” into something more grounded: in-the-field design research.

The Problem with Designing from a Distance

Let’s be honest. A lot of tech-for-good work starts like this:

• Someone sees a statistic or reads a report.
• They identify a “pain point” in a slide deck and idealize it.
• They convene a team of smart people in a room (or on Zoom).
• They brainstorm features.
• They build.

On paper, it looks rigorous. There is data. There are reports. There are survey findings and user personas. There might even be a few interviews quoted in the appendix. But human life is not a PDF. It is a continuum.

The way people actually experience a problem is rarely as neat as the way it is described in a report. Two people with the “same” problem may live it in completely different ways:

• A woman in an informal settlement and a young man in a peri-urban town may both be “unemployed,” but the constraints, risks, aspirations and trade-offs they navigate are totally different.
• Two families living under the label “low income” may have very different social networks, coping strategies, and access to information — which changes what kind of tech is actually useful, and what feels like one more burden.

Innovators lose touch with reality precisely at the point where they stop going beyond what is easily accessible:

• secondary data,
• neat problem framings,
• and conversations with people who ‘look’, ‘think’, and ‘live’ a lot like them.
  

Desk research is important. Quantitative and qualitative studies are important. I am not arguing against them.

What I am saying is this:

If your final design is based only on what can be captured from a distance, you will almost certainly miss the real pain points.

Design Research: Not a Buzzword, but a Practice

When I say “design research,” I don’t mean another formal study with a 60-page report at the end. I mean a way of moving through the world as you design:

• getting into the field,
• meeting the people you’re building for,
• listening actively and deeply,
• and allowing what you hear to change the shape of what you thought you were making.

In short, design research gives you the grounding on which you can build from

Typically, this involves:

1. Starting with a hypothesis, not a conclusion
   You can (and should) start from existing data. You can draw from surveys, policy papers, evaluations, and lived experience. But you hold your framing loosely:
   “We think X might be a problem for Y group in Z context. Now let’s go and see how close or far off that is.”
2. Spending time in the actual context
   Not just in capital cities and co-working spaces, but in markets, waiting rooms, schools, farms, bus parks, community halls, compounds. The places where people are actually making their lives work.
3. Asking open, human questions
   Not just, “Would you use this app?” But:
   • “Tell me about the last time you tried to do [thing].”
   • “What was hardest? What took the longest? Who helped you?”
   • “What happens when things go wrong?”
   • “What have you already tried?”
4. Being comfortable with ambiguity :: You should understand that the answers you are going to get will be messy and far from making sense but therein lies the “goldmine” of your solution. 
5. Looking for patterns in the small, specific stories
   The “broad problem” (e.g. access to information, access to finance, lack of documentation, difficulty reaching services) might be lifted from existing data. But the leverage points often live in the small details:
   • The time of day people have access to phones.
   • Who they trust more: radio, religious leaders, a neighbour, a WhatsApp group.
   • The step in a process where people always get stuck or exploited.
6. Letting the field re-shape your solution
   This is the part many teams quietly resist.
   You go into the field and discover that:
   • The channel you chose (say, a smartphone app) is unrealistic.
   • The person you assumed would be the user is actually not the decision-maker.
   • The “feature” you were excited about solves a problem nobody prioritises.
7. Good design research will break your favourite ideas. That’s its job.
   

Why In-the-Field Matters (Especially for Under-Resourced Communities)

When you work with communities in under-resourced contexts, the margin of error is thin. If a solution doesn’t work for them:

• they don’t just “churn” like a paying customer with options,
• they absorb the cost in time, data, hope, and sometimes safety.

In-the-field design research helps avoid three traps I see often:

1. Designing for the “average user” who doesn’t exist
   The “average poor woman” or “average informal worker” is a fiction. Real people live at intersections — of gender, age, location, disability, class, ethnicity, language, belief. Fieldwork forces you to see who exactly is most affected, and how.
2. Mistaking visibility for impact
   A dashboard with thousands of data points looks impressive to funders. A shiny pilot looks great on a stage. But if the people you claim to serve can’t feel the difference in their daily lives, it’s not impact. It’s theatre.
3. Ignoring the emotional and relational dimensions of the problem
   A lot of tech-for-good focuses on transactions: get info, submit form, make payment, track status.
   But in the field, you discover that people’s decisions are also shaped by:
   • fear (of being cheated, shamed, arrested, or ignored),
   • pride and dignity,
   • obligations to family and community,
   • past experiences with authorities or systems.

Without understanding these dimensions, even the smartest tech will sit unused because the pain point becomes sanitised and stripped of the social, institutional, and power dynamics that shape it in real life.

So, How Do Tech Builders Actually Do This?

If you are a tech-for-good builder, here is a simple three-part pattern you can adopt and adapt:

1. Start with a grounded hypothesis, not a “big idea”

Instead of: “We want to build a platform to help farmers access finance using AI.”

Try: “Smallholder farmers in X region are losing income because of A, B, and C. Data suggests that documentation, trust barriers, and timing are key. Let’s speak with 20–30 farmers, traders, and local brokers to understand when and how these barriers show up, and what they already do to cope.”

You still draw from existing datasets and studies. But you treat them as a map, not the territory.

2. Commit to a minimum level of field immersion

Set a non-negotiable: before any major design decisions are final, your team will:

• Spend at least a few days in the communities you say you’re designing for.
• Speak with a diverse slice of people (age, gender, role, connectivity level).
• Bring at least one decision-maker (product lead, founder, senior engineer) into that fieldwork, not just junior staff.

The goal is not to “extract stories” for a report. The goal is to let those stories change your mind.

3. Build, test, and refine with real users in the loop

Rather than building a full solution and then “rolling it out,” you:

• Prototype small pieces (paper mock-ups, simple flows, WhatsApp-based experiments).
• Put them in front of people.
• Observe what they do, where they get stuck, what they ignore, what they light up at.
• Iterate.

It’s slower at the beginning. And then, if you do it right, it saves you months (or years) of building the wrong thing beautifully.

Who This Work is For (And Where we Come In)

This kind of work is what I love doing. I thrive in that space between the data and the real lives — where you take what the numbers and reports are saying, then walk into communities to ask:

• “Is this true for you?”
• “How does it actually show up in your week?”
• “What is the part that hurts the most?”
• “What already works that we should not break?”
  

For teams that are serious about designing tech that bridges real-world problems — not just looking good in a pitch deck — in-the-field design research is not a luxury. It is an investment in getting it right. And if you don’t have those skills or capacity in-house, you don’t have to invent it from scratch.

This is the kind of partnership my team and I at Project by Projects are built for:

• We bring strong design research chops into under-resourced, complex environments.
• We love ambiguity, it helps us cut through the clutter and  advise you better to achieve your set goals.
• We combine that with a strategic, systems-thinking lens, so the insights don’t just live in a research report — they shape strategy, product, service, funding, and partnerships.
• We help you see where your work intersects with others, and how to build intersectional, collaborative tech-for-good ecosystems instead of isolated tools.
  

An Invitation to the Builders

If you are building tech-for-good, civic tech, AI-driven tools, or digital services that aim to serve communities on the margins, here is my recommendation:

Don’t just ask, “What can we build?”
Ask first, “Who needs to be heard?” and “Where do we need to go to listen?”

And if you’re at the stage where you know something is missing between your vision and the reality on the ground — and you’re ready to bridge that gap thoughtfully — we would be very open to working with you.

You can reach out, bring us into your process, and let’s design with real people in mind.

Because at the end of the day, tech-for-good is only as “good” as it feels in the lives of those who use it — or are used by it.

Yop Rwang Pam & Maria Unawu