Fleet Optimizer — Nayara Marques
Loadsmart · Chicago · 2021—2023

Capacity matching for private truck fleets

Fleet Optimizer connects private fleet capacity to shipper demand. A design sprint produced a web platform; a comparison test said the plain email it replaced was the better bet. We shipped the email.

Role

Senior Product Designer. Sole designer; I ran the research and facilitated the design sprint.

Team

Me, 2 PMs, plus product, business and tech across four countries. Sponsored by The Home Depot.

Context

A new business vertical at a logistics unicorn, still experimental and leaning on market research.

Contribution

qual + quant research · sprint facilitation · concept design · comparison testing · product strategy

View Matches — the platform the sprint produced, and the research shelved.

01 — Context & my role

Loadsmart automates how freight is priced, booked and shipped. Fleet Optimizer was a new vertical aimed at private and dedicated fleets: companies that own their trucks, or run dedicated service for a single shipper.

The product team already had a solution concept. What it didn't have was evidence that the concept met a real demand. My job was to find the similarities across fleet types and bring the findings to the table with the PM and VP of Product — including when they pointed away from the plan.

02 — The problem

Empty return trips are expensive, and nobody was being paid to care.

Six 30-minute semi-structured interviews with fleet managers of dedicated fleets, conducted over Google Meet. Four findings mattered:

6 of 6

Fleet managers spend most of their time analysing data — largely in spreadsheets — trying to optimise the fleet and hit their metrics.

6 of 6

Dedicated fleets are paid for the round trip. Around 70% of return freight moves empty, and the customer has already agreed to pay for it.

5 of 6

Service on dedicated loads outranks third-party freight every time. A backhaul that risks the committed route isn't worth taking.

6 of 6

Loading and unloading time decides it. Drop-and-hook is easy; a live load with strapping and tarping can add four hours to a driver's day.

So filling backhauls was not the top priority we had assumed, and available capacity is not a simple calculation — it depends on shipper volume, hours of service, and the characteristics of the load offered.

03 — Constraints

We couldn't get a fleet manager into the room, so every sprint output was a hypothesis until tested. The sprint ran online with participants in the US, Peru, Brazil and Argentina, which shaped how it had to be facilitated. Investment depended on evidence, and the company could — and later did — change strategy.

04 — Process & key decisions

No method was set out in advance. Looking back, the work moved through four stages: the interviews, the sprint I facilitated, the comparison test, and the decisions that came out of it.

01 — Interviews

Six people from fleet teams, 30 minutes each, semi-structured. The findings in section 02 came from this round and reset what the team thought the priority was.

02 — Design sprint

A cross-functional sprint run online across four countries, with product, business and tech in the room and no fleet manager available. Its winning concept was View Matches, the platform pictured above.

03 — Comparison test

Six participants, each shown the platform and the existing match e-mail in sequence and asked which they would use. The split it exposed — tactical staff against managers — was not something the sprint had modelled.

04 — Key decisions
The sprint's winning solution was View Matches — a site where fleet managers upload and manage available capacity and receive load matches. Instead of testing it alone, I ran a sequential comparison against the existing e-mail matches with six participants. We redesigned the match e-mail around the lane rather than the fleet number, made the price and CTA prominent, linked the map to Google Maps, and added recurrency information plus a feedback and add-capacity section. View Matches stayed on the roadmap for high-level managers.

05 — The solution

A rebuilt match e-mail, designed to be decided on from a phone in a yard. Four changes carried the redesign.

Before

The original match e-mail: led by the fleet number, with the price and the action below the fold of a phone screen.

After

Lane-led, with price and CTA up front, the map linked out to Google Maps, recurrency stated, and a feedback and add-capacity section at the end.

Lane, not fleet number

The subject and first line now name origin and destination, so the message can be placed without opening a record.

Price and CTA up front

Accepting or rejecting is a price decision, so both sit above everything else in the message.

Recurrency stated

A one-off load and a weekly lane are different propositions, so the e-mail says which it is.

A way to reply with more than yes

Feedback and add-capacity sections turned a broadcast into a channel the team could learn from. Loading time decided most rejections, and this is where that reason could finally be captured.

06 — Impact

Six participants saw both options in sequence. The test produced two findings.

Finding 01 — the platform was the wrong surface

The people who actually accept and reject loads preferred the e-mail; only managers, who read reports rather than work the loads, preferred the platform. Recommending the e-mail meant asking the team to set aside a platform it had already sprinted on and designed. The comparison made that case, and the build moved to the channel the tactical users were already in.

What shipped View Matches platform Redesigned match e-mail
Finding 02 — the channel was under-used, not exhausted

The e-mail had produced four replies in six months, which had been read as the channel being dead. Rebuilt around the lane and the price, the same channel lifted its response rate 250%, tracked in a Superset dashboard.

+250%

response rate after the e-mail redesign

4

replies in the six months before it, the baseline the lift is measured against

07 — What I learned

Asking "is this good?" gets you agreement; asking "which of these two?" gets you a decision. It also surfaced a split between tactical and managerial users we hadn't modelled at all. An e-mail was a worse portfolio piece and a better product decision. The channel a user already checks beats the one you would rather build. It was still worth running — it aligned four countries' worth of stakeholders in a week. But I now write the test that will check its output before the sprint starts, not after. The research cost days and moved the plan before a build cycle was spent. Sizing research to the decision, rather than to the ideal, is what lets it fit a delivery timeline at all.

08 — What this case doesn't cover

The work runs from the interviews to the e-mail redesign going live. Four things are outside it.

The company later changed strategy and stopped focusing on private fleets, so there is no long-run figure for booked backhauls or revenue. The +250% is a response-rate lift on a small baseline, not a business outcome. View Matches was designed in full during the sprint. Only the matches view is shown here, because the rest was never tested and never built. Six interviews and six comparison sessions, all with dedicated-fleet teams. Enough to redirect the plan; not enough to generalise to private fleets that don't run dedicated service. Every finding about loading time and hours of service came from managers describing drivers' days. No driver was interviewed.