SCADA Dashboard — Diana Kuzachenko
← All cases

Industrial B2B SCADA Dashboard UX

SCADA dashboard for equipment monitoring

Dense boards became more responsive with 30+ widgets; support questions dropped — drag-and-drop, charts, and safe editing for engineers and operators.

Channel monitoring mockup: MAIN / BACKUP status across nine streams

Situation

Engineers and operators worked daily with SCADA-oriented dashboards: building boards, reading charts, switching between objects and tracking equipment state.

The product worked, but daily flows were fragile — overloaded setup, drag dead ends, weak chart interaction, and changes that could be lost on switch. My task was to strengthen dashboard UX without exposing NDA data or rebuilding the technical foundation.

Task

Not “bad visuals” but operational failures in daily work:

Complex widget setupMany fields, weak grouping, no preview before add — users errored and reworked setup.
Dashboard state resetScale and position were lost when switching boards — operators had to re-orient each time.
Weak chart interactionHard to zoom a region, read an exact value, or change period quickly.
«Тупики» при перетаскиванииDense boards required empty zones and workarounds — wasted time on placement.
Risk of losing changesLeaving the page or co-editing without clear feedback — edits could be lost.

Action

Mapped scenarios with product, support, and engineering; defined a UX quality bar; designed drag, chart, and feedback patterns; delivered prototypes and specs through handoff and design QA to production.

  1. Mapped scenarios with product, support, and engineering — where users lose time, which questions repeat, which states are critical for monitoring.
  2. Defined a UX quality bar for mission-critical dashboards: predictable editing, explicit feedback, safe saves, chart interaction for analysis.
  3. Designed key patterns: drag-and-drop, widget preview, chart zoom, state memory, unsaved guard, editor presence.
  4. Delivered prototypes, UI states, and specs; ran handoff, design QA, and iterations through production release.

Key trade-offs

  • Rebuilding the grid/canvas fully was risky for timeline and release stability — improvements had to extend the existing model.
  • Priority was removing daily friction — state loss, unclear feedback, setup errors, drag dead ends — not an “ideal” builder.
  • Part of the work shipped as release-ready MVP; part was scoped for later iterations.

Expanded widget catalog

Added five new widget types for the dashboard builder — chart, metric, label, shape, and table — with setup, preview, and placement rules. Reworked device widgets: clearer configuration, states, and readability on dense operational boards.

Перетаскивание без «тупиков»

Drag over dashboard, dynamic placement, ghost preview, blue insertion hint, saved state after drop.

Drag-and-drop: suggested position → preview → saved state

Charts for analysis

Zoom and pan, X/Y tooltips, quick periods, custom range, fullscreen card.

Metrics and charts mockup: temperature, fan speed, voltage — week, day, month, and 3-hour ranges

Feedback and safe editing

Tooltips, toasts, unsaved guard, and editor presence — with clear rules for when to show each message.

Feedback types: tooltip / toast / guard / editor presence
Widget setup with preview before add to the board
As-is experience process map: detection → repair → recovery across system, operator, and engineer

Result

At 30+ widgets per board, drag stayed responsive on dense layouts; recurring support tickets on save, widgets, and drag dropped after release (not dev handoff); charts fit operational analysis; feedback and co-editing were no longer a black box. Released to production.

30+Widgets stress-tested

Power-user scenario the drag mechanic was designed for.

5New widget types

Chart, metric, label, shape, and table — plus reworked device widgets.

4Feedback patterns

Tooltips, toasts, leave warning, editor presence.

3Support ticket themes

Save, widgets, drag — recurring post-release support tickets dropped (not dev handoff).

NDA

Case uses anonymized mock data and recreated UI fragments — no client or production identifiers. Selected dashboards and process maps are shown on this page.

First case Get in touch