RAMP / Remote Asset Management Platform

Making a five-system alert chain operable

I led RAMP's design from discovery through UAT and production, bringing a five-system alert chain into one workflow for reviewing equipment signals, recording findings, and creating maintenance notifications.

The RAMP alerts workspace, with risk summaries, the next alert to review, and the Prospector assistant alongside the queue.Open full-size image

My scope2024–26: Design lead for discovery, responsive workflows, UAT, and production review. Engineering owned implementation and system architecture.
Result: Alert handling reached production; RAMP 360 research extended the work into missing-alert diagnostics.

5 technical layers translated into one alert-handling workflow

Team and role details

Product and engineering partners, telemetry and alarm-logic specialists, SAP APM stakeholders, equipment subject-matter experts, and operations users. Engineering owned implementation and system architecture.

Contents

One alert, five systems

An equipment alert crosses telemetry, alarm logic, maintenance records, monitoring, and RAMP before someone can act. Each layer has different identifiers, states, and owners. The operator needs one accountable workflow instead of reconstructing that chain.

The discovery board below brings together the legacy interface, Grafana dashboards, and weekly review spreadsheet that fragmented the work.

The interface had to make a distributed technical process feel like one accountable workflow.

The discovery board, filed by evidence source: a screen-by-screen audit of the legacy interface, the Grafana dashboards, and the weekly review spreadsheet RAMP had to replace.Colleagues' avatars are blurred, as are the participant names on three session chips.Open full-size image

Researching a workflow no one person owned

No single specialist could explain the complete workflow. I combined interface audits with sessions across telemetry, alarm configuration, maintenance, and operations to map disagreements and handoffs.

Recurring jobs included refining thresholds, reducing false positives, validating telemetry, and tracking alert ownership. Those findings separated fleet, alerts, mobile equipment, fixed plant, approvals, and database management into distinct areas, while keeping status language and table behavior shared.

Designing the queue for action

The queue keeps workflow status and equipment severity independent. New or In Process describes the team's work; Warning or Error describes the signal. Counted, dismissible filters preserve context, while two-line cells pair machine codes and identifiers with readable names.

Live Stream, Pending, Closed, and an unavailable Errors state frame the queue over time. Unresolved names and missing links have explicit states. Notification creation and status handling moved into RAMP, while SAP APM remained the underlying maintenance system.

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

The RAMP alert queue feeding SAP APM. Workflow status and severity run as two independent pill systems, over counted dismissible filter chips and two-line cells pairing fault codes with plain descriptions.One row recording operator behavior on an identified vehicle is blurred.
Open full-size image

Making design traceable to delivery

The MVP design file mirrors the delivery backlog: epic and feature lanes contain responsive journeys at four widths, with eighty-six frames marked ready for development. Shared filters, tables, status tokens, and navigation keep the workflows consistent.

I led design from concept through UAT and production, resolving responsive behavior, edge cases, and review feedback. Engineering owned implementation and system architecture.

The RAMP MVP Figma file zoomed out. Sections map one to one onto Azure DevOps epics and features, 86 layers are marked ready for dev, and four breakpoints exist per screen.Open full-size image

When an alert never arrives

RAMP 360 explored where an eligible alert stopped: qualification, processing, downstream acceptance, or delivery to the interface. Operations needed a simple health summary; technical specialists needed identifiers, timestamps, failure points, and diagnostic history.

The research kept those views separate, with a route from summary to evidence. Authoritative counts, resolvable errors, ownership, and history retention remained open implementation questions.

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

A year of focus-group and stakeholder sessions covering alert traceability, access roles, and approval flows. The board also records the build-versus-buy decision on moving off Grafana.Colleagues' avatars and names are blurred, along with a block of internal spend commentary attributed to a named employee.Open full-size image

Delivery and the next measurement step

The alert-handling experience reached production after discovery and UAT. The evidence supports its workflows, states, and delivery structure; it does not establish reductions in response time, false positives, cost, or downtime.

My next measurement plan would track acknowledgment and resolution time, false-positive disposition, filter reuse, cross-system failures, and complete alert traces. Those measures would test whether the redesigned workflow improved operations.

◆Decisions

Move alert handling, notification creation, and status management into RAMP instead of keeping SAP APM as a required step in the operator workflow.
The tradeoff
RAMP had to model maintenance states and validation rules that previously belonged to another system. That increased product scope and created another integration surface to maintain.
The consequence
The user could review and act on an alert in one operating surface while SAP APM remained the underlying maintenance system. The dependency moved out of the interaction path rather than being described as eliminated.
Keep workflow status and equipment severity as two independent state systems in the alert queue.
The tradeoff
Every row carries more visual information, and two amber treatments can compete if hierarchy is weak. A single status pill would be quieter and easier to implement.
The consequence
A reviewer can distinguish what the machine reported from what the team has done without opening the row. Urgency and accountability remain separate, which prevents one from overwriting the other.
Give operations a simple delivery-health view and technical specialists a separate detailed trace instead of exposing the full diagnostic chain to everyone.
The tradeoff
Two levels require an escalation path, role-aware permissions, and agreement about when the summary is no longer enough. One universal diagnostics screen would have been cheaper to build.
The consequence
The RAMP 360 research defined a summary for operations and a detailed trace for specialists. Diagnostic ownership and authoritative counts remained open questions for implementation.

Complex workflowsObservabilityEnterprise productInformation architectureResponsive design