CalcuCafé is a web and mobile tool that helps Peruvian farmers track their coffee production costs. Farmers enter data on their crop yield, transportation costs, etc., and the system figures out what price point will allow them to break even. I joined the Cornell UX research team leading the project in order to redesign the tool from a prototype into a production-ready system.
Since the UX researchers leading the CalcuCafé project are non-technical, they relied on a separate engineering team to develop the prototype for them. When it came time to evolve that prototype into a full-fledged system, the researchers had immense difficulty translating their UX findings into technical specifications the developers could work with. Neither team could understand each other's needs, so the project wasn't progressing.
The initial prototype
The UX team's overarching goal was to get CalcuCafé production-ready. They discovered a few key issues with the prototype while user testing in Peru, so the lead researcher and I came up with the following goals for the design of the new system.
Instead of the current API-based login (requiring email and password), users should be able to register and sign in with only their phone number.
Users should be able to use the system on the farm (i.e. without internet). Data should auto-sync when users visit a WiFi-enabled area.
Every part of the system should be capable of instantly switching between Spanish (for the coffee farmers) and English (for the researchers).
In addition to these goals, the core functionality of the existing system (i.e. calculating the optimal coffee prices based on farmer input) had to work correctly regardless of how the new system is implemented.
How can I best bridge the gap between what the UX team wants and what the prototype can do?
This project was super exciting because my role bridged the gap between the UX and engineering teams. My background in CS + UX proved to be a perfect fit, and I'll jump into how I cleared up a lot of the miscommunications between the teams.
The UX team had a ton of knowledge on the target users (Peruvian coffee farmers), so I had a few researchers walk me through their work in depth. I organized the information from those interviews into a user persona to help focus my design decisions.
Male / 45 years old / Coffee farmer
Passionate about coffee production (farm has been in his family for decades)
Open to data-driven decisions (eager to improve and increase quality of his coffee)
Stressed about losing crop yield to pests or disease
Favorably views collaboration and sharing information
Visits co-op in the city every few months to meet with technicians about management decisions (i.e. loans, renting vehicles, etc.)
Mingles and shares "personal" information (prices, farm info, etc.) with other coffee producers within the co-op
Writes down all of his costs in physical notebooks (co-op requirement)
Needs guidance on how to be more economically sustainable
Wants to understand the long-term economic viability of his production
Wants to learn how to increase profits
Needs to remain in good standing with the co-op (gives him access to large buyers at fair prices)
Very limited internet access (only when visiting the co-op and/or an urban center)
Infrequent trips to cities
Not very technically savvy
Limited economics knowledge
No laptop/desktop computer (has very low-power Android smartphone)
In order to design a better system, I first had to understand the current system. I sat down with the UX team to learn how the system should work in theory, and then met with the engineering team to see how the prototype works in practice. I used these interviews to create a model of the system and identify the fundamental design issues.
Since I came into this project after the research studies, testing, etc. had already been done, I had a lot of clarity on what my design had to accomplish. I simplified the system architecture so it would work in an offline environment and presented my plan to the lead researcher. Once she was on board with the direction I was headed in, I got started on implementing the new system.
After seeing the structural issues with the prototype, we all agreed that it made more sense to start CalcuCafé 2.0 from scratch rather than trying to modify the existing code.
I built the new system in Ruby on Rails, replacing the API functionality (authentication, chart rendering, etc.) with native code capable of working offline. Visually, I gave the tool a more professional feel by brightening up the color palette and replacing the bare data inputs with a uniform style. I also made sure the new web app, with a few minor tweaks, can be ported into an Android app that works even if users restart their phones.
Though the UX research team is non-technical, I kept them in the loop of my design decisions (and the impacts of those decisions) to avoid another communication disconnect between the UX and technical aspect of the system in the future. I found that by framing technical decisions in terms of their impact rather than their implementation, the team was engaged without feeling overwhelmed by technical details.
The project was a huge success! The UX team loves the new-and-improved CalcuCafé, and they are moving forward with the redesigned system for the next phase of their research. The team plans to eventually expand the reach of the system beyond Peru, helping farmers across Latin America better understand the economics of their industry.