Vehicle maintenance module background

The vehicle maintenance module is part of Webfleet platform where the customers can monitor vehicle issues or breakdowns reported either by the vehicle diagnostics or created by drivers through vehicle check app. It also includes scheduled maintenance created by fleet managers to plan recurring maintenance defined by mileage, time period or engine hours.

Every diagnostic event would come as urgent and critical while the other issues would be classified based on the reported severity or based on schedule.

The problem

The diagnostic error messages from OBD through telematics device were coming up as notification and maintenance issue each time the vehicle send the signal. With every DTC message, the system was repeating the warning, and creating a new maintenance task resulting a long list of unresolved maintenance alerts.

Customers described the module as confusing, ineffective and not useful and needed a change of approach while adding new payable advanced features.

The module was not responding multiple requirements of customers and there was no fulfilment other than manually closing a task

How could we reduce the vehicle downtime and optimise the workshop time?

Discovery

To lead the discovery and to gain insights on how the customers plan their workshop visits, who are the responsible parties and what kind of information is crucial for an effective workshop planning

Riskiest Assumption Canvas

Working with the PM, identified the assumptions we had at the beginning and categorised them by giving risk points. This helped us focusing on the riskiest assumptions to be validated and reduce the risk points. The interviews would then consider those assumptions and mitigate the risks.

Interviews

I wrote the interview plans, introduction and questions to be used by stakeholders who will be present in the interviews

• 9 interviews done with various European businesses including enterprises, workshops and car rental companies.
• Recording of customer responses in Confluence
• Gaining insights to help building a user journey map and personas

Findings

• Fleet managers had to deal with the issues singularly and communicate with workshops externally then close the issues manually in the platform. It was time consuming and also complicated.
• Operations are complicated; in some cases the drivers are responsible for identifying issues and responsible for maintenance. In other cases maintenance managers have to call workshops and book a time with them but they need better reporting of issues to estimate time and cost
• Companies have different agreements with workshops and tire related issues may need to be handled by other workshops separately from mechanical issues
• Managers also need to identify if a work is included in the warranty or not
• Customers would welcome a complete solution to track maintenance issues, and to create workshop service document and to follow the vehicles in service with a reporting on costs

Define

User personas

Created user personas for drivers and fleet managers who are mostly responsible with the maintenance of vehicles and planning and those we intended to target

Main purpose of these personas was to remind the skills and responsibilities of our target users, and to keep these in mind in our discussions.

User journey mapping, service mapping

To focus on the user outcomes and to break the ambiguity while aligning PM and PO on the user pain points, mapped various user journeys and created service mapping aiming to help defining feature propositions

Requirements as user stories

There were many number of requirements for each phase and each area of the module. Some technical requirements and user requirements were mixed.

There are many benefits of using stories rather than a list of requirements

For example a requirement says: A drop-down search filter to list vehicles with severity.

This requirement is technical and unlikely to come from a user's perspective and also suggests a certain UI type to be used. It is too detailed for user story while not saying anything about who is doing what and why.

Rewrote the story as: As a fleet manager I want to see the vehicles that has the severe mechanical issues easier on the list of vehicles, so that I can immediately set up a repair job

This user story gives us an ability to think of a best solution, gives opportunity to create ideas while considering technical capacity and using established methods, while maintaining the purpose for the user

I have re-written all the requirements as user stories and combined similar requirements into one user story making sure that every story has a persona, a need and an outcome.

Design

Ideation

DTC errors taken out from maintenance task list and put into their own table list. This way they would be included in any service plan automatically as an error without cluttering the task list

As I have gone through feedback of customers and the user journey map, moved the focus into service order creation. This made it possible to change the view from tasks to complete to vehicles to repair.

Reducing the list of potentially hundreds of issues as maintenance tasks, to vehicles with issues ordered by severity. The details of the tasks would be under vehicle maintenance information.

Rapid prototyping with design system

Using Figma atomic design system which I was managing for Webfleet, created series of rapid prototypes, interactive flows and static pages and modals.

• Created the DTC warning messages list with severity and recurrence numbers as I suggested so that the rather than creating many similar messages we group under one error code and show how any times it occurred.
• Designed DTC error message details modal, two versions, pro and standard accounts with different copy and details
• Designed new Service Order creation form to show how the different types of issues can be presented and also eliminated if necessary.
• Included workshop selection option which will be integrated with the general address book, which I proposed to utilise using a familiar functionality which was already developed.
• Choosing new icon for garage and service order

Vehicle Checklist app

Problem

Checklist app was designed to enable regulatory vehicle and trailer checks before and after a trip, based on pre-scheduled templates created by admins or fleet managers. But it did not offer ad-hoc defect reporting by drivers through the app.

Another limitation of the checklist app was it only let the driver to submit a check on his own vehicle but not other assets whereas a driver might be using more than one trailer in multiple trips

Holistic approach

To create holistic experience through multiple touch-points, extended the vehicle check app to accommodate multiple asset checks and defect reporting outside regulatory checks

Both the driver and the fleet manager would be able to report a defect without going through the full checklist which was not possible before

As a strategic decision to get more subscriptions on the checklist app, driver reporting was paramount. Otherwise drivers would communicate the issues to fleet managers and that would be both time consuming and prone to errors as more likely the drivers would know the error and be next to the vehicle

Retrospect

• Insight gathering is the most crucial step in defining the real user pain points and prioritising the constantly growing requirements. It needs to be done with an open mind and honesty as it may reveal weaknesses, and it should not be a sales pitch or "will this be good for your business ", "will this be enough for you" type questions limiting exploration of real use case scenarios
• There is always a tendency to jump into development of the first idea that comes into mind and tick through requirements which are mostly based on assumptions. This is dangerous for a product. It can cause over-engineering, scope seep and scope creep problems.
• For complex services and functionalities, the user journey map is an invaluable tool, and it needs to be supported by the PM and PO equally as it enables holistic design, common understanding and opportunities for innovation
• User outcome should define the product offering especially if it is paid features. There should be ROI calculated for the user. "If I pay the extra what will I be able to achieve and will it help my business in the short to medium plans?" would be a good question to think about.
• Leaving too much guess work and creating more tasks for the user is bad experience as it increases cognitive load
• To be critical when comparing and considering competitor feature offerings, since their context, target audience and market position would be different and their data types which may be from the core of their business can also differ.