Truth is time-sensitive
A verified load can become unavailable minutes later without us knowing.
"Man, the loads you sent me [are] already gone..."
"You guys are super slow lol"
Shipped
Redesigning Dispatch, an AI assistant for truck owner-operators
TruckSmarter offers a centralized platform that helps truck drivers grow their businesses. Small carriers are the fastest-growing segment of the $940B freight industry, but finding jobs is time-consuming and expensive: drivers either spend hours a day piecing together loads across dozens of broker apps, or pay a dispatcher 3–5% of every load to do it for them.
I identified the need for and drove the redesign of Dispatch, an AI assistant that helps owner-operators find jobs faster. This tripled weekly active users and eliminated the need for our ops team to provide white-glove support to users.
- Timeline
- 1 month research,
40 days to ship - Role
- Lead Product Designer
- Team
- 2 PMs,
10 engineers,
1 other designer - Tools
- Figma,
Claude Code,
Mode
Problem
Carriers spend hours on tedious, repetitive job booking.
User workflows are messy and send truckers in loops. Dispatch v1 helped truckers with the search step, but left them with the rest of the messy process.
Truth is time-sensitive.
A load Dispatch verifies as available can become unavailable minutes later. As a result, users often get stale information.
Product was a mystery.
Dispatch ran 10+ minutes with little visible progress, so users often became impatient and left before seeing any value.
Solution
Outcomes
Weekly users3.1×
More users validated demand for the reworked product and gave us more insights, leading to faster feedback loops.
ACTIONS PER SESSION1.8×
Users were trusting it with taking real actions, a first step towards it becoming a part of their workflow.
Self-serve0→100%
Freed up ~15 hours of our ops team’s time per week that used to be spent calling users and handling support requests.
Design decisions
We kept Dispatch v2 as a distinct experience to protect our main customer acquisition lever.
Rather than disrupting our free load board, we chose to first prove Dispatch v2’s value as a distinct experience. Our tight deadline also made changing existing code riskier and costlier.
We guarded user agency: Dispatch v2 does the tedious work before handing off to the user to finalize.
We chose an approach that keeps users in the driver’s seat. Rather than Dispatch fully booking the load, it loops the user in when it’s time to finalize the booking. This choice also let us reuse significant calling technology we had already built.
Process
Past feedback was mostly "need more loads," a marketplace liquidity issue that didn't give actual product insights. I designed a study circumventing that.
In previous sprints for Dispatch v1, user feedback revolved around wanting more loads. I found this strange, since our free load board drew thousands of active users despite sharing the same load ecosystem as Dispatch. To further examine this hypothesis, I devised a study, queried relevant users, and talked to dozens of users.
Users didn’t understand Dispatch’s value
Dispatch offered little users couldn’t already get from the load board.
"What's verification?"
"What is it even doing?"
Feels harder to use than using the free load board
Dispatch offered little users couldn’t already get from the load board.
"I still need to call them myself, so why pay..."
"Need to figure out how to use it properly..."
Convinced incremental fixes wouldn't be enough, I prototyped a new vision and pitched it to leadership, resulting in alignment that a deep rework was needed.
Leadership set a 40-day window to ship to capitalize on the summer freight wave. This kicked off an intense period of rapid prototyping, feedback, and iterations. During weekly design feedback meetings, I presented my designs, iterated on feedback, and worked closely with engineers to ship within the timeline.
With 40 days to ship, I prioritized figuring out how Dispatch v2 should integrate into the wider app ecosystem.
We ultimately decided to keep Dispatch v2 as its own distinct product surface, primarily to not disrupt the load board as our acquisition engine.
- Reduced scope + familiar UI
Keeps core experience unchanged, making development and adoption faster.
- Easier entity resolution
Visible context simplifies entity resolution.
- Disruptive to main user acquisition channel
Any friction here impacts our top of funnel.
- Undersells our AI bet
Positions Dispatch as an add-on, rather than a premium, stand-alone experience.
- Familiar channel
Users already get text updates by from human dispatchers, so this feels natural.
- Great for alerts
Reaches users even when they’re not in-app.
- Easily lost
Our users get dozens of texts every day.
- Harder to parse
Even with RCS, dense load information and other complex tasks are more difficult without rich UI.
- De-risks user acquisition channel
Load board changes have historically frustrated users; a separate surface lets us build without disrupting them.
- Allows us to build faster
We won’t need to untangle years of legacy code.
- Cleaner mental model
Load board is for scrolling; Dispatch is for insights & actions.
- Habit is hard to change
Low-tech audience may never convert.
Search was still the first step of Dispatch, so I next prioritized exploring designs and interaction models for the load cards.
Load cards need to communicate a lot of information for drivers to accurately making judgement calls, so cutting information was out of the question. Considerations while designing: reducing height of card as much as possible to fit enough results, ensuring clear visual hierarchy for quick scanning, keeping designs breathable.
Number as primary ID
- Easy to reference (“book load 1”), but gets confusing when the list re-sorts or paginates
- 2 rows of tags gets noisy when cards stack
- Broker name is buried among the tags
- Pickup/drop-off times aren’t immediately visible (requires tap to expand)
Labeled checkbox + number
- Broker name is given sufficient prominence
- Most important tags fit on one row; the rest visible upon expansion
- Stacked route makes pickup and drop-off scannable, but times need to be a window
- Pairing the number with a labeled checkbox makes mechanic obvious, but costs space
Checkbox top left
- Information dense, but clear hierarchy keeps key details prominent
- Condensing tags to one row saves space and preserves most important information
- Checkbox position saves vertical space, but the left gutter wastes horizontal space
- “Time posted” helps judge freshness, but has no clear home yet
Checkbox top right
- Moving the checkbox right removes the gutter, so content sits flush left in the studied F-pattern for easy scanning
- Most important information in F shape; progressive disclosure
- As a sanity check rather than a deciding factor, “time posted” is anchored to the bottom right where the scan ends
Beyond the interface, I proposed ways for Dispatch v2 to anticipate needs, so users could spend their time on judgement calls, not on routine steps.
- How can Dispatch keep providing value when the driver's attention is elsewhere?
- How might Dispatch take initiative without misrepresenting the driver's intent?
For example, when the market has no match, Dispatch offers to keep working instead of returning a dead end.
Some design decisions: not allowing users to cancel a task so that they could go back.Didn’t want important actions to get buried within multiple different chat threads.
We ended up shipping within the 40 day deadline to get our product out in the wild to test. I monitored conversation data to identify UX issues, prioritize improvements, and also shipped PRs directly to code!
While the agent still needed refinement, we had a much stronger foundation to build from. I monitored conversation data to identify UX issues, prioritize improvements, and close the loop between user feedback and product iterations. I also contributed directly to the codebase, writing agent instructions, polishing the UI, and fixing bugs in production!
The redesign transformed Dispatch from a tool that simply verified loads into an assistant users could independently engage with throughout their workflow.