As technical editors, we love words. We love making sure that each word communicates clearly. If you hear that someone is an editor, you immediately think of grammar and syntax and word usage. But, as technical editors, the time has come (really, it came awhile ago, but the saying goes, “the time has come”) for us to let go of a singular focus on the words. As technical editors we must edit so much more than just the words — words on the paper or words on the screen, words in a PDF or words in a help file, words in a user interface or in a message. We have to look beyond the words.
Maybe we never really had a singular focus on the words, but it sure seems that way when you think about how to teach technical editing. If you look at syllabi or courses about editing or technical editing, it really does seem to be all about words. In the online (and now in-person) certificate course, Technical Editing Fundamentals, Linda Oestreich and I recently added a new module about editing more than text. One example that we talk about is editing a user interface. We start off defining user interface very broadly. We explain that it includes more than just a graphical user interface: a user interface might be a tiny display window and a set of buttons on a printer or maybe those graphical instructions for how to assemble a book case to hold all your grammar books act as a user interface to all that hardware you have to assemble. (I know my bias for software development shines through in my examples, as that has always been my background, but I challenge you to think of user interfaces outside of that realm.) Every editor is immediately drawn to edit the words on the screen, but as teachers we try to direct our students to think about how the user interacts with the UI controls and how the users perceive that interaction. All of those interactions affect the choice of words and even whether words are necessary to communicate clearly and make the interface usable.
For a special issue of Intercom on technical editing, I co-authored an article with a colleague of mine, Julian Cantella, called “Embedding the Editor: Tips and Techniques for Editing Embedded Assistance”, where we touched on how different techniques help editors engage in this new type of assistance. We certainly had our fair share of tips that involved the use of words as we stepped into collaborating and improving the quality of user interfaces that implement all the types of embedded assistance. However, I think we definitely tried to present a more holistic approach to editing embedded assistance, coming at the task from the user experience perspective and not just the words on the screen. I also co-authored another article (with 4 other STC colleagues) called “The Evolving Role of the Editor,” where our conclusion reminded technical editors to focus on more than the text for non-traditional information deliverables, such as YouTube videos which are becoming viable ways to deliver technical communication. (Contact me at my email address on the About page if you are not an STC member and cannot log in to view those articles.)
At some point in the past ten or so years, I bet that we have all heard that our jobs as technical communicators were going away… that developers would create a product that was so intuitive and so user-friendly that no documentation would be needed. A few of us were slightly concerned, but others challenged our developers to go for it. Technical communicators are now stepping up to partner with developers on designing the user experience and are working to try to remove the need for documentation. I find myself questioning the need for topics (that is, I make the editing comment to delete an entire topic) more and more after having edited graphical user interfaces and error messages. Or, in thinking about the typical user for our product, I find myself deleting entire steps from lengthy procedures because the users don’t need quite so much hand-holding.
Just as technical writers do more than write words, technical editors need to do more than edit words. We both are letting go of the words and using our foundational skills of audience analysis and task analysis to create or modify the user interactions or the user experience. Yes, we still try to communicate clearly, but the communication has expanded to include more than words. This evolution away from a singular focus on words has been happening over the past 20 years, but for some reason I feel like technical editors are only just starting to jump on the bandwagon. I think editing in the broader sense is so closely tied to the writing of words that it is difficult for technical editors to let go of the words and focus on the interactions and experience.
***P.S. I must acknowledge that the title of this post was inspired by re-discovering the Ginny Reddish book, Letting Go of the Words: Writing Web Content That Works, which is now in its 2nd edition.
P.P.S. I found myself an editor! (Just like I said I would in my last blog post.) I might seek out another one! I’m very excited (thus, the exclamation points). This was my first edited blog post.