Design Issues

Every craft has its design issues. Many issues are specific and limited in scope, but a few are fundamental and have the widest possible application. In Help, three design issues seem to underlie all the others:

nFirst, design is about making tradeoffs.

You give up one thing to achieve something else. Design principles cannot be considered absolutes like the law of gravity, although frequently you may have to pretend that they are absolutes to achieve a certain effect. For example, if you want your Help file to have a consistent look and feel, you may have to restrict the types of formatting you use in your Help topics.

To create a successful Help file, intelligently apply the principles in this chapter. That means you should use your own judgment about how these principles apply to the Help system you are creating. Naturally, these principles do not pretend to know about your product or your Help system. They merely discuss general principles about designing any Help system. Some principles will be relevant to your design and others won’t. Ultimately the design is yours, and you will have to discover it on your own. These principles can help, but don’t fall into the bad practice (which is so common today) of using a design simply because the technology provides the feature. Remember, successful systems test the skill of their designers, not of the technology or of the design principles.

nSecond, design is about relating things to each other to achieve a purpose.

To design with skill involves more than just choosing the correct elements. A topic design may be perfectly correct, perfectly logical, and yet for a particular subject and product it may be a very poor Help topic. In fixing the problem, we do not want to ask what is right or wrong; that question was already answered when the elements were put together. We ask rather what is better and what is not so good for our immediate purpose in this topic.

That is the rhetorical challenge: to find the best means and employ them, to avoid what is feeble or vague or heavy-handed and choose what is strong and definite and balanced. What is constantly present in the designer’s mind is this question of figuring out the best way to produce certain effects. Questions of technology and features come in as something that defines limits and methods but that should never overshadow the fundamental rhetorical focus.

nThird, design is the designer’s responsibility, not the computer’s.

Despite their usefulness, computers are machines and Help tools are tools. Help authors, not tools, are responsible for design. No matter how spiffy the tools become, they won’t design the Help file for us. Our job is design; the computer’s is technology. But sometimes we forget this. We start to think that our tools will do our work. Tools may give us more choices, but they also demand more from us, because they can’t tell us which choice to make.

For example, a graphics program can give us 256 colors to choose from, but it can’t tell us which color is appropriate for the picture we are creating. To use graphics software, we need to understand visual communication. Graphics programs can take some of the effort out of producing graphics, but we have to know something about graphics to communicate with these programs. And computers can’t help us with that, or even make it easier.