< Return to AGDATA Portal Overview
- Part One: Rebate Estimator
- Part Two: Payments & Customer Insights
Part Two: Payments & Customer Insights
Problem Statement:
A high-profile client wanted a wholesale replacement of their 20-year old custom software – and AGDATA wanted to expand platform functionality.
Problem Context:
AGDATA’s “platform” had been steadily expanding and adding features, but it was almost entirely client-request driven; the organization’s product development strategy was heavily skewed towards client-funded work. As a result, the product had evolved into a hodgepodge of disconnected features.
Meanwhile, a key client’s outdated custom software was a bit of a hodgepodge itself: years of custom, one-off development had led to a mishmash of tools. The software was built primarily for their internal staff – mostly sales reps – who needed access to sales data. These users could find just about any sales data they needed to support their customers, but it was messy and convoluted. Data was organized into a half-dozen different reports – some displayed in the UI, others required downloading a spreadsheet. None of the data was unified.
Enter: Project Jigsaw. The client wanted a modern, efficient user experience, but they weren’t sure how to get there. They also wanted a replication of everything they had. Simply speaking, these two requests were incompatible: if we were to create a new, modern, efficient experience, we would necessarily have to evolve the way they interacted with their tools and reports. We had a massive puzzle to assemble.
The Process:
When the client approached us about updating their digital toolset, there were a lot of discussions around approach and implementation. Given some of the challenges with the existing AGDATA platform, I advocated for a fresh start: Build a new, simple platform that starts with the client’s required features and eventually rolls in the content from our other platform, while ensuring developmental best practices and a carefully executed design strategy. Once you’re up and running, you can onboard other clients. After several calls with users and some exploration of the tool, I started concepting.
My proposed designs and our existing platform had some significant overlap – both being oriented around customer accounts. This led the organizational leadership to opt for building on top of the existing platform with the hope that it would support faster, cheaper development.
Once that was determined, we set to work on understanding users’ needs, coloring in the full user journey and listening to feedback on how the current solution did / did not improve their work. The number of user calls, pages of notes and Miro boards we built out in our discovery process was easily greater than any project AGDATA has done before.
We ultimately broke the work into a few smaller chunks of work. To best walk through the whole design, I think it makes sense to organize this case study the same way:
- “Payments” – robust, on-the-fly access to payments data
- “Customer Insights” – bringing all the reporting into a single, 360-degree view of the customer
- “Reporting” – New homepage dashboards and high-level data reporting
Payments:
Ag retailers can range from small “mom and pop” type shops to mega-corporations with hundreds of locations and billions of dollars in annual revenue (Nutrien, LTD has over 1200 North America stores, and generated $29 Billion in revenue in 2023).
The smaller retailers often have small enough revenue, and consequently, small enough rebate payments, to not require significant management. But the big accounts often face critical bookkeeping questions: How much rebate did I earn? Which products earned it? Which locations earned it? Where’s the payment, now? Have I been paid for everything? As noted previously, these payments often comprise the entirety of a retailer’s profitability; they understandably care a great deal about these details.
In the past, the payment fulfillment process has not been tightly coupled with the Sales Rep experience. As a result, when their customers called with these questions, the Sales Rep would have to call AGDATA; research would have to be done to find the answers to these questions. Eventually teams started building Payment files – Excel files that would be shared to the Sales Rep.
The design process centered around the user’s desire to find these answers themselves. Because of the nature of the work, Sales Reps often don’t know which questions they’ll be asked – so the data needs to be flexible enough to find any answer, while being streamlined enough to bubble up answers to the most common questions.
In general, the most common questions tend to be centered around specific payments: “what contributed to this check?” Our client has historically worked from a robust, pivoted spreadsheet that would allow them to dig into these complex calculations.
Based on conversations with the client and user research, I wanted to shift away from the old method of downloading a spreadsheet and performing a pivot. Often, searching for specific answers in a spreadsheet with thousands of rows of transactions often felt like searching for a “needle in a haystack.” My goal was to eliminate the need to download the file and instead provide the data right in the interface; more importantly, I wanted to enable fast, effective searching. To follow the “needle in a haystack” analogy, I wanted to give users a magnet.
The biggest challenge is that the payments data is very robust: the Data Table in an payment Excel file could have 40+ columns and 6,000+ lines of data.
I wanted to improve the findability and digestibility of the data – to do so, we would need to reduce the amount of information we present, and to support search and filter capabilities. One of the ways we did this was by supporting grouping: users could choose some preset methods to view the data in aggregate, such as “Group by Product” or “Group by Location” – This allowed the interface to behave much like their familiar “Payment Pivots.” Further, we wanted to support drilling into those groupings to allow users to go deeper based on the questions they received.
Finally, we knew we’d be dealing with more potential columns of data than would ever fit on a screen – so we removed them from the default interface, but allowed users to add the extra columns as needed. We wanted to design for the lowest common factor.
The design concepts were sound – in theory, at least. The mockups looked good and we got a lot of positive feedback from users.
We had some developmental limitations that led to awkward interactions. As a result, we revisited the groupings and looked for ways to further simplify. This coincided with an intentional shift to our development teams working from a unified component library.
Implementation issues aside, the results were very encouraging. These designs helped users instantly feel they had improved access to critical data.
“The [Payments module] is awesome… this is what I have been needing to show my account what they earned, the program they earned it under, and the locations that earned it. Very good work.”
– client Key Account Manager
Customer Insights:
AGDATA has historically collected sales data for our clients, but generally that data was either provided back to the client via files, database syncs or reporting projects; it’s never been provided in a customer-centric view.
Outside of the agricultural context, that issue – not having a customer-centric view of sales and inventory data – might sound a bit bizarre. But for AGDATA’s clients, that’s the way they’ve always operated. Their common practice often required running reports, cross-referencing those with other reports, and cross-referencing those with still other reports.
As previously noted, very early in the discovery phase it became clear that users tend to hunt for data by Account. Meaning: if one of their customers has a question, they start scrolling through different reports to find data related to that customer’s account. And since we already had the concept of an “account view” in the platform, it became the obvious pivot point for almost all of our data.
Nearly every one of this client’s reports was unwieldy. These reports typically featured dozens of columns and thousands of rows of data. We wanted to modernize the way users interacted with this data – leaning first on primary tools like search and filter, with a view towards the future of AI-assisted search and data management. But to do that, we needed to bring all these reports into the UI.
The premise of rolling these reports into interactive tables was a daunting design challenge and a scary transition for users. While we wanted to make things easier and faster for them to manage, many of these users had decades of experience working with these reports; even if our new experience would be “better,” there was resistance to change.
My primary proposal centered around a dramatic simplification and customization of the tables. The core use cases for each of these reports required far less data than the 50+ columns suggested, and by reorienting the way the data was presented, we could eliminate or minimize the need for most of the columns. We trimmed 50+ columns down to the most critical 10, then allowed users to add columns of data to the table on-the-fly as the circumstances demanded. This would allow for users to more easily ingest the data they need most, while still finding the data they needed less frequently.
The concept and design is admittedly simple. There’s nothing real flashy and brilliant about the solution, and the presentation structure is a bit… boring. It’s tables of data.
But when you’ve had a lot of pain points around data access, boring is what you need. Straightforward table design with easy search, grouping, filtering and customization may not be flashy, but it’s effective.
These mockups are a sampling from comprehensive prototype built in Figma. Since we built within the context of our existing platform with a developmental intentionality on leveraging Design System components, we opted to forego the traditional wireframes and iterated directly in Figma.