Frontline Adoption Is a Design Responsibility, Not a Change Management Problem

Authored by Mitzi Orkus, Director of Strategic Growth, KAStrack

In the first piece of this series, Proof of Execution Is an Operating Discipline, Not a Deliverable, we made a claim that the operational software industry does not like to make plainly: when a frontline crew doesn’t adopt a system, the failure is design, not training, and not change management.

The first question should be whether the system was designed for the way they actually work.

That distinction matters. Because if frontline adoption is a design responsibility, then the work starts much earlier than rollout. It changes what gets asked during procurement, what gets built during implementation, and what counts as success after launch.

The frame the industry uses, and why it costs operations

For years, frontline software failure has been diagnosed as a change management problem.

The system is fine. The training happened. The crew is resistant. The supervisor isn’t reinforcing it. The frontline is "not ready."

The implication is that the adoption gap is a human problem that shows up after the software decision has already been made.

That framing is convenient for software vendors because it moves responsibility away from the system itself. The operation, meanwhile, absorbs the cost: more training, more follow-up, more supervision, more workarounds, and eventually another process running beside the system that was supposed to replace it.

What often gets missed is the most basic question: Why did the crew stop using it?

Too often, the answer to that question is another training session.

I’ve heard some version of this complaint from more clients than I can count, almost word for word. Frontline workers get frustrated by how many clicks it takes to enter routine data, and eventually they stop entering it consistently. I sat in a room once where leadership diagnosed that as an adoption problem. It wasn’t. What drove the frontline away wasn’t resistance to change. It was the ridiculous amount of time the system demanded just to track something that should have taken two seconds.

Two failure patterns that show up in nearly every stalled rollout

There are two patterns we see across stalled rollouts. They look different on the surface, but the underlying cause is the same.

Pattern 1: The digitized paper process.

A team has a working process on paper or in a spreadsheet. It may not be elegant, but people understand it. They know where the rough edges are, and over time they’ve built informal ways to handle the exceptions.

Then the organization buys a new system and asks the implementation team to reproduce the existing process inside it.

That sounds reasonable. Sometimes it is. But if nobody stops to examine how the work actually happens, the result can be a digital version of the same process with more clicks, more required fields, and fewer of the workarounds that made the old process usable.

The frontline opens the system and discovers that it takes longer than the spreadsheet, interrupts the sequence of the work, or makes simple exceptions difficult.

Within a few months, usage drops.

Leadership sees an adoption problem. The crew sees a tool that made the job harder.

Those are two very different diagnoses.

I built one of those workarounds myself, years before I worked here at KAStrack. I couldn’t get the invoicing I needed out of the system I was using at the time, so I started patching together my own process around it. When I brought the problem to my client liaison at KAStrack, he built me a form that covered what I actually needed, and the workaround I’d started building never had to exist. That’s the difference between a system you have to build around and one that gets built around you.

Pattern 2: The high-touch pilot that doesn’t survive expansion.

A system rolls out at one location with a lot of attention around it. The implementation team visits the site, works closely with supervisors, answers questions quickly, and adjusts the process as problems come up.

The site succeeds.

Then the organization expands the rollout.

The second location gets less hands-on support. The third gets less still. The questions that were answered in real time at the first location now become friction for the people at the next one.

Adoption starts to fall off.

At that point, leadership often points to the original site as proof the system works. And technically, it does.

But something else was doing part of the work at that first site: the people standing beside the system, helping users navigate everything the design hadn’t yet solved.

If that support can’t scale, then whatever made the first location successful hasn’t actually been built into the system.

What frontline-first design actually looks like

Designing for frontline adoption means building around the conditions in which the work actually happens, not chasing simplicity for its own sake.

The work stays recognizable.

People shouldn’t have to translate their job into the software before they can use it.

If a crew performs an inspection in a particular sequence, the system should support that sequence. Certifications with specific expiration rules need to reach the right people before they become a problem, not after. And when different locations run the same process differently for legitimate reasons, the system should account for that instead of forcing everyone into one generic workflow.

The goal is not to make the operation look like the software. The software should make the operation easier to see and execute.

Capture happens inside the work.

In the first article, we talked about capturing proof at the point of execution.

That matters for adoption too.

A frontline employee doesn’t experience “doing the work” and “documenting the work” as two equally important jobs. When the shift runs long, something breaks, a customer needs help, or the next task is already waiting, the separate documentation step is the easiest one to postpone.

And postponed documentation becomes missing documentation very quickly. If the organization needs the record, the system should make creating that record part of completing the work itself.

The system has to fit the conditions on the ground.

The frontline is rarely sitting at a desk with perfect Wi-Fi and twenty uninterrupted minutes.

They’re likely moving through a facility, wearing gloves, working outside, sharing devices, dealing with a weak signal, or checking something between two other tasks.

That matters.

A system that technically works on mobile but takes twelve taps to complete a two-minute task wasn’t designed for mobile work.

A system that requires a steady internet connection in an environment that doesn’t have one was designed for somebody else’s day.

Frontline usability belongs inside the operating design, not bolted onto the end of it.

Three questions worth asking operations leaders, training managers, and executives

If you lead operations across multiple locations, ask this:

If frontline use dropped tomorrow, how quickly would you lose visibility into what was actually happening across your locations?

If the answer is “almost immediately,” you may have a reporting system that depends on frontline participation without having designed enough value into the frontline experience itself.

If you manage training and certifications, ask:

Does the system help people act before something expires, or does it simply give you a place to record that it expired?

There is a major difference between storing training records and supporting workforce readiness.

And if you are the executive who approved the investment, ask the people using the system what it is like to use.

Skip whether they’ve been trained or know where to click. You already have that answer somewhere in a completion report. Ask what slows them down, where they leave the system to finish the job somewhere else, and what they still keep in a notebook, spreadsheet, text thread, or their own memory.

Those answers will tell you far more about adoption than a completion report ever will.

Where this leaves operations

Frontline adoption shouldn’t begin when the rollout team arrives.

By then, many of the decisions that determine adoption have already been made.

They were made when the process was mapped. When the workflow was configured. When someone decided which fields were required, which steps could be skipped, what device would be used, what happened when connectivity dropped, and whether the system reflected the way the work actually moved.

None of that erases the importance of training, leadership, or change management.

But none of them can permanently compensate for a system that makes the work harder than it needs to be.

Operations ready to look at this more closely don’t need a generic demo. What helps is a needs assessment built around how your organization actually works: where adoption has stalled, where people have built different workarounds, and what the system would need to do differently for the frontline to use it as part of the job instead of beside it.

Have a question about this? Email Mitzi directly at sam@kastrack.com.

About the author: Mitzi Orkus, a petroleum engineer turned growth strategist, is the Director of Strategic Growth at KAStrack. Before joining the company, she was a client for six years, using KAStrack to improve the way she ran her own business. Today, she helps other organizations move from chasing proof to producing it as part of how work is done.