Hack The Rainforest
A case study for UX in the Amazon
Hack the Rainforest was the brain child of the wonderful people over at Digital Democracy. It brought together indigenous activists, technologists and plain ol’ people who give a damn at the cloud forest of Tarapoto, Peru, to address environmental challenges in the Peruvian & Ecuadorian Amazon.
Across the Amazon, (and all over the world, really), deforestation, mining and oil drilling by multi-national corporations are destroying the forests and rivers that indigenous people depend upon for their survival. Indigenous people have little say over this invasion of their rainforest home, and they often lack access to the communication technology to share their story with the world.
This creates a situation where the companies mentioned above, and their interests, dominate the narrative of the story that’s been told to the general public and to the government.
Here was an opportunity for us at the tech community to take all the knowledge we had gathered, and put it into a truly noble cause — build a tool that will help indigenous communities document environmental and human rights abuses so that actions could be taken by the governments who had failed to recognize the severity of the situation.
“For the past two years, Digital Democracy has been collaborating with indigenous groups in rainforest regions in Peru, Ecuador and Guyana to build robust tools to allow them to document, manage & share information about ongoing environmental challenges, including oil contamination, land invasions, deforestation and more.
A key component of this work is mobile devices that monitors can take to the field to document what’s happening in their areas. We’ve leveraged existing open source tools, but consistently found something lacking. Our goal with the Peru Hackathon is to build cross-platform tools (mobile, tablet, offline-web) for gathering and managing monitoring data from the field, which includes water sample results, photos, quantitative and qualitative data, observations and interviews. The tools need to work in an entirely offline environment.”
“We’re not poor, we have everything we need”
For more information about the indigenous communities and their suffering, feel free to see this short video.
After diving into the problem for two days, attending lectures from both professors and the people that are in the field, we had decided to split up into 3 groups of 3 technologists each to attack the problem from a different angle.
Each group would take on a challenge:
1. There was only one challenge that was consistently brought up by every person we had interviewed, be it a monitor or a professor.
I could have given you a hundred attempts, and you still would have not guessed what it was. It was data sync.
The process of getting the reports from the mobile devices onto a computer had left too much room for human error. It was a source of major loss of the data collected by monitors, and even if not lost, many of the images taken could not be associated with the appropriate entry due to poor tagging.
This was a lot to do with the fact that most monitors, despite them being brilliant people with in depth knowledge of the forests, were not computer-literate, let alone smartphone ones.
Interesting as this challenge may be, it is not the focus of this case study.
2. The second team was assigned with the important task of sticking their fingers where it’s leaking right now. Having a long term view is important, but right now there are people out there, at the Amazon dealing with an app that was not meeting their needs. We needed to see how we can make their lives better today, not two months from now.
3. @antoniocuga (Front/Back end Dev), @becowilk (PM/Developer/UX) and myself (UX/UI and some front-end) were tasked with clearly defining the job at hand, and figuring out what would be the appropriate tool for it — or in other words, design the app. And that’s today’s topic.
Let’s get to work! Before we could get into designing and building the actual app, we needed to spend time framing the problem. This included:
Interviews were held relatively unofficially. Rather than going through a set list of questions, we would simply let the person talk.
Carefully listening to people (whether it be on a coffee break, or during the lectures that were given), and searching for where the energy was at helped us understand the context at which the app will be used and how it would potentially work — based on their perspective.
I personally feel the moment everything clicked for us was at a whiteboard session involving all the technical people from the group. We all brought everything that we had learned over the first two days and visualized it in the form of a timeline.
Based on this, we could set 2 main goals:
- Reduce the time between Event and Action.
- Maximize the Event/Action ratio.
Each one of these steps has the potential to improve these goals, but seeing as how little time we had, we decided to focus on Collection.
Framing the Story
We started out with a persona for a monitor, I am aware that there are some mixed feelings about personas around the web right now, but we needed to design for people that are so different from us, that we needed to put to paper everything we had learned.
I would also note that it was super helpful for us to use the JTBD vocabulary to frame the problem of collecting the data as a job that needed doing.
Once we had that, we could use the rest of the little time we had left to prototype.
We had spent so much of the time we had to do research, which left us with little time to actually build anything (Our first goal was to get an actual app up by the time the hackathon has ended) BUT, I think the alternative was to rush into a solution that would not necessarily serve the monitors as well.
Over the following couple of days, we would use Axure to build a clickable prototype, while constantly iterating, changing our minds, mostly based on information we would receive from our awesome potential users.
Keep in mind: This is an Axure prototype. It’s not meant to be “designed”, no baseline grid, typography or any sort of polish.
Be it a map view, or a chronological list view, the home page is meant to give the monitor easy access to information about past events from around that area.
Pressing the Blue plus button will prompt an overlaying menu from which you can either Plant a Flag or Record an Observation.
The difference between the two being that planting a flag is meant to surface new problems and add a point to the map which will aggregate all observations made around it. Alternatively, recording an observation will prompt you to take a picture of an incident, and enter a short description.
That’s where we’re at right now, our team has gathered on Slack to continue to develop the ideas, and further collaborate on building the actual app.
You can play around with the actual prototype here (Note that you will need to download the Chrome Axure extension).