UC Davis PHEV
Electric vehicle budget calculator
With the UC Davis Plug-In Hybrid Electric Vehicle Research Center (PHEV), I helped build a web application for users to explore their daily commute expenses with electric and hybrid vehicles and compare their results with different vehicles.
About the project
The Electric Vehicle Explorer is an application built for a consumer interested in purchasing an electric vehicle. The application pulls data about all vehicles and allows the user to compare operating costs of 4 different vehicles at a time. A user can map out their commute and provide inputs on their charging options to understand whether a vehicle will fit into their lifestyle and what the costs would be. An unreleased “trip” feature would allow the user to build various multi point trips to explore their options outside of their daily commute. They might use this for things within their regular routine or to consider whether an electric vehicle would allow them to take a road trip.
About the team
This project was part of a part-time role I held with the UC Davis Plug-in Hybrid Electric Vehicle Research center. My role was the designer and front-developer, and I worked closely with a back-end developer and a product manager.
About the work
When I joined this project, work was already underway and a basic layout to the application had been set. We had no real process in place, and really we just tackled different features as we went. My back-end counterpart would work through the implementation of a feature, and then I would work through the design, all in code. While I’ve noted what I would change about this project later, it’s important to keep in mind the ad-hoc method with which we were building it given that none of us had really worked on this sort of project before. It’s clear now how much our process would have benefitted from a more defined UX process outside of the code, and more time spent focused on usability.
Going back to the drawing board
One of my first steps after onboarding was to pull my team away from our laptops and in front of a white board to rethink the layout and the information we provided. We settled on this layout, which now included a bar at the bottom of the page to convey how much charge a user had used towards their car’s maximum.
Building out the user inputs
A major challenge of this project was working through the different input a user could provide and the information we were giving back to them. Given the large number of inputs we were asking for, we kept the information we were giving to what we considered “enough”. The screen above show the full amount of information a user received after giving us information about their trip.
The settings menu allows users to change gas and electricity price, though we set generic default based on live data we pulled. Throughout the project I tried to keep instructions as clear as possible, but there are many cases where steps could have been clearer.
The car manager allowed a user to change the cars they were comparing. The program starts with 4 cars already selected. Our original thought was that we wanted to get users to see some data as soon as possible, and then start to explore the settings and features. In retrospect, I think it would have been interested to test more of a “flow” onboarding experience that walks the user through some of the initial input we need.
Breaking out the steps
We had attempted this originally by starting with a “Home” screen that provide no information, and simply just asks the user for their home location. The benefit of this is that we limited the information we asked for to start. But this also made it awkward to later change the home location, because the user had to navigate back to this screen via the top menu.
Creating an introduction and help tool
We also created an “introduction” modal with slides on how to use the tool. Various parts of the tool included (?) icons that would open up a specific slide in this introduction and explain how to use that area.
What would I do differently?
Given that this was one of my first UX design projects, I’ve got a laundry list of things I would do differently. Most importantly, I would have forced myself to step away from the code more and work on sketching designs on paper or through mockups. I think this would have made a significant improvement to the quality of the work in the end because it would have forced me to think through layout and usability before I was deep in HTML and CSS. This also would have allowed me to try out multiple versions of a design and really way pro’s and con’s.
If the project had more resources, I also would have done more formal user testing than the ad-hoc testing I had done on my own. I think this project would have made a great candidate from remote, unmonitored usability testing. Our biggest concern was the amount of settings and options we were offering to the user, and that was the main reason the “Trip builder” screen didn’t make it in MVP. Unmoderated testing would have given us some low-cost, quick feedback on how well user’s could understand the information we were giving.
Overall, I think the main thing I would change would be to age myself 10 years and try this project again! There’s so much I’ve learned that I think could really make this an awesome and easy to use tool that can make a major impact on how we evaluate an electric vehicle purchase.
Explore other projects
Create a pattern library for an online software marketing platform to improve the quality of the product and reduce friction between designers and engineers.
Engineering training tools
Conduct interviews to gain a better understanding of how Google engineers use the internal resources available to them and redesign those tools to better fit their needs.