Electric Vehicle Suitability Assessment
End-to-end Product Design
Apr – Oct 2019
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.
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.
I led and worked on all aspects of the design of this new product, including design strategy and principles, interaction, visual design, and usability testing. I also collaborated with the product manager on defining and measuring success metrics.
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.
Prior to me joining the team, the product manager (let’s call him Sir H) had conducted customer discovery interviews to help the team better understand why vehicle fleets were looking to go electric, the barriers that made the transition difficult, and what the team might do to eliminate those barriers and help fleets achieve their goals.
Using insights from those interviews, he created a value proposition canvas showing the customer jobs-to-be-done, their pains and gains, and possible pain relievers and gain creators.
Sir H 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.
It was after this point that I joined the team.
Through the problem and solution validation research, Sir H 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.
Using the design requirements and principles for direction, we decided that the product would guide the user step-by-step (think of your favourite tax software) through the EV comparison and evaluation process. We hoped that this 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 assumptions and questions we had failed to consider.
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.
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.
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.
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.
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.
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.
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.
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.
Please scroll through the image gallery below to see some final UI screens.