The Yellow Brick Road to Technical Communication

by Paul Mueller
STC Senior Member

Paul Mueller is president of UserAid and has been involved in technical communication for more than 20 years. He has served as a director and a conference track manager for STC. Paul is also active in his local STC community in Houston and has held various positions in the organization, including president, vice president, director, and strategic advisor. Paul received the Distinguished Chapter Service Award in 2006.

Making the Transition from Developer to Writer

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 communicator, I didn't. I graduated with a computer science and mathematics degrees. I took a few technical communication 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 system that 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.

An Editor Guides the Way

The second important event in my career path occurred when I met my first mentor, my editor, Ria (you can meet her at www.dutchtrans.com), who 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 that 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 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.

The greatest element about technical communication 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.

EPSS Becomes a de facto Standard

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 terms like chunking and single-sourcing became the buzz words. The big breakthrough 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 breakthrough approach and one I quickly latched onto. The conference sessions and discussions 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 technical 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. We have also 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 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. 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, 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 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.