VisionLink — Trimble × Caterpillar
Customers depended on the fleet-telematics platform and still couldn't work inside it. Seventeen of them, across three continents, told us why — and the answer wasn't the interface.
Seven top-level tabs, and the picture assembled by hand. Users came to the old VisionLink to read numbers off stacked statistics tables, then rebuilt the view they actually needed in their ERP or in Excel — a page at a time.
Fleet overview, redesigned. A role-scoped view that assembles the picture for them — hours, fuel and asset status read together, with the full asset list one scroll below.
customers visited across the US, Europe and India — quarries, ports, foundries and road construction.
interviews spanning seven roles, from equipment managers and mechanics to an owner and an IT manager.
days in the field, before a single screen was drawn.
product streams the design was sequenced into: Maintenance, Project 2D/3D, Fleet Management.
-
Two research programmes, not one
Stakeholder research first — product offering, OEM and software competitors, positioning and the dealer sales cycle, plus a usability review. Then field research to test it. The gap between what Trimble believed and what customers did became the brief.
-
Thirty-two days on the road
Seventeen customers across three continents, 33 interviews across seven roles. Sampling was deliberately weighted to maintenance — sixteen maintenance managers — because that was where the product was actually being used daily.
-
Mapped the ecosystem, not the user
The work spanned back office and field operation across five functions — equipment allocation, maintenance, on-site maintenance, project and operations. We mapped the actors and the messages passing between them, then named the primary personas from that map.
-
The finding that reframed the project
VisionLink didn't sit inside the customer's business workflow. Users came to it to extract numbers, then did the real work in their ERP or in Excel — scanning pages and tabs to assemble a picture the product never assembled for them. That is a product problem wearing a UI costume.
-
Design goals before design
Rather than move to screens, we published design goals in five bands — business, system, functional, training, interface — each traceable to a research finding. Role-specific workflows, the bird's-eye view, and modular licensing all originate there.
-
Structure, then streams
A function-priority workshop set the order; then information architecture, UI structure and technical validation, before storyboards split across three streams so each could be validated on its own. I led delivery for a team of nine across research, IA, interaction, visual and brand.
“There is a 12-hour delay between the alerts. We missed our whole work period — we could have repaired it in the night.”Maintenance manager · field research, 2013–14
The IA and the design goals were accepted as the basis for the next-generation product, and the build was sequenced across Maintenance, Project 2D/3D and Fleet Management rather than attempted as one release — with VisionLink's visual and brand identity redefined alongside the structure. The engagement began in September 2013 and continued past the redesign.
Research the business before the interface
The stakeholder round mapped the OEM–dealer–customer chain and the sales cycle first. Without it, "users find it confusing" would have been read as a UI problem and answered with a UI fix.
Design goals as the contract
Publishing goals across business, system, functional, training and interface gave engineering, product and marketing one document to argue against — and gave every later screen something to be right or wrong about.
Modular, because the licensing was modular
Fleet, Maintenance and Project were structured as modules because that is how the product needed to be sold. An interface structure that ignores the commercial model doesn't survive contact with it.