COGNITE · 2026 · DESIGN TASK

Helping engineers trust AI fault detection

Helping engineers trust AI fault detection

Helping engineers trust AI fault detection

36

36

commits

42

42

prototype builds

Overview

Engineers struggled to spot earlier abnormalities in their own data, and to trust that automatic detection would not miss new faults. I designed and built a working prototype where the AI detects and the engineer judges.

Role

Product designer

Product designer

Timeline

October 2026

October 2026

Responsibilities

Research, UX, AI interaction, prototype

Research, UX, AI interaction, prototype

Research, UX, AI interaction, prototype

01

The brief

The brief

Task: redesigning how humans & machines detect faults together

Machine learning algorithms can be better suited at monitoring & detecting abnormalities, while humans are (currently) better at recognizing which abnormalities are ok and which are not. Please watch this demo video and treat this as the “before” (manual) solution.

How would you go about redesigning this system for the LLM era? Please ideate and prototype a solution using AI prototyping tools.

Make reasonable assumptions where required. You can choose to focus on details of one part of the system, or a overall concept for the whole human-machine collaboration

OK behavior in the before tool: turbine speed drops while the wind drops too

OK behavior: lower turbine speed (black line) while low wind conditions (orange line) indicate normally functioning wind turbine

Unwanted behavior in the before tool: turbine speed drops suddenly while the wind stays steady

Unwanted behavior: sudden low turbine speed (black line) while steady wind conditions (orange line) indicate problem in wind turbine

Before: label a range by hand, train a model, then watch a status pill.

The current Cognite tool: label a selection as abnormal, train a model, watch a status pill
The current Cognite tool: label a selection as abnormal, train a model, watch a status pill

02

Eirik and the problem

Eirik and the problem

Typical user: engineer with significant technical knowledge (computer systems and industrial expertise) and abstract/analytical skills. Works in office environment, primarily at his desk but also significant meeting activity.

Imagine that the first round of informal user testing of this solution revealed that users struggled with 2 things:

  1. Identifying earlier abnormalities in their own data

  2. Trusting that the automatic fault detection would not miss any new faults

Typical user: an engineer on the phone at his desk in a control room, with monitors in front of him

03

My assumptions

My assumptions

The brief asked for reasonable assumptions. These three shaped every screen.

  • Noisy desk. Eirik already gets alerts from many channels and people, so the tool adds as little as possible.

  • Desktop only. He works at a desk on a laptop or monitor, 1280px and up.

  • Three verdicts. Fault, Investigate or Not an issue. No warning level: the detector only finds sharp events.

04

Key decisions

Key decisions

  • The AI detects, Eirik judges.

  • Rules, not retraining. Every correction becomes a rule he can read and undo.

  • Show what was checked. Cleared dips stay grey, so trust comes from coverage, not silence.

  • Quiet by default. Browsing never starts a chat, and alerts go only where he chooses.

Eirik logs his verdict and the issue bar locks
Logs, Learnings: the rules Eirik taught and the flags he rejected
A dip the AI checked and cleared stays on the graph in grey
A live curtailment: the AI checks the setpoint and stays quiet

05

Finding earlier abnormalities

Finding earlier abnormalities

Problem 1. Users struggled with identifying earlier abnormalities in their own data.

Answer. The AI flags a mechanical fault before SCADA alarms and explains it from the data. Eirik confirms it and shares the section.

06

Trusting nothing is missed

Trusting nothing is missed

Problem 2. Users struggled with trusting that the automatic fault detection would not miss any new faults.

Answer. When the AI misses a drop, Eirik labels it. The AI owns the miss, finds another like it, and takes his correction.

07

How I built it

How I built it

I built it with Claude Code in small, checked steps. Each card is a step on the way.

Previous card
Next card
Paper sketch: greeting, label and clear state, the graph and timeline, the turbine and the LLM box

01

Paper sketch first

The greeting, the graph, its timeline and an AI panel beside it.

An excerpt of CLAUDE.md: the Cognite design principles

02

Rules before prompts

Every decision lives in CLAUDE.md, read before each change.

Version 1: full screen

03

The brief, read literally

Version 1: an edge-to-edge graph with the AI in a column.

Version 2: two blocks

04

Two blocks

Version 2: the sketch’s layout, graph and AI side by side.

Reference: a Premiere-style timeline, 30 days in one strip with a draggable work-area bar

05

Researching for references

Adobe Premiere’s timeline shaped the 30-day strip under the graph.

The hidden turbine simulator with three researched field scenarios

06

Research changed it

Curtailment, a planned slowdown, became the false flag to learn.

The final build in light mode: Logs with a year of issue history

07

The Cognite brand

Three verdicts, quiet alerts, light and dark.

ITERATIONS

Previous iteration
Next iteration
Version 0 · First build

Version 0 · First build

The brief, read literally: a graph and a chat.

Version 1 · Full screen

Version 1 · Full screen

An edge-to-edge graph with the AI in a column.

Version 2 · Two blocks

Version 2 · Two blocks

The sketch’s layout: graph and AI side by side.

Version 3 · Teaching loop

Version 3 · Teaching loop

Every correction becomes something the AI learns.

Version 4 · Brand

Version 4 · Brand

Manrope, the Blue Fade, colour only for meaning.

Final

Final

Three verdicts, quiet alerts, a mechanical fault explained.

08

What’s real, what’s next

What’s real, what’s next

2

2

PROBLEMS, ANSWERED IN A WORKING PROTOTYPE

Real. The interaction, the rules Eirik teaches and the alerts.

Simulated. The turbine data and the AI’s replies.

Next.

  • Review the UX copy of each flow.

  • Test the training flow with customers.

  • See how engineers use the AI, and whether they need it.

  • Validate notifications, to learn what should be on by default.

  • Find what to remove. It still feels overwhelming to me.

Turbine Fault Watch: an emergency stop flagged on the graph, the AI explaining it from the data