data.day

If the App Needs Training, It Will Not Be Used

Field workers do not read PDFs. If your software requires a 'Training Day,' you have built it wrong. The interface must be as obvious as a hammer.

The Classroom is Empty

I walked into a site office. There was a stack of binders on the table. “User Manual v2.0.” They were covered in dust. Someone had used one as a coaster for a coffee mug.

This is the reality of software documentation. Nobody reads it.

We assume that if we send a PDF, the team will read it. They will not. They have concrete to pour. They have trucks to load. They will open the app. If they cannot figure it out in thirty seconds, they will close it. They will call the foreman. They will say, “The app is broken.”

It is not broken. It is just obscure. But the result is the same: The data stops flowing.

The Bottleneck: Cognitive Load

Designers love “Features.” They add menus. They add sub-menus. They add “hamburger” icons that hide critical functions.

Imagine a hammer with a menu system.

  • Select Mode: Nail / Claw.
  • Select Intensity: High / Low.
  • Confirm Swing? (Yes/No).

The carpenter would throw it off the roof.

When we force training on a crew, we are admitting that our design is weak. We are trying to patch bad software with human memory. But human memory is faulty. Two weeks after the training session, they will forget how to find the “Submit” button.

The Pipe: The 30-Second Rule

My standard is simple. I take the tablet. I find the oldest, grumpiest foreman on the site. I hand it to him. I say nothing.

If he can complete the main task (e.g., “Log a Delivery”) without asking me a question, the software passes. If he asks, “Where do I click?”, the software fails. We go back to the code.

To achieve this, we strip the interface.

  1. One Action per Screen. Do not mix “Inspection” and “Time Sheet.”
  2. Language of the Site. Do not use “Submit Asset Verification.” Use “Check Tool.”
  3. Linear Flow. A pipe goes one way. The app should go one way. Next. Next. Done.

The Cost of Complexity

We calculated the cost of training for a logistics client.

  • 500 drivers.
  • 2 hours of training each.
  • $40 per hour cost.
  • Total: $40,000.

That is $40,000 spent just to explain how to use a bad tool. We took that money. We spent it on better design. We simplified the app.

We rolled it out with zero training hours. We sent a one-page flyer with a picture of the screen. Adoption was 98% on day one.

Do not train the human to serve the machine. Build the machine to serve the human.

FAQs

But our process is complex, so the app must be complex.

The process is your problem. The app should hide the complexity, not expose it. Do not export your organizational mess to the user's screen.

Don't we need to show them the advanced features?

No. Hide the advanced features. Reveal them only when necessary. 90% of users need 10% of the buttons.

How do we support older workers who aren't tech-savvy?

Older workers know how to use tools. Make the app feel like a tool. Big buttons. Clear labels. High contrast. They aren't 'bad at tech,' your font is just too small.