Designing Trust Into a Vehicle Service Platform

Software for vehicle service shops competes badly on one key aspect: usability. Existing tools offer complex functionality with interfaces that clients, mechanics and shop staff all struggle with. I joined the team to design a platform that handles booking, service and payment, with an outstanding and functional UI.

Some people know a lot about cars. Many more don’t care beyond whether the car starts — and they are the ones who usually end up at a service shop. People who lack vehicle knowledge struggle to explain or understand technical issues, which creates miscommunication with mechanics. Miscommunication leads to distrust, and distrust is bad for business.

The project manager, a former IBM developer, introduced the project with a detailed flow diagram — an engineering artifact covering many flows, including the backend architecture. From a designer’s perspective it lacked one important detail: the user.

I translated the diagram into a simplified, journey-focused flow for each role while staying faithful to the approved architecture. The journeys helped us both understand how clients, mechanics and staff would use the app. They also showed that clients needed only a small fraction of the platform — small enough for a lightweight app in the browser or on a phone.

To tackle miscommunication, I researched local service shops and interviewed mechanics about how they handle clients who can’t explain a problem. Most check the vehicle themselves, then call the client to report the issues and let them decide whether to proceed.

I then interviewed drivers who own a car but don’t know much about vehicles. They used vague words for noises, the car’s behavior or dashboard lights. When they couldn’t explain at all, mechanics asked simple questions: “Is any light on in the dashboard?” “If not, what noise do you hear?” “Where is the noise coming from?” “How does the car behave?”

I explored prewritten questions, but questionnaires are long and users get impatient. A free text box alone was too unreliable. The solution: an illustration of the vehicle with a pin to mark where the problem is, plus a short text field to describe it. Even if the description is unclear, knowing the location helps the mechanic isolate the problem. It doesn’t replace diagnosis — mechanics have their own tools — but it narrows the search and builds trust.

This was my one engagement with no component-library restriction. It called for polished, custom UI elements with intuitive usability. The biggest challenge was designing one platform for three types of users — keeping it authentic and familiar while giving it a fresh UI.

The design was completed and delivered. The product itself has faced funding obstacles, which are delaying development.