Emerging Tech

Tacos and idiot-proof systems

Most companies with longer-term employees are still providing fast-food training on convoluted systems. Here's what you should do instead.

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.

About

Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent ...

4 comments
shawn_collins24
shawn_collins24

"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" I absolutely agree (and I don't understand the poster that said: "I would not completely disagree, but this is really depends on the application your company developed.). I will go further and say it is imperative that you do research into the business. It is one thing to be given a list of needs and wants and code them. Anyone with a book for a given programming language (and general computer aptitude) could accomplish this. It is an entirely different thing to go into a business, understand what their needs are (and why) and their goals. I'm providing an example below. I've also checked the box to alert me when new comments are made (which I don't usually do because of very real time constraints due to school). I am not here to argue. I'm here to learn. Example: We were given a project for a fictitious charter airline. We were provided with their current processes which were paper-based. Turning those requirements into working code was a "no-brainer". I fulfilled my field interview by meeting the man that designed the reservation system for a major airline. Our presentation earned us a high "A" in a class where the instructor is rather stringent on grading. Furthermore, a maximum of 5 Powerpoint slides were allowed to negate the "wow factor" (my term, I think) of audio/visual presentations. Understanding the business allowed our presentation to excel above others because I discovered (and the team integrated) the following: (the future goals of the fictitious charter company were expansion) 1) Does any non-pilot (like me) know that a pilot has to carry a flight manifest listing all the passengers? No other team bothered to have their system print out a hard-copy manifest. 2) Flight plans are not mandatory, but a phone call to an insurance agent verified that company policy mandating a flight plan would result in lower insurance premiums. 3) Commercial airlines and travel agents use a one-letter unique code for each day of the week to avoid confusion. As the charter airline may well now (and in the future) employ people already familiar with the industry, it only made sense to integrate that into the project. On a very real level, this would allow the charter airline to more easily market themselves into an as-yet-untapped customer base (i.e. travel agents). Rather than catering to a niche market of those already familiar with flying on a charter, opening this market would allow a travel agent a very real option when there are no seats available but travel for the client is essential. 4) A steward or stewardess is required on any commercial flight (which, by definition of "commercial", includes a charter airline charging fees for their services). We added a check-box to the form if a steward or stewardess was needed. There were many other points that only research and understanding the business could accomplish, but this post is already long enough. I thank you for reading it! Please! Opposing comments welcome! Anybody want to call me with a job when I graduate? Keith Schmidt keithschmidt@live.com

Ricky Tandiono
Ricky Tandiono

"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" I would not completely disagree, but this is really depends on the application your company developed. Not to mentioned that sometimes the way it was currently done is not effective or not the way it should be done (if done properly) and rather just a habit. Training and usability team is a better step.

SKDTech
SKDTech

The teller in question may have been one of those types who care nothing about the customer and will take any excuse not to work. I have become somewhat cynical from too many encounters with that type of employee over the years. I recall much the same principles you have discussed about improving the way software is designed from my classes in program development. Although the instructor was more on the side of having engineers go out and carefully observe how things are done rather than trying to do them theirselves.

Spitfire_Sysop
Spitfire_Sysop

I had the misfortune of working with a CEO who's master plan was to idiot proof the production of Airforce Aircraft parts. He had a team of underpaid felons that didn't understand the machines they used on a daily basis. This is not an exaggeration. He was always coming up with creative IT solutions to hide the complexity of what was being done. With the goal of boiling everything down to a 10 step process with illustrated pictures. The whole place would implode any time something went wrong. This was purely to cut labor costs and avoid hiring real skilled workers in a desperate attempt to be competative in a collapsing market. I'm surprised more planes don't fall out of the sky or rather I wouldn't be surprised if they started to.