Dispatch Details — Screen that mattered

Summary:

The case study explains problems users faced with the dispatch details screen in an app. Many found the screen confusing and relied heavily on Activation Coordinators (ACs) for help, similar to how individuals depend on accountants for tax filing.

During busy harvest seasons, users sent multiple trucks carrying large amounts of corn, involving big payments. However, they often didn’t understand their earnings, dispatch statuses, or how profitable their deals were.

The dispatch details screen was the only place where users could check their financial outcomes, commissions, and shipment updates. But its complexity left them confused, causing them to depend on ground staff instead of using the app. Issues like rejected shipments, rerouted deliveries, and multiple sales per truck required manual fixes, wasting time and creating errors. In certain regions, a dedicated person was needed to manage these concerns daily, indicating inefficiencies and potential errors that slowed down procurement goals.

The objective was to enhance the dispatch details screen to provide clearer information, reduce reliance on manual interventions, and improve overall user trust and efficiency in the dispatch process.

Context:

Much like the confusion and intimidation of filing taxes, this screen created a similar experience for our users. They often relied heavily on their Activation Coordinators (ACs), much like we depend on accountants. However, unlike taxes, this was an every-other-day affair. During peak harvest season, users typically sent 2-3 trucks per week—transporting 30-32 metric tons of corn and handling millions of IDR. The problem was that users didn’t fully understand how they were earning money, what happened to their trucks, or whether their deals were profitable or causing losses.

This screen was the only part of the app where users could see whether they made or lost money, how much commission they earned, and what happened to their corn after it left their doorstep. There was a lot of complexity to untangle and resolve.

Post the buyer selection model (DPM and FSM) went live in all the regions, we had a singular model support i.e. a region is either on Delivered Price Model (DPM) or Feedmill Selection Model (FSM).

In reality, both these models are essentially enabling a SJ to select a buyer before sending their truck, with the only difference being the rules around volumes that can be sent to a buyer and the price that buyer will pay for the sale.

• In DPM, Jiva and the buyer are on a contract that enables them to fix a price for the corn procurement for a fixed volume. This requires the daily volumes and price information to be managed via quotas.
• In FSM, there are no restrictions on volume that Jiva can sell to a buyer. It is purely dependent on the demand and supply at the spot a.k.a the market (at buyer level) and prices fluctuate accordingly.

The team:

The Problem:

• Currently, with the buyer selection model (DPM and FSM) being live in all the regions, managing rejections/ redirections of dispatched trucks had become a major pain point for managing dispatches with multiple sales/ GRNs.
• The communication around these manual adjustments to the final payout is also a point of dissonance amongst the SJs. We were not transparent around the reason and method for calculating the final payment amount for multiple sale scenarios. The user had no clue why the corn was rejected, making it difficult to trust Jiva as a service.

A considerable amount of time is spent addressing these concerns. In South Sulawesi, there is a dedicated person for addressing multiple GRNs related concerns throughout the day. The frequency of these concerns vary according to seasonality. Addressing every issue takes around 10-15 mins/ concern of the their time. There are other stakeholders that help the SJs raise these concerns who invest their time in facilitating these communications. MC -> AC -> PA. We safely concluded that a significant amount of time was spent to address them.

Overall, this meant our users were more reliant of the folks on ground than the app. The app which was supposed to help them understand crucial information. We also saw exchange of information happening over WhatsApp as the app failed to convey them the information.

What did success look liked?

For internals teams:

• Reduce and eventually eliminate the need of manual intervention done by our internal teams. This should reduce the time spent of calculating and explaining calculations to our users.
• Decrease the dependencies on Gsheets to calculate adjustments: Currently, the Data team uses Google sheet to calculate the adjustments related to multiple GRNs. Very hacky!
• Decrease in settlement time of a dispatch: Currently, due to manual adjustments in multiple GRNs settlement time per dispatch is higher because of manual calculations involved. This also impact that cash rotation time, which is the most important metric for Jiva.

For our SJs:

• Show them what was happening to their trucks. Minimise the need for them to rely on their ACs or get information through WhatsApp. Lessen the headache. While this was not something we could measure, every interview we did with our users said how difficult the post dispatch phase was for them.

Once we understood the problem and clarified expectations, the process became straightforward. Pam and I began working on wireframes. My role was to support Pam and Fathia throughout the project, ensure we adhered to our timelines, and consistently communicate updates to the larger team.

With Pam: A key focus of this project was emphasizing the importance of wireframing. While it’s tempting and exciting to dive straight into Figma and start creating pixel-perfect designs, I realised this often leads us to focus on less critical aspects early on. This can be overwhelming and makes it harder to prioritise what truly matters at the moment.

With Fathia: We worked together to identify what we wanted to learn from users, define the timeline, and decide which users we needed to speak to and why. I also helped her anticipate questions users might ask, ensuring we were prepared for discussions. Since Design Research was a shared resource, we took extra time to bring her up to speed, and she excelled in her role. One of my goals was to empower her to present the learnings to the larger team, which she did exceptionally well.

Some behind the scenes…

What went out in the world & why?

How the screen looked in 2021 vs. how it looks today?

Outcomes of the project:

• Time Efficiency: The time spent by internal teams and developers was significantly reduced. Introducing tools to input data into our systems eliminated reliance on Google Sheets. While this metric is challenging to quantify, feedback from internal users confirmed that this addition made a noticeable difference.
• Transparency: Users now have complete visibility into their truck’s status, along with clear feedback on any actions taken. If a truck was redirected or rejected, the reasons are explicitly provided, ensuring better communication and trust.
• Design System Transition: [Tiny but relevant] We transitioned from our old design system to a new one. This project served as a good opportunity to adopt and practice using our design system, Akar.

What I learned while leading this project?

Take the win: It might not look exactly as you envisioned, it might come at an unexpected time, and it might not come from the people you anticipated. But a win is a win—big or small. Embrace it!

Be less descriptive: I used to think I needed to be extremely detailed, explaining everything from A to Z. While there’s some truth to that, it’s not entirely accurate. When you spell out every step, people miss the chance to develop critical thinking or learn to overcome challenges on their own. It’s like giving someone turn-by-turn directions instead of teaching them how to read a map.

What my teammates had to say?

“In the research projects we collaborated, you always made sure you provided me with enough context so that I understand why we should conduct the research, what scopes to be covered, and what goals we would like to achieve. You're also clear in concluding meetings with action items and expected timelines (by when we should finish each task). Not to mention how you actively include and convince the product team of our users' voice to influence their decision making process. Keep doing this! :)”

Fathia Ramadina

“Firstly, it's your collaborative approach— it honestly shines through in every project/problem statement we work on together. Secondly, your sincere efforts at knowing more about the SJs. The DD project serves as an excellent example of a collaborative process. It honestly doesn't matter where the project is at right now. Your collaborative approach was exceptional. Lastly, from all the conversations we've had it's evident that you think a lot about MC's preferences and needs over other stakeholders— it's really motivating and empowering.”

Atisha Kudesia

“Taking notes and share it, this really help me, especially because I easy to forget something :D, also this is make me start take a note in a discussion. And your confidence, damn girl, I feel your confidence is the thing that makes me feel safe in offtake design haha. Well, sometimes there is too much doubt about the design, but you just being okay about your doubt and communicate it as well.”

Prasetyo Pambudi