If you’re reading this, you probably already know: technology built to help address social issues can be a powerful source for good. If you’re also working in the tech for good space, it’s an exciting position to be in to conceptualize and bring to life projects that are focused on solving some of the world’s biggest problems like poverty, inequity, global health, and access to critical services. This excitement and potential for impact is exactly why I fell in love with engineering many years ago, and it’s still what gets me out of bed every weekday morning.

As I’ve spent more time in the social impact space, it has become clear that in order to have a significant and long-lasting impact, the decision-making around tech projects aimed at solving the world’s biggest problems needs to be thoughtful, open-minded, and grounded in empathy. While this is true for the process of shaping any idea into a tech solution, it is especially true for the process of building technology for good. 

‍

How to Understand the Problem, People, and Ecosystem of Tech for Good Projects

One issue often present in tech for good failures is not approaching the problem from a user-centered perspective. It’s common for these kinds of projects to not be built by people who match the personas of end-users. It can be easy to unwittingly make incorrect assumptions about (1) the problem you are trying to solve, (2) the people you are trying to solve it for, and (3) what part your tool will play in the ecosystem. The consequence of these assumptions can result in building something which does not work for anyone. 

The Problem

Those who fail to understand the problem often over-engineer. For example, maybe you want to craft something which helps drought-impacted farmers improve food production. You could build a platform that predicts which plots in an area will be less impacted by drought in a given year. The technology possibilities are interesting, with potential uses for machine learning, satellite imagery syncing, and image analysis. 

However, this information in the hands of farmers is less helpful than at first glance. Most farmers are not equipped to entirely relocate their plot every season. While this drought geography insight could be valuable at a high level, it is not particularly rational in the short term. All too often, a beautifully built, robust, and highly technical application is delivered to intended end-users, and it gets almost no use because it isn’t solving a real problem for those users. Often, much simpler solutions can actually see much higher benefits. Providing a crop rotation plan based on an individual farm’s characteristics, for example, is a relatively low-tech solution but one that helps improve an everyday problem.

The People

Not understanding the people you are building your application for can result in low application adoption in similar ways to not understanding your problem. This could look like assuming an issue with your application’s adoption is in its engineering element when it is actually in the human element. Let’s say you build a new micropayment mobile application in an area where there was a previous catastrophic failure of a similar application. In fact, maybe you’re building it because of the previous failure. When faced with extremely low site traffic, many will consider this a technical failure, theorizing that it is too slow, or it needs shinier features, or it missed the mark on addressing the real problem.

But what if the real issue was failing to really get to know your users? If the previous application resulted in an impactful failure, it also likely has created a culture of mistrust around these kinds of applications' reliability and security. The right problem is being solved, but a failure to meet the users where they are at results in an application that is not used. User research early in the development process can help to discover sentiments like these that should influence the application’s design.

The Ecosystem

Finally, misunderstanding your user’s ecosystem is another pitfall that can result in low adoption. Let’s say you build a mobile application to help emerging healthcare facilities in developing countries track and improve upon their care standards. If you don’t account for the fact that there could be inconsistent access to cell service, it doesn’t matter how well you have solved a real problem in a way real people desire — it can’t be utilized effectively without engineering it within the ecosystem.

Resources to Move Forward

Most applications of tech for good require significant interactions with humans using that tech every day in order to solve the intended problem in a way that works for everyone. For our projects at Exygy, we do this by involving users early and often while we develop a product:

1. Sometimes this looks like taking a step back to engage in service design, a problem-solving approach that takes a holistic view to “connect the dots” of organizations, services, and clients.

2. We regularly utilize journey mapping, a design tool used to better understand the overall process the user is experiencing while using a product.

3. Other times, we set up user tests to understand accessibility barriers for an existing website or app.

‍

Through all of these approaches, the heart of our work — what I experience to be most rewarding and most challenging — is creating a technology that is worthy of its users.