MS XIV Driver Display

MS XIV is the UW Midnight Sun Solar Car Team's 13th solar car, which will participate in the upcoming American Solar challenge and Formula Sun Grand Prix.

The driver display contains the instrument panel for the vehicle and will be displayed on an LED display mounted to the vehicle, which is visible to the driver at all times.


Team

  • Product Owner
  • 2 UX Designers
  • 1 Firmware Developer
  • 2 Front-End Developers


Contributions
I led the collection of research, design, testing and handoff of the interface.


Timeline
12 weeks


Tools
Figma

BACKGROUND

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.

Supporting Two Speed Metrics

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.

Displaying Explicit Errors

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.

Optimizing for Competition

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.


STAKEHOLDER OBJECTIVES

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.

PRIMARY RESEARCH

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...

  • Have a speedometer to display the speed
  • Revisit the importance of the battery level relative to all other elements
  • Revisit the choice of element to show the state of charge (i.e. is a bar the most appropriate)
  • Iterate upon the dial to declutter - will only show one unit at a time
  • Revisit the needle and its contrast against other elements inside the dial to make it more noticeable


BREAKNG DOWN FEATURES

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.



SECONDARY RESEARCH

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)



WIREFRAMES

Design A


Features

  • 260° arc sweep for speedometer where the path aligns with the min/max speedometer markings.
  • Cruise indicator is located below the speed.
  • Battery is sectioned to indicate specific intervals of charge.


Limitations

  • Needle appears to be floating - hiding the track it follows makes it difficult to determine the needle's position.
  • Drive state is too eye-catching - draws attention away from the recommended speed and dial sections.

Design B


Features

  • Full circle acts as a container, emphasizing the visual grouping of elements inside the speedometer.
  • Cruise indicator is between the turn signals, to be easier to see when the driver quickly glances down
  • Needle connects to a track that follows the dial outline, to emphasize the needle's position and the current speed


Limitations

  • Full circle speedometer takes up more real estate, causing nearby elements to appear cluttered
  • The needle's sweep is not a full 360° sweep - the full circle outline is more confusing since the outline serves as the track for the needle as well.

VISUAL DESIGN GUIDELINES

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.




HANDOFF

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.


FINAL SOLUTION

Below, you can find a short video that highlights some of the main features and the transitions between theri various states.

NEXT STEPS

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.

  1. smoke and unit testing of flutter app on 7" screen
  2. usability testing in rolling chassis (stationary vehicle)
  3. usability testing in slow moving vehicle in a parking lot (controlled enviornment)
  4. usability testing on race track to mimic the FSGP track race

By following this more extensive plan, we are able to put our drivers first while ensuring that any iterations are of value to the driver.

LEARNINGS

There's more than what meets the eye to designing a single screen
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 identify a need to do so and 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.

Did something pique your interest?

I'm always happy to chat more! Feel free to reach out to me through LinkedIn or email. I look forward to meeting you!