MOBILE / Chentronics Flame Sensor

Chentronics' first mobile product, designed for expert technicians

A guided flame-sensor diagnostic for field technicians, built in React Native and launched on iOS and Android.

Available now on the Apple App Store and Google Play, or download direct from Chentronics download at:

chentronics.com [ ↗ ]

Industrial IoT

Hardware Diagnostics

Real-Time Monitoring

Data Visualization

Mobile (iOS + Android)

Client / Chentronics & VividCloud

Client / Chentronics & VividCloud

Industry / Industrial Flame Sensor

Category / IoT Devices

Team / UX, Product, Engineering

Team / UX, Product, Engineering

Platform / Mobile

Platform / Mobile

Role / Lead UX Designer

Role / Lead UX Designer

Tools / Figma

Tools / Figma

Framework / React Native, .NET backend

Framework / .NET MAUI

Timeline / 6 months

Timeline / 3 months

1st

1st

1

1

1

2

2

iScan 3+

6 1

CHENTRONICS'

MOBILE PRODUCT

TEAMS

ALIGNED

IOS & ANDROID

REACT NATIVE CODEBASE

LIVE ON

APP STORE & GOOGLE PLAY

SHIPPED WITH

HARDWARE LAUNCH

THE CONSTRAINT

Chentronics was shipping its first mobile product, and the technicians who would use it had never held a tool like it. There was no app to study and no usage to observe. The only reference points were the hardware itself and the years of feel each technician brought to a burner front.


The stakes sat in the plant. For the power generation and petrochemical operations that run these scanners, an unmonitored fault means downtime, equipment damage, or a slow response, each one expensive. The job of the app was to put live flame status in a technician's pocket and ship on the same day as the iScan 3+ hardware.


Direct user access was closed. The project manager carried the field's voice as a proxy, relaying what slowed a diagnostic down. Every requirement traced to something heard at a plant, not assumed at a desk.

WHAT I DID

With no users to interview, the field reports became the spec. Standard gestures and safe-distance Bluetooth stayed as the baseline, since that was what technicians would arrive expecting. The diagnostic led with a guided read instead of a screen of raw values, because a Chentronics technician should not have to decode numbers the hardware already speaks.


Monitoring became the default and configuration a gated step, matching how the work actually happened. The result mapped the technician's first visit to a plant as a service, not a set of screens: sync the fleet, monitor by default, configure only when needed.

Forney HD Connect, the desktop tool technicians already trusted. This set the signal read iScan Live had to match before improving on anything.

The main read screen. The scanner's Ring of Light becomes a color-coded flame state on the phone, and TempProtect flags a scanner nearing its temperature limit before it trips.

The iScan 3+ scanner and its Ring of Light, the hardware cue the app brings to the phone.

The core read, built for the burner front. Flame state, signal detail, and device pick, sized to stay legible in glare and through gloves.

Fleet management. Scanners group by turbine and sort by connection state, so a technician sees what is live, what dropped, and what needs attention before walking the plant.

The working prototype, Bluetooth pairing through live monitoring.

OUTCOMES

A working mobile product, live in app stores, built to extend the trust technicians already had.

First mobile app for Chentronics

A hardware company's first move into mobile, live in the App Store and Google Play.

A guided flow where there was none

Diagnostics that ran on individual experience now follow a consistent, device-aware path.

Visual language extended to the phone

The Ring of Light technicians read on the hardware now reads the same way in their hand.

Foundation in place for desktop

A React Native front end that can extend toward a desktop tool without a rebuild.

What I'd do differently

Next time, the push is for direct access to technicians. On a first-of-its-kind product there was no existing behavior to observe, and the project manager carried the user's voice well enough to ship. Direct conversations with technicians would have validated the fault-state language faster than relaying it back and forth, and the next time access is closed like that, the move is to fight for a few hours on the floor.

COPYRIGHT © 2026 | Paul Wentzell UX