Improving Perceived Performance in Vehicle Monitoring

Overview

The Trips Page is a core monitoring tool within DadyCar where fleet managers track the movement history of their vehicles. Rather than just showing raw GPS pings, the platform intelligently segments data into distinct “trips” and “pauses” (e.g., filtering out 2-minute stops for heavy traffic, while logging a 15-minute stop as a true pause). It combines a live map view with a detailed timeline of movements.

I led the UX redesign for this feature to solve a critical performance issue. Because this was fundamentally a data-fetching challenge, I collaborated heavily with the PM and backend engineers to find a solution that balanced technical limitations with user experience.

The Problem: When “Standard UX” Fails

The core issue on the Trips Page wasn’t the layout; it was the perceived performance.

Our platform pulled GPS data from a secondary provider, who in turn fetched it from a primary provider. Because our clients manage large fleets, calling this chained API every few minutes resulted in massive data payloads. Engineering couldn’t simply “make the backend faster” due to this third-party dependency and our own database storage limits.

The Failed First Iteration: Skeleton Loaders
Initially, we relied on standard UX best practices: we used skeleton loaders while the map and trip data fetched. However, because the API response could take up to 20 seconds for vehicles with heavy trip histories, the skeletons stayed on screen far too long.

Users found this waiting period extremely frustrating. In UX, 20 seconds feels like an eternity. Users assumed the app was broken and began constantly refreshing the page — which only triggered new API calls and worsened the server load. The frustration reached a point where clients were directly complaining to our PM and CEO about missing data.

We realized that when dealing with extreme technical latency, traditional loading states are not enough. We needed to redesign the perception of how the data loaded.

The Pivot: Cached Data

During an internal sync, the engineering team and I discussed an alternative approach: instead of making the user stare at a blank skeleton loader, we could retrieve and display the most recently saved data from our own database.

I strongly supported this direction. By showing cached data — such as trips from yesterday or earlier in the week — we could give the user immediate visual feedback within the first second of opening the page. They would instantly see the map and their recent trip history cards on the left, satisfying the immediate need for content while the system worked in the background.

Designing for Trust & Transparency

While showing cached data solved the empty screen problem, it introduced a new UX risk: Trust. If a fleet manager looked at the page and saw yesterday’s data, they might mistakenly believe the vehicle hadn’t moved today, or worse, that the system was broken.

We had to design an experience that clearly communicated state without blocking the user.

The “Syncing” Banner
To manage expectations, I designed a subtle but persistent banner that appeared at the top of the trip list the moment the page loaded.

• State 1 (Fetching): A light blue banner displaying the text “Sync en cours” (Syncing in progress), accompanied by a small spinning loading icon on the left, and a timestamp of the last successful fetch on the right. This immediately told the user: “You are looking at older data, we are currently getting the new data.”
• State 2 (Success): Once the 20-second API call finished, the banner turned green with a “Sync Done” message.
• State 3 (Resolution): The new trip cards seamlessly populated the list, and the green banner faded away, leaving a clean UI.

Why this design works:
This approach shifted the user’s perception of time. Because they had real data to look at and interact with immediately, the 20-second wait felt significantly shorter. More importantly, the explicit UI banner replaced user frustration with system transparency.

Outcomes & Impact

The impact of this update was immediate. By replacing the empty skeleton loaders with cached data and clear system status, user behavior shifted dramatically.

• Complaints dropped significantly: Calls to the PM and CEO regarding “missing data” decreased. Users now understood they were looking at cached data while the system worked.
• Fewer server requests: Because users saw the “Syncing” banner, they trusted the system was working. This stopped the anxious behavior of constantly refreshing the page, reducing unnecessary strain on our servers.
• Positive internal feedback: Both the PM and the engineering team noted that the page felt significantly faster and that the user flow finally made logical sense.

Reflection

This project was a masterclass in the difference between actual performance and perceived performance.

The most important lesson I learned is that designers cannot control all technical aspects of a product — especially when dealing with third-party APIs and massive data payloads. We cannot always make the data load faster, but we can control the user’s perception of that wait. By ensuring the user always has some data to look at, and clearly communicating the system status, we can effectively eliminate frustration.

If I were to improve this feature in the future, I would add a manual “Fetch Now” button. While the auto-sync works well, giving users explicit control over when to call the API could provide an even higher level of trust and flexibility.