They had a web interface and two mobile apps that enabled dispatchers and drivers to manage jobs through the supply chain, as well as help shippers (customers looking to have grain moved) with their work.
Due to the pandemic, there was a shift in demand for freight work. There were fewer drivers on the road. The costs of transporting grain had significantly increased. Through discussions with our customer account managers, we learned that shippers were struggling to find reliable drivers.
Together with Denis (my product manager), we focused on the carrier (driver) side, while John (design peer) worked with his PM, Misha. To ensure the four of us had clear objectives, we drafted "how might we"s and settled on two that would help drive our work over the next quarter...
We brainstormed and produced low-fidelity designs of how we could connect carriers and shippers on our platform. Then, we made a prototype to demo for our shipper customers.
It showed them inputting job details (origin and destination, the product, the quantity, the ideal “received by” date, and the rate) that would generate a draft job request.
John and Misha drove sales and research calls with shippers to learn their needs and solicited feedback on the prototype.
The shipper would send the request to carriers on our platform, from their own rolodex, or both. They could track the status(es) of the job(s) they’d sent and could edit or revoke. Once a carrier had accepted the job, the shipper could manage it from our platform.
We focused on what carriers would typically look for when seeking out and evaluating jobs. I had them stack-rank the ~15 most common job aspects (e.g. distance, hours of operation, rate).
We shared our insights and collectively validated what details were important when creating a job (e.g. rate, date range, distance traveled). But we learned there were “custom” job details that varied from job-to-job, such as:
We decided to add one open text input, rather than adding six or more specific inputs (which required a database overhaul). 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.
John and I collaborated (and iterated with our PMs and engineering leads) to build the core userflows that shippers and carriers would interact with on our platform. While we dreamt big, it had to be scoped down to hit our EOY 2021 target.
We designed six different prototypes as to how both sides of these jobs would interact with each other.
We shared our prototypes in customer calls and prompted our participants with the scenarios:
In 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 4+ weeks out, they’d send those requests based on existing relationships.
If the carrier already used our platform, they would receive the request details via email and SMS (~97% of our carriers were owner-operators who were always on the road). SMS could communicate details to them at a glance.
The carrier could 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).
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).
But our engagement rates were low; we assumed it was because it launched at the end of year near 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:
To help improve the feature (with limited insights), I led a design brainstorm with my team, specifically focused on negotiations (because it was a highly requested feature from our customers). We focused on a few HMWs...
The leading ideas: