Amazon Monitron

Overview

Most industrial maintenance is still reactive or preventive — costly, slow to recover from, and one failing machine can cascade across a production line. Monitron brings predictive maintenance to the people who need it most: maintenance teams who are experts in their machines but new to IoT and machine learning.

I joined in September 2019 as UX lead and helped build the product from 0 to 1 — working like a startup inside AWS, with broad ownership of the design and research strategy across product, engineering, science, research and business teams distributed over three countries. The experience spanned hardware, software and every service touchpoint in between, launching in December 2020.

An End-to-End System, Not an App

Monitron is a complete condition-monitoring system rather than a piece of software: adhesive-mounted sensors capture vibration and temperature from a machine, a gateway on the factory wall carries that data to the AWS Cloud, and the service compares it against ISO 20816 vibration standards and its own machine learning models to flag developing faults. Designing it meant designing every touchpoint — the physical act of mounting a sensor, the commissioning flow, and the software that has to make an ML judgment trustworthy to someone who has never worked with ML.

The information architecture had to match how factories actually organize themselves: a project holds sites, sites hold assets — bearings, motors, gearboxes, pumps — and each asset has up to twenty positions, one per sensor. Commissioning a sensor is a tap of the phone against it over NFC, which is why the mobile app owns setup and the web app owns everything else.

Machine state is expressed as one glanceable status per asset — healthy, warning, alarm, or in maintenance once someone acknowledges it — so a technician walking a floor can triage without reading a chart. The charts are there when they need to go deeper, with ISO alarm and warning thresholds drawn directly onto the vibration plot so a reading is interpretable without knowing the standard by heart.

Because a model that cries wolf gets ignored, technicians can tell the service when it got an alert wrong — recording failure mode, cause and the action taken — and that feedback trains the model. Closing that loop in the interface was as much a trust problem as a usability one.

Highlights

• Built the research foundation for non-traditional AWS users — customer calls, interviews, field visits and literature reviews — then translated it into a milestone-driven UX project plan the whole team executed against
• Anchored every define-phase decision in a user insight: a standalone app instead of the AWS console, mobile-first for technicians on the go, and a deliberate focus on making proof-of-concept fast to set up and easy to evaluate
• Designed the key experiences end to end — a three-stage service setup (with the first site auto-created to remove a whole step) and asset monitoring, narrowed through stakeholder reviews and nine research sessions
• Kept the loop running after launch: a quarterly user interview program and a User Insights Database that turned tracked insights into sprint work — closing 13 items in its first three months
• Shipped one coherent experience across iOS, Android and web from a single backend

Impact

Customers including GE Gas Power, Fender, RS Components, and Amazon Fulfillment Centers across the EU and US deployed tens of thousands of Monitron sensors — saving millions by discovering anomalies early and minimizing unplanned downtimes. The full case study walks through the planning, the insight-by-insight decisions, and the setup and monitoring design work with final designs.