Electric Vehicle Suitability Assessment

Helping commercial vehicle fleets make the transition to electric vehicles.

Overview

The Challenge

Commercial and government vehicle fleets are looking to replace their conventional vehicles with electric vehicles (EVs) but are not sure whether this transition would help them save money, or if EVs would suit their current operations.

The Solution

As a vehicle telematics company, we set out to create the Electric Vehicle Suitability Assessment (EVSA) application, an easy-to-use tool to help fleet managers determine the viability of replacing their current fleet vehicles with EVs. This tool would ensure that we fully support our current customers on their electrification journey, and attract new customers who are looking to go electric.

My role

I led and worked on all aspects of the design of this new product, including design strategy and principles, interaction, UI design, and usability testing. I also collaborated with the product manager on defining and measuring success metrics.

Teamwork makes the dream work

As the first designer on the team, hired specifically for this new product, I initiated and worked with product management to design a framework for collaboration between product managers and designers, clearly showing phases, roles and responsibilities. This helped us work and support one another better.

Product management and design collaboration framework

Not all proposed solutions solve a problem

The product manager had also conducted solution validation interviews with customers, using functional wireframes to test out several solution ideas and concepts. The tests gave the team a better sense of what functionality resonated with customers and what functionality did not.

EVSA functional wireframes

Good design needs good anchors

Through the problem and solution validation research, the product manager had established that the problem was worth solving. I knew I needed to build on this to provide a more unified understanding of who we were solving the problem for, and set the direction for what a satisfactory solution could be like.

After listening to, and making notes from, hours and hours of interview recordings, I synthesized customer behavioural archetypes, an overarching user story, high level design requirements and design principles that would serve as anchors for the design solution going forward.

Behavioural Archetypes

These helped us better understand the motivations, needs and pains of the customers who would use this product. Our primary archetype (the efficiency-driven fleet manager) was considering going electric because they wanted to save money on vehicle operational cost and increase asset utilization. They needed to carry out an evaluation of EVs for the fleet but did not have the time or trustworthy data to do so.

Overarching user story

Leaning on the behavioural archetypes, I reframed the problem from a product to a user perspective and presented it in a format that everyone, especially our developers, could grasp easily.

Overarching design requirements

Taking it one level deeper, I documented requirements the product had to fulfil to successfully meet the needs and address the concerns of the user. This exercise was important as it laid the foundation for design choices and direction.

Design principles

With the benefit of the the overarching user story, design requirements and my understanding of the user and the problem, I drafted several design principles to anchor and guide design decisions throughout the design process.

Before the destination comes the journey

Using the design requirements and principles for direction, we arrived at a solution where the product would guide the user step-by-step (think of your favourite tax software) through the EV comparison and evaluation process. This approach, we believed, would make navigation easy and reduce the mental effort required to complete the process, ultimately helping users accomplish their goals faster.

The next logical thing for me to do then was map out the steps users would take within the product to compare their current fleet vehicles with EVs. This mapping surfaced gaps in our knowledge, as well as assumptions and questions we had failed to consider.

Augmented task flow

Augmenting the task flow with the thoughts and concerns of users helped ensure that I was continually keeping the focus on the user throughout the design process. For example, in the image below you can see how the user thoughts and concerns in the “Begin” column of the task flow influenced the UI design of the home screen of the application.

EVSA Home screen with user thoughts and concerns addressed

Going one step further in mapping the user journey, I broke down the steps into a realistic flow through the application, showing potential screens, input requirements and key design considerations. Mentally, this was beginning to provide some clarity on what the UI could look like: what input was required for each screen and what questions each screen needed to fully answer.

High level user flow

With the UI direction becoming clear, I needed to map out the navigation flow through the application. Doing this before proceeding to the visual design allowed me to be very intentional about how users went about completing their tasks from one screen to another. It allowed me consider how screens and tasks were to be ordered, where it made sense to allow users the flexibility to skip certain tasks, and what tasks and screens needed to always be one click away.

If it’s smooth sailing, you’re doing it wrong

The EVSA seemed like a relatively straightforward application to design, but as with all design problems, the devil is in the details. One of the biggest design challenges I faced was reducing complexity. How many steps is too many steps? Are there things we could do from the technical side to find out certain information (for example, the annual weather patterns at a user’s location) than requiring the user to enter every bit of information? Are we making sure that every step in the process is strictly necessary or are there some steps that do not impact the outcome the user is looking for?

Take for example, this portion of the user flow below that starts from when the first time user opens the application and ends at when the application receives the user’s location.

Receive user location flow V1

This was way too many screens and decisions the user and system had to go through just to get through the setup and reach a place where they can actually begin the comparison steps. Critiquing and reviewing with the team, it was clear that this was too much friction and did not meet the user’s need for speed.

Several iterations and refinements later (which involved combining or eliminating steps where it made sense) I was able to design a more streamlined flow, reducing the number of steps from eight to three.

Receive user location flow V4

Another challenge I faced was the potential trade off between brevity and clarity of content. For example, in the home screen images below, there’s a lot of text explaining how the EVSA works and other important information the user needed to know before they began.

EVSA Home screens V1

While this was anchored by our design principles around clarity and transparency, it also introduced unwanted friction in the process and did not meet the user’s need for speed. Could we successfully achieve clarity and be concise at the same time?

I took on this challenge and several iterations later, we arrived at a solution that was empirically better than the initial version.

EVSA Home screens V3

EVSA Home screens V5

Finding the optimal path

With the UI designs complete, I tested the application with 10 representative users. Although several issues were uncovered, the EVSA did better than I had expected, achieving a SUS score of 79.

Usability test plan

Usability test synthesis

Issue prioritization

A happy ending

After several months of iterative design and testing, we arrived at a solution that helped users achieve their goal of evaluating their current fleet vehicles with EVs to see which vehicles could potentially be replaced by EVs. I show some of the more important screens below.

How the EVSA works

Home screen where users begin their assessment

User selects telematics data period

User selects fleet and electric vehicles to evaluate

User enters cost information

EVSA analyzes input and provides summary results

Detailed vehicle-by-vehicle breakdown and recommendations

Documented exceptions and error conditions

Launch and beyond

UX metrics

Prior to launch, the product manager and I decided on and documented UX metrics (using Google’s HEART framework) that we would measure and monitor for product success. These metrics would help inform future iterations of the product.

UX metrics (Google HEART framework)

Launch outcome

The EVSA was launched, first in Europe and then in North America, to happy and satisfied users. It has gone on to do great things for our business, helping the company attract new customers, especially in Europe where commercial EV adoption is much higher.

We’re continuously iterating on the product to serve our users better.

Product feedback

Reach out if you want to create impactful experiences together.