Team
Contributions
I led the collection of research, design, testing and handoff of the interface. I also led weekly meetings with the cross-functional team throughout the design and development of the flutter app.
Timeline
12 weeks
Tools
Figma
Problem
MS XIV is a solar car that is designed and built entirely from scratch by undergraduate students at the University of Waterloo. The car is expected to traverse 3000 km in an endurance race in the American Solar Challenge in the USA, where
we will rotate between 2-3 drivers over the course of the race. The driver display is a critical element that will communicate the current state of the vehicle to the driver at all times and is expected
to serve as an aid rather than a disctraction for drivers behind the wheel for a couple to several hours in a single leg of the race.
How might we communicate the current state of the vehicle while minimizing the risks of distractions and cognitive overload for the driver?
Goal While we are competing in a race, it is also our team's belief that as an electric vehicle, we should showcase and design to accentuate the strengths that an electric vehicle has.
To present pertinent information at a glance without adversely affecting the driver's tasks at hand for both practical everyday use and competition.
The driver display's speedometer can alternate between mph and km/h, to cater to both
drivers of Canada and the USA.
While we are a Canadian team who will conduct testing in Canada and drive in km/h, the race
takes place in the USA, where our drivers will be driving in mph.
A maximum of 4 errors will be displayed at a time, which are shown as text abbreviations for easy recognition for debugging.
If more than 4 errors are triggered, the following overflow content behaviour in the accompanying mockup will be used.
With the goal of the ASC being to test the reliability and endurance of all solar car systems, we will be creating models to determine
the range of our vehicle as well as a recommended speed for a given leg of the route.
The recommended speed will change after a certain distance is travelled, and this change will be shown with a subtle visual indicator - a change in the colour of the ring.
Development The app should be low maintenance. It will be created in Flutter and we hope that our time can be put towards using the display for debugging, rather than debugging the screen itself.
Design
All elements should be easy to digest at a glance. An important principle of automotive HMI design is to ensure that the interface keeps distraction to a minimal so that the driver can focus on the road.
Also, important transitions between states should
have indicators that stimulate multiple senses.
The design should make use of both visual and audio indicators when components such as the turn signals and errors are triggered.
Understanding User Perspectives The driver display will be used by the drivers of MS XIV. We interviewed 2 previous drivers of MS XII, our previous vehicle, to better understand their experience driving in previous competitions and what information is most important for them to know when behind the wheel. We identified these key considerations:
💬
Do we have any electronically applied/implicit brakes? otherwise we cannot have parking mode and can only have neutral.
💬
Many inputs are push buttons and we will need to know when something is enabled/disabled.
💬
Speed is the most important and should be on the screen at all times, regardless of what state we're in.
Preference Testing with Early Iterations
We also conducted 5 preferance tests with preliminary iterations of the driver display. To simulate the driving environment,
we had asked our participants to position themselves arms-length from their laptop screen and to only glance down at the screen when responding to questions.
These 5 tests challenged and validated our hypotheses around the need for a speedometer to show speed, clarity of the charge icons and the battery bar, and the ease of navigating the screen at quick glances.
Design A
Design B
The major concerns raised during the preference tests that we will use to guide the design of the next iteration included:
🤔
I thought the battery bar was showing incoming energy. It's not clear what is means at first glance.
🤯
The dial is cluttered and it's hard to read the numbers amongst all those ticks.
🧐
I'd like to see everything in the dial in one unit. But I can see the need to have both.
In response to the feedback, we plan to...
Handling Feature Requests
During the user research interviews and preference tests, we noticed that some features and their various states had not been considered and so
we revisted this with the teams responsible for their implementation.
Unlike many other projects I have worked on, the experience of using the display did not rely on direct interactions that take you from one screen to another.
Rather, we are working with various states that are triggered via a mix of manual inputs such as push buttons and switches, and software errors.
The electrical teams had designed the controls and inputs for various features to be shown on the driver display. And to understand the indicators and their respective states that
needed to be considered, we created a variation of a state transition table.
a modified state transition table was created to outline all features that could be displayed on the driver display, their states and all events that may trigger them. This table will later play a key role in handoff to development.
Competitive Analysis
The following are some driver displays that we sought inspiration from to design our display. We have outlines general technical aspects,
special features, and takeaways that we may consider when designing our display.
Hyundai Ioniq
Volvo XC90 (2019 Early)
Design A
Features
Limitations
Design B
Features
Limitations
Style Guide
We created a style guide to ensure the visual design remained consistent and fairly simple - since all of these would be seen on one screen, we wanted to keep
the number of colours and text styles to a minimum while having enough to help emphasize visual hierarchy.
we also considered colour contrast when creating our colours. We ensured that any active text and symbols met the AA AODA colour contrast ratio requirement of 4.5:1.
Feature Breakdown Along with the state transition table, we put together a graphic to help better visualize the changes of states of the indicators. and the placement of each feature.
Below, you can find a short video that highlights some of the main features and the transitions between theri various states.
Developing and Designing in Parallel
The goal is to have the two front-end developers complete the front-end over the next 4 months. In parallel, we (the designers) will
be meeting with the electrical teams - hardware and firmware, to verify that we have included all the features and if they have any additional issues
with the design.
Additional Testing
Due to the dangerous environment the screen will be used in, we plan to follow a 4-stage plan to evaluate the clarity of features and how distracting the screen may be.
By following this more extensive plan, we are able to put the safety of our drivers first while ensuring that any iterations are of value to the driver.
Designing for a single screen is a different beast
This was my first time tackling a project where I was working on a single screen with numerous inputs, rather than mapping out flows and user journeys as they walk
through multiple screens. This project has taught me the importance of communication across multiple teams (hardware, firmware, strategy) to understand how various were implemented so we can design
them appropriately.
Don't be afraid to restart if you have the resources
Up until a couple of months ago, we were planning to stick with Design B that was shown earlier. However, after reviewing the preference test results on those iterations, we believed that there was lots of room for improvement and we had some members who were
interested in UI/UX design. And so we used this project as a learning opportunity as well as a chance to imporove the driver experience. I have learned the importance of prioritizing projects by considering team member development as well as impact on the overall project, MS XIV.
