The brief
We had a lot of data. Banks wanted a lot of data.
I started working on Sage in November 2021. The original brief was to build a report that could accommodate the agricultural data products that banks wanted.
SatSure had a growing set of agricultural intelligence derived from satellite imagery, remote sensing and related datasets. These included crop history, yield, irrigation, cropping intensity, land information, weather, regional parameters and agricultural performance.
The initial ambition was larger than a report. We had considered a system that could support the entire lending journey. As we worked with clients and ran proof of concepts across different stages of lending, we found that not every team wanted to use satellite intelligence at every stage.
Understanding the user
I interviewed approximately 7 to 10 Credit Managers and Relationship Managers. One key user was a Credit Manager from a bank's central team who also led a group of field users, giving me a view of both decision-making and operational realities.
The problem was not simply that information was unavailable. Relevant information was spread across different sources and processes. Gathering it, consolidating it and interpreting it could introduce delay and manual effort.
This shaped the design direction: bring relevant farm intelligence together without making the user understand the technical systems producing it.
The first product
The first version of Sage focused on one core job: help a user find the relevant farmland and request the right SatSource Report.
The dashboard handled search, filtering, map exploration and report generation. The deeper agricultural intelligence lived in the generated SatSource Report.
Design decision: make SatScore understandable
The most important design problem was the SatScore. The model produced an overall score on a 400 to 1000 scale. A credit manager could see a score, but the score alone did not explain why the farmer received it or which aspects of agricultural performance were affecting it.
Opening up the score
When I dug into the scoring model with the data science team, I found that the overall SatScore was composed of three major parts:
The Kharif and Rabi scores each contained additional parameters. Those parameter names and details are confidential, so this case study intentionally does not disclose them.
The design created a hierarchy of understanding. A user could start with the overall SatScore, then understand the contribution of the base and seasonal scores, and connect those signals with the farmer's agricultural history.
From an aggregate number to an agricultural story
A farmer could perform differently across seasons. An overall score could hide that difference.
The report therefore brought the score into context with farm details and historical crop performance. The SatSource Report shows farm details, irrigation condition, cropping intensity, farm location, cropping history and crop yield comparisons, alongside three years of agricultural history.
The design decision was not to simply expose more model output. It was to help the user understand which signals contributed to the decision and where attention was needed.
Design decision: not everything deserves equal weight
The data science team could provide historical values across multiple years for parameters such as irrigation and cropping frequency. But availability did not automatically mean that all of the information deserved equal visual weight.
For irrigation, a recent change in practice could be more relevant to a lending decision than an older state. For cropping frequency, the pattern across years could itself be useful evidence.
This meant deciding what to prioritise, what to compress and what to omit. The report was designed around decision relevance rather than the full list of parameters available from the system.
Design decision: design for the real workflow
Then a bank gave us a 2 MB problem.
Our initial detailed report was approximately 10 MB. One banking client had an internal file-size limit of 2 MB because their workflow required them to download the report from Sage and upload it into their own system.
The report worked technically, but it did not work operationally. I worked with the PM to rethink what information was essential for that workflow.
We created a Brief SatSource Report that retained the core information needed for the decision, including the farmer score, requested farmland and key agricultural history, while reducing the size of the report. The brief version was brought below the 2 MB limit, even when reports were requested for approximately 100 farms.
From one report to a modular product
The 2 MB constraint led to a broader question: if different financial institutions needed different information, did we really need one universal report?
We started looking at which versions clients actually used and asking why particular parameters were needed. When a client repeatedly requested a parameter, we could evaluate whether it belonged in the brief report or another curated version.
The underlying API was already structured as JSON. Over time, the front end also became more modular, so the experience could represent the relevant set of parameters rather than forcing every possible data point into every report.
Design decision: design for imperfect data
What happens when the data is missing?
A user could know a survey number but not find it in the system. Or the survey number could exist without a polygon or boundary, which meant a SatSource Report could not be processed.
Instead of leaving the user at a dead end, we introduced a way to raise missing data or a query. The experience could explain that availability depended on the underlying government data and capture what the user was looking for.
Designing around asynchronous data
Ownership information introduced another constraint. SatSource intelligence was farm-specific and could be generated separately, while ownership information depended on government websites or external vendors and could take longer to return.
Waiting for ownership information before generating the core report would slow down the part of the workflow that could already be completed quickly. At the same time, repeated client requests made it clear that ownership information was valuable.
In states where the response time was predictable, we supported a partial report first and allowed the report to be refreshed once ownership information became available. This allowed the product to work with the reality that not all data arrives at the same time.
My role
I started working on Sage in November 2021. At the time, I was the only Product Designer at SatSure, working with one PM across approximately five products.
For Sage, I was the primary owner of the design direction and initial product concept. I worked closely with the PM, data teams and development teams to shape what was built, how it was represented, how it behaved and how it would be validated with stakeholders.
The first version launched around May or June 2022, followed by a major iteration in July. I continued working on the product through the post-launch period and transitioned day-to-day design ownership towards the end of 2022.
As the design team grew, designers reporting to me took over the product. Over the years, at least three designers reporting to me have worked on Sage. When designers moved on, I stepped back in during transition periods to maintain continuity and guide the next designer.
I continue to lead the design team responsible for the product today.
Impact
The broader bank lending process moved from approximately 45 days to 10 days. Sage and SatSource contributed to that improvement by bringing relevant farm history and agricultural intelligence together so credit teams could access and interpret information much faster.
For the Sage workflow, a credit manager could access the relevant history and intelligence associated with a farmland in less than five minutes, rather than relying entirely on a slower, more fragmented information-gathering process.
Over the years, more than 15 financial institutions have adopted the Sage solution. The product has also been consumed through APIs, so dashboard usage does not represent the full number of people ultimately consuming the intelligence.
During the initial period when I was directly designing the product, one financial institution adopted the dashboard and report solution, three financial institutions tested it through POCs, and two financial institutions adopted the SatSource API.
I also led an integration with TransUnion CIBIL to explore embedding the intelligence into a broader financial information workflow. The partnership later ended due to business misalignment.
Product evolution
The product did not stop evolving when the first version shipped. Later designers added smaller interaction details, improved error and boundary-not-found states, introduced help and bug-reporting functionality, refined iconography and visual design, and contributed to later UI revamps while retaining the core product flow.
I continue to review and brainstorm around the product as part of the design leadership team.
What Sage changed for me
Sage was one of the first products where I realised that designing a data-heavy product is not primarily a visualisation problem. It is a translation problem.
The most important design decisions were often not about adding information. They were about deciding what deserved attention, explaining why a signal existed, accommodating incomplete data and adapting the product to the customer's actual workflow.
A score is not useful simply because a model can calculate it. A report is not useful if it cannot move through the customer's process. And a missing dataset should not leave a user without an explanation or next step.
I was not designing a dashboard. I was designing the layer between complex intelligence and human judgement.