Creating User Guides

Publish date:
Social count:

So youve figured out the coolest, slickest, and most wonderful feature to incorporate into your installations. Off you go, investing corporate dollars to develop this new feature, getting a slick GUI to make it a thing of visual beauty, and adding an intuitive operational flow. You deploy it, debug it, and make it a standard part of your delivered software package.

But then, out of the blue, one of your clients with this new whiz-bang add-on feature calls and says that they want an upgrade or need a new feature. This is nice return business, but as they describe what they have in mind, they start discussing that slick feature that you implemented. Or worse yet, they got themselves into that very feature and were having one heck of a time figuring out how to navigate their way through it. So youve invested all of that corporate time, money and energy into something that no one seems to be using.

This is really just another occurrence of a greater problem with most of the installations that our industry deploys these days. Most of us go into a sales opportunity with a competitive bid and a tight time line. If were lucky to get awarded the contract, theres not much extra in that bid for unforeseen expenditures. Hopefully you get enough time to do a check of the installation to ensure everything is actually fully functional. The only problem is, who showed the client (much less his family) how to use the system, including that slick feature?

Sound familiar? Wheres the users manual for that system anyway? Have you ever created an operational manual for any system? Probably not. The multi-room, multi-source audio/video systems being installed today are all still very unique and differ greatly from installation to installation. This makes one generic user manual that would cover all installations an impossibility.

I have found that this absolutely needs to happen in some form if the client is to view the installation as a success and grow to be happy with it. Without the time to generate custom user manuals for each and every new installation, it is best that a one-on-one usage session happen during the final systems and touch panel testing phase, first with the primary client, who is usually the more technically driven individual with the interest in such a complex system; and later, separately, with the spouse of the primary client. These are generally two different approaches to describing how the system works and what it does. The techie of the two will want to know how to store station presets and what happens when I do this. The non-techie will want to merely know, How do I get HGTV. The first is a functional flow description of how the entire system operatesan understanding of whats happening behind the panel page flips. The second is primarily memorization of a sequence of button depressions, and a disinterest in whats operationally happening.

I have also found that usage documents for individual subsystems, such as HVAC control, dont vary as much as overall system design does. So separate, more generic, descriptive subsystem documents such as on how to use thermal set points and programmable timers can be used over and over again with minimal modification. Anything visual is a huge aid to the novice user attempting to learn and trust their system.

It only takes one or two hours, at the most, to personally provide a training session to each of the clients. These are different but important sessions. Any client who gets any such system handed to them without being trained to some degree on how to use it will almost assuredly get wrapped up in I would rather have had this here or why didnt you do it this way? By preemptively training them on the flow and functionality delivered the client develops confidence in using the system. Without such training, there will undoubtedly be service calls. In the end, these follow-ups will take more than the one or two hours that you could instead of invested up front training them in the first place.

Carl Easton ( is the director of systems engineering at Axiom Design Inc.