CalcuCafé

Problem

For coffee farmers in developing nations, managing production costs (labor, equipment, etc.) is critical to becoming profitable and maintaining negotiating power with buyers. Despite this, most Latin American coffee farmers lack visibility into the economics of their operations until it's too late to make adjusments. Often, farmers need to wait until the end of an annual harvest before they know if they made any profit at all. This makes the farms economically fragile and ultimately puts the farmers' livelihoods at risk.

Overview

CalcuCafé empowers Peruvian coffee farmers by helping them make data-driven decisions based on the economics of their farms. Farmers simply input their costs into the app, and an advanced cost model outputs the optimal pricing data for their crop (i.e. coffee beans). This data is aggregated among all farmers within a cooperative, and farmers can even simulate how different cost structures affect their profitability.

My role

When I joined the CalcuCafé team, the product was just a prototype. The researchers leading the project wanted to progress to a production version of the tool, but they lacked the technical skills to translate their research into a live system. With my background in both UX and engineering, I applied our UX research to turn the CalcuCafé prototype into a production-grade system ready for use in the field.

Understanding the user

CalcuCafé is focused on helping coffee farmers throughout Latin America, which means there are a lot of unique cultural, geographic, and technical constraints to consider while developing the system. The UX researchers had already amassed a lot of deep insights into the needs of our users, so I set up a user persona to organize those learnings and help steer my design and engineering decisions later on in the process.

Creating a plan

Based on the team's research and my conversations with the project lead, I enumerated the high-level goals for the production version of CalcuCafé. I broke down those overarching goals into specific technical considerations, which I then assigned a priority rating from 1 to 3 (1 being highest priority; 3 being lowest) based on a combination of the importance and the time requirement of the given goal.

Priority Goal Tasks
1 Farmers should be able to record their data offline
  • Save user data locally in the client
  • Detect internet connectivity status
  • Migrate the cost model processing from server to client
  • Render charts natively rather than via third-party API
1 Farmers should be able to use the tool on a low-powered Android phone
  • Make UI responsive for small screens
  • Restyle and resize input touch targets
  • Restructure system into progressive web app
  • Limit size and quantity of assets
1 Farmers should be able to register without an email (farmers will have an internet connection when registration)
  • Remove reliance on MS authentication
  • Build authentication system for just a phone number
2 Content should be available in both English and Spanish
  • Dynamically display text based on lang attribute
  • Cache user's preferred language on client
3 Navigation should be clear
  • Increase visibility of action buttons
  • Add titles to each page
  • Signal the active page in the navbar
3 The tool should look nicer
  • Increase contrast between foreground and background
  • Increase visibility and constrast of action buttons
  • User accounts should only require a phone number

Navigation design

CalcuCafé's interface consists primarily of input fields and output charts. This keeps the UI straightforward, but it also means that different pages share a lot of the same elements. For example, a user could mistake the simulation to be the results page, leading them to misinterpret the graph they see or mistakenly believe they're recording their farm data when they've actually just simulating it. In order to combat ambiguity in navigation, I made the following usability changes.

  1. Page titles

    A large title at the top of each dashboard page avoids confusion between the visually similar (but behaviorly different) "input" and "simulation" pages by visually reinforcing which page a user is currently on. This is extra important in the mobile version of the UI, where a smaller above-the-fold space and limited navigation bar increases the risk of page confusion.

  2. Clarifying the "home" tab behavior

    The "home" tab actually leads to the results page, which was an unclear behavior in the prototype. Since the results page is most common page users visit, I hyperlinked the CalcuCafé logo to point to results page as well. This eliminates the need to open the drop-down menu when viewing on mobile.

  3. Providing a tab status

    I added a dimmed background and white border to signal which tab is currently on. This reinforces the page title information in reducing navigation confusion.

  4. Simplyfying the language toggle

    Users can already see whether the page was presented in their desired language, so I simplified the language toggle to only show the non-selected language. I added a flag icon to provide a visual draw to the option and to serve as an implicit separator from the navigation options to the left.

  1. Menu dropdown states

    The transition from a hamburger menu to an "X" communicates how to close the newly opened menu without taking up additional screen space.

  2. Dimmed body content

    Yet another device to help steer user attention toward the primary element at the right time. In this case, an open menu dims the body and prevents scrolling until a selection is made or the menu is closed.

Input fields

I made the input fields physically larger, magnified the associated icons, and encapsulated each input within a container to enforce visual distinction between sections and between inputs. This was a major improvement for mobile use, since the previous touch targets were too small to reliably select.

Responsive design

When redesigning the coding the front-end for CalcuCafé, I made sure that heirarchies, touch targets, and layouts were robust enough to accomodate the web app view as well as the mobile view.

System redesign

Since the flow of the system had to remain the same, I went through the prototype and noted the limitations in the existing architecture. Addressing many of our users' needs would require a drastic overhaul of CalcuCafé's back end.

Offline capability was the absolute must-have feature necessary for the production system, so I restructured the architecture to handle most data processing on the front end, rather than relying on third-party APIs.

By moving most functionality to the client rather than the server, CalcuCafé finally gained the ability to work completely offline. The initial onboarding to register users with the system still required an internet connection, but this was a workable limitation, since farmers are already in a WiFi enabled environment (i.e. a nearby city) when being onboarded by the CalcuCafé team for the first time.