Fixing the Information Architecture of the Sahabat Jiva app

When I joined Jiva in 2022, we had been leveraging collectors in rural areas to facilitate our business model.

The harvest of a smallholder corn farmer is typically around 2.5k-3k tons. The economics of sending it to the buyer isn’t economically viable for such a small quantity when you factor in labour cost & transport cost. Additionally the ability to evaluate quality at the farmer level is approximate.

Collectors helped fill this gap by aggregating corn for dispatch from multiple farmers and using moisture meters to estimate quality of the corn.

Jiva’s business model was working with buyers to acquire purchase orders for the corn and coordinate with the collectors to dispatch to feedmills to get the best price.

This wasn’t a disruptionary model. The concept of middlemen have always existed in agricultural systems. Jiva and it’s Collectors operated at a country level scale that hadn’t been tried before. The Sahabat Jiva android app was used by our Collectors to manage their Harvest Procurement, their Input sales (In the Agriculture business; Seeds, Chemicals, Fertilizers, Equipments are collectively termed as Inputs) and view their Earnings.

Challenge

Jiva had started off in the pandemic and we hadnt got a chance to observe our users on the ground. Moving to mobile apps had led to most of our transactions now flowing through a digital channel. However our qualitative research, quickly showed us that our users really struggled with our app.

These could be narrowed down to

1. The app’s localization was a mess since there had not been a dedicated UX Writer who was involved in the app in the past which led to wrong translations, english terms in various pages and alien terminology being used.
2. Every new user had to sit through multiple training sessions to learn how to use the various features on the app and there was no guarantee that they remembered how to use it.
3. There were many disconnected user flows which needed to be followed in a particular sequence.
4. The Collector’s privileges on the application were managed by the province’s branch manager and finance team due to the financial risk. This led to a non-uniform user experience and rogue user behaviour.

Business-wise, this was leading to:

1. High investment into canvassing, recruiting, training and onboarding
2. Churn increasing Season-on-Season

What this really meant was that the Android app was not the primary channel used by the Collector but more of a digitization system while most of the actual activity happened on Whatsapp.

There were even cases where our field agents (Activation Co-ordinators, Finance Co-ordinators) may actually be the operators of the application as it had been mandated to digitize every transaction that flows through the system.

This was not a scalable business model as it was dependant on having more feet on ground to increase transactions. Our data had been lying all this while about product adoption and usage.

Solution

Can you really solve a problem this systemic and prevalent at so many different levels?

For sure! but could we do it at one go? No way.

I advocated to break these problems into multiple phases. The goal here was to ship small and impactful to show value in the larger project to the stakeholders. Given the state the app was in, any change we brought in was definitely a net positive to our users.

In this case study, I will talk about the first phase; the Information Architecture overhaul.

Before we began redesigning, we needed to deeply understand our users’ mental models — how they think about tasks, organize information, and navigate the app.

To do this, we took a mixed-method research approach, combining qualitative and quantitative inputs from multiple sources:

Card Sorting with Users: On the ground, we spoke to users and conducted card sorting exercises to learn how users perceived and grouped key features. This gave us foundational insights into user mental models and navigation logic.

Usage Data and CX Reports: We analyzed historical usage data from CleverTap, Mixpanel, and UXCam, alongside customer experience reports, to surface patterns, popular flows, and pain points. One of our takeaways was that over the years, the quality of in-app tracking had degraded and the data we had couldn’t be relied on.

Competitive Research: We reviewed similar apps to understand how they structured information and workflows. This helped us identify best practices we could adapt to Jiva’s context.

Stakeholder Interviews and Workshops: As we knew that our data was in-accurate and prone to telling the wrong story, we had to rely on doing some qualitative research. We held workshops with branch managers, trainers, and on-ground teams. Their first-hand experience highlighted key gaps and opportunities that might not surface through analytics alone.

I’ve done these kind of projects many times over the years and it’s fairly easy to know how to execute each of the steps above, but the challenge really is in bringing all this together in a coherent way.

The data from all these sources can be overwhelming to deal with and the team often got stuck on how to go ahead. I had to step in to give direction on what we need to do next and keep moving forward.

Impact

Conclusion