Earlier in my career, one of my least favorite comments was the request to make a system “idiot proof.” I heard the comment so often that I’d quip in response: “If I build an idiot-proof system, they’ll just build a better idiot!”
I was reminded of this recently when I stopped in a Taco Bell for my regular dose of mass-market Mexican, and the employee at the register told me “my screen isn’t working.” We stared awkwardly at each other for half a minute, and when I suggested she use the drive-through register, which appeared to be working perfectly and was currently free, she slowly backed away with downcast eyes as if I had drawn a weapon and demanded a wheelbarrow full of tacos. After a couple minutes her “screen” made a Lazarus-like resurrection, and she took my order, still staring quizzically at he who would dare suggest a workaround.
Presumably this young lady was trained as many employees are: push the buttons, check the boxes, put a certain value in the field on page seven for some reason no one can explain, then hit Enter. If it doesn’t work, back away slowly, reboot and hope for the best. While the fast food industry has extremely high turnover which somewhat explains the short shift given employee training, most companies with longer-term employees are still providing fast-food training on convoluted systems.
The problem starts with systems that are built by disconnected individuals. IT employees receive stacks of requirements, some conflicting, and attempt to do the best they can with little familiarity with how a system might actually be used. Similarly disconnected managers and “stakeholders” who worked at the line level decades ago provide their own input, and then the back office functions step in with user-friendly requirements like “they need to enter a 48-digit cost center code, and no, we can’t have a drop-down box for that!”
When the poor sods that actually have to use the system first see it and are utterly confused, the various parties try to build technical controls to make up for what’s a disjointed design. With the “idiot-proof” mess finally complete, training programs are delivered by technicians who don’t understand the job that actually needs to be performed, and focus on which buttons to click rather than how to accomplish some business process.
This is certainly not the fault of IT, but since IT ends up building the systems in question, it’s often left holding the bag when the complaints roll in and productivity suffers. However, IT can help mitigate some of the pain caused by “idiot proofing” by partnering with end users to build new systems. Before a line of code is written, send your developers out to the field for a few days. Make them work the registers or answer the phones, and observe how employees interact with customers, coworkers, and systems. That seemingly annoying demand to move a field may seem more compelling after seeing how it would be used, just as the urge to skimp on training may be mitigated when IT sees the volumes and revenue generated by a particular process.
With this relationship established, recruit a few savvy line employees onto the team to help guide the design of the system, answer usage questions, and eventually deliver end-user training. These team members are the glue between IT and end users, and they are the ones that will serve as translators between technical requirements, and how the system helps someone actually accomplish their jobs.
Finally, rather than assuming your employees are idiots, hell-bent on circumventing controls and misusing IT-driven tools, assume they are the same people you trust to come into work every day and perform their jobs. Should they misuse these tools, regard it as a training problem first. Should the problem reoccur, your HR department likely has reams of policies for corrective action that are more effective applying layer after layer of idiot-proofing.