So, what's the problem anyway?

In 2024, Ford Motor Company spent roughly $46M on battery related issues, that the assumption is to build an early detection tool to discover fleet and vehicle level issues with 12V Battery State of Charge (SOC). Democratizing the vehicle data enables systems engineers to hypothesize, quickly triage, and coordinate accordingly to root cause and release a corrective action to the vehicles.

With the current Key Off Load (KOL) metric confusing and not backed by data, we needed to develop a new KOL metric based in data, that provided better clarity and abberation control.

  • Existing metric: “No more than 1% of Ford and 1.5% of Lincoln key off cycles can have an SOC drop of greater than 8%.”

  • New metric: Specific average current targets for each of 7 time periods, based on known vehicle shutdown patterns.

How we got there

We first defined time buckets and the factors that affect the key off behavior of a vehicle based on time since key off.

0 to 6 mins:

  • Customer interaction with vehicle

  • Delayed features and accessories

6 to 12 mins:

  • BCM 10 min timers and vehicle goes back to sleep

  • Customer interaction with vehicle

  • Delayed features and accessories

12 to 30 mins:

  • BCM 10 min timers and vehicle goes back to sleep

  • ECG and TCU shutdown

  • Customer interaction with vehicle

  • Delayed features and accessories

30 to 60 mins:

  • CAN activity

  • Local awake modules

  • Things plugged into Power Points

60 to 90 mins:

  • CAN wake ups

  • Local awake modules

  • Things plugged into Power Points

Duration 8 weeks

Role Product Designer

Team Product Owner, Product Manager, Product Designer, 3 Software Engineers, 2 Data Scientists

Tools Figma, Miro

90 mins to 3 hours:

  • CAN activity

  • Local awake modules

  • Stop mode

3 hours to key-on or hibernation:

  • CAN activity

  • Local awake modules

My data scientists analyzed the data from vehicle KOL tests to identify trends and patterns and settled on the average current during each time interval as a target metric. They then wrote a Python script that aggregated the vehicle KOL tests and calculated the average current and standard deviation for each time interval to develop a final score.

Bringing it to life

From here, we developed a dashboard experience that aggregates all the vehicle KOL data in a week and assign it one score. A score of 1 or lower passes. A score of greater than 1 requires further attention.

Things didn’t go right

To measure success beyond just usage numbers, here's what I'd do differently next time —

  • Design more graceful degradation when sensors or data feeds fail

  • Make dashboards simpler with clear warnings

  • Show what battery readings actually mean

  • Add predictions about future battery performance

  • Test more thoroughly in real-world conditions

  • Involve actual battery engineers earlier in the design process