Vehicle Management System

Vehicle Management System

This is a system for loading and managing vehicles for an organization.

🧑🏽‍💻 Role

Lead UX Researcher and UX Design, UI Design and Team Lead

⏱️ Duration

6 Months in 2018

👬 Team

2 Designers, 3 developers, 1 Software Manager, and 1 scrum master.

🛠️ Tools

Miro, Adobe XD, Illustrator, Photoshop.

Overview

The target audience is department administrators, vehicle inspectors, senior management, and employees who are authorized to book the vehicles.

The previous version had so many issues and only the developer could manage to use it.

The user journeys were confusing and the product did not align with the branding.

Each time you try to do a different task, you discover how not user-friendly this system is.

Previously, all the journeys, research, and development were done by one software developer reporting to stakeholders that are more familiar with Telecommunications Infrastructure than Software development and its process.

Solution

Introduce a new comprehensive Vehicle Management Software (VMS) to the local municipality, providing real-time vehicle tracking, automated maintenance scheduling, and fleet optimization. The VMS offers user-friendly interfaces, data-driven decision support, and scalability. This solution will improve operational efficiency, reduce maintenance costs, and enhance fleet management for the municipality.

Problem Statement

The local municipality currently lacks an efficient and comprehensive vehicle management system, leading to operational inefficiencies, increased maintenance costs, and a lack of real-time visibility into the status and utilization of its vehicle fleet. To address these challenges, the municipality seeks a solution that can streamline vehicle tracking, maintenance scheduling, and usage optimization, ultimately reducing costs and improving overall operational effectiveness.

Design Thinking Approach

My Process

I follow the design thinking approach on all my recent UI/UX work. 

It adds value and saved time in conceptualizing a bespoke product but also being user-centric. The process that simplifies design thinking in my honest opinion is the Double Diamond Design Process, it has four phases, discover, define, develop and deliver. These phases tough on the elements required for design thinking but in a much more concise fashion.

Click below for more information about the process and view a detailed diagram. 

1. Discover Phase

Understanding and getting insight into the problem

GETTING STARTED

Analysing the brief and defining research areas

We had to first understand the basics, that is WHO, WHAT and WHY we are doing this then decide on the requirements for an MVP given the strict deadline. This required research.

Other features were pinned in the planning phase and not ignored.

We decided to conduct potential user interviews and narrow down user personas based on that.

We realized we needed personas because nobody else understood how the system works besides the developer that worked on it.

This is where empathy came in.

I researched what competitors have built to find insight, where we could improve and what would not work for a government organization.

PRIMARY RESEARCH, EMPATHY

Personas and user research

Based on the interviews/workshop we set up three personas. We referred to them throughout the entire product development process.

We realized we need personas because nobody else understood how the system works besides the developer that worked on it.

We asked the department who will be using the software inorder to put together these personas. Most users struggled to know what to expect so we really had to come up with a persona that has expertise in such systems and would really challenge our product then simplify our solution for the rest of the users from there. This main user persona helped us push the product to its potential.

The other personas were for management/supervisors/executives and drivers.

At some point during our iterations, I realized we missed one crucial user, and that was the inspector. This user would assure drivers would not misuse the vehicles.

We also noticed that cars had to be monitored even more, making sure the distance traveled is equivalent to what is expected from the trip planned by the driver and reasonable for personal trips for food, personal admin, etc.

We can now define requirements for our Minimal Viable Product and start ideating concepts at this stage.

User Groups and User Interviews

My initial user group was with my team and 2 additional colleagues to evaluate expectations from users. The second round involved the client.

Interviewed the administrator and advised that we also need to involve a vehicle inspector which is something that was overlooked but discovered it has to be something that is included in the vehicle online booking process.

Competitive Analysis

There was no official detailed brief but rather just a written request so looking at what was out there was essential.

I browsed several systems and referred to 2 most well-known vehicle management systems.

  1. eWorks Manager
  2. NetStar Fleet Manager

They helped to assure some of my findings but also were given room for improvements as well as see gaps for improvements. I evaluated the previous suggested solution and analysed where it failed.

 

2. Define Phase

Focus areas

INSIGHTS + opportunity area

Pain points and challenges

The Previous Version:

This is how the old version looked like. We started off by jotting down what works and what is necessary to keep from this version.

No officially documented brief was available so we had to come up with our own. Basically, the BRIEF was “Make a better version of this for our client” on a tight deadline since the company had already wasted time on something that didn’t work.

BUILDING CLUSTERS AND THEMES

Card sorting

I used the same team from the user group to help out with the card sorting. We had an open card sorting and a closed card sorting afterward. 

Participants were given a list of vehicle-related terms, features, and functions on individual cards. I encouraged them to create lists, and groups and label them accordingly. These categories should represent the main sections or modules of your vehicle management system. This process helps a lot with the information architecture and building clusters.

OPPORTUNITY AREAS

Geeting the Edge and standing out

Car Booking Process

I felt a vehicle inspection had to be monitored and captured in the system.

Flagging

I added a flagging system, this is coming from interviewing the fleet manager, some vehicles end up in blurry lines, and the manager doesn’t know if the car has been inspected and if everything is in order.

Cars that are overdue for collection, returns or inspection are flagged.

Mileage

This was to make the users and admin aware of the condition of the vehicle.

3. Develop Phase

Evaluating posible ideas and solutions

IDEATION

Sketches and Wireframes

Asset 24@2x-8
I usually start the development process with low-fidelity wireframes. This is the way I iterate through many design options quickly.

I used the same feedback from our card-sorting session to influence our navigation and journey mapping. The flagging system also affected our user journeys.

I used these sketches to present to our software manager, share ideas with our junior designer, frontend developer (sometimes), backend developer and our business analyst.

Drew sketches that helped with information architecture and primary user needs. Had about 4 sketches for the main journeys, these changes were made primarily because of the feedback I got from my co-workers and the time constraint to develop the suggested solution. 

These sketches helped a lot on placing of elements and navigation.

It was not my proudest moment but this is where I cut corners with my wireframes, I jumped into my UI of the design, I made sure all frames were covered before doing so.

4. Deliver Phase

Solutions that work

FINAL ui AND testing

Layouts and Prototyping

We could develop a prototype at this stage for testing and further ideating. As mentioned,  I decided to use the approved sketches as my “final” wireframes and started working on a UI prototype. 

Before handing over the prototype for development, I did a testing round in order to reveal possible usability problems. This was my first phase for testing.

The second phase was to test with developers again then show potential users and stakeholders what will the final product look like before developing.

These are 2 phases that were repeated the most on the design.

We then had a focus group consisting of a department IT Director, supervisor, 2X vehicle inspectors and 3 “typical” users was conducted as the 3rd phase. 

The third phase would be the final developed product that is ready for launch after the client’s approval.

The other reason for testing was to see if the design can be developed within a reasonable time frame.

Developers concluded that we do not have enough time to pull off a decent tracking device where the system can automatically track all vehicles if management is concerned about where the vehicle is being flagged by the tracking company for being in dangerous areas. We also couldn’t track when the vehicle went above-allocated kilometers, this required a centralized GPS system. We could, however, log the traveled kilos when the car gets booked and when it returned then compare it with the kilometers allocated for the vehicle upon booking. 

FINAL PRODUCT AND RELEASe

Implemetation + Testing

Handing over work to developers and monitoring if designs align with frontend development on staging. Documentation of the final prototype from the UI is also done at this stage. Sometimes it can be started if proper wireframes are available🙈.

This phase got tricky as backend required more time and but what we did was focus on the main elements that were needed by sticking to the skeleton requirements/brief. 

Fortunately, my UI design was not an issue since the journey mapping was also shared with developers for any issues that may arise when developer, issues like object oriented programming where some information is required before the next step is taken and goes against my current user journey.

AFTER THOUGHTS

Knowledge and Experience I've Attained...

Mentoring a junior full-time was very interesting, we both learned from each other a lot. I actually ended up relying on him a lot 🙂

My fear is not having something to present when I committed to that deadline, I would rather have a rough sketch with a smart concept than a cool-looking wireframe. 

I learned some new tricks on how to cut corners so we can have something to present at all times. 

I noticed something that I was not aware about myself through my manager, and that is I start slowly when things are unclear, which can be expected but I really don’t have an issue being comfortable in uncomfortable situations.

I have how to help my team put together a good brief/requirements with supporting data for our clients/stakeholders.

Thank you for all your hard work and going the extra mile on this one.
You bailed us out on this one.
We really needed something cool to retain our biggest client.

🧑🏽‍💻 More Case Studies

🧑🏽‍💻 More Case Studies

Scroll to Top