Stupid people, or design flaw?

I haven't been in consulting very long, but I've learned a valuable lesson already: You should always plan for everything to go completely off the goddamned plan. Sometimes this happens during the testing phases, and the project fails integration testing or no longer matches the business goals. Typically, this just pushes go-live back a few weeks or months (don't just blindly set a new finish date!!), but worst-case, you go back to the drawing board.

"This isn't so bad -- you should have seen the one last week..."

Other times, you literally have multimillion-dollar aircraft smashing into the runway just as they  commit to final approach. This is why system design and process design are important: prevent plane
crashes and project train wrecks. This post is inspired by an article I read about very stupid employees.

Surprisingly, the article wasn't about stupid employees, or in that case, stupid pilots. It was about bad design.
In the case of the B-17, the flaps lever (used to change the aerodynamics of the plane at low speeds) was adjacent and identical to the gear retract lever (used to put tires on the runway instead of inside the plane).

From the article, since I couldn't put it any better myself (emphasis mine):

 Take for example the Boeing B-17 Flying Fortress, they were given to hundreds of pilots, who successfully took them out, fought the enemy and brought them back to land.  Then, the second they touched down, instead of pulling the lever to lift the flaps and slow the plane down they pulled the lever that retracted the undercarriage.  It hardly takes a genius to realise that retracting the undercarriage just as a plane touches down is not a clever thing to do, the wheels come up into the plane, the propeller ploughs into the field and the machine attempts to do cartwheels; very expensive and potentially lethal cartwheels.

The designers failed to account for the human aspect of the control system they designed. Pilots landing the B-17 were fatigued, working in low light, and flying a relatively new craft.

It's easy to look at a project which is struggling to meet of all of its goals, and blame the end users. Instead of saying "Look at all the mistakes these dumbasses are making!", fix it so that the correct action or input would be obvious to any user. Use validation and controls to prevent avoidable wrong entry.

Yes, I am advocating for designing to the lowest common denominator, but only to a point. You don't have to design an interface for a chimpanzee. Design it to the barest level of competency you expect to be able to train your dumbest users up to.

Einstein is frequently misquoted as saying "Make it as simple as possible, but no simpler." He never actually said that, but do this anyway. Competent employees will find the system easy to use; the lower rungs of the capability ladder will manage to muddle through without making things worse.

Every project, no matter how small or how strategic, has the potential to become a major train wreck. The more end users of a project deliverable, the more rigorous the user interface testing must be. Be open to feedback during training, and adapt accordingly. More importantly, watch the final product in use during the first days and weeks of production. If you fail to design a system that protects users from themselves, your clients will feel the pain, and so will you.