Thursday, March 24, 2011
I want to begin with the question that I was asked during that seminar: "Why is it important for technical communicators (or anyone performing the role of technical commicator, such as an engineer) to understand that they are doing design?” The question is an important one because it demands that we reconsider traditional treatments of the disciplines and fields that serve (and are served by) Technical Communication (TC).
For a long time, I have viewed TC as a co-opted discipline; taking pieces and parts from any number of closely and remotely related fields, practices, and disciplines. My perspective placed TC in the middle of the design/development universe. Yet when asked to qualify the importance of viewing the technical communicator’s activity as something other than “technical communication,” my heliocentric perspective broke down.
Such a break down is possible because all perspectives of TC across the scholarship and literature are based on uneasy and inconsistent definitions of the discipline and the practice. These definitions always include (arguably, must include) descriptions of design, development, and production activities that are performed by technical communicators. This move to include any and all activities associated with creating an information product is what complicates an answer to a simple question about disciplinary perspective. Blame it on the reflexive nature of Composition as the mother discipline. Blame it on technology-mediated practices. Whatever the cause, technical communicators are unable to foreground their discipline within a clearly demarcated practice of design/development activities. TC is not at the center of the design/development universe; it has gradually become the generic glue that connects hundreds of fields, practices, and disciplines.
This is the position from which I will further consider the relationship of Information Architecture to TC over the next few posts.