Background

While at IBM, I worked with Watson Internet of Things (IoT) as a UX designer alongside a UI designer, developer, researcher and business analyst. The tools I used were paper prototypes for lo-fi and Sketch for mid-fi.

Opportunity

Factories are full of aging machines. If these assets fail, results can be disastrous:

"If we lose a batch, it's a quarter of a million dollars, so we try not to mess up." - Manufacturing participant

“If [machine failure] clogs up assembly line, you can lose up to $100K / hour, easily.” - Stakeholder

Senior-level machine engineers have the expertise to fix these older assets but are retiring, and incoming engineers are not as familiar with older machines. Identifying opportunity, our stakeholders realized that Watson could diagnose and offer solutions for broken machines through monitoring audio. Irregular audio would indicate the machine needs to be examined.

Refining the Ask

Background Research

To better understand the ask, our design team interviewed subject matter experts, visited a local manufacturing factory, and read various articles. This research led to a variety of insights that ultimately pivoted our direction and heavily informed our design decisions.

Insight 1) Audio analytics alone isn’t sufficient

Originally, our stakeholders focused on audio to diagnose machine problems and directed our design team to create a solution that assumes sound is already captured. However, through our design team’s research we discovered that machines are already broken by the time they produce audible irregularities. Technologies such as ultrasound and vibrations are more predictive of upcoming failure.

Our goal became to address problems earlier to prevent machine failure and monetary loss, so we focused on a design solution that could work regardless of the technology used to detect the irregularity.

Insight 2) Watson must be trained without disrupting workflow

Because Watson is an AI tool, it must be trained to associate certain triggers with potential solutions. This training would be done by users on the manufacturing floor, which would help preserve local veteran engineer knowledge. However, witnessing the chaos of Toyota’s floor firsthand highlighted to us the significance of training Watson without disrupting workflow.

We decided to create a tool that could provide value to manufacturing spaces while training Watson in the background without workflow disruption. From our research, we discovered that manufacturing facilities regularly use asset management systems with complicated UX. If we could improve this experience with our own IBM asset management system, floors could inherently find value in our product. Therefore, incorporating Watson’s training in the background of our asset management system would compound our design’s value.

After discussing these findings with our stakeholders, our opportunity statement became:

How can maintenance engineers be utilized in machine learning to develop a prescriptive maintenance system?

Design Process

After refining our project direction, we developed personas to better categorize our users’ roles on the manufacturing floor and to help explain our design solution through story telling.

I also led an ideation workshop in which design team members individually drew their interpretations of our project goal. These metaphors visually aligned our team and contributed to our design solution. In addition, I showed the design team how to make rapid interactive paper prototypes so that we could quickly receive feedback and iterate.

Pain Points

Based on our extensive research, we created a timeline that tells a realistic story of maintenance in a factory, from discovery of an issue to resolution.

Heidi, the line worker, detects an anomaly within a machine and creates a work order. Her manager Lester assigns Chuck, a maintenance engineer, to address the problem. Since Heidi doesn’t have deep knowledge of the machine she operates, she cannot properly report the severity of the issue. Chuck comes ill-prepared to fix the machine and must return with different tools. Lester needs to reschedule, and the plant loses valuable time.

Design Solution

Alleviating User Pain Points

To address user needs, our design needed to:

• Alleviate Heidi’s (the lineworker) stress by automating fault detection and work orders.

• Provide Chuck (the maintenance engineer) with suggested diagnosis and solutions when machine failure arises so that he can better prepare with the necessary tools.

• Monitor all machines’ potential problems, enabling Lester (the reliability engineer) to take preventative action against machine failure and prioritize maintenance.

There are 2 phases to our solution:

Phase 1: Untrained Watson

• Watson detects a machine abnormality and reports the work order instead of Heidi, preventing floor disruption.

• Lester evaluates the asset and assigns Chuck to the work order, who fixes and updates the work order with his solution.

This interaction trains Watson to recommend this solution in the future.

Our design team learned from our interviews that most floor managers utilize tablets, so we focused on this medium.

Phase 2: Trained Watson

After preliminary training, Watson sends Lester work orders that include potential problems and solutions with a measured percentage of confidence. This approach enables maintenance engineers to come prepared with the right tools and saves time, money, and stress within the factory. Once Chuck fixes the machine, he verifies Watson’s suggestions within the asset management system to complete the work order.

The updated phase 2 designs are below:

Product Stages

There are 3 stages we imagined for our product.

Stage 1 (cupcake):

The minimal viable product was to integrate Watson machine learning with an asset management system. We would gather asset information through audio only.

Stage 2 (birthday cake):

Next, we envisioned a multi-variant prescriptive maintenance; we would rely on more than sound analytics to predict machine fault.

Stage 3 (wedding cake):

Finally, we would automate prioritization of work orders based on the multi-variant machine learning.

Measuring Success

I would have preferred to spend more time design testing with users in lo- and mid- fidelity before transitioning to high-fi. However, our team was intended as a concentrated 2-month timeline to jumpstart Watson IoT progress.

The ultimate sign of success for our team was that our stakeholders were convinced to continue funding the project. They set up a permanent team to continue our progress after our 2-month timeline, showing commitment to testing and developing our solution. Our design also served as a framework for the eventual design which was presented in major tech conferences such as CES.