Amazon Monitron

Service Introduction

What is Amazon Monitron?

Amazon Monitron is an end-to-end system that uses machine learning to detect abnormal conditions in industrial equipment and enable predictive maintenance. Monitron sensors and gateways collect temperature and vibration data from assets and machines; the data transfers to the cloud, where Monitron's machine learning engine analyzes it to detect anomalies, and the results surface in the Monitron app. Enterprise customers can also obtain the measurement data to develop their own machine learning models.

Customer Problems

Most industrial asset maintenance is still reactive or preventive, resulting in high maintenance costs and long downtimes — and a critical issue with a single machine can cascade across an entire production line. Customers face multiple hurdles to implementing predictive maintenance on their own.

Target Users

Unlike traditional AWS services, Monitron targets people who work in industrial maintenance. They're experts in their machines — but usually less tech-savvy, with little exposure to technologies like IoT and machine learning. That single fact shaped product and design decisions throughout, as the process section shows.

Product Timeline

I joined the team in September 2019 as UX lead — a rare opportunity to work closely with leaders across product, engineering, science, research, and business and customer engagement to define and build the product from 0 to 1. After launch in December 2020, the team kept shipping new features and improvements driven by customer feedback, with UX collecting and consolidating user needs and turning them into action.

Role & Challenges

My Role & Team

Working on Monitron was like working in a fast-paced startup inside AWS. As UX lead I had broad ownership and autonomy to define and drive the design and research strategy, collaborating closely with people holding very different perspectives on the product. And the user experience wasn't just hardware and software — it was every touchpoint between users, the product and the service team: learning about the service, using it, getting help, giving feedback. Close cross-functional collaboration was essential to make that whole feel coherent.

Product Challenges

• A single underlying backend supporting front-ends across iOS, Android and web
• The AWS design system covered web only — no mobile support
• Non-traditional AWS users, without deep domain knowledge
• A complex system, with limited time and resources
• Complex integration across machine learning, IoT, data storage, data streaming and user authentication services

Collaboration Challenges

• Engineering teams distributed across the US, Germany and Japan
• Onboarding new team members — writer, front-end engineer and researcher — at different stages of the project
• Balancing UX workload between two brand-new services sharing the same launch date
• No existing business requirements or user stories

Challenges are also opportunities. Joining early meant learning the product from technology to business, inventing new processes and mechanisms to deliver results, and sharpening skills well beyond the designer's craft.

Design Process & Results

Product launches are just the beginning of another journey of continuous improvement. The process below connects research, user insights and iterative design to define and deliver Monitron — and to keep serving customers after launch.

Two examples show the process applied in practice: the overall planning of design and research activities, and the delivery of design solutions for two key experiences — service setup and asset monitoring.

Example 1: Overall Planning of Design & Research

To design for "non-traditional AWS users, without deep domain knowledge," I first had to build the foundation: collecting insights from numerous customer calls with product managers; planning and running several rounds of customer interviews and field visits with PM and research; learning from AWS IoT service teams' experience; and conducting online research and literature reviews — answering the who, what, when, where and how of our users.

From that background and the key insights, I worked with PMs and engineers to identify the MVP scope and translate it into a shared UX project plan — working backward from milestones like private beta and launch to estimate design and research needs per workstream. The planning exercise pushed the team to think strategically and surface dependencies early.

Example decisions in the define phase — each anchored in a user insight:

• Make Monitron its own app outside the AWS console — maintenance personas aren't familiar with AWS, and logging into a console full of unrelated services just to check their assets is overwhelming
• Prioritize the mobile app over web for launch — technicians treat laptops as workstations for detailed diagnostics, but prefer phones for responding to anomalies on the go and setting up devices; web matters more for deep analytics later
• Focus on the PoC phase of the adoption journey — industrial adoption can take years to go from proof-of-concept to scale; making PoC fast to set up and easy to evaluate shortens that timeline
• Invest most in the key workflows — service setup, device setup, monitoring and notifications: sensor work is slow and error-prone for less-experienced staff, and routine checks consume technicians' shifts — a shared, holistic view of asset status changes that
• Deprioritize what PoC doesn't need — user management (valuable but tangled in IdP integration dependencies), device end-of-life, and multi-site oversight, since managers expect reports from technicians rather than logging in daily

Planning was never one-and-done: the plan kept being refined as new insights arrived, holding the high-level goals and milestones steady while leaving room for each smaller project to flex.

Example 2-a: Service Setup

Goal: enable technicians and maintenance managers to quickly set up Monitron hardware and software and start predictive maintenance. That meant understanding why setup is critical, where the experience gaps are, who is responsible for which tasks, and which technical constraints apply.

Three key stages emerged, with one decision drawn straight from customer insight:

1. Set up project — by the IT manager, through the AWS console
2. Set up site — by maintenance managers through the app. Since PoCs rarely need more than one site, we create the first site by default at project creation, removing a whole step for the maintenance team
3. Set up devices — by managers or technicians, through the app

Multiple design directions explored how best to support the two different persona groups through their setup tasks.

Rounds of surveys, user interviews and customer calls refined the decisions across the experience — from project setup in the console to device setup in the app.

Example 2-b: Asset Monitoring

Goal: enable technicians to easily monitor asset status and act on it. This example focuses on the test-and-iterate phase — how design options narrowed to the final design, and the customer insights that decided it.

Explorations ranged across card views, table views, split views and combinations. Early customer learnings suggested a TV mode — projecting asset status onto a factory screen like other monitoring systems — but further study cut it: Monitron is about predictive maintenance, informing users of abnormalities, not passively displaying a wall of mostly-healthy assets.

I hosted rounds of design reviews with stakeholders to pressure-test the options against five criteria: easy to use for the key tasks; informative without overwhelming; flexible enough for planned future offerings; aligned with design-system guidance; and consistent with other AWS services. After narrowing through iterations and quick internal validation calls, I worked with our researcher on nine research sessions with internal and external participants to make the final call and inform future design.

Beyond the launch scope, design also led new initiatives — exploring future experiences with PM, science and engineering:

Keeping the Loop Running

The Listen–Define–Ideate–Refine–Test cycle doesn't stop at launch. With support from PM and other leaders, I worked with our researcher to launch a recurring quarterly user interview program — consolidating customer questions against product plans each quarter to shape the roadmap, from adoption barriers to what the web app should do next.

I also built a User Insights Database to consolidate, share and track everything we learned — insights synthesized and labeled by platform, user need, source, and experience epic. Once an insight is validated and design or engineering has capacity, the item flows straight into a sprint. Within the first three months, the team closed 13 items across the app and documentation directly from tracked user insights.

Accomplishments

By simplifying every step of the adoption journey from PoC to scale, and making IoT hardware work seamlessly with a powerful machine learning engine, Monitron earned strong customer feedback. 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.

Every challenge was an opportunity to improve and learn. Here's a summary of how the team overcame the challenges and successfully launched Amazon Monitron.

Key Learnings

Leading design end to end on a 0→1 product spanning hardware, software and service reshaped how I operate: the leverage isn't in producing more screens, it's in creating the conditions for good decisions across a distributed, cross-disciplinary organization.

Leadership

• Making the call with imperfect information — weighing risk and reversibility so ambiguity slows the team down as little as possible
• Treating problem identification as part of the role: surfacing issues no one owned yet, and taking the initiative to close them
• Earning stakeholder trust deliberately — reliable delivery and transparent communication are what buy design a real seat in scope and roadmap decisions
• Actively seeking feedback and investing in the growth of the people around me, so the team's capability compounds beyond my own output

UX Design

• Deciding under ambiguity and time pressure without letting the quality bar drift — and being explicit about which decisions are reversible
• Working fluently inside complex systems: understanding the architecture and its dependencies well enough to negotiate trade-offs with engineering credibly
• Spotting information gaps early and closing them before they hardened into design debt
• Using fast iteration and prototyping as a decision-making instrument for the whole team, not just a craft exercise
• Shipping a coherent experience across iOS, Android and web from a single backend — designing the behavior once, then expressing it per platform

UX Research

• Pairing foundational research with strategic bets, so insights shaped the roadmap rather than trailing it
• Building durable relationships with users that kept real-world signal flowing well past any single study
• Consolidating scattered insights into narratives stakeholders could act on — communication as the last mile of research
• Becoming a domain subject-matter expert in industrial maintenance, so design could lead conversations instead of following them