Making a five-system alert chain operable

There was no single subject-matter expert who could explain the complete workflow. I worked across the people who owned telemetry, alarm configuration, maintenance records, monitoring, and day-to-day alert review, then mapped where their explanations agreed and where they did not.

Discovery combined a screen-by-screen audit of the legacy interface, Grafana dashboards, and the spreadsheet used for weekly review with focused sessions around the decisions each role had to make. The recurring jobs were configuring alarms, refining thresholds, reducing false positives, validating telemetry, and moving alerts through an accountable state model.

That research changed the information architecture. The product separated fleet, alerts, mobile equipment, fixed plant, approvals, and database management because those areas have different objects and permissions, even when they share the same status language and table patterns.

The alert queue separates workflow status from severity. New and In Process describe what the team has done. Warning and Error describe what the equipment signal means. Combining them into one color scale would make an urgent alert look complete or an ordinary alert look dangerous, so both systems remain visible in every row.

Live Stream, Pending, Closed, and an explicitly unavailable Errors state frame the queue over time. Counted, dismissible filter chips preserve the current query, while two-line cells pair a machine fault code with a plain description and an asset identifier with its resolved name. Missing links and unresolved names are designed states rather than data defects hidden from the layout.

Direct alert handling moved notification creation and status management into RAMP instead of requiring the user to leave for SAP APM. That reduced a tool dependency without pretending the underlying maintenance system had disappeared.

Severity describes the machine. Workflow status describes the team. The queue has to show both.

The MVP design file was organized as the delivery backlog. Epic and feature lanes map to responsive user journeys, and the same screen is specified at large, medium, small, and extra-small widths. Eighty-six frames were marked ready for development in the captured working file.

That structure made scope visible to engineering and kept fixed plant, mobile equipment, approvals, database management, and notification work from becoming separate visual systems. Shared table behavior, filters, status tokens, and navigation patterns could be reviewed once and applied across the product.

I led the product design from concept through UAT and into production. Engineering owned the implementation, while I worked through responsive behavior, edge cases, review feedback, and the interaction details required to make the operating workflow coherent.

RAMP 360 began with a question the original queue could not answer: if an eligible alert never appeared, where did it stop? A missing row could mean the signal was ineligible, the alarm logic did not run, a processor failed, a downstream system rejected the record, or the experience never received it.

The research split the answer into two levels. Operations needs a simple health view showing whether alerts were evaluated, processed, and delivered. Technical specialists need the detailed trace, identifiers, timestamps, failure point, and diagnostic history required to repair the chain.

Keeping those levels separate avoids turning an operations product into a log viewer while still giving specialists a route to evidence. The unresolved questions were as important as the proposed interface: which counts are authoritative, which errors are resolvable, who owns each failure, and how long diagnostic history should persist.

A missing alert is not one failure. It is a question about which system last knew the truth.

RAMP moved from discovery through UAT and into production with alert triage, mobile and fixed-plant workflows, approvals, database management, responsive specifications, and direct alert handling represented in the product and delivery file.

The public evidence supports the workflow, the designed states, the delivery structure, and the move away from SAP APM-dependent alert handling. It does not support a quantified reduction in response time, false positives, maintenance cost, or downtime.

If I returned to the product measurement plan, I would instrument time to acknowledge, time to resolve, false-positive disposition, filter reuse, cross-system failure rate, and the percentage of eligible alerts with a complete trace. Those measures would show whether the interface improved the operation rather than only reorganized it.