Fleet-management SaaS: designing for the exception

The company's product is no longer online, and I have not asked permission to publish its screens. This page describes the decisions in words. I walk through the designs in interviews.

The problem. The vehicle maintenance report looked like a paper form: one very long page covering damage, condition and current status, so neither the report nor its condition table fit on a screen. A fleet owner with many vehicles had to read all of it for every car.

My decision. A vehicle rarely has problems everywhere. Most parts are normal, so an owner should read a summary and open only what looks unusual. I put the vehicle profile and a major damage summary at the top: last known status, charging state, tire pressure, model. Everything below became a collapsible section, and several can stay open together. I added counts of newly added and fixed damages, icons, and error states.

Outcome. I proposed it to the senior engineers, and the design was implemented in production. I have no measured time saving, so the case rests on the reasoning.

What I took from it. Design for the exception. A report earns its length by pointing at the one part that is wrong.

The problem. Fleet owners assign tasks to crew such as valets and technicians. Crew saw a dated list and could not tell which tasks were due today and which they had missed.

My decision. I added a separate Overdue section and a date filter, for example "due today". A task not finished by the end of its deadline day moves to Overdue automatically and notifies the fleet manager on the web app. The manager chooses: keep it, reassign it or delete it. A kept task stays in the crew member's Overdue list and can be started at any time. A deleted one leaves their list.

I took the flow to the developers and confirmed it could be built before I handed it over.

When my senior designer left, the main apps were already in development. I chose to leave them alone and spent my time on the new crew app for valets, mechanics and maintenance workers. I mapped the flows, explained them to developers regularly, and had each one validated as buildable before handoff.

I also improved search filters and sorting, designed how remaining, current and ongoing tasks behave, and designed the Play Store and App Store screenshots in Figma for every app.

I designed looping animations that show the product's claims instead of describing them. For "always connected", a car drives along a moving road with a blinking connection signal up to dashboard screens. For "spot problems early", a laptop dashboard cycles through vehicles and raises an alert on the faulty ones.

I built them in Figma as prototypes, screen-recorded them and delivered 5 to 15 second looping MP4s to the developers, who placed them on the site. I designed and delivered them; the developers integrated them.

My senior designer asked for a floating vehicle profile that appears when an alert arrives. I designed a compact rounded card in the top-right corner, within our design system, showing the car photo and status, clickable to the vehicle page. He wanted a full-width bar across the top.

I argued that an alert should not take the full width, because it uses header space and reads as another menu. He made the call and I built his version. I still think the card was the better pattern. What I would change: bring a reference or a side-by-side of both versions before the decision is made, because my opinion alone did not move it.