Designing for the field

My dad owned an HVAC company until I was 21. I didn't work in the field, but I grew up around the business. I understood how it operated, the kinds of problems techs ran into, the tools they used. So when I started researching the field service software market, I already had some context for how broken it was.

The dominant tools cost $245/month and up, and they're all designed for someone sitting at a desk. The actual technician, the person in the attic or the crawl space or on the roof, is an afterthought. That's the gap I designed ColdSnap to fill.

The environment changes everything

Most software assumes you have two hands, a stable internet connection, and time to think. HVAC techs have none of those. They're holding a phone in one hand, probably wearing gloves, squinting at the screen because they're either in direct sunlight or a dark attic. And they need an answer in seconds because they're billing by the hour.

That constraint shaped every design decision in ColdSnap. Big tap targets everywhere, because precision tapping with sweaty hands doesn't work. Offline reference tools, because attics don't have wifi. Voice notes instead of typing, because nobody is writing a paragraph about a compressor failure while standing on a ladder.

Offline is the default, not a feature

The reference tools in ColdSnap (PT charts, wire sizing, error codes, superheat calculators) are the features techs reach for most often. And they reach for them in places with no signal. If the app needs to fetch data to show a pressure-temperature chart, it's useless. The tech goes back to the laminated card in their truck and never opens the app again.

So everything critical is bundled client-side. No network dependency. That's not a feature you advertise. It's just table stakes for an app that's supposed to work where work actually happens.

One app, different users

I thought about building separate apps for techs and shop owners. But a lot of HVAC businesses are one to three people, where the owner is also the technician. Making them switch between two apps would have been unnecessary friction. So I designed role-based surfaces instead. A solo tech sees a simple dashboard with quick actions. A shop owner with a team sees dispatch, scheduling, and revenue. Same app, different entry points.

What I took away from it

Designing for field conditions made me think differently about every interface I work on now. When you can't rely on attention, connectivity, or precision, every element on screen has to earn its place. That's probably true for all software, but you don't realize it until you design for someone who's standing on a roof.