Making sense of the signals

The challenge

When an engine reports a fault, identifying that something has happened is only the first step. Users also need to understand the urgency, see when the event occurred and get a clearer picture of what might require attention.

The challenge was to make diagnostics information easier to read and navigate over time. The experience needed to bring together full fault code readouts, warnings and alerts without overwhelming the user with information.

Since the feature is aimed at both dealers and end customers, it was important to find a solution that fit both user types while staying relevant to each group.

My role

I acted as the feature owner and product designer, taking the feature from early definition through design and development collaboration.

My responsibilities included:

• Defining the feature scope and identifying the information users needed.
• Aligning stakeholders around how diagnostic information should be presented.
• Establishing the visual hierarchy for different fault and alert states.
• Exploring ways to make historical information easier to scan.
• Designing the experience and its different data states.
• Collaborating with developers to clarify behaviour and support implementation.

Three key design decisions

1. Make history easier to scan

   Diagnostic information can become difficult to navigate over time, especially when users need to go through individual readouts to understand the effect.

   I explored heatmap overviews that let users scan historical data across months. Instead of presenting every event as a separate item, the visualisation gave users a clear overview of where readouts and fault activity had occurred.

2. Use visual distinctions to communicate meaning

   Not all diagnostic events have the same meaning and urgency. Treating every readout with the same sense of urgency would make it harder for users to understand what really mattered.

   Together with stakeholders, I established a visual system that uses colour and intensity to distinguish between the different states:

   • Grey represents days without readouts.
   • Blue intensity indicates the number of fault codes in a readout.
   • Orange and red represent severity states.
   • A red marker indicates that an alert was sent that day.

   The intention was to create a visual hierarchy that helped users scan and identify important events without having to dig into every item.

3. Distinguish missing data from a healthy readout

   There's a clear distinction between a healthy readout and a day without readouts.

   A day without a readout provides no real information about the engine's fault status. A readout with no active fault codes, however, confirms that the diagnostic information was received and that there are currently no active fault codes on the unit.

   I made deliberate design decisions in the UI to help users tell these apart. This way, we avoided misleading interpretations and made sure we communicated what was actually known about the engine.

Outcome

The result was a more structured way to explore diagnostic history and understand engine health over time.

The heatmap brought different diagnostic states together in one overview, using colour, intensity and markers to help users tell urgency, severity and healthy events apart.

What I learned

This project reinforced how important it is to consider the meaning behind data before deciding how to visualise it.

Two states can look similar at first glance but communicate very different things. Making those distinctions clear is essential, particularly when users rely on the information to understand technical issues.

I also learned that a good overview shouldn't try to tell the whole story. It should help users recognise where something happened, understand why it matters and know where to look next.