Digital Product Design
A Case Study
As the founder of Prosper Community, I led a distributed team of over 100 volunteers to design and build an open source product that helps relief organizations make sense of "who is doing what—where" amidst the refugee crisis.
While the project wasn't a linear process, for the sake of presenting this case study in logical parts, I've broken down our product cycle into five main phases:
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
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.
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:
- 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.
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.
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.
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.
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.
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.
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:
- 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
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.
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:
Once I was satisfied with a general approach for displaying project information on a card, I set out to implementing it in code for the live prototype:
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 RefugeeProjects.com.
I spent a few days trying variations of the Lean Canvas to discern the best way forward, asking myself:
How might RefugeeProjects.com be financially sustained?
In working over the canvas with a few designers at Clearleft, I realized I had a range of options regarding financial sustainability:
- 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.
Beta App Redesign
Soon after we launched the prototype we had a massive influx of learning about the app we designed, the people we intended for it to serve and how it needed to function to meet their needs. Having accumulated a massive amount of project knowledge, I had a very clear vision for the product we needed to create to solve the problems we identified.
This time I took to Sketch and started creating higher fidelity versions of the app. By this time our project stakeholders had grown to include other organizations and so we had the benefit and challenge of a more diverse project team to move the application forward.
There are some screenshots of the redesign below. You can also download the redesign files and take a closer look at the design documentation if you'd like:View Design Docs
Mobile UI Flow
Tablet UI Flow
Desktop UI Flow
Reflection & Projection
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 support organization or not, I feel that we've accomplished something special and have learned a lot along the way.