TRIMBLE · EXPERT FUEL

Designing Expert Fuel around the full dispatch journey

Designing Expert Fuel around the full dispatch journey

At Trimble, I designed UX/UI for Expert Fuel, a fleet fuel product released to customers. I translated the full dispatch journey—from configuring approved fuel networks to planning stops, reviewing route execution, and investigating compliance exceptions—into connected, data-rich workflows.

At Trimble, I designed UX/UI for Expert Fuel, a fleet fuel product released to customers. I translated the full dispatch journey—from configuring approved fuel networks to planning stops, reviewing route execution, and investigating compliance exceptions—into connected, data-rich workflows.

ROLE

UX/UI Designer

Workflow mapping, information architecture, interaction design

PRODUCT

Expert Fuel

Fleet fuel operations

SCOPE

Network, planning, compliance

OUTCOME

Released to customers

Updated Expert Fuel planning workspace with trip queue and optimization controls

View portfolio prototype ↗

This case study reflects work during my Trimble employment. The workflow and rationale reflect my contribution; interface screens and sample data are recreated for this portfolio and are not production screenshots.

Overview

Overview

Fuel planning was one moment in a longer operating day

Fuel planning was one moment in a longer operating day

Expert Fuel connects decisions that happen at different times: which fuel locations a fleet approves, where a dispatcher asks a driver to stop, and whether the eventual purchase followed the plan.

Expert Fuel connects decisions that happen at different times: which fuel locations a fleet approves, where a dispatcher asks a driver to stop, and whether the eventual purchase followed the plan.

The work continues after a plan is sent. A driver may miss a stop, buy more fuel than planned, or purchase outside the approved network. Reviewing that event requires the original route and recommendation, not just an isolated transaction.

The work continues after a plan is sent. A driver may miss a stop, buy more fuel than planned, or purchase outside the approved network. Reviewing that event requires the original route and recommendation, not just an isolated transaction.

My design scope joined configuration, planning, and compliance into a legible sequence. I used the workflow maps to identify who makes each decision, what information must be visible, and which details should travel with a dispatch from one workspace to the next.

My design scope joined configuration, planning, and compliance into a legible sequence. I used the workflow maps to identify who makes each decision, what information must be visible, and which details should travel with a dispatch from one workspace to the next.

Problem

Problem

A good stop recommendation could still leave the dispatcher guessing

A good stop recommendation could still leave the dispatcher guessing

The workflow maps exposed three breaks in the journey: finding dispatches without plans, evaluating or adjusting a recommendation, and understanding what happened after a purchase. Network configuration ran in parallel, but its rules shaped every viable stop.

The workflow maps exposed three breaks in the journey: finding dispatches without plans, evaluating or adjusting a recommendation, and understanding what happened after a purchase. Network configuration ran in parallel, but its rules shaped every viable stop.

Operations and configuration have different owners and timing. Dispatchers need to act on a current route; network changes can affect many future routes. Combining them in one emergency flow would blur the difference between an exception and a policy decision.

Operations and configuration have different owners and timing. Dispatchers need to act on a current route; network changes can affect many future routes. Combining them in one emergency flow would blur the difference between an exception and a policy decision.

THE EXPERT FUEL OPERATING LOOP

THE EXPERT FUEL OPERATING LOOP

The design question became: how could Expert Fuel help a dispatcher find work, trust a recommendation, respond to a change, and explain the eventual purchase without losing context?

01

Set network rules

Locations, access, prices, and discounts shape every viable fuel stop.

02

Plan active routes

Find unplanned dispatches, compare stops, and approve a reviewable draft.

03

Follow execution

Keep the recommended stop and the actual purchase connected to the route.

04

Resolve exceptions

Investigate deviations, document action, and inform later policy changes.

Network configuration runs alongside dispatch operations. Shared rules guide the plan; compliance evidence can inform a separate, deliberate network update.

Understanding the Product

Understanding the Product

Two workstreams, one shared network

Two workstreams, one shared network

The workshop maps showed two related paths. In configuration, a team maintains approved stations, network membership, pricing, discounts, and fuel-card rules. In operations, a dispatcher needs to make a decision for a specific active route.

The workshop maps showed two related paths. In configuration, a team maintains approved stations, network membership, pricing, discounts, and fuel-card rules. In operations, a dispatcher needs to make a decision for a specific active route.

I kept network editing in the configuration workspace and surfaced network eligibility where a plan is reviewed. A dispatcher can inspect an alternative stop for the current trip, while a change to the company’s approved network remains a separate, deliberate action.

I kept network editing in the configuration workspace and surfaced network eligibility where a plan is reviewed. A dispatcher can inspect an alternative stop for the current trip, while a change to the company’s approved network remains a separate, deliberate action.

The “is this stop in the network?” branch matters because an out-of-network purchase may be a one-time operational exception or evidence that the approved network needs updating. The interface must support both interpretations without confusing them.

The “is this stop in the network?” branch matters because an out-of-network purchase may be a one-time operational exception or evidence that the approved network needs updating. The interface must support both interpretations without confusing them.

Tradeoff: keeping network changes out of an active plan adds a step when a new stop truly is needed. It also protects other dispatches from an accidental policy change.

Parallel workstreams

Parallel operations and configuration workflows connected through shared context.

Configuration and dispatch operations run in parallel. The approved network is the shared input that connects them.

Planning decision path

Planning decision path covering optimization, plan adjustment, network eligibility, alternatives, and compliance review.

The planning branch asks whether a recommendation works and whether an alternative stop belongs to the network. That choice should be visible before the plan is sent.

Approach

Approach

DESIGN QUESTIONS

DESIGN QUESTIONS

Three questions shaped the interface

Three questions shaped the interface

I used the workflow maps to keep the design focused on the decisions a dispatcher or reviewer actually needs to make.

01

What needs attention?

Make active dispatches and plan status visible before asking someone to open a route.

02

Why this stop?

Show route fit, price, network eligibility, and alternatives at the moment of review.

03

What happened next?

Carry plan context into purchase and compliance review so an exception can lead to the right action.

Make optimization a reviewable draft

Make optimization a reviewable draft

The planning experience begins with active dispatches and their status, so a dispatcher can find trips that need a plan before opening detailed route controls. For several eligible trips, optimization can prepare drafts together; each result still needs individual review.

The planning experience begins with active dispatches and their status, so a dispatcher can find trips that need a plan before opening detailed route controls. For several eligible trips, optimization can prepare drafts together; each result still needs individual review.

A reviewable plan shows the evidence behind a stop: route mile, gallons, effective price, detour, and the fuel needed to reach the next segment. If a stop is unsuitable, the dispatcher can compare alternatives, adjust the stop or gallons, and recalculate.

A reviewable plan shows the evidence behind a stop: route mile, gallons, effective price, detour, and the fuel needed to reach the next segment. If a stop is unsuitable, the dispatcher can compare alternatives, adjust the stop or gallons, and recalculate.

The workflow maps raised the possibility of fully automatic plans. I favored assisted preparation with a clear review and send step because route timing, station access, driver needs, and fuel conditions can change after optimization runs.

The workflow maps raised the possibility of fully automatic plans. I favored assisted preparation with a clear review and send step because route timing, station access, driver needs, and fuel conditions can change after optimization runs.

Tradeoff: the dispatcher still makes the final call. That costs a little time, but makes the recommendation explainable and gives the expert a way to handle exceptions the model cannot see.

Solution

Solution

The experience connects the approved fuel network to an active plan, then keeps route and purchase context available for exception review. These recreated screens illustrate that handoff; they are not Trimble production screenshots.

The experience connects the approved fuel network to an active plan, then keeps route and purchase context available for exception review. These recreated screens illustrate that handoff; they are not Trimble production screenshots.

01 · CONFIGURE THE NETWORK

01 · CONFIGURE THE NETWORK

In the portfolio reconstruction, configuration users manage approved stations, prices, discounts, and fuel-card access. Network eligibility stays visible when a dispatcher later evaluates a stop.

In the portfolio reconstruction, configuration users manage approved stations, prices, discounts, and fuel-card access. Network eligibility stays visible when a dispatcher later evaluates a stop.

Updated Expert Fuel network workspace with approved locations map and fuel stop details

Fuel Network

Manage approved stations, pricing rules, coverage, and the network context available to the optimizer.

Portfolio reconstruction: Fuel Network makes approved locations, price context, and stop details visible before they become candidates in planning.

02 · PLAN THE DISPATCH

02 · PLAN THE DISPATCH

The planning queue shows which active dispatches need attention. Optimization prepares a draft, but the dispatcher reviews route fit, gallons, effective price, detour, reserve, and alternatives before sending a plan.

The planning queue shows which active dispatches need attention. Optimization prepares a draft, but the dispatcher reviews route fit, gallons, effective price, detour, reserve, and alternatives before sending a plan.

Updated Expert Fuel planning workspace with trip queue and optimization controls

Fuel Planning

Triage active dispatches, batch-optimize plans, and review trip-level decisions before sending.

Portfolio reconstruction: the active trip queue keeps plan status and batch preparation in view before the dispatcher opens a route detail.

03 · FOLLOW THE DISPATCH

03 · FOLLOW THE DISPATCH

Keep the plan visible after fuel is purchased

Keep the plan visible after fuel is purchased

A sent plan should remain useful during execution. When a fuel purchase differs from the recommendation, the reviewer needs the route, driver, stop, planned gallons, actual purchase, and network status together.

A sent plan should remain useful during execution. When a fuel purchase differs from the recommendation, the reviewer needs the route, driver, stop, planned gallons, actual purchase, and network status together.

Updated Expert Fuel dispatch detail with route map, fuel activity, and compliance metrics

Dispatches & Map

Follow plan execution against route context and open stop-level exceptions without losing the dispatch.

04 · REVIEW COMPLIANCE

04 · REVIEW COMPLIANCE

The maps surfaced several reasons a plan can break: a missed stop, an out-of-route location, excess fuel purchased, or a non-network transaction. I organized the review path around the specific incident, so the dispatcher can investigate the evidence and decide whether to adjust the plan, document an exception, or coach the driver.

The maps surfaced several reasons a plan can break: a missed stop, an out-of-route location, excess fuel purchased, or a non-network transaction. I organized the review path around the specific incident, so the dispatcher can investigate the evidence and decide whether to adjust the plan, document an exception, or coach the driver.

A fleet-level score shows a pattern; it cannot explain a single purchase. The design moves from summary to driver and dispatch detail, then to the stop-level event that needs action.

Updated Expert Fuel fleet performance dashboard with driver compliance and savings metrics

Fleet Performance

Move from portfolio KPIs to driver and dispatch details, then resolve or coach with evidence.

Portfolio reconstructions: dispatch and fleet views connect route activity, compliance signals, and the detail behind an exception.

Outcome

Outcome

Expert Fuel reached customers

Expert Fuel reached customers

Expert Fuel was released to customers during my Trimble employment. This case study documents the workflow and design rationale behind my contribution; the interface examples use recreated screens and sample data to protect confidential production work.

Expert Fuel was released to customers during my Trimble employment. This case study documents the workflow and design rationale behind my contribution; the interface examples use recreated screens and sample data to protect confidential production work.

CONFIRMED OUTCOME

Released to customers

The design work made the relationship between network rules, plan review, active dispatches, and exception investigation explicit. In the portfolio reconstruction, each screen carries the context needed to move from one decision to the next; the visuals are illustrative rather than production screenshots.

The design work made the relationship between network rules, plan review, active dispatches, and exception investigation explicit. In the portfolio reconstruction, each screen carries the context needed to move from one decision to the next; the visuals are illustrative rather than production screenshots.

What I would measure next

To evaluate the released experience, I would track the share of dispatches with a plan before departure, time to prepare and approve a plan, how often recommendations are changed, planned versus actual purchases, network compliance, and time to resolve an exception. These are proposed measures, not reported results.

To evaluate the released experience, I would track the share of dispatches with a plan before departure, time to prepare and approve a plan, how often recommendations are changed, planned versus actual purchases, network compliance, and time to resolve an exception. These are proposed measures, not reported results.

Challenges & Learnings

Challenges & Learnings

The handoffs were the real design problem

The handoffs were the real design problem

A fuel optimizer can calculate a stop, but operations teams still need to know why it was recommended, whether it fits an approved network, what changed on the road, and who should act next. Mapping those handoffs made the product story more useful than treating each screen as an isolated feature.

A fuel optimizer can calculate a stop, but operations teams still need to know why it was recommended, whether it fits an approved network, what changed on the road, and who should act next. Mapping those handoffs made the product story more useful than treating each screen as an isolated feature.

If I revisited the work, I would test edge cases earlier: unavailable stations, stale prices, hours-of-service limits, and urgent out-of-network needs. I would also instrument each handoff so the team could see where expert review adds value and where the system can safely remove work.

If I revisited the work, I would test edge cases earlier: unavailable stations, stale prices, hours-of-service limits, and urgent out-of-network needs. I would also instrument each handoff so the team could see where expert review adds value and where the system can safely remove work.