Our client is a B2B vehicles leasing company. They required an administrative platform that allowed them to track the servicing needs for all the vehicles under their service, on duty on any client, as well as being able to log and follow unexpected service and repair events. We also one an extra function directly requested by the final users.

Brief

The user of the platform needed to be able to follow the progression of any one vehicle through its servicing process. Given the amount of concurrent servicing items or “instances” going through the system, they also required a notification systems that would give them prompt information about where their attention was needed most urgently.

As the full servicing process contained not-yet-automatized stages, staff also needed to be able to intervene manually to have them execute, as well as create overrides.

These vehicles are not serviced internally by the client but on a network of independent commercial partners, external facilities and car shops. The platform needed to show communication with digital systems on the side of the exteral partner the user, but also to integrate manual contact functions.

Design restrictions

Two restrictions were added to the brief. The first one was inherent to the platform: the product would exist inside a more general app framework, which placed a header on top which we could not modify.

A second, maybe more quirky restriction, was to make no use of modals or accordions. As an internal app for a B2B company, this was sadly not surprising, no custom UI was foreseen either, making use of general front-end libraries instead: “No fancy stuff”.

The product

I divided the design of the product in 3 main areas: A subheader on top, containing the client/account selector and a backlog indicator; the tables and tabs below in the main area, following the progress of every vehicle going through the system; and a side-modal section containing alternatively a search function or the notifications.

The backlog indicator gives an immediate overview of all instances currently active in the app, allowing the user to prioritize different workflows depending on the workload. In fact this functionality was a specific request that current users put forth during reviews of early wireframes of the app.

Tabs categorize instances according to their origin: While some instances are created in the system based on scheduled interventions, some others are created by monitoring systems in each vehicle. Users were also given the possibility of creating instances manually in most categories.

The tables under each tab show the most relevant information of every instance, often giving options for immediate actions to the right, or otherwise providing detailed pages that contain all pertinent manual overrides.

The notifications give immediate information about the most recent information received or produced by the platform and steer the user towards the more relevant actions required.

Search functions are divided in two as it is common in many high-volume information systems: one quick-function with limited screen real estate due to the side-modal container, and an Advanced mode in full scren and extensive filters available.

No modals to side modals

In order to design without modals, for simpler things like Yes/No interactions, I created an in-page interaction that looks more like an interactive flow chart. This got me some of the focus grab of a modal, thanks to its simple and logical real-time appearance on screen.

But functions like notifications need to be contextual, not separate from all other activity in a screen of its own. Especially if “Nothing fancy” meant no ajax, then interactions would happen in the form of navigation to and from another page, just to see a notification.

Ready to argue about it with the client, I put both search and notifications, which are very important and high-level functions, inside a full-height side-modal. When the client saw them in a review, this seemed such a natural and familiar structure to view the notifications in, that no argument about the use of modals took place whatsoever.

Future UI

The UI you see here is an extension of a UI we presented to the client for a different project, it was never actually implemented. I would very much recommend implementing it, not out of a discourse of aesthetic, but for the usability benefits that a well thought out UI brings in terms of cleanliness, color-coding and the action-reaction hints offered by micro-animations.