I recently attended a conference intended to generate new and interesting ideas to help solve one of the biggest humanitarian crises of our time: the refugees that are pouring out of Syria, Afghanistan and elsewhere. The event was attended by entrepreneurs, tech workers, designers, and some NGO workers. We were broken into groups and tasked with coming up with an idea for a single technology-enabled idea that could help refugees in a substantive way by the end of the day.
As we milled around, getting to know each other, I was struck by the number of people who were already working on their own apps. I saw some of them: a crowdsourcing app for volunteers, a translation app, an app mapping resources. All were wonderful ideas, and yet they shared some commonalities. All were being developed by one or two people. All were created as a response to the refugee crisis, yet conceived of and developed without partnerships on the ground or feedback from their end users (refugees and the volunteers who work with them). All were seeking funding. And most importantly, there are literally hundreds of apps which are seeking to solve the same problems through the same approach.
The tendency of technologists to view the refugee crisis through a techno-utopian lens is certainly understandable. If one could just get the right app into the hands of a refugee, the thinking goes, perhaps they could find a health clinic where they could get a checkup, a place to stay, or a lawyer to help them file an asylum petition.
The altruism and creativity behind these apps and the hackathons that tend to generate them is undeniable. What is concerning is the lack of coordination amongst technologists, the creation of apps without local context, and duplicative efforts which will likely result in the failure of potentially great ideas. As such, the refugee apps movement raises some important questions.
What responsibility, if any, do designers and developers have to collaborate with NGOs, volunteers, and refugees themselves on creating apps? If they have an idea for a tech solution that is already in the works, should they build on what already exists, or try to create something new and better? What responsibilities do they have to refugee, NGO, and volunteer communities to stick around through the deployment phase?
One need not look too far afield for lessons, and the area of mobile health (mHealth) serves as a useful example.
Map of mHealth pilots in Uganda by Sean Blaschke (Unicef Uganda, 2010), courtesy of TTCmobile.
The health field has over a decade of experience using mobile technologies to try to solve complex problems in low-resource settings. Providing access to quality health services has been a huge challenge in the developing world. Like refugees fleeing war with limited possessions, many people even in low-resource settings have access to mobile phones. Today, more people have access to mobile phones than clean water or to toilets. The widespread availability of mobile technologies is a fact that has been seized upon by NGOs and companies looking to improve the health of hard-to-reach populations. Among other things, cell phones have been used to provide accurate information to patients about conditions, remind them to take medications, connect them with clinics and transportation, take surveys, and train community health workers.
And yet, many NGOs and startups have found that developing the tech is the easy part. The devil, as always, is in the details: how to deploy these technologies, encourage the local population to adopt and use them, get them to scale, and (most importantly), ensure that they are improving lives. A 2013 study of 500 mHealth interventions found that very little was known about the effectiveness or adoption of these technologies and cautioned that the push for scale was premature.
So many mHealth pilots have been launched and then abandoned that this phenomenon has a name: pilotitis. In 2012, Uganda famously imposed a moratorium on mHealth projects flooding into the country, citing a lack of coordination and collaboration amongst developers that had left a veritable graveyard of apps that were never able to get off the ground.
So what works? Following are some suggested best practices gathered not only from the mHealth field, but from other socially-good focused technologists who design apps for communities.
SOLVE REAL PROBLEMS.
How do you know if your awesome idea for an app is solving a real problem? You need to learn what the problems are, and there are tons of ways to get that information. Connect with one of the dozens of organizations that are already working with refugees in the camps and across Europe. Who are they working with? What are their problems? What are their pain points? Can technology help?
FIND OUT IF SOMEONE IS ALREADY DOING IT.
Is someone already working on your idea? Chances are, the answer is yes. Duplication of apps and ideas is the biggest contributor to app failure. “But my app is going to be way better,” you think. Now’s the time to show some humility, roll up your sleeves, and ask how you can help the team that is already working on your great idea. Why? Because the apps-for-good space is dealing with extremely limited financial and human capital resources, and we need to conserve them. Because this is about helping people, not burnishing your LinkedIn profile. How do you know if your idea already exists? Check out RefugeeProjects.com, an online repository of all the efforts, tech and otherwise, that are underway to help alleviate the refugee crisis.
DESIGN WITH THE USER.
When designing technologies for underserved populations, it’s simply not enough to design for the user. You need to design with the user. What does that mean? If you have an idea for an app that could help connect volunteers, work with your users to design that solution. If your app is about helping refugees access resources, ditto. This approach, often called human-centered design, design thinking, or participatory design, starts from the assumption that solutions need to be created with the people they are designed to serve, not for them. How will you know if your cool looking icons are understandable in different contexts? How will you know what the most essential features are and the best way to design the navigation? Embedding yourself with the communities and people you intend to help is not simply good practice, it’s essential.
WORK WITH PARTNERS ON THE GROUND.
This isn’t a nice-to-have. It’s a must-have. How in the world do you plan on getting your cool job finding app into the hands of refugees in camps? You need partners, including NGOs and government entities who are working with these populations every single day. If you’ve done the work to Solve Real Problems, you will already have partners to work with. Which brings me to the next point…
BE IN IT FOR THE LONG HAUL, OR FIND SOMEONE WHO IS.
Those who have worked on mHealth projects know that if a pilot fails to take root, it’s because the deployment stage is so arduous. Chances are you won’t get the technology right the first time. Or the second time. Or the third time. You need multiple iterations. You need partners who get it. And you need to be committed to seeing this through.
PREPARE FOR UNSEXY LOGISTICS + SUSTAINABILITY.
Who is paying for this? And not just the development of the technology. Does it require a data plan? Special phones? Unique infrastructure? Access to wifi? Is it SMS-based? Who will pay for those fees, now and in the future? Your idea might look great on the whiteboard until you get pushback from users who don’t want to spend their precious data on your app.
REMEMBER, TECHNOLOGY IS NOT THE POINT.
The world, thankfully, is filled with idealistic and talented technologists with the time, resources, and expertise to meaningfully contribute to efforts that could improve the lives of refugees, not only in Europe, but around the world. But fundamentally, it’s important to remember that lasting change is not engendered through an app alone, and the refugee crisis is no different. Online payment systems or SMS text messaging tools are great, but will only improve the lives of people at the margins.
This last point is perhaps the most important one for technologists to keep in mind. Technology is not a standalone solution to solving complex problems such as asylum procedures, access to government services, assimilation, and questions about statehood and citizenship. For better or for worse, these issues are still fundamentally debated and hashed out solved at a policy level. In the end, the transformative change that refugees need must come through laws which will extend, or limit, rights to these newcomers. And sadly, there is no app for that