Case Study 04 / 05
Amazon Web Services AI / Machine Learning Predictive Maintenance 0→1 Launch

Amazon Lookout for Equipment

Amazon Lookout for Equipment is a machine learning service that enables industrial customers to build custom ML models to detect abnormal equipment behavior using their existing sensor data — with an automated machine learning workflow that requires no data science knowledge.

UX Lead · Solo Designer
Role
PM · Eng · Science · Business
Team
Dec 2019 — Apr 2021
Timeline
New product launched
Status
Amazon Lookout for Equipment console — detect abnormal equipment behavior by analyzing sensor data

Service Introduction

Case study contents — service introduction, my role and challenges, design process and results

What is Amazon Lookout for Equipment?

Customers store historical time-series sensor data and maintenance records in Amazon S3. Lookout for Equipment ingests that historical data, helps select features, automatically trains an ML model, and lets users evaluate performance and view explainability — then serves continuous scheduled inference on operational data for near-real-time insights through a customized inference API.

How it works — historical time-series sensor data and maintenance records in Amazon S3 feed Lookout for Equipment, which ingests data, selects features, trains an ML model and evaluates performance, then serves a customized scheduled inference API

Customer Problems

Building ML models for predictive maintenance is costly. Industrial companies are already streaming enormous volumes of sensor data into the cloud, but modeling equipment behavior and diagnosing issues from that data takes significant investment in time, resources and expertise — a hurdle for scaling across assets, as customers like Koch Ag and Energy Solutions told us. The service answers this with an automated machine learning workflow that requires no data science knowledge.

Today we are streaming thousands of sensors into AWS and want to leverage this data to help reduce maintenance and downtime for our operations. However, being able to model equipment behavior and diagnose issues from these sensors requires significant investment in time and resources, which has been a hurdle for scaling across our assets.Dave Kroening, IT Leader — Koch Ag and Energy Solutions

Target Users

The target users are developers with a basic understanding of machine learning: full-stack builders who are experts in cloud and operations, generalists in ML — hands-on "doers" whose goal is to build applications that use the latest AI/ML to solve specialized business problems. The design implications: give them resources to dive deep into how the AI solution works, tools to bend the service to their will, and easy ways to connect multiple services together.

Developer persona — a generalist in ML but expert in cloud and operations, a hands-on doer whose primary goal is building applications that use AI/ML to solve specialized business problems, with design implications and a responsibilities breakdown

Product Timeline

I joined in December 2019 as the sole UX designer, while also leading Amazon Monitron. The project kicked off in December 2019, reached initial design in March 2020, finalized launch scope in June 2020, and the service launched on December 1, 2020 — with UX work spanning user-needs definition, design iterations and testing, customer feedback collection, and implementation support throughout.

Product timeline — kick start December 2019, initial design March 2020, launch scope finalized June 2020, service launch December 1 2020, with UX workstreams for user needs, design iterations and testing, implementation support and customer feedback running across them

Role & Challenges

My Role & Team

As UX lead for design and research — and solo designer — I worked from defining the vision through MVP prioritization, customer PoCs, and post-launch improvements, collaborating with one product manager (who joined at the same time), a senior manager, a technical writer, engineers, data scientists, senior leadership, the design community, solution architects, and business development.

  • Conduct research to better understand users and collect feedback — 12 user interview sessions and numerous customer calls
  • Define product features & scope and plan the UX work — journey maps, user stories and workflow artifacts to support discussion; MVP scope, roadmap and timelines with PM and engineering leaders; UX design and research strategy; UX work trackers for cross-functional collaboration
  • Finalize design and follow up on implementation — 3 design sign-offs from the AWS UXDR review program for initial launch; filing and prioritizing front-end issues with engineering
  • Support business discussion and new initiatives — PoC experience with a third party for large customers, decks and presentations on the product journey and customer insights, early designs for new offerings explored through customer calls and solution architects
UX lead for design and research as solo designer, working across one product manager, a senior manager, a technical writer, engineers, data scientists, senior leadership, the design community, solution architects and business development Challenges, what I did and what we achieved as a team — collaboration mechanisms including a UX tracker across both services, weekly status emails, daily engineering stand-ups, PM:UX one-on-ones and sprint planning, and cross-time-zone front-end channels

Challenges

  • Complex system with limited time and resources
  • No existing business requirements or user stories
  • Engineering team with less front-end development experience working with the AWS design system
  • Onboarding new team members — front-end engineer and writer — through different stages of the project
  • Balancing UX workload between two brand-new services with the same launch date, as the solo owner for both
  • Limited access to external users before launch

Design Process & Results

The process ran as a continuous cycle with the user at the center — Listen, Define, Ideate, Refine, Test & Iterate — asking at each stage: who is the customer and what are their needs? What is the key problem and the most important experience to benefit them? What are the potential solutions? What technical constraints apply? And how do we measure success and improve? UX engaged across the full launch cycle: design, implementation, UX QA, launch, and back into collecting feedback.

Listening to the users about their needs and wants, pains and joys — a product launch is just the beginning of another journey.
Design process cycle with the user at the center — listen, define, ideate, refine, test and iterate, each stage framed by the question it answers UX engagement across product launch cycles — design (listen, define, ideate and refine, test and iterate), implement, UX QA and launch, each with its outputs, feeding back into the next cycle

Clarify the Workflows

I created high-level workflow diagrams to facilitate discussions with PM, engineering, and science teams, simplifying a sprawling end-to-end journey into five main workflows: create dataset/ingest data, create model, evaluate model performance, schedule inference, and view inference results & provide feedback — the last deprioritized for the initial AWS console scope.

Simplifying a sprawling end-to-end journey map into five main workflows — create dataset and ingest data, create model, evaluate model performance, schedule inference, and view inference results and provide feedback — each with its additional workflows

Prioritization & Launch Scope

User insights, business needs, and technical constraints together informed scope: prioritize what has high user value, low ease of access to an alternative solution, and low time & effort. Users told us the key value of Lookout for Equipment is reducing the need to develop and manage ML models, and that inference-results viewing is usually handled through integration with existing services. The business needed a strategic launch at re:Invent 2020 alongside the Industrial 4.0 and Anomaly Detection family of services — and to start collecting data early for more accurate models. Technically, data schema detection and in-console data cleaning would be high-effort. So data schema detection and quality statistics ranked highest among post-launch features, while inference-results viewing received the lowest priority given white-glove enterprise offerings.

Prioritization framework — a cube of user value, ease of access to an alternative solution, and time and effort, beside the intersection of user insights, business needs and technical constraints that informed launch scope The resulting launch scope across the five workflows — items in scope shown in bold and deprioritized items greyed out, with viewing inference results and providing feedback deferred entirely

I then dove deep into each workflow with PM, science, and engineering — clarifying user needs, engineering details and business needs per workflow, documenting comprehensive scenarios including validation, error and failure cases, and first-time-user onboarding. From there I established the overall framework and information architecture, and iterated on each workflow: from IA to each workflow, from key tasks to edge cases and error scenarios, from lo-fi to hi-fi. Validation combined testing with 10+ internal users using prototypes and joining customer calls through PM and business development — feeding terminology changes to align with users' mental models across UI and API design, prioritization adjustments, and consolidated feedback for engineering, documentation and marketing.

Workflow deep dives — clarifying user needs, engineering details and business needs per workflow, task flows covering validation, error and failure cases, and the architecture and dependencies behind the scenes Design iterations from IA to each workflow, key tasks to edge cases, lo-fi to hi-fi — beside the feedback collected from users, including terminology changes tracked for UI and API alignment and a consolidated improvements list

From Insights to Design

Design evaluation prioritized four intents: easy to understand (help users complete tasks easily), flexible (accommodate future changes and foreseeable needs), consistent (align with the design system across AWS services), and accurate (technically precise, to avoid confusion and set the right expectations). Applied to model performance evaluation, that meant: an executive summary of high-level metrics users can copy straight into reports (early confusion-matrix concepts tested as "too technical, too granular"); a chart view for quickly judging whether a model is good enough alongside a table view for deep-diving individual events; and event details with the appropriate level of diagnostic depth — top contributing sensors rather than raw data dumps that users said they'd hand off to maintenance teams anyway.

The four design intents used to evaluate every decision — easy to understand, flexible, consistent and accurate Final model performance design — an executive summary of high-level metrics, an interactive chart of abnormal equipment behavior events with a scrubber, and event details on selection; below, the early confusion-matrix concepts users rejected as too technical and too granular Supporting two levels of need — a chart view as the default for judging overall model performance at a glance, and a table view for deep-diving individual events with sorting and collapsible rows Event details diagnostics — top 15 contributing sensors by percent of importance, chosen over raw data distributions and time-series plots that users said they would hand to their maintenance teams anyway

What We Accomplished

The service previewed at re:Invent in December 2020 and reached General Availability in April 2021. I actively engaged with preview customers, conducted foundational research, and ran usability testing on prioritized features.

  • Successfully prioritized features and planned the product launch stages: private preview and general availability
  • Consolidated customer requests into a comprehensive collection of user pain points and needs shared across the team
  • 12 interview sessions with internal and external users; 11 research reports collected from other Amazon services and shared among AWS anomaly detection services
  • 4 AWS UXDR milestone reviews passed with high quality
  • One of the fastest-growing AI/ML services offered by AWS focusing on the industrial field
  • Thousands of models deployed across large industrial corporations, saving millions by preventing downtime
Customer and partner reactions — Michael Graves, Director of Strategic Alliances at OSIsoft, on Lookout for Equipment expanding the insights available through automated machine learning built for equipment monitoring, and Kang Bum Lee, EVP at GS EPS, on enabling plant operation teams to build models with no ML expertise required
The process of design is the process of overcoming challenges and solving problems.

Reflection — What I Learned

Owning two brand-new services to the same launch date, solo, is a forcing function: it teaches you to operate at the portfolio level — where the scarce resource isn't design time but decision quality, and where the mechanisms you set up matter more than any single deliverable.

Leadership

  • Balancing competing needs under time pressure by making prioritization explicit and visible, so trade-offs were made once — deliberately — rather than re-litigated in every meeting
  • Making informed decisions by weighing risks against outcomes, and being clear with the team about which bets we were taking and why
  • Building trust through reliable delivery, open communication and transparent sharing — the currency that let design influence scope, sequencing and API decisions beyond the UI
  • Actively seeking feedback on my own operating style, and treating every information gap as a signal to pursue another perspective before committing

UX Design & Research

  • Deciding amid ambiguity with the best available knowledge — then instrumenting the decision so evidence could correct it quickly
  • Using design artifacts — journey maps, workflows, scenarios — as the vehicle for defining user stories and requirements, turning design into the alignment mechanism for PM, science and engineering
  • Prototyping and iterating rapidly so user insight arrived while decisions were still cheap to change
  • Connecting directly with internal and external users, and pulling the broader org into that signal rather than keeping research a designer-only activity
  • Developing genuine subject-matter expertise in predictive maintenance and the industrial domain — the foundation for leading, not just supporting, product conversations
Further reading Predictive maintenance for line-of-business users
Previous case study

Amazon Monitron
Next case study

IMDb