CalcuCafé Redesigning farmer analytics Nugget
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.

Problem

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.

Banner old model

The initial prototype

Goals

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.

1. Phone number login

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.

2. Offline functionality

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.

3. English/Spanish Support

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?

User research

This a production-grade redesign, so I wanted to understand the problems, limitations, etc. as much as possible. Luckily, the UX team had collected a ton of research on the target users (Peruvian coffee farmers), so I interviewed some of the researchers and used that information to create a user persona to steer my design choices.

Alejandro

Alejandro Alvarez

Male / 45 years old / Coffee farmer

Attitudes:

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

Behaviors:

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:

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)

Limitations:

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)

System design roadblocks

CalcuCafé core issues all stem from the lack of domain crossover between the developers and the UX researchers. I interviewed the UX team to learn how the system should work in theory, and then walked through the back-end 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.

Roadblocks

3. Design

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.

Architecture

4. Trade-offs

There

Implementation

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.

Improved system

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.

Impact

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.

← Previous project Luck Studio
Next project → Prestofolio