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”.
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...
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.
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:
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.
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:
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.
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:
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...
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.
If I could go back in time and do anything differently, I would: