< Main PortfolioUI/UX / McLeod Timeline Case Study

McLeod Software — Case Study | Joel Maxwell
Case Study · McLeod Software
DEEP DIVE - Timeline

The Tool Nobody Used — Reimagining the Driver Manager Timeline from the Ground Up

Role
Director of User Experience
Industry
Transportation Management Software
Products
PowerBroker · LoadMaster
Audience
Driver Managers

During my six years at McLeod Software, I worked across an entire suite of enterprise TMS products. Most of that work was highly visible — the screens users lived in every day, the workflows they ran dozens of times a shift. But some of the most important work happened in the corners. The places that had been there for years, quietly failing the people who needed them most. The Driver Manager Timeline was one of those places.

"It wasn't broken. It was invisible. There's a difference — and fixing that difference is exactly the kind of work I'm here to do."

Part · 01

Overview

A driver manager is many things at once. They are a manager, a friend, a babysitter, a planner, a scheduler, and a constant reminder for the people behind the wheel. Their presence is what keeps drivers focused, loads moving, and customers happy. They are, in many ways, the human infrastructure that holds a trucking operation together.

The Timeline View exists to give that person a single place to see everything — every driver, every load, every status, all at once. Done right, it's the cockpit of the entire operation. Done wrong, it's a wall of noise that nobody looks at twice.

At McLeod, it was the latter.

Early Sketches of Story, Final Icons
Part · 02

The Before

The original timeline wasn't broken in the way that crashes a system or stops work from getting done. It was broken in a quieter, more insidious way: people had simply stopped using it. What remained was a glorified spreadsheet — rows of data dressed up with background colors that were supposed to communicate driver status but instead caused immediate eye strain. The color logic required training to decode. The indicators for hours, alerts, and messages were cryptic at best. Nothing was intuitive. Nothing told a story. It was a screen you glanced at, got confused by, and closed.

That's not a data problem. That's a design problem.

Part · 03

The Problem Was Never the Data

Think about the original texting interface on a Nokia phone. The information was all there — you could send a message, receive one, read it. It technically worked. But compare that to texting today: read receipts, emoji, file sharing, payment transfers, threaded conversations, rich media. Same fundamental purpose. Completely different experience. Nobody would go back to the Nokia version by choice — not because it was broken, but because the new version respects what the task actually demands of the person doing it.

That's exactly the gap the Driver Manager Timeline had fallen into. The data was there. The function existed. But the experience had never been designed for the human being who had to use it for eight hours straight, making real decisions about real drivers carrying real freight. It needed more than modernization. It needed a complete rethinking of how to tell the story of a driver's day.

Early Sketches of Story, Final Icons
Part · 04

Storytelling at Scale

The challenge with the timeline is the sheer density of what it has to communicate in a small space. For every driver: their name, their tractor, whether they're running late, whether they're over hours, whether they're assigned to a load. For every load: its status — in progress, being loaded, being delivered, on an empty move. The origin and destination. The customer and supplier. What's being shipped, what it costs, and whether everyone has been paid. And that's just the surface.

The solution wasn't to show less. It was to show it better. Modern iconography replaced color codes that required a decoder ring. Status indicators were designed to be read at a glance, not studied. Load bars communicated progress visually rather than through abbreviations nobody remembered. The timeline went from a screen you needed training to read to a screen that explained itself.

Order Planning + Timeline View
Part · 05

One Tool, Many Lenses

A driver manager's needs shift constantly throughout the day. Sometimes they need the 40,000-foot view — a full picture of the entire fleet, every driver, every load, overall status at a glance. Other times they need to zoom all the way in on a single driver to plan their next assignment or understand why something is running late.

The redesigned timeline was built to serve both. As the user zooms in, the level of detail increases proportionally — more information surfaces as the view narrows, without overwhelming the broader view when they need to scan the whole fleet. One tool. Two modes. No context switching.

Part · 06

The Hover Card

Seeing is only half the job. A driver manager doesn't just track drivers — they communicate with them constantly. The redesigned timeline surfaces contextual actions directly from the view, without requiring the user to navigate away. On hover, a card appears for each load with quick access to the most common tasks: send a message, log a call-in, track status, clear a stop, add a planning comment. The actions the manager needs most are right where the information already lives.

This matters more than it might sound. Every screen transition is a moment of lost context. Keeping the action inside the timeline means the manager stays oriented, stays informed, and stays fast.

Part · 07

In Closing

The Driver Manager Timeline was one of those projects where the gap between what existed and what was possible was almost uncomfortable to look at. The old version wasn't the result of bad intentions — it was the result of years of incremental additions to a foundation that was never designed for the job it was being asked to do.

The new version was still in development when I left McLeod. I don't have adoption numbers. What I do have is the memory of showing those designs to the driver managers and operations teams who had been living with the old version — and watching their reaction. That reaction was the validation. When the people who know the problem best see the solution and immediately understand it, you've done the job.

It wasn't broken. It was invisible. There's a difference — and fixing that difference is exactly the kind of work I'm here to do.