Blue Collar Technician Assistant

Blue Collar Technician Assistant

Blue Collar Technician Assistant


Role

Product Management & Design; built in collaboration with a backend developer

Timeline

~2 months

Client

A local HVAC (heating, ventilation, and air conditioning) company

Status

In daily use by the company

Context

This project started on a walk, when one of my neighbors reached out to me because they wanted a technical solution to their HVAC business operations. They had difficulty manually keeping track of who was going where, and getting the details of finished work back to the office so invoices could go out.

The business comprises of 10+ employees including both technicians and service employees in the office. Depending on the contract, anywhere between 3 to 15 technicians are deployed on the job to help with residential and commercial needs. On a typical day, a technician handles 3 to 4 residential jobs on top of at least one longer-term project, while the service team schedules jobs and turns finished work into invoices.

The goal was to develop a solution that keeps every job's details in one place, so technicians can focus on the work and the office can focus on the paperwork.

Problem

The information about each job lived in too many places, and most of them were technicians' phones and memories.

Technicians jotted down requested services, memorized them, or kept them in their own notes, which led to missed jobs and wrong details. On site, in a hurry, they took photos of the parts they used so they could remember later. Then they texted the office part photos, service notes, and bits of information, often without saying which job or which address it belonged to.

This led to a lot of hiccups in getting information in order to deliver to clients. Many photos were too blurry to read a part number, so someone would call the technician to ask. The technician, busy with the next job, would say "I'll tell you later," and the office waited. The same happened when a text arrived without context. Every invoice depended on a phone call being returned, and an invoice took about a day on average to go out.

What they needed

  • Technicians: a tool to keep track of what they need to do each day, with the client's name, address, phone number, service type, and status.

  • The office: status updates as jobs happen, so paperwork can start right away, including when a job is delayed or runs long.

  • Both: one place for everything a technician did on a job, including services, parts, and photos, so the office never has to piece it together from texts.

Process

I followed one job from call to invoice

The tool was intended to be internal to the company, so I started by spending time with their daily operations. I followed single jobs through their whole cycle from the service call all the way to the payment. At each step I noted where things slowed down and who was left waiting.

I identified two very different sets of users

Technicians mostly weren't comfortable with technology. They had phones and company email accounts, but didn't use them much beyond calls and texts. Many kept their phone's text size large by default, which made sense once I saw where they work. They were often in dark, cramped spaces. When typing was hard, they took photos instead, to jog their memory later.

The office was comfortable with technology. They already used AI tools to look up parts from the serial numbers and details technicians sent, and they created invoices in Microsoft Excel, a workflow they wanted to keep.

I prioritized security over polish

This was an internal tool with no customers using it. That made data security, sign-in, and reliable processing more important than looks or selling points.

I designed with the software build in mind

I designed the platform on my own and built it with a developer who knew backend work better than I did. I proposed features like Google sign-in, offline saving, and a parts history, and we worked to narrow the gap between the ideal product and the realistic build. Working closely together helped to retain integrity of the scope.

I built in layers at the technicians' pace

Asking technicians who weren't fond of technology to switch to a full-featured app on day one would have been a hard sell and unprofessional as a UI/UX designer. So I started with the simplest version that worked and added to it as they got used to it, based on what they told me and what I saw them struggle with.

Solution

The technician app: today's jobs with one standard form per job

Sign in once. Technicians sign in with their company Google account a single time and stay signed in. Only company email accounts can sign in, and technicians only ever see their own jobs. The office sees everything.

Today's jobs as the home screen. Each job shows the client's name, address, phone number, service type, and status, in a to-do list with large text, bright colors, and large buttons. Tapping an address opens their map app, and tapping a phone number calls the client. Long-press opens options to edit or delete jobs.

One form per job. Tapping a job opens a form for the services provided, the parts used, and any photos. Tapping Submit at the bottom marks the job as done and sends everything to the office. Until then, the job shows as in progress with edits saved.

Works with a weak signal. Technicians are often somewhere with spotty signal. The form shows whether it's online, and saves their work offline until it can sync.

Outcome

Invoices went out within 8 hours. The average time to get one invoice out dropped from about a day to 8 hours at most. The details arrive with the job, so the office no longer waits on a returned phone call to start the paperwork.

Everyone uses it, every day. Every technician uses the platform daily, because it's now where all the job information lives.

Each role gets to do its own job. Technicians focus on the work in front of them, and the office focuses on scheduling and invoicing, without chasing each other for details.

Bigger projects are easier to coordinate. Larger construction projects, with several technicians over several days, live in one entry that the whole team can see.

Reflection

This project resonated with me because a lot of my family members are involved in blue collar jobs, and have previously expressed that they wish they could utilize their technology better but without “the complicated fancy stuff.” I realized early on that this project wouldn’t be the most visually impressive but perhaps one of the more valuable projects of mine that showed how my UI/UX skills can help make someone’s daily job easier and faster.

One of the most memorable design moments of this journey was when I started brainstorming how to indicate detail and options without making it too complicated. Simplicity was a major design principle starting this project, so I had a lot of fun brainstorming how to develop a product that was intuitive, simple, and accessible.