Our Journey To Build A Guide for Digital Humanitarians

Since starting Prosper over four months ago, we've had one incredible journey which has challenged our ability to focus and brought light to the stark reality of the refugee crisis. I have learned more than I ever imagined and thought it important to document my learning for anyone else who wants to use design and technology to help amidst a humanitarian crisis.

The purpose of this post is to provide a retrospective roadmap of the work that we did on our first project: I hope this post can be a resource to anyone who is interested in using the web to make the world a better place and might consider using distributed volunteers to do it...

Project Context

In October, I attended John Willshire's Popular Thing for Broken Thing workshop facilitated by Ben Sauer at Clearleft for the Clearleft Interns. In the middle of the workshop I was staring at two sticky notes in front of me. The note on the left was a 'popular thing': Slack, a team communication app with a great user experience. The note on the right was a 'broken thing': Immigration and the refugee crisis, a complex crisis affecting millions worldwide.

my popular thing for broken thing combo: slack and migration

As the workshop progressed, I pitched my two sticky notes as a startup concept to the rest of the workshop participants. By the end of the session, I had a really deep feeling in my chest that I had to do this—I had to see if 'it' could work.

I didn't have the clearest idea of what 'it' was, but in true Design Thinking fashion, I decided to think by building. I envisioned a global community of professionals working together to help refugees. I decided to build a landing page to test the concept.

The very first iteration looked like this:

Quickly I realized that I had I spent way too much time on this first iteration. I was focusing on things that really didn't matter and forgetting the big picture of the value proposition and target audience. I should've started by making a lean canvas of some kind instead of building a website, but I guess that is what experience is for—to teach you things you didn't know before...

I pitched the landing page to the team at Clearleft and asked for their feedback. I spoke to some people in a cafe and decided to pivot the concept to this:

Once I had receive the in-person feedback I was looking for, I decided to spread the word online. I sent out a few links and got a lot of humbling messages in response. Talented, skilled and experienced professionals from all over the world wanted to help.

Within a month of launching the landing page, the proposition had changed dozens of times and finally it felt like we were headed in the right direction.

Once we narrowed in on 'digital workers' as our target audience, we started gaining momentum and clarified our sense of identity and purpose. We suddenly had a team of 20 volunteers with a wide range of skills who were asking the same questions:

How can we help refugees prosper in Europe using design and technology?

With this question as our guide, we iterated again and this time had a proper brand and ethos behind what we were proposing:

Now that we knew who we were (a community of digital workers), what we wanted to do (help refugees prosper in Europe), we had to figure out the best way to do it.

We wanted to find a 'first project' to test the validity of our concept.

Project Process

I've broken down the process of our work into the major phases of the project:

  1. Research
  2. Design
  3. Data
  4. Development
  5. Iteration
  6. Marketing

1. Research

We decided to research the wide range of problems that could be solved by a distributed team of volunteers using human-centered design and open-source technology. We were pretty clear about our constraints:

  • We didn't have a lot of time or money
  • We needed to measure the impact of anything we built
  • We wanted to be able to produce something that could scale

As a team of volunteers all over the world we began our research with three major activities:

  • User interviews
  • Searching, reading, discussing
  • Crowdsourcing

User Interviews

We wanted to begin with the real human needs that made up this complex humanitarian crisis, so we decided to interview as many people as we could to get an understanding of the problems of the crisis that we could solve as a community. We spoke to project founders, NGO staff, volunteers, refugees and government officials.

We recorded our interviews and wrote reflections about what we experienced on our team's Slack channel. I started a Google Doc with a list of potential problems that could be solved. Other team members began to add to it as they discovered problems from their research.

Searching, Reading, Discussing

We used Google search and social networks to gather information about problems that people were experiencing on the ground across Europe. We wanted to understand what affected both refuge seekers and providers.

After reading an article we would post it into our #research channel on Slack and provide a few comments or reactions. Sometimes it would spark bigger discussions and other times it would simply add to our growing list of problems that were candidates for solving.


We reached out to the broader community of the crisis and asked for their feedback: What problems are you experiencing on the ground? Rather than put together a formal survey and review responses programatically, the crowdsourced problem lists served as fuel for our discussion and reflection. We began to see trends around certain topics and themes.

With a weekly meeting in place we discussed through these as a team and decided democratically on the first problem we should try and solve as a community.

2. Design

To collect our initial research findings into one place and to provide the team with a central point of information regarding the project, I wrote a detailed brief.


In the brief, we defined the problem that we wanted to solve as follows:

Initiatives addressing the refugee crisis are scattered all across the web. This makes it difficult for refugees, volunteers, and donors to find exactly what they are looking for and leads to duplication of efforts.


We defined our proposed solution as:

Create a free-open source platform that centralizes all of the initiatives of the refugee crisis in one place.


We defined our approach as:

Using human-centered design so the application meets real human needs.

With the limited resources available, we wanted to do as little design and development as possible with the maximum impact.


In our research we defined four target audiences for our application:

  • Refugees
  • Volunteers
  • Donors
  • Project Founders


We knew it would be difficult to perform proper user-centered design with a team of distributed volunteers, but we wanted to give it a try. We had some very skilled and experienced designers on board to help guide the design process, but we didn't have very much time.

Design takes a consistent level of understanding, commitment and contribution. With volunteers all over the world contributing an hour or two a week, it proved to be incredibly difficult to gain real insights and to articulate those insights in a way that could be absorbed by the community.

As a result, we ended up moving forward on a massive stack of assumptions with very little blueprint as to what we were building or who we were building it for.

Looking back, I would have tried to find a corporate sponsor (like Clearleft) to help us navigate through the Discovery and Design phase so that we had a clear blueprint and strong foundation for our community to build upon.

But as we all know, working in perfect conditions never happens so we kept moving forward and did the best with what had, but as a result—a large amount of the project knowledge rested in the minds of a few core contributors and the rest of the community participated on the fringe.


As an approach for the MVP, we decided that we would use Google Sheets as a database and would render the data into a user interface using front-end javascript. Bob Breznak, my former mentor at The Firehose Project, was the brains behind this concept.

This approach would allow us to leverage our community of volunteers to clean the data within the spreadsheet. If we moved the data into a proper relational database, it would set a much higher bar for people to access the data or would require development resources to build even the simplest CRUD interface.

In a quick 30-minute session, I threw up a landing page that expressed the concept of the application and asked users to submit their project to our database. We used Google Forms to gather the data into a spreadsheet.

refugee projects prototype

refugee projects form

refugee projects form data

With the approach for our MVP outlined, the next steps were all about gathering as much data as possible. As we began writing the form questions we realized the importance and complexity of data that we were facing.

3. Data

We wanted to reach a critical mass of project data that would provide value to our target users and would allow us to leverage user engagement and grow both the value we created as well as our user base.

Creating A Data Model

I worked with a couple of our developers who had strong experience in data management to develop a working data model:


We iterated upon the model a few times until we felt we had a good foundation to begin to publicize our landing page and ask people to submit their project data.

Gathering Data

Within a few days we had 30-some projects listed in our spreadsheet. Within a couple weeks we had discovered that many people across Europe were collecting lists of projects in order to make sense of the chaotic crisis.

Many of the people gathering lists had no design or development background and were motivated purely by the value that a list of projects gave them within their involvement in the crisis—usually as a volunteer or project founder of some kind.

Importing Data

We gathered a list of external sources of refugee project data and stuck them into our team's Google drive. One of our talented developers began building a tool that would allow us to import multiple external data sources into our spreadsheet.

Once the import tool was working, we mapped the external data sources to our Google Sheets database and ran the script. We received over 130 submissions to the Google Form via our landing page, but after running the first data import we had over 1000 projects.

It was exciting to see the script execute and watch as all the rows filled it with valuable data—knowing that each piece of data was one small component of a big complex puzzle that spanned from the Middle East to Scandanavia.

4. Development

With a working data model and a growing database, Bob had a couple hours to spare and decided to develop the prototype we had spoken about a while back. The result was a simple interface that allowed users to search through our database or browse projects by category.

The code behind the prototype is pretty straightforward. Bob used a few libraries to handle core functions of the application:

  • Tabletop.js - Takes a Google Sheet and makes it easily accessible to Javascript via JSON
  • Lunr.js - A small full-text search library for use in the browser. It indexes JSON documents and provides a simple search interface for retrieving documents that best match text queries.
  • Isotope - Filter and sort magical layouts

In just 204 lines of Javascript, Bob was able to link together the open source libraries above to accomplish the functional requirements of our prototype—including the measurement of search queries and user actions on a Mixpanel dashboard.

I went through his code line-by-line to fully understand how it works. It's amazing how much I've learned simply from working with people who are smarter and more experienced than me.

As soon as our database scaled, it created some bugs with the prototyped code that Bob had written. With a basic understanding of how it worked, I was able to fix them and push it back into production. While I definitely couldn't have written the code from scratch it was a pleasure to be able to make a contribution to the javascript side of the codebase where necessary!

5. Iteration

Once we had a wider range of data, it created new issues and challenges for the UI. Some projects only had a name. Some projects had both an organization name and a project name. Some had incredibly long descriptions and some had no content at all.

As a result of these issues, I spent some time re-thinking the way we displayed project information:

project card mind map

project card UI sketch 1

project card UI sketch 2

Once I was satisfied with a general approach for displaying project information on a card, I set out to implementing it for the live prototype:

Lale help project card

Back To The Canvas: Discerning The Way Forward

Upon launching the prototype we had a significant contraction in the energy and size of our active team. It seemed pretty clear that we needed to find another way forward to further the mission of

I spent a few days trying variations of the Lean Canvas to discern the best way forward, asking myself:

How might be financially sustained? lean canvas

In working over the canvas with a few designers at Clearleft, I realized I had a range of options regarding financial sustainability:

  • Crowdfund
  • Traditional Fundraise
  • Corporate sponsorship

But those elements were just the financial side of things, it didn't even touch the reality of how we would actually design and develop the MVP that we'd built. It became pretty clear that we had three main approaches for execution moving forward:

  • Hire a full-time product team (very expensive but effective and powerful)
  • Leverage volunteer efforts with a full-time project manager and volunteer coordinator
  • Leverage corporate sponsorships in the form of 'product sprints' to increment the project forward version-by-version

I quickly realized in performing these canvas activities that I'd completely run out of steam. I'd been working nights and weekends, thinking about this project every hour of the day. I had a huge sense of urgency to get something out there, but I neglected some crucial considerations along the way.

I should have considered these elements of financial sustainability and long-term growth and development from the very onset. I blindly started out with a concept a community of digital workers collaborating to help refugees prosper in Europe without an understanding of what we would actually be doing together and how it would actually work.

6. Marketing

Since launching the very first version of our prototype of, we've promoted our work through various channels in order to build the database, attract volunteers and test with new users.

promoting our project on facebook

Over the past couple weeks several bigger initiatives noticed what we were doing and got in touch.

A research team at the BBC contacted us about using the application to scope a project in the Balkans and to connect with local organizations who were working with refugees on the ground.

International movement Techfugees saw our app and suggested that we talk. We're in the middle of a conversation about merging our initiatives in order to further the mission of both of our organizations.

Reflection & Projection

We are committed to growing in a way that can make a significant difference in the lives of refuge seekers and providers across Europe. We took an infrastructure approach to a large problem and decided to create something that could potentially have a bigger more long-term impact than something that focused on immediate needs.

We wanted to do something that only design and technology could do—to serve the community of the crisis in a way that other people couldn't. Building the central database of refugee crisis initiatives was a really challenging and complex process. Our application is just a proof of concept, but in testing it with users and sharing it with the world it became clear that there is a genuine need for this type of tool in the crisis landscape.

A wide variety of actors (both refuge seekers and providers) benefit from making sense of who is doing what, where and from being able to communicate with the initiatives that meet their needs.

Whether our application becomes an indispensable tool for refugee crisis actors or not, we feel that we've accomplished something special and have learned a lot along the way.


We've been inspired by the likes of Info Compass who have taken this type of project data and made it useful to local communities of refugees in Berlin. They've created physical spaces where refugees can come to find answers to complex problems they're facing. They've got their application in nine languages and are constantly growing their local outreach. screenshot

Of all the projects I've seen, this unique combination of design, technology and real human relationship seems to be the most effective approach. For any designer or technologist considering how they can help in a humanitarian crisis, I urge them to start with real human relationships first and to use design and technology to leverage solutions that meet their needs.

A Big 'Thank You'

As a closing thought, I want to give a big thank you to everyone in the Prosper community who has contributed to—we couldn't have done it without you. It was an amazing spectacle to behold. Strangers from all over the world came together under a shared vision, formed a community and created a prototype for a problem that affects refuge seekers and providers across Europe.

Feedback Welcome

It's an honor to write this reflection and I hope that this post may provide value for people like us who have skills in design and technology and want to use it to help make the world a better place. Feel free to reach out to us on Twitter or Facebook with any feedback or questions.

John Ellison

Read more posts by this author.

Subscribe to Prosper's newsletter

Get our monthly newsletter delivered right to your inbox with updates on the latest within the community including ways to get involved.

or subscribe via RSS with Feedly!