How digitizing a worker orientation revealed a more interesting question about why compliance tools fail — and what actually gets people to use them.
Replaced a paper-based worker orientation process across 60+ construction sites. 52,000+ workers processed. $171K in documented annual value. But the more interesting part is why the first version almost didn't work, and what that taught me about building for the field.
Construction worker orientations are, almost universally, terrible. A stack of paper forms. A laminated safety poster. A supervisor reading bullet points off a sheet — or worse, a PowerPoint — while workers fill out their signatures mostly to get it over with. Legal box checked. Nobody retained anything.
The obvious answer is to digitize it. Put it on a tablet. Add a video. Make it trackable. I built that system — and it worked, up to a point. But the version that actually scaled was different from the first one I shipped, and the difference is the part worth writing about.
The initial version was a digital form that replaced the paper form. Same content, better delivery, automatic data capture. From a compliance standpoint, it was a clear upgrade. From a field adoption standpoint, it had a problem I hadn't anticipated: it was built for me — the safety manager who needed compliance records. Not for the supervisors running it.
To use the system, a supervisor had to:
That's not complicated. But in practice, it meant the system added about ten minutes of administrative overhead to a process that supervisors already saw as a distraction from actual work. Some of them used it because they had to. Most found workarounds.
Interviews and visualizing the process revealed the truth: workers weren't engaged, the process broke and took too long. Once it took longer than five seconds for a video to load, workers lost interest. Any attention that remained was immediately lost when they reached a part of the video that didn't apply to them. This was a vital opportunity to train and educate that was being missed entirely — and we were burning it on friction.
I went back to the sites with the highest orientation rates and asked a simple question: what's actually getting in your way?
The answers were consistent. Workers needed language support — Spanish primarily. Supervisors wanted a system they could run on a tablet and hand to a worker without a phone. Universally, they wanted easier pre-fillable links to limit the number of fields that needed to be entered by hand. And the videos needed to be trade-specific — a concrete worker and an ironworker don't share the same hazard profile, and treating them like they do wastes everyone's time.
The changes I made weren't technically impressive. I simplified the flow, added language support, reorganized the content so workers could self-navigate, and removed the supervisor from the critical path wherever possible. We paired this with a revamp of the video library, breaking generic content into trade-specific modules.
Adoption went up. Not because the content got better — it was mostly the same content — but because using the system stopped being harder than not using it.
The regulatory piece was almost an accident. I hadn't designed for that outcome. It happened because the data was there.
The paperwork was never the problem. Compliance programs fail when they're designed around the compliance officer's needs rather than the needs of the person doing the complying. That sounds obvious in retrospect, but it's not how most safety programs are built — and it's not how most EHS software is built either.
The version of this system that worked shared more in common with a consumer app than an enterprise compliance tool. Not because it had better UI, but because it respected the user's time and removed friction from the path they were already going to take anyway.
I still think about this problem whenever I look at EHS software. Most of it is built to create records, not to make the underlying process easier. The record is the product. The safety outcome is secondary. That's a design problem, not a regulatory problem — and it's fixable.
If people use your system because they have to rather than because it helps them — that's usually a solvable design problem. It's also almost never where it looks like it is. I work on these problems on the side.