Even though the course I am teaching this spring semester has the same name and number as the one I taught in the fall—LMC 3403: Technical Communication in Theory and Practice—the two classes couldn’t be much more different. For starters, last semester was my first at Georgia Tech and also my first teaching a Tech Comm class (and three sections at that). The learning curve was steep for this and a number of other reasons, not the least of which was the fact that, while I do have experience in communications generally (broadcast radio, web design, freelance writing and editing, etc.), strictly speaking I don’t have a technical writing background and through grad school primarily taught traditional literature-based courses. Still, the major differences I have already seen only five weeks into the new semester are not simply the result of having learned the course material better myself. The differences come from the fact that this semester’s class has an urgency that was entirely lacking from those I taught in the fall, one that allows students to recognize the purpose and impact of the work that they do for my course. This urgency comes from the client-based model I have adopted for this semester, a model I’ve inherited from my colleague Christopher Ritter, who in turn inherited and adapted it from former Brittain Fellow Daniel Vollaro. Following their syllabus, my students work from the beginning of the course in specific roles on one of three separate teams to complete major information design projects for clients external to our class. The course is essentially a combination between an internship and an advanced communication class, and it centers on the idea of multivector communication between client, teacher, student, and team.
From the outset, this interactive model requires students to engage with a wide range of actual communication situations, effortlessly illustrating the various lessons that I struggled to convey last semester while teaching the course as a series of independent units and case studies drawn from a textbook. There’s nothing to demonstrate the importance of careful communication in any form like the teammate or client who doesn’t convey needs and expectations well and who, therefore, increases other team members’ stress and work. This multivector model gets students actively thinking about and involved in a variety of professional interactions, and it consequently increases student interest and buy-in, a process that begins with their first assignment—an application packet aimed at a specific role on a specific client team. The roles for which the students can apply are Project Manager, Managing Editor, Writer/Researcher, Graphic Designer, and Programmer. Those who applied to be Project Managers interviewed with me, and those I selected then assembled their teams from the remaining pool of students based on their individual application packets. The resulting connections that students have formed with one another are now influencing the rhetorical decisions that they are making in their teams as they begin to interact with their clients. The educational impact of this team-based, multivector arrangement is something that I could barely achieve in my non-service-learning classes last semester.
In the fall, I taught the class basically straight out of our textbook, the seventh edition of Paul Anderson’s Technical Communication: A Reader-Centered Approach (Wadsworth, 2011). Generally speaking, student engagement was acceptable but not extraordinary, and the central cause of this was the difficulty in demonstrating the need for, as well as the real world application and urgency of, the material we covered. For most of the semester, our class discussions and activities focused on essential matters that I intend to cover again this spring—things like the elements of document and website design, the rhetorical principles that influence usability and persuasiveness in workplace communications, or the difficulty of crafting effective instructions. But without a consistent and cumulative project toward which to apply the lessons learned, I don’t feel as though the students got everything out of the class that I think they could have, at least not from the beginning. This situation started to change, however, in the last six weeks of the semester when I introduced their final assignment—a multi-step, team-based project that required students to produce documentation and accompanying videos to address specific instructional needs on campus. Like the more developed team model I have adopted for this semester, my final assignment in the fall allowed students to select their roles and decide which project they wanted to work on. The result was an increase in student engagement and an elevated recognition of the application of the lessons they had learned, something that I have witnessed to an even greater degree with the introduction of third-party clients in my team-based, service-learning class this semester.
I had borrowed my final fall project from former Brittain Fellow Michelle DiMeo, but I modified it slightly to incorporate a couple of extra steps—the requirement that each student had to write a proposal that was anonymously evaluated by fellow students, the sort of multivector interaction that is a critical component of my classes this semester. To begin, each student was to find a problem on campus that could be solved by better instructional materials and then argue persuasively in his or her proposal for permission to produce them. Once the proposals were in, I divided the students in each of my three classes into teams based on major; the teams then reviewed two proposals from the other classes that were appropriate to their areas of expertise and then selected the project that they thought could best be accomplished by semester’s end. This review process ultimately proved critical because, given their field-specific knowledge, the student review groups were able to see holes and potential pitfalls in proposed projects that I thought were generally quite sound. For instance, one Computer Science team reviewing a proposal for documentation that would teach the user how to program for Android pointed out that the scope and schedule were far too ambitious for the time remaining in the semester. While I knew nothing of Android programming I did, in fact, find the project a bit overwrought, but because of the polished fashion in which the proposal was written, I assumed the project could have been dialed back to reasonable form in the weeks we had left before final exams. I was apparently all wrong, and the students were eager to point out how the rhetorical moves of the proposal failed to persuade them that the project was possible.
Once the winning proposals were selected, I presented them to the class from which they had originated and allowed the students to decide which project team they wanted to work on. Similar to my class this semester, students applied to serve on their team in one of several specific positions—Project Manager, Graphic Designer, Writer/Researcher, Programmer, or Editor. When the projects were finished and usability tested, the results were, by and large, quite good. For example, I had a team of industrial design students develop a very slick ring-bound instruction manual that taught the user to operate the College of Architecture’s laser cutter, a device on which students apparently receive little training but that could cause fires if misused. The team’s highly portable, acrylic-covered volume came complete with swatches of sample material that had been both etched and cut in order to demonstrate what the machine could do if used properly.
Of course, with a team of designers at the helm, the formatting and layout of the manual was not only functional and engaging, but also quite attractive. And their video was a worthy counterpart to their manual—a fun-to-watch training guide that walked the viewer through the various steps over a music bed of mellow rock guitar. This laser cutter documentation was among the best of the final projects in my fall classes, but I witnessed something in the production of all the manuals and videos that I hadn’t seen much of prior to the proposal stage mid-semester. That something was real student interest and buy-in, both of which stemmed from the nature of the final project itself—team-based, multivector interaction that illustrated the lessons of the course and provided the opportunity to apply them. In other words, once I put the students in teams and had them work together to evaluate written communication and then to produce multimodal artifacts based on it, they recognized the exigence of the principles of persuasiveness and usability that we had been discussing all semester.
This minor epiphany on my part will come to many as an insight of no particular profundity. Still, I hope it serves as a reminder for my fellow teachers of multimodal communication that students need to experience, to explore, and to experiment with a variety of communicative modes in a variety of contexts if they are to grasp fully the rhetorical principles we teach. Service-learning is a highly effective way to extend the variety of modes and contexts in a communication classroom, and the multivector interaction it introduces adds real urgency to the lessons that students learn. In my experience thus far, it is the best way to bring these elements into the Technical Communication classroom.