← All workCase study · FuelerLinx · UX and product

Trips 2.0: a real-time dispatch dashboard

I took Trips 2.0 from field research to shipped components for a jet-fuel marketplace, and average dispatch time dropped 60%.

Role: Sole UX owner. Research, flows, interface design, and shipped front-end components.
Timeline: 2024-2026
Team: Engineers, product owner, ops contacts
Stack: Figma, Blazor WebAssembly (.NET 9), Razor, Radzen.Blazor, Material Design, Claude Code
Users: Fixed-Base Operators, Dispatchers, Pilot, and Fleet Managers
Result: Average dispatch time down 60%

Problem

FuelerLinx is corporate aviation's largest jet-fuel marketplace: $3.2B+ in annual transactions, 120,000+ monthly dispatches, and 5,000+ aircraft. A trip has legs, fuel needs, vendors, and costs attached.

The people managing trips do it under time pressure, often several at once.

Dispatchers were juggling paper logs, spreadsheets, and a legacy web app that hadn't been redesigned in years. Trip information was scattered across all three, and no single view was trusted as the source of truth.

There was no real-time visibility. Trip status lived in people's heads instead of in the system, and errors built up during shift handoffs.

The legacy app

This is what dispatchers worked in before Trips 2.0.

Legacy FuelerLinx trips screen before an aircraft is chosen, showing only filters and the message 'Please select an aircraft above to begin.' — First screen: nothing loads until you choose a group, an aircraft, and a call sign.

Legacy trips screen listing three legs of one trip, each with a fuel price dropdown and a Take Fuel button. — After choosing an aircraft: the legs of a trip in a list, each with its own fuel price dropdown.

Three more screens, one level deeper each

Legacy trips screen with the first leg expanded, showing fuel setup details, fees, and FBO contact fields. — Opening a leg: fuel setup and FBO fee fields expand inside the list.

Legacy optimization settings tab, a long form of fuel, weight, and routing fields. — Optimization settings: a long form of fuel, weight, and routing fields.

Legacy fuel price options table opened over the trip details, covering part of the leg panel. — Fuel price options: a table opens over the trip details, covering part of the leg.

Role

I was the only UX person on the product, so I owned the work end to end: discovery, information architecture, flows, Figma design, and the Razor and Radzen components that shipped.

Process

Discovery and field research

Before any screens, I did discovery and field research on how trips actually get dispatched.

Defining the shape of the dashboard

The finished product covers four jobs in one real-time view: trip dispatch, leg tracking, fuel optimization, and financial workflows.

Design

I designed in Figma with the shared component library, so the dashboard reused patterns from other modules instead of inventing new ones.

Early Trips layout that was ruled out — Option you ruled out

Final Trips 2.0 layout as shipped — What shipped, and why

Build

I built the interface in the product's own stack, Razor with Radzen.Blazor components, instead of handing off a spec and hoping it survived.

Review

Solution

Trips 2.0 puts dispatch, leg tracking, fuel optimization, and financials in one dashboard that updates in real time.

One sentence saying what the screen shows — Multi leg component shows all the details of the upcoming trip and connecting legs. I set them as dropdown rows and gave it the ability to quote all legs at once.

Outcome

−60%average dispatch time after Trips 2.0

Trips 2.0 is a more responsive Blazor web application. Users can switch between sections without friction, and a custom navbar gives easy access across multiple devices.

We were able to capture more of our users' metrics, because the FuelerLinx API integrated a range of capabilities, including a new AI feature called the Smart Assistant. As we collected more of our users' monthly usage, we concluded that an AI agent would benefit every flight department by pre-scanning all upcoming scheduled trips and fuel calculations.

That feature cut the time a dispatcher spends on upcoming scheduled trips by 60%. The Smart Assistant sorted everything in the queue by category and automated the process to fit each department's needs. We measured this through Microsoft Azure analytics and our API integrations, and saw it in our internal analytics system and in Lucky Orange. The figure covers two years, as we rolled out Trips 2.0 features gradually.

What I'd change

Next case studyFuelerLinx design system →

All work