Finding a better way to build digital solutions for NGOs

This comic above depicts how we can think about building digital products in iteration and can be rewarded with continuous feedback from users.

The first row, “Not like this” shows us that instead of attempting to build something 100% perfect right away like a perfect wheel or axle of a car, our resources should focus on developing something that is fully functional at every stage such as a skateboard or bicycle (shown in the second row, “Like this”). By doing so, we can build something that users can immediately use at every stage and enable more informative user feedback to help us develop toward a car in the future.

What does this mean in practice? In fact, it means breaking from a typical way of working in the NGO sector and applying a totally different logic to the assessment of success. Development projects tend to be, with good reason, pre-conceptualized, highly-designed, and rigid in implementation from launch to conclusion. Learning is a process that happens at the end, if at all, and is incorporated only in future efforts rather than progressively along the way.

The successful implementation of a digital product turns this paradigm completely on its head: we start with a skateboard, use it, collect data, and then make improvements. The key is that what we develop must be functional at every step of the way. Even as we encourage users to test our hypothesis, the key is that they must derive some functionality from each stage of the development as we work continuously towards the end goal. We might know that what we want is a car, but if we refuse to develop anything in the interim our users will be without a workable solution and the final product may respond incompletely, or not at all, to the actual needs. Taking the top row as a metaphor, we might only focus on building a wheel at first - but you can’t go anywhere with just a wheel. Even when you have your axles in place, you still can’t drive the car.

If you want to be able to move from point a to point b at every stage, you might have to accept a high-level prototype with light features: maybe just a login, data input field, and a place to see the results. That’s the skateboard: it doesn’t go fast and it probably isn’t the safest, but it will get you there. Once you’ve learned from your skateboard, you might decide to build a scooter: it’s a little bit faster, a little bit safer, but still not functional in all situations: what if it rains? Still, slowly but surely you are able to build a car, and then maybe even a faster car or an all out electric car.

Working iteratively gives us more insight into users’ desired features (see our article on designing M&E systems) than what they may be able to think of initially. Indeed, it can even be better to come to the table with only a few core needs in mind that are vital to work on as a first priority. Getting the minimum viable product (MVP) out and having the users test it out can lead to different questions or desires than would have been conceived of if they had simply been looking at a blank slate. Indeed, working this way increases user interaction and engagement with the digital product in question and thus allows us to build something far more valuable.

A great example of this is a project we did with a leading global NGO: at the outset, we were asked to build a specific form for a single project in the country where they operated. Rather than focusing on executing this vision right away, we asked our point of contact to speak to their teams. It quickly became clear that there would actually be great value in leveraging standardized forms for a range of work that would allow the product we built to meet the needs of all their projects and scale to the country level. Indeed, it could even be adopted by other partners and peers in the same sector (for more on the related concept of building for scale, see our article on digital principles that guide our work here). Asking these questions unlocked a deeper insight into user needs and habits and saved the NGO significant work down the line when they would have had to completely overhaul the overspecified form they’d originally thought they wanted to meet the needs of users at the country level.

There are numerous examples of how thinking small, acting quickly, and gathering real-world feedback can save time, effort, and money while leading to better end results. Working iteratively ensures that your staff receives products adapted to their needs and their constraints. For further information on how our approach to iteration and feedback is translated into a concrete strategy, read more about agile practices for project management.

At Hikaya, we help NGOs and nonprofits worldwide improve their delivery of goods and services to those most in need while making reporting to donors more transparent.

To learn more about our approach, visit our process page or see some of our past work.