Indigo Transport – Freight Requests

2021–2022 / Team: Myself, John Hunter, Misha Sidorsky, Denis Berekchiyan

In less than three months, we researched, brainstormed, iterated, validated, and shipped logistics software to help farmers and grain buyers send jobs to carriers. We also helped those carriers fill in gaps on their calendars and grow their networks for future jobs.




When I joined Indigo Ag in 2020, they were offering transportation and logistics software and services to help connect farmers, grain buyers, and processing mills all across America.

They had a web interface and two mobile apps that helped dispatchers and drivers manage jobs through the supply chain, as well as help shippers (customers looking to have grain moved) with their work.

Due to the COVID-19 pandemic, there had been a shift in demand for freight work. There were fewer drivers on the road, thus the cost of transporting grain from farms, to grain elevators, to processing plants, and their final destinations had significantly increased. Through discussions with our customer account managers, we learned that shippers were struggling to get reliable, steady drivers for repeat work and last-minute “spot jobs”.


Product leadership and the executive team had identified this as a major bet to boost adoption and growth of the Transport product.

I paired up with Denis (my product manager) to focus on the carrier (driver) side, while John (another designer on my team) worked with his PM, Misha. To ensure the four of us had clear objectives in mind, we drafted "how might we"s. We whittled those down to two that would help drive our work over the next quarter...

HMW help shippers fill logistical gaps and efficiently send freight service jobs to carriers? and HMW make it efficient for carriers to receive, review, and act on freight service jobs?

We brainstormed and designed high-level visions of how we could connect these two parties in our existing web apps. Then, John and I made a lightweight prototype to demo for our shipper customers.

It shows the shipper inputting job details (origin, destination, product, quantity, ideal “received by” date, and rate) that would generate a draft job request.

John and Misha setup sales and research calls with shippers to get intel on what their needs were and to solicit feedback on the prototype.

The shipper would send the request to carriers on our platform, from their own rolodex, or both. They could then track the status(es) of the job(s) they’d sent and could edit or revoke. Once a carrier (or carriers) had accepted the job, the shipper could manage it from our platform.


While they were researching with shippers, Denis and I ran some research sessions for carriers.

Because of time constraints, we only had access to one of our carriers. We used our internal carrier account managers as proxies, learning what they'd typically look for when seeking out and evaluating jobs. I had them stack-rank and prioritize the ~15 common job aspects (e.g. distance, hours of operation, rate).






We were able to validate what details were important when creating or reviewing a job (e.g. rate, date range, distance traveled). However, John had learned there were “custom” job details that varied from job-to-job, such as:

  1. • seasonality
  2. • facility details
  3. • hours of operation
  4. • phone numbers
  5. • directions
  6. • on-site manager name
Indigo Ag Shipper Delivery Notes

John and Misha decided that instead of adding in six or more additional form inputs (which required a database overhaul), that we'd add an open text input. This would allow the shipper to write in any additional notes. We had planned to scrape for common phrases and datapoints, and later revise the job request inputs.

With these insights and decisions being made on the shipper side, I iterated on ideas for how carriers would receive, review, compare, and respond to job requests. And how they would manage those if they accepted them.

Design explorations Design explorations

John and I collaborated the next few weeks on the happy and sad paths that our shippers and carriers would interact with.

We iterated with our PMs and engineers to come to a viable, lightweight solution. While we dreamt big, we had to compromise to hit our EOY 2021 target. We put together ~six directions (eventually just one) as to how both sides of these jobs would interact with each other.

We shared our prototypes in a few internal and external customer calls where we prompted our participants with the scenarios:

  1. 1. You’re a shipper who had one of their carriers drop out due to time conflicts. You need to find a new carrier or carriers on our platform. How would you do this?
  2. 2. You’re a carrier who has some upcoming capacity for more work. How would you find, receive, review, and respond to job requests?

During those research sessions, we determined that the custom job details and the ability to negotiate were critical for success.

For the MVP, shippers would send freight job requests to one or more carriers, who could claim them on a first-come-first-served basis, or they could order them based on their preferences. John and Misha bet that shippers who needed a last-minute job replacement would use the FCFS feature and send those to our network of carriers. But for jobs that were four or more weeks out, they’d send those requests based on existing relationships with their rolodex of carriers.

If the carrier was an existing partner on our platform, they would receive the request details via email and text message (~97% of our carriers were owner-operators who were always on the road, not in front of a computer). SMS could communicate details to them at a glance.

The carrier would be able to evaluate the job, accept it at the offered rate and offered quantity, or decline it. If they weren't already an Indigo Transport carrier, they'd receive an invitation from the shipper(s) that had sent them job request(s).

Because of scoping and resourcing in the last few months of the year, we decided to do a fast-follow of negotiation in the second release, even though it was a highly-requested feature. We assumed that if the carrier or shipper wanted to negotiate, they would do that via email, text, or phone.

We launched the MVP in early December 2021. A few shippers created and sent job requests, and many carriers had accepted. There was excitement from shippers, carriers, brokers, and the executive team.


For the second release in early January 2022, we launched a lightweight version of negotiations, where the carrier and shipper would only have one round of negotiating (mostly due to resource constraints).

However, our engagement rates were low; we assumed that it had to do with the launch of this new feature at the end of year (coinciding with the holidays). By mid January 2022, we only had a small, steady trickle of job requests come through.

I hypothesized as to why engagement was low:

  1. 1. The new request feature wasn’t discoverable.
  2. 2. No negotiation on-platform, so transactions were abandonded.
  3. 3. Traffic was low due to the holidays and snow blocking roads.
  4. 4. Little marketing spend or campaigns designed to drive traffic.


To help improve the feature (with limited insights), I led a design brainstorm with my PM and our engineers, specifically focused on negotiations (because it was a highly requested feature from our customers). During the brainstorm I honed in on a few HMWs...

HMW make negotiating frictionless? HMW help shippers understand and send fair market rates? HMW help carriers understand and send fair market counteroffers?
Image of ideas from brainstorm

  1. 1. Show carriers the current going rate averages for specific lanes or regions, so they can assess if the rate they’ve been given is fair.
  2. 2. Send monthly or weekly newsletters that highlight market trends.
  3. 3. Guide carriers to an ideal rate, and help them course-correct if an entered rate is overpriced (e.g. their counteroffer is 200% over the average), potentially saving them from unnecessary back and forth negotiation cycles.
  4. 4. Display cost of diesel/ethanol, weather conditions, road closures, routes, etc. to help them make an informed decision.
  5. 5. Let shippers send “requests for quotes” so the shipper doesn’t underestimate or overestimate and put the price decision in the carrier’s court.

Unfortunately, an executive-level decision was made and the Transport product was shelved indefinitely.


I was and am proud of the work we did, and wished we had been given a longer runway to see it through. My plan had been to conduct user interviews and usability studies with carriers and shippers. I intended to treat them more like partners than customers; collaborating and iterating the software together. I also wanted to do a deeper dive in our analytics; specifically conversion rates, transaction attributes, repeat customers, and usage metrics.

This was a learning experience for me. I’ve had projects or divisions shuttered at other companies, and recognize that it’s all part of running a business.

If I could go back in time and do anything differently, I would:

  1. 1. Push for more research time and budget upfront to make sure that this was the right problem to be solving.
  2. 2. Spend fewer cycles iterating on the design explorations, and thereby get it launched sooner. This may have allowed us to ship earlier than the last few weeks of December 2021.
  3. 3. Advocate for closer collaboration with our marketing team, to better understand how we planned to drive traffic and convert customers.










Stash Web Application
View next case study