Putting a welding helmet's controls on a phone, without taking off the gloves.

Design for before and after, not during

Nobody adjusts their helmet mid-weld. The real moments are setup and switchover: dialing in a new material, moving between welding and cutting, checking how long the arc ran today. I stopped designing a remote control and started designing a staging tool, something you configure with clean hands and then stop thinking about.

One control, sized for a glove

Shade, sensitivity and delay share a single screen, but only one is live at a time. The active parameter takes a large radial gauge with the value set in numerals you can read at arm's length in daylight, and adjustment happens through two oversized plus and minus targets at the bottom of the screen, thumb-height, no precision required. The other two parameters sit underneath as small chips. Tap one and it becomes the gauge. It is one interaction pattern learned once, reused three times, and it survives a gloved hand.

Welding and cutting are different jobs

The same helmet does both, and they want different settings. Rather than bury that in a preferences screen, mode sits at the top of the control view as a two-up toggle, and it carries all the way through: saved configurations are typed as welding or cutting and can be filtered that way when you go looking for one. The mental model stays consistent from the moment you set a value to the moment you recall it three weeks later.

Twenty slots, because a welder does not think in shade values

A welder thinks in tasks, not numbers. The app stores up to twenty configurations as recallable slots, each one a bundle of shade, sensitivity and delay tagged to a mode. Switching from tacking to a long structural pass becomes one tap instead of three nested adjustments through a hooded visor. Empty slots are shown rather than hidden, so the ceiling is legible and filling them feels like progress instead of a chore.

Bluetooth is a state machine, and the states are ugly

Hardware pairing is where most companion apps fall apart. Disconnected, discovering, pairing, connected, connected-but-stale, out of range, firmware mismatch. Every one of those needed a screen, a plain-English explanation, and a way out. The pairing view separates helmets it can see right now from helmets you have paired before, and identifies each one by its hardware ID, because a shop with four Sentinels is a shop with four things called Sentinel A70. Most of the design work in this app is not the controls. It is the recovery paths.

Say when the data is from

Arc time lives on the helmet, not the phone, so the number on screen is only as fresh as the last time the two were connected. The easy thing is to show a big confident figure and let the user assume it is live. Instead the screen states its own last sync time and offers a refresh. On a device that protects someone's eyes, admitting the limits of what you know is not a caveat, it is the feature. Connection status and helmet battery stay visible in the header for the same reason.

Over-the-air updates on a safety device

The helmet protects the wearer's eyes. Pushing firmware to it is not a routine software update, it is a change to protective equipment. The OTA flow had to make the stakes legible, make interruption safe, and never leave a helmet in a half-flashed state.

Arc time as a chart, not a number

Arc time is how a welder measures a day. A running total tells you almost nothing on its own, so the app pairs the cumulative figure with a per-day breakdown across week, month and year. That turned the app from a settings panel into something worth opening on purpose, and gave shop leads a way to plan work and schedule maintenance instead of guessing at both.

On the web you can ship a bad state and patch it Tuesday. A helmet is in someone's hands, on a job site, with no signal, and the failure mode is a person who cannot see. Designing against physical constraints, glove-sized targets, a screen viewed in daylight, a connection that will drop, forced a discipline I now bring back to every web surface I touch.

It also broke a habit. I came up building for browsers, and I had quietly assumed mobile was the same work at a smaller width. It is not. Connection state, permission prompts, background behavior, and the App Store review process are their own craft, and the only way to learn them was to ship.

I designed this app end to end: the parameter control model, the welding and cutting mode split, the saved configuration slots, the Bluetooth pairing and recovery states, the over-the-air firmware flow, the arc-time visualization, the first-run experience, and every failure state in between.

This work sat outside my normal web workstream, and I did not arrive knowing how a welding helmet works. So the first job was not design, it was learning the product: what the hardware actually does, what the firmware will and will not allow, where the safety line sits, and what ESAB wanted the thing to become. I spent real time with the product team getting that picture, because you cannot design a credible failure state for a machine you do not understand. That groundwork is what made the rest of it possible.

See it on the App Store →