Enhancing Data Visualization Dashboards with Threshold Mapping

My key responsibilities

Jobs-to-be-done scenarios

Information architecture

Wireframing + prototyping

The team

Lead UI/UX Designer, Jacky James

UI/UX Design Intern, Aidan Myers

Software Developer, Sasa Schwartz

Timeline

About 3 months

Background

Intelligent Assets is a no code industrial IoT application that supports monitoring connected assets with a wide range of use cases, from regulating microclimate environments to detecting anomalies in sensor data streams.

Problem

In dashboard visualizations, users struggle to distinguish when key performance metrics fall outside defined thresholds. The lack of visual cues for normal vs. abnormal values impedes rapid data interpretation and anomaly detection.

Solution

To help users quickly identify when metrics are out of range, we introduced value threshold mapping, settings that enable users to set custom, meaningful ranges and style them with colors or icons so spikes or drops are immediately visible without needing to dig into the data.

Prototype

“When I’m monitoring the performance of thermal regulation water pumps, I want to set and visualize RPM thresholds directly in the line graph, so I can easily spot when pump behavior crosses critical limits and take immediate action to prevent overheating or system degradation.”

“When I’m monitoring the key metrics of thermal regulation pumps in a dashboard, I want to set and visualize when a pump is in a critical status with a color and icon, so I can immediately identify when pumps require action to maintain up-to-date reporting and analysis.”

User can select any metric from the query of the widget visualization.

Select from unique display modes per visualization type that best fit their use cases.

If the selected metrics have numerical outputs, the user will define thresholds by entering number values to map to a color.

If the selected metrics have string outputs, the user can select from a list of the defined values to map to colors and icons.

Hand off

To ensure a smooth handoff, I first reviewed previous feature hand offs with our development team to identify what had worked well. I met with the developer that would be working on the feature early on to understand their questions and pain points for hand off and identify any gaps. From our sync, I prepared a structured ticket in Jira and Confluence that included:

• Interactive prototype to demonstrate the UI and behavior.
• Zeplin file with finalized screens, design specs, spacing, and functional annotations.
• Comprehensive documentation that included all charts, their visualization settings and appearance, list of reusable components and variants, table of all UX copy, and a defined list of accessible preset color pairs for light and dark modes.

Once reviewed and approved by my design lead, I let the developer know it was ready to be worked on.✨

What I’d do differently…

1. Spent more time defining the problem since, over the course of this feature, recognizing the qualities that informed the UI flows: which chart type has which settings, which settings were for each data type, was difficult to wrap my head around. Working too quickly before understanding the pattern of user needs across so many chart types led to a lot of re-work of UI designs, and I would have focused more attention on defining those things more thoroughly before starting working on wireframes and have saved more time in the long run.
2. Asked for feedback earlier and before it felt “ready”, in order catch potential issues earlier in the process, validate my approach and that the UI was going to meet the needs for our user, and I would have improved my own individual design process by learning from the perspective of my design lead.
3. Been quicker to ask questions with the UX design and development team about design approach and feasibility and also getting earlier feedback on my concept ideas more often, I think I could have designed quicker with less mistakes and saved a lot of time.