For those of us who communicate technical content for a living, we share many job titles, such as technical writer, information developer, technical communicator, multimedia engineer, content developer, and many others. Without one focused set of titles, how did we know this is what we wanted to do?
The truth is…like many other technical communicators…I didn’t. I graduated with a Computer Science degree and a Mathematics degree. I took a few Tech Comm courses at Penn State, but I had never heard of Technical Communication as a profession. I was going to be a programmer, like all good Computer Science graduates. But then, something happened… After developing my first database-driven security system, I had to document the system and train others how to use it. This process introduced me to my future career. I had always enjoyed teaching and coaching…and this was teaching through a different medium.
But how could I make the transition? I joined a writing shop as an entry-level writer. I first worked on a database product and I was hired for my technical knowledge in that area. I thought I knew all about writing when I started. After all, I had written more than 100 pages to “document” the entire system I had developed. I quickly learned how little I actually knew about creating quality software documentation. Luckily for me, there was a light at the end of the tunnel.
The second important event in my career path occured when I met my first mentor…my editor. Ria (www.dutchtrans.com) was an excellent guide and mentor. She used each edit as an opportunity to teach me the guidelines and show me how to refine the content and present my thoughts in a clear, concise manner. She used a green pen so it didn’t look like my pages were soaked with blood, and we talked about various ways I could improve. I soon became much more aware of the other senior writers around me and I learned to watch and listen instead of show and talk. I am very thankful to all those mentors, including many who may never know about their profound impact on my future. We should all learn from each other when the opportunity crosses our paths.
The greatest element about technical communication for me is the opportunity to continually learn and grow. We are consistently faced with new challenges and ways to communicate content to our audiences. Even if we are in a “standardized” environment, we can always look for ways to improve knowledge transfer to our audience. When we think we know it all, we actually fall behind and lose our drive and motivation.
When I started in Technical Communication, we wrote everything in books. Online help soon followed, providing all the printed content in an online format. These formats became standard and common, with terms like chunking and single-sourcing. The big break through for me was the introduction of electronic production support systems (EPSS), which accompanied products and provided assistance in parallel. Delivering the information users need, when and where they need it was a break through approach for me and one I quickly latched onto. It was the conference sessions and discussions at that time that truly inspired me to design and implement my first embedded help solution.
We continued to play with our embedded help implementation techniques and talk with users about their experiences with the product. I also began presenting regularly at conferences about embedded help and discussing these ideas and methods with others. These idea exchanges were the key for me to find new ways to present information and expand my ways of approaching techncial communication.
Today, we look at integrated user assistance as commonplace in many products. For example, wizards and text in the user interface are never considered to be forms of help. We learned that if we didn’t call it help, people would actually read it and use it. In addition, we have found ways to more closely integrate the online content with the product. For example, many help pages provide links that do something in the product itself to resolve an issue, such as a button to open a window in the product and perform a specific task. Multimedia continues to extend our communication methods with demonstrations and tutorials integrated with the product. These powerful technologies and our creative minds help us find better ways to communicate effectively with a wide range of audiences.
As we move toward community-generated content and extensible user assistance through Wikis and other technologies, are we working ourselves out of a job? I believe not at all. This evolution is just the next step in our journey and with it our role changes in the process. We now move toward helping to shape the content and to focus on accessibility and structure within these information sets. We become the information architects and we will develop ways to make it easier for others to develop standardized community-generated content.
What’s next? True industry leaders never stop learning. Mentors share their knowledge and experience with others, and in turn they learn from the fresh perspectives of those they work with. We continue our discussions, share ideas, experiment and try new things, and continue to watch, listen, and learn. From our idea exchanges at conferences and various events, future approaches that more effectively meet the needs of our audiences are born. I hope you will be a part of our future and I look forward to our continuing discussions as we find the next, better way.
Alliene Turner says
Hi. I’d like to republish your article ‘The Yellow Brick Road to Technical Communication’ in the East Bay Society For Technical Communications newsletter, Devil Mountain Views. May I get permission to do so? See our site at http://www.ebstc.org/newsletter/front.htm . Thanks, Alliene Turner – DMV Managing Editor.