Technical writers are in a unique position to influence human factor decisions in software design. Their primary role is advocating for the user, understanding the user and interpreting the software's capability to the user in a way that the user best understands. This is, in a sense, Human Factors engineering. I believe, however, that a serious study of Human Factors issues would benefit any technical writer and might even enhance his or her role in the organization. It would certainly add value and enhance the organization's ability to design and develop a high quality product.

• Visibility of system status—the system should always keep the users informed about what is going on through appropriate feedback.


• Match between system and the real world—the system should speak with words, phrases and concepts familiar to the user, not system-oriented terms and phrases.


• User control and freedom—the system should provide a clearly marked "emergency exit" to cancel or undo a task.


• Consistency and Standards—words, situations, or actions should always mean the same thing: follow platform conventions.


• Error prevention—a careful design is better than good error messages: prevent a problem from occurring in the first place.


• Recognition rather than recall—make objects, actions and options visible: users should not have to remember information from one part of the dialogue to another.


• Flexibility and efficiency of use—accelerators, unseen by the novice, speed up interaction for expert users (all levels of users).


• Aesthetic and minimalist design—dialogues should contain no irrelevant information, no extra "noise".


• Help for users in recognizing, diagnosing and recovering from errors—error messages should be expressed in plain language (not codes), indicate the problem, and suggest a solution.


• Help and documentation—any information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.