It seems that anyone working in an i-space (information, interaction, interface, or dare I say Internet) feels compelled to define who they are and what they do (or what value they provide). Technical communicators have been doing this since the late 1980’s and continue to do it to this day. We constantly redefine our roles and tasks (technical writer, information developer, technical communicator; information architect, user experience, or content strategist; technical editor, oh wait, they seem to have remained with that role) as the i-space redefines itself with the changes in technologies.
As I read this article, “7 Things I Wish Everyone Knew About Interaction Design,” by Chris Noessel, who is the author of one of my favorite books, About Face: The Essentials of Interaction Design, I was struck by the similarities and overlaps with technical communication. In particular #2, #3, and #4 in his list:
- #2 is his elevator pitch for what it is he does. He says that interaction designers help answer 3 questions: Who? How? and Does it Work? Technical communicators also answers similar questions.
- #3 is his confession that it is really hard to do. This made me think about one of my favorite quotes about writing from Mark Twain: “Writing is easy. All you have to do is cross out the wrong words.” He explains that it is hard work because you have to know many disparate domains and you have to be an expert at dialogue and facilitation. Yes and yes, technical communicators face these same challenges. I think that is why we must constantly define ourselves and what we do, because we do have to understand many different domains and be able to collaborate with many different people.
- #4 is his claim that personas and scenarios are his best tools. Again, this is right on the money for technical communicators, too. The more we know about our users, the better our information will be. The more we can tell a story for our users, the better our information will be.
Whether I am writing blog posts, editing error messages, or architecting embedded assistance in a mobile application, I’m working for the user, or the consumer of the information. I must synthesize many ideas from many domains for many “masters” in our organizations, all in service to the user.