Systems Training

Created: Tuesday, 03 June 2008 Written by Gary Elsbernd Print Email

Gloria Gery once told me that all systems training is compensatory for poor design.  In other words, if the design is perfect, no training is needed.

"Just remember: you're not a 'dummy,' no matter what those computer books claim. The real dummies are the people who–though technically expert–couldn't design hardware and software that's usable by normal consumers if their lives depended upon it." - (Walter Mossberg)

This thought has stuck with me as I've designed every increasingly complex systems.  I've decided I agree with her, and that it's not a bad thing.

Before you start sending emails, this doesn't say:

  • All training is unnecessary in every case.  Training is necessary to incorporate new employees into a business.  Domain knowledge about the business you are in, corporate attitudes, principles and guidelines must be learned, along with key procedures in case of emergencies.  What this does imply is training should be focused on value-added information that is best transferred person-to-person, instead of rote procedures and facts about systems.
  • People should be able to walk up and use a system to its fullest.  The system should be built so that given a user knowing WHAT he or she is supposed to do, HOW to do it is evident.  Shortcuts and other productivity enhancements may be learned over time, but their absence should not inhibit or prevent performance of the task.
  • Designing systems that require no training is possible, or even desirable in all situations.  Such explicit systems require a great deal of knowledge of the performance environments, users, motivations, business needs and capabilities.  The time spent to develop a training free system may not be justified by the benefits.  If a short tutorial or instructions and system help within the application can help the user grasp the essentials, it may be a better use of resources to go this way.Additionally, ease of learning does not always equate with ease of use.  A system that is easy for anyone off the street to use is rarely one that "expert" users can use productively.  Consider most "wizard" interfaces.  An interview style interface walks the user through decision points and gathers information.  The wizard presents the decisions along with explanations of the implications of the step.  These systems can be used by nearly anyone because the domain knowledge and how it is represented in the system are explicit.  If an expert user does not require such handholding, a single screen interface with just the data fields may be sufficient to perform the task much more efficiently.  Familiarity with the business and a system allows experts to rapidly perform tasks such as data entry at a speed that would be impossible in a wizard-like interface.

As a designer, I strive to design the most intuitive systems and applications I can.  I go into a design knowing some training will probably be necessary, but I don't give in to the temptation to say, when faced with a design compromise, "Oh, that will be covered in systems training."

My approach has been to design a system as intuitively as possible, and then, based on user feedback during testing, add instructions to the screens and information to reference and training.  The key is frequent and iterative testing.  Get a design out in front of as many people as possible.  When faced with an issue, either integrate a solution into the application, add on-screen instructions, add online reference or training, or add it to a training class curriculum.  This "Frequently Asked Questions" method of systems documentation and training allows the trainers to focus on issues that realistically come up instead of spending time and effort documenting functions and behaviors that are well accepted by everyone.

Now you may let the emails fly.  :)