Empowering farmers with a national advisory platform
UX lead on AAMS, the platform connecting ICAR scientists, subject experts, and KVK field workers into one shared advisory chain, so agricultural research actually reaches the farmers it was written for.
Research that never left the lab
ICAR runs one of the largest agricultural research networks in the world: over 700 Krishi Vigyan Kendras (KVKs), spread across every state, institutes and universities producing research continuously.
The knowledge exists. Getting it out of inboxes and into fields, in the right language, at the right time, for the right crop: that was the actual problem.
Before AAMS, there was no system. Advisories moved through chains of people via email threads and printed documents. I spent time with a senior ICAR researcher who walked me through how things actually worked day to day. Five problems shaped everything that came after.
Research lived in inboxes and filing cabinets
Scientists wrote up findings and sent them by email or printed them out. No central place to store, search, or build on existing work. Every season, effort got duplicated from scratch.
Translations happened slowly, or not at all
India's farmers speak dozens of languages. Researchers largely write in English. Getting an advisory translated into Telugu or Marathi meant finding the right person, explaining the context, and waiting. A lot of advice never got translated at all.
Nobody knew if farmers were actually getting the advice
Once an advisory went out, it disappeared. No delivery logs, no read signals, no way to know if it reached anyone. Scientists were writing into a void.
Scientists had no idea if their research was being used
No feedback loop. Was the advice useful? Were farmers following it? Did it change anything? Years of research, with no way to prove its own impact.
Contradictory advisories were going out at the same time
With no central coordination, different institutes sometimes published conflicting guidance on the same crop or pest. A farmer getting two advisories telling them to do opposite things had no way to know which to trust.
2.1 The gap between ICAR research and the farmers it was written for.
ImageOne honest conversation was worth more than a survey
I did not have a research budget or a research team. What I had was a senior ICAR scientist who was willing to talk honestly about what was broken. That single conversation gave me more direction than any desk research would have. All five problems in the previous section came from it.
Three specific things shaped the design most directly.
The metadata problem
Scientists would write a perfectly good advisory and leave out half the information needed to make it useful: which region, which season, which growth stage. Not because they didn't know, just because there was nowhere obvious to put it. The result was advisories that couldn't be searched, filtered, or targeted. They just existed as documents.
This told me the creation flow had to capture metadata upfront, progressively, as part of writing, not as an afterthought at the end.
The credibility problem
Scientists cared a lot about attribution. If they wrote something, they wanted their name on it, their institute on it, and a clear trail showing it had been reviewed. Advisories in the old system circulated without clear authorship, and sometimes got modified in ways the original author never knew about.
Version control and audit trails weren't nice-to-haves. They were essential to getting scientists to trust the platform enough to use it.
The feedback vacuum
The researcher had been writing advisories for years with almost no idea whether any of them made a difference. He wasn't asking for detailed analytics, just some signal that the work was reaching people. That's what made the feedback and analytics features feel urgent rather than supplementary.
The metadata problem
Scientists would write a perfectly good advisory and leave out half the information needed to make it useful: which region, which season, which growth stage. Not because they didn't know, just because there was nowhere obvious to put it. The result was advisories that couldn't be searched, filtered, or targeted. They just existed as documents.
This told me the creation flow had to capture metadata upfront, progressively, as part of writing, not as an afterthought at the end.
The credibility problem
Scientists cared a lot about attribution. If they wrote something, they wanted their name on it, their institute on it, and a clear trail showing it had been reviewed. Advisories in the old system circulated without clear authorship, and sometimes got modified in ways the original author never knew about.
Version control and audit trails weren't nice-to-haves. They were essential to getting scientists to trust the platform enough to use it.
The feedback vacuum
The researcher had been writing advisories for years with almost no idea whether any of them made a difference. He wasn't asking for detailed analytics, just some signal that the work was reaching people. That's what made the feedback and analytics features feel urgent rather than supplementary.
Three tools that had to feel like one
AAMS wasn't one product for one user. It was three interconnected tools for three completely different people, whose work only made sense in relation to each other.
4.1 The three-persona cycle: creator, approver, customizer.
ImageA scientist's choices at creation time shaped what an approver saw, which shaped what a KVK expert could localise. If any link in that chain felt wrong, the whole system fell apart. That was the central design challenge. Not any individual feature. Coherence across three very different user contexts.
1. Guided creation, not a blank form
The biggest risk for the creator flow was that scientists would skip metadata fields and publish under-specified advisories that couldn't be found or targeted. A blank form wasn't going to fix this.
I designed the creation flow as a four-step wizard: domain first, then commodity, then the factual scaffold (region, season, period), then the advisory content itself. Each step unlocked the next. The structure made it hard to leave things out without noticing, and kept each screen clean since only the relevant fields were visible at that stage.
4.2.1 Choose domain.
ImageWhat each scientist gets: a four-step guided flow, drafts saved automatically, co-authors added before submission. My Content gives a single organised view of every advisory across five tabs, with voice search, filters, and batch actions.
4.2.5 My Content, with filters.
ImageAnalytics per advisory shows KVKs reached, farmer referrals, and satisfaction rate. A dashboard aggregates everything with date-range toggles and export options.
4.2.7 Analytics at content level.
Image2. Approval as a conversation, not a gate
Approval workflows in most platforms feel like a binary: approve or reject, with a text box for comments. That's not how subject experts actually think about feedback. They want to point at a specific claim, explain the issue, and see the creator respond in context.
I designed the review interface around remark slips. The approver clicks on any field and adds a note, which docks at the bottom of the page into a running slip. When sent, it flips the status and notifies the creator. The creator can reply inline before revising. Every exchange gets locked permanently once the advisory is published: an audit trail that serves both accountability and future training.
4.3.1 Approver's home: pending, in-progress, and closed queues.
Image
4.3.2 Approver consolidating and leaving remarks.
Image4.3.3 The remark slip, in action.
Loop
4.3.4 Remarks and reply thread: the full conversation view.
Image3. Localise without breaking the original
The customizer's job is to adapt an approved advisory for their specific geography. The risk was that heavy editing could corrupt the original research intent, or that different KVKs would diverge so much that conflicting advice went out again through a different route.
Every field in the customizer view is editable in place, with changes logged instantly in a changelog. Publishing a customised version creates a separate variant. It doesn't overwrite the original. Approvers can see all variants downstream. Version history lets a customizer restore any earlier state with one click.
4.4.1 Customizer view, editing in place.
ImageWhat each KVK expert gets: a personal home screen with total items customised, farmers reached, and average turnaround. Farmer feedback arrives in four views: content-wise, all feedback, flagged, and analysis.
4.4.4 Customizer's home.
Image4. Connecting everyone: the forum
A discussion board where all three user types can share data, request peer reviews, and coordinate joint advisories. Threads follow the same domain taxonomy as advisories, so conversations stay tied to the content they relate to. Institutional knowledge that used to live in email now lives in the platform.
4.5.1 Discussion forum: viewing threads.
ImageOne conversation, and its limits
My primary research source was a single ICAR scientist. Candid, experienced, and gave me more direction than a survey of fifty people might have.
But one perspective has real limits.
The development team came on board after the design phase was complete, which is how new government initiatives often get structured. The handoff was thorough, but a design relationship is harder to maintain when both sides don't exist at the same time.
The project ended at handoff, so I don't have data on adoption or outcomes.
That's an uncomfortable place to end a case study. It's also the honest one.
Live, only recently
Once the design handoff was complete, I moved to other projects and wasn't involved in the build. That's how the engagement was structured. What happened after was on the product team to execute.
From what I can tell, the core flows were built and the portal is now live. The team has been putting out tutorial videos on their YouTube channel covering how to use the platform as a content creator and approver, with the first ones going up about four months ago and the most recent posted just weeks ago.
That's a reasonable signal the platform is real, and being actively rolled out to scientists and experts.
Numbers on adoption and impact will have to wait. The rollout is recent enough that there's nothing meaningful to report yet. I'll update this when there is.
What I took away
Every decision made for the scientist had consequences for the approver, which had consequences for the customizer. Designing handoffs that felt seamless across all three is a different problem than designing a good screen.
Beyond the design challenge, the project gave me a genuine education in how agricultural advisory actually works in India: how KVKs function as the last mile between central research institutes and farmers, how advisories move through the system today on email and paper, and how fragile that chain is when there's no coordination layer.
Understanding that gave the design decisions real weight.
