Ambetronics Flame Sensor App

Ambetronics, a manufacturer of robust flame scanners and gas detection solutions, set out to launch a mobile app to support their upcoming wireless flame scanners, moving beyond the outdated desktop workflows.

This is the story of how I designed that mobile experience as the sole UX/UI Designer on the team, collaborating closely with subject matter experts.

Figure 1: Selected concept screens showing the proposed mobile-first direction.

At a Glance

Sector: Industrial Diagnostics / Connected Hardware
Challenge: Field diagnostics relied on desktop tools, slowing technicians down on-site.
My Role: Led end-to-end UX/UI, working with subject matter expert and a remote development team.
Timeline: 2 months, from research to handoff.

Design a Mobile-First Experience

The goal was to design a mobile-first, user-friendly application that meets current needs while scaling seamlessly to support desktop use, with a focus on creating a foundation to support future devices and technician workflows.

Our high level goals were to:

Empower service technicians with real-time sensor diagnostics in the field.
Create a scalable mobile-first foundation for future product growth.
Ensure compatibility with both current and upcoming devices.

My Role

As the sole UX/UI designer, I mapped technician workflows, benchmarked competitor apps, and integrated regulatory requirements to design scalable solutions for current and future devices.

I partnered with subject matter expert, product owner, and developers to ensure alignment across the project.

Focusing on Goals

We framed the project around technician goals rather than features.

The initial brief emphasized surpassing competitors in functionality, but early domain research and workflow walkthroughs showed that feature parity was not the right measure of success.

In field use, technicians needed clarity around device status, signal behavior, alerts, and historical context without piecing information together across separate tools and documents.

This helped me align the project around technician workflow instead of feature count. From that point, design decisions were evaluated by whether they made field diagnosis clearer, faster, or easier to act on.

Understanding the Domain

Before moving deeper into workflow and interface design, I spent time building a working understanding of the burner flame-scanner ecosystem.

So I began with broad desk research to understand the domain at a high level. By reviewing Google Search results, technical articles, explainer videos, and regulatory documents, I built initial familiarity with burner management systems, flame monitoring systems, scanner technologies, optical detection, communication patterns, and safety standards.

This phase helped me establish a baseline understanding of the space, identify recurring concepts, and collect the documents most relevant to our use case.

**Figure 3:** Broad desk research used to map the flame-scanner ecosystem.

AI-Assisted Document Research

Once the source material was gathered, I uploaded the relevant documents into a retrieval-augmented workflow (RAG), which let me ask focused questions against the material instead of reading every document end to end.

This helped me connect concepts across sources, clarify terminology, compare system behaviors and build a broader understanding of the domain at a much faster pace, without needing technician-level expertise.

Tools used: Notebook LM and a custom n8n pipeline.

**Figure 4:** AI-assisted document review used to query technical & regulatory sources.

By the end of this stage, I had a clearer sense of what to investigate next:

What sensing technology this device uses, how it communicates, whether an existing desktop interface already exists, what information technicians rely on, how they actually operate and monitor these devices, and how competitors structure similar workflows.

**Figure 6:** Four research tracks that shaped the next phase of discovery.

Device Familiarization

After the domain research, I studied the device ecosystem more closely.

This included reviewing product documentation, scanner behavior, hardware indicators, wiring diagrams, LED logic, sensor readings, and API documentation to understand what the flame scanners measured, how they reported status, and what information technicians needed during diagnostics.

This helped me connect the physical device behavior to the interface: status lights, signal readings, connection states, alerts, and historical data all had to be represented clearly in the mobile experience.

**Figure 7:** Product diagrams and hardware references used to understand scanner structure, wiring, indicators, and installation context.

**Figure 8:** System diagram showing how flame scanners, gas transmitters, gateway hardware, cloud dashboard, and alerts connect across hazardous and safe zones.

**Figure 9:** Device photos and API documentation reviewed to understand physical status indicators, running status, and data returned by the system.

Desktop Application Design Audit

After understanding the device, I audited the existing desktop application interface using two lenses: heuristic evaluation and visual design principles.

The review focused on system status, navigation, terminology, data density, visibility of key readings, error handling, consistency, and how easily a technician could understand what needed attention.

The audit showed that the desktop tool contained useful diagnostic information, but the interface was not built for field use. Key data was spread across dense tables, small controls, and inconsistent visual states.

This gave me a clearer baseline for what the mobile app needed to simplify, prioritize, and make easier to scan.

**Figure 10:** Existing desktop application workflow mapped to understand navigation, setup steps, data views, and technician actions.

**Figure 11:** Desktop application audit identifying usability issues, visual design gaps, and recommendations for mobile translation.

Workflow Walkthrough

To understand how diagnostics happened in practice, I walked through the existing desktop workflow with the subject matter expert.

The walkthrough helped me see how technicians moved between the desktop tool, spreadsheet logs, test setup screens, alarm settings, reports, and manual documentation. It also showed where the workflow depended on memory, repeated checks, and switching between formats.

**Figure 12:** Remote walkthrough with the subject matter expert, reviewing how desktop software and spreadsheet logs were used during field diagnostics.

**Figure 13:** Technical and workflow references used to understand burner operation, scanner positioning, inspection flow, and alarm configuration logic.

**Figure 14:** Workflow walkthrough mapped across field-test stages, pain points, channels, and design opportunities.

Document & Artifact Analysis

Alongside the desktop walkthrough, I reviewed supporting artifacts used around the diagnostic process.

This included calibration certificates, field reports, burner operation diagrams, scanner sighting references, inspection flows, and alarm-setting logic. These documents helped clarify what technicians needed to confirm, record, and communicate before, during, and after a test.

The artifacts also showed that the mobile app needed to support more than live readings. It needed to account for setup, validation, historical evidence, report handoff, and the way technicians explain results after the field visit.

**Figure 15:** Calibration and inspection documents reviewed to understand reporting requirements and technician handoff material.

**Figure 16:** Data log artifact reviewed to understand how sensor readings, alarm states, trend graphs, and validation records were documented after field tests.

Competitive Benchmarking

I reviewed competitor desktop and mobile tools to understand how similar flame-scanner products handled monitoring, tuning, spectrum views, device settings, and fault states.

The goal was not to copy their flows. I used the benchmark to identify what technicians might already expect, where existing tools worked well, and where the mobile experience still felt like a compressed desktop interface.

The review showed a few useful patterns: bottom navigation for core tools, dedicated views for monitor/tune/spectrum/fault states, and direct access to device settings. But it also showed recurring issues around dense layouts, unclear status hierarchy, technical terminology, limited error guidance, and charts that became harder to interpret on smaller screens.

This helped shape the design direction for Ambetronics mobile app.

**Figure 17:** Calibration and inspection documents reviewed to understand reporting requirements and technician handoff material.

**Figure 18:** Competitor tune screens reviewed to understand how flame relay settings, device configuration, and local saving were handled across desktop and mobile.

**Figure 19:** Spectrum monitor comparison showing how dense desktop diagnostic charts were adapted to mobile.

**Figure 20:** Competitor mobile screens reviewed for tune, flame relay, and device settings patterns.

What the Research Revealed

Desktop‑bound tools misaligned with field technicians

Existing experience assumed technicians would be working from desktop-based systems with stable access to data and time to interpret it.

In practice, they were troubleshooting in active industrial environments where speed, clarity, and mobility mattered far more.

01

Diagnostic data was fragmented

Flame intensity, sensor health, historical trends, and alert states were scattered across disconnected systems with inconsistent visual patterns.

This created unnecessary cross-checking and made it harder to understand what needed attention quickly.

02

Limited visibility into historical context

Historical data, event logs, and sensor data were difficult to access in the field, which made it hard to validate the nature of the reading.

Technicians lacked the context needed to diagnose issues confidently, leading to unnecessary escalations and longer resolution times.

03

Status indicators needed clearer meaning

Hardware indicators, desktop states, alerts, and chart colors did not always translate into a consistent visual language.

For the mobile app, status needed to be readable at a glance and consistent across device cards, detail screens, logs, and charts.

04

The workflow was not mobile-first

The existing workflow did not support quick scanning, offline access, or quick scanning of flame status during high‑pressure tasks.

This became the core design opportunity: reduce cross-checking, make critical status easier to scan, and support technicians from device discovery to diagnosis and review.

05

Product Direction

The research narrowed the focus around the information technicians needed most during field diagnostics, and how the mobile app could make that information easier to access, scan, and act on.

Show device status first

Technicians needed to quickly see which devices were connected, where they were installed, and which ones needed attention.

01

Keep diagnostics readable on mobile

Live readings, flame status, signal values, gain, temperature, voltage, and relay states needed to be grouped in a way that could be scanned on-site.

02

Make history easy to reach

Event logs, past readings, and trend behavior needed to be available without moving back to desktop reports or spreadsheets.

03

Use status colors consistently

Color needed to carry clear meaning across device cards, alerts, logs, charts, and hardware states.

04

Support current and future devices

The structure needed to work for the first scanner workflow while staying flexible enough for future connected hardware.

05

Design Development

This section shows how I worked through the mobile interface structure using sketches, comparison frames, and annotated screens.

The goal was to make technical diagnostic information easier to read on a phone, while still keeping the values technicians needed for field checks.

Building the device dashboard

The first step was to decide what belonged on the main device dashboard.

The annotated sketch maps the information a technician would need during a device check.

This helped separate high-priority diagnostic information from lower-frequency actions such as device details, support, and settings.

**Figure 21:** Annotated device dashboard sketch mapping live readings, threshold scales, status indicators, graph access, settings, and technician actions.

Exploring signal display options

I explored whether flame signal data should be shown as a radial dashboard or as separate diagnostic cards.

The radial options were useful for visualizing scanner state in a compact way. One version combined flicker signal and signal gain into a single model, while another simplified the model around flicker signal only.

The issue was interpretation. The radial layouts looked more compact, but they made the readings harder to understand quickly. For a technician in the field, a more explicit layout was safer and easier to learn.

**Figure 22:** Radial signal sketches comparing dual-signal and single-signal models for flame status, flicker signal, gain, temperature, and input voltage.

Choosing the clearer dashboard model

I compared a card-based dashboard with two radial dashboard options. The card-based view became the recommended factory default because it made each reading explicit.

The radial views were still kept as optional dashboard modes. They offered a more compact visual summary for users who preferred that model, but the default view prioritized clarity and first-time understanding.

**Figure 23:** Dashboard view comparison showing the recommended card-based default and optional radial dashboard modes.

Finalizing the dashboard and settings split

The final dashboard kept frequently checked information on the main screen: connection visibility, threshold-based scales, critical values, graph access, and system status.

Lower-frequency actions were moved into settings so the main screen stayed focused on monitoring and diagnosis.

**Figure 24:** Annotated dashboard and settings screens showing how diagnostic information on the dashboard while lower-frequency actions are moved into settings.

Final Screens

**Figure 25:** Entry screens for group view and device list, with connection status shown before opening a scanner.

**Figure 26:** Device dashboard options, including the recommended card-based view and two optional radial views.

**Figure 27:** Flame signal, recordings, and event log screens used to review graph data, saved sessions, and device events.

**Figure 28:** Landscape flame signal view and recordings list for reviewing graph detail and saved diagnostic sessions.

Outcome

The final product moved the diagnostic workflow into a working mobile app, available on iOS and Android.

It gave technicians a guided path where the previous workflow depended heavily on desktop tools, spreadsheets, and individual experience. The app also carried the device’s visual language into the mobile interface, so hardware status and app status could be read more consistently.

It also created a foundation that could extend toward desktop workflows later, without rebuilding the product from scratch.

Closing Note

This project pushed me to work through an unfamiliar technical domain and turn dense diagnostic workflows into a mobile interface.

The hardest part was understanding what technicians needed to check in the field, what information could be simplified, and what details had to remain visible for confidence and accuracy.

Up next

MAW’s Lottery Reconciliation System

Designed from store visits, interviews, & workflow mapping.