The Design Challenge of Anomaly Monitoring
Objects in the thermal experiment, fans, pipes, heat sinks, each carry multiple monitored metrics. The design challenge was organizing all of that so engineers could grasp the full picture at a glance.
Anomaly Triage
With multiple objects monitored at once, how do you help engineers spot an anomaly at a glance instead of scanning every value one by one.
Information Density
Each object has several metrics. How do you show them all on one screen without causing cognitive overload.
Version Switching
Handling an anomaly means switching the object's version and re-running the experiment. The interface needs to make clear which version was switched to and what changed.
The scenario:
Design a dashboard for a thermal simulation experiment that lets engineers quickly locate the problem object, switch its version, and re-run the experiment when something goes wrong.
Information Architecture
The first step was mapping out the relationships between data entities and sketching the data fields, as the foundation for the interface design that followed.
- An Experiment contains multiple Objects
- Each Object has multiple Metrics and multiple Versions
- When a metric exceeds its threshold, it automatically triggers an Alert
- The experiment's execution status is tracked separately as a Log
Layout Decisions
Once the information architecture was settled, the next step was putting those entities and fields on screen. I used a bento-box layout logic: the more important the information, the more space it gets and the more prominent its position.
In a thermal simulation scenario, the 3D heatmap naturally becomes the focal point. With that principle set, I evaluated a few options:
Option A: Heatmap, Key Metrics, and Object in Three Equal Blocks
The 3D heatmap sits on the left, key metrics in the center, and the object block on the right. The three sections map directly to three entities in the information architecture, which made it easy to understand.
But later design work showed the object block carried the most information. This option risked frequent switching between sections and lower efficiency, so I didn't go with it.
Option B: Heatmap and Key Metrics Merged, Object Block Enlarged (chosen)
Folding key metrics into the heatmap block on the left frees up space to enlarge the object block, which now holds the object list and detail together. No more frequent switching, and it's faster to review.
A monitoring interface should keep key information visible at the same time, cutting down on switching so engineers can judge faster.
Anomaly Display
I defined three severity levels for an object's state, normal, warning, and critical, so engineers can judge how urgently to respond.
The object list flags each object's alert status and alert count. The status light reflects the most severe state among all of that object's metrics, so engineers can see at a glance how many objects are in trouble. The list can also be sorted, bringing anomalous objects to the top quickly.
Inside an object's detail view, every monitored value is shown as a time-series chart with a threshold line, matching the need to continuously track how the data changes in a monitoring scenario. Engineers can expand the chart for a closer look when needed.
Handling Anomalies
After spotting an anomaly, the engineer switches the object's version and re-runs the experiment. If the anomaly is resolved, the experiment ends, if not, monitoring continues.
Version switching is handled through a modal, which lists each version's information and marks the version used in the previous run. Engineers can choose which version to apply, and after switching, the interface shows that a new run is needed to get results for the new version. They can also look back at the previous run's results.
Figma design file (opens in a new tab)
From Design to Development
Once the design was done, I extended it into a working Vue 3 prototype, both as frontend practice and to verify that this design logic could actually be implemented.
During implementation, I focused on architecture and logic, using AI assistance to speed up the actual coding. The architecture has four layers:
- Component layer: Vue 3 + Element Plus, components never touch the data layer directly
- State layer: managed with Pinia
- Service layer: simulates the backend API
- Data layer: pre-generated mock data
With the service layer kept independent, connecting to a real backend in the future only requires swapping out that one layer.
View interactive prototype (desktop only) (opens in a new tab)
Learning and Reflection
After finishing this design challenge, I put together a few design points worth revisiting in any monitoring scenario, not just this simulation monitoring case, as reminders for myself:
- Reduce cognitive load: with a large volume of information, use structure and layout to guide the eye and avoid clutter.
- Shorten decision time: keep the information needed to judge an anomaly within one view, cutting down on switching back and forth.
- Prevent accidental actions: mishandling a monitoring system is costly, so it needs the right safeguards.
- Consider where automation should sit: a deeper question. The more automated a monitoring system gets, the weaker a user's response to unexpected situations can become, and design needs to balance the two.