Tom Johnson wrote a blog post about innovation in technical communication in which he included a quote from a comment from Mark Baker on a previous blog post. It is a phrase in this comment that I want to react to and muse upon today. In talking about how the strategy of information finding has reversed itself thanks to the innovation of the web, Mark said:
Google first; manual maybe never.
As a technical communicator, I do read user manuals, online help, or other product documentation…at least for some things. However, it doesn’t take long before I venture out to Google to search for answers. This phrase really rang true to me.
This turn of phrase within this blog post got me thinking about the future of product documentation and how we really should be re-imagining and re-defining it in the wonderful world of Google. If users naturally seek answers on Google, it’s not enough to just push our product documentation out on the web and make it more findable with SEO techniques. We need different types of information, delivered in different ways, that can more readily answer the questions that are being asked via Google.
Are technical communicators ready to deliver adaptive content, that is “smarter and situation-aware,” as described by this article, “Improve Validation Errors with Adaptive Messages“? In my past experiences, it was a challenge to get my developers to write one really useful error message let alone several that are “adaptive” to the user’s context. Be that as it may, I think that mobile applications almost mandate adaptive content and rich, smart, situation-aware embedded assistance (like validation error messages), because we no longer have online help (and users just do not want online help). Users will always respond more favorably to help that doesn’t feel like help but that just feels like part of the app to begin with. We need to build adaptive embedded assistance into our architectures, into our strategies.
While I have never worked as a freelance editor, I follow several people and businesses that offer freelance editing services. An article “Why is Editing So Expensive?” by Sophie Playle was recently posted by @LouiseHarnby, whom I follow on Twitter, and both are freelance editors. This article clearly explains why editing is expensive, but only after explain why editing is worth the expense. Two of the three reasons apply to working as a technical editor: editing takes time (and time is money) and editing is a specialized skill. Playle not only gives the reasons, she takes the time to expand on the core ideas, and even how writers can help reduce some of the costs of editing. All her ideas are fully developed, well written, and very compelling. I bet she had an editor help her on her article!
For the first several years of my career as a technical communicator, I was a technical writer. I researched, designed, and wrote online help systems for enterprise software products. To use Debbie Chachra’s label, I was “a maker,” which she explains in an Atlantic Monthly article “Why I Am Not A Maker.”
After being a technical writer, I moved into the role of technical editor, which is definitely not a maker, but more of an educator, critic, or caretaker of what is being made or who is doing the making.
I started thinking about this divide between the “maker” and “caretaker” roles, and the perceived value of these roles in various industries as described in Chachra’s article, and I was struck by how there seems to be this “pendulum” of the value for technical editors. Some technical writers go there entire career never working with a technical editor, although many seem to experience the ebb and flow of having one and then not having one. It was about 12 years ago that I researched and wrote “Technical Editing as Quality Assurance: Adding Value to Content,” trying to justify and show the value of being a caretaker for the makers.
In the fast-paced self-publishing world, will the makers brush aside any caretakers or try to take care of themselves?
Last month, I bought a new book that was a primer on information architecture, based off of reading an excerpt that was published to the web. I even wrote a post about that excerpt, “Knowing is not enough.”
Here is my Goodreads book review:
How to Make Sense of Any Mess: Information Architecture for Everybody by Abby Covert
My rating: 3 of 5 stars
I wanted to like this more than I did. Several of her focus areas interested me, or inspired me, but her writing style and the organization of the book was a bit lacking.
Here are the passages that I highlighted, and my own thoughts on what she said:
- “Part of that [knowledge] includes agreeing on what things mean. That’s our subjective truth. And it takes courage to unravel our conflicts and assumptions to determine what’s actually true.”
To understand our messes, so that we can do something about our messes, we must have a common language, a common set of terms, but most importantly a common set of definitions and usage. I recently wrote about how information architects are often terminologists, which speaks to this point about agreeing on what things mean.
- “Knowing is not enough. Knowing too much can encourage us to procrastinate. There’s a certain point when continuing to know at the expense of doing allows the mess to grow further.”
It was this very quote in an excerpt that made me buy her book, and which I already wrote a blog post about this quote.
- In the second chapter, State Your Intent, I highlighted several phrases that I’ll talk about together: (1) “The words we choose matter. They represent the ideas we want to bring in to the world.” (2) “…define what good means for our stakeholders and users.” (3) “Having a strong why will get you further.” (4) “What before how.” (5) “Why, what, and how are deeply interrelated.”
I’m always amazed at how the fundamental journalistic writing principle of “who, what, where, when, why and how” finds its way into so many other areas. I also love that Abby encourages IAs to define their terms (including what “good” means to everyone involved), and use those terms to define why something must be done, what specifically needs to be done, and all of that before you explain or start doing it.
- “As users, our context is the situation that we’re in….Our context is always unique to us and can’t be relied upon to hold steady.”
When architecting information, users are primary and context is a close second. This was a harsh reality to think about and come to grips with, about how unique or wavering a user’s context or environment is. Abby goes on to talk about how “channels” (which transmit information; which I think of as different media or ways in which to deliver information) can “work together to support a single context” or that a single channel “can also support multiple contexts.” Ultimately, because we are trying to coordinate or organize across users, their contexts, and channels, we end up with messes, both big and small.
- Abby spends a good bit of time talking about all the different diagrams and maps that you use to make sense of the messes, with scope, scale, and time all playing a roll in what you depict.
- “Everything connects to a larger whole. Whenever you’re making something, figure out which levels you’re working at…… Being able to zoom in and out as you work is the key to seeing how these levels affect one another.”
To be a good technical editor, you must be able to be both a substantive editor, looking at the big picture and considering how content fits into the whole, and a copy editor, looking at the individual sentences and words, making sure that it is all readable and understandable. To be a good information architect, you must be able to see both the forest and the trees, knowing exactly all the types of trees and foliage that is making up that forest. I loved this idea of zooming in and out and seeing how the levels affect one another. This is so true that you can’t focus on just one level, or you will end up with a mess of one kind or another.
- “When we decide that a word or concept holds a specific meaning in a specific context, we are practicing ontology.” (Wordnik definition of ontology.)
Again, here in Chapter 4, Choose a Direction, she returns to focus on the importance of terminology. She goes on to speak about controlled vocabularies (and eventually taxonomies). The worksheet that she provides breaks the terms down into “Words we say” (with the term, definition, and history of it), “Words we don’t say” (with the term, the reason why not, and the term to use instead), and “Requirements” (breaking them down into nouns and their associated verbs, since she believes that the nouns are created as a result of a verb). Later in Chapter 6, Play With Structure, she says this about taxonomies: “Taxonomies shape our experience at every level. We use taxonomies to make sense of everything from systems to objects.”
- Chapter 5, Measure the Distance, spends a great deal of time discussing setting goals and measuring against them. Among the many, many different types of measurements, she includes “kudos” as well as “complaints,” and other standard web stats or metrics.
- “Ambiguity costs clarity; exactitude costs flexibility.”
This speaks to the technical editor in me, who constantly balances the application of corporate standards, styles, and templates in the name of consistency and exactitude and yet going against those rules in the name of flexibility and hoping for greater clarity.
- “Taxonomy is one of the strongest tools of rhetoric we have.”
As a technical communicator, I received a strong foundation in rhetoric in my studies. Many technical communicators roll their eyes or do not believe that rhetoric plays a role in what we do. I wrote a separate blog post that describes how rhetoric informs all of our decisions.
- “Information architecture is like the frame and foundation of a building.” Also, “When your structure and your intent don’t line up, things fall apart.”
Every book on information architecture draws the analogy to architecture of buildings at some point. It is a good metaphor for describing what this field is all about. Noone wants the building to fall down, and so we work to try to set the frame and foundation by applying the principles of information architecture early and often.
- “Design with, not for.” This quote is actually in the middle of the book in Chapter 4, Choose a Direction, nestled in the discussion of ontology and controlled vocabulary. However, I think it makes a great summary for this blog post. The choice of preposition in this phrase highlights Abby’s focus on language and terminology throughout the process of information architecture. With is inclusive, and for is judgemental (or it is from my perspective). We must work with our users, with their contexts, and with all the knowledge. We need to put our hard hats on and hammer some of those nails, not stay in our suits reviewing reports and pictures of progress.
If you really want to understand the basics of information architecture, from its roots of Web site design, read this excellent long article from Cameron Chapman on WebdesignerDepot. Technical communicators started pulling design ideas from information architecture when they started delivering content to the Web or as part of Web sites. Now, they apply this role and these principles to more than just Web sites.
Here’s the best tweet that links to this article:
I thoroughly enjoyed this information architect’s views of agile development practices in this article “Information Architecture and Agility: A Work in Progress” posted on UX Matters, one of my favorite Web magazines. Agile development is here to stay, so figuring out how the practice of information architecture (or user experience design, or technical documentation for that matter) fits within it is important. It is easy to become frustrated by the agility, but it is definitely a key tool in our professional toolkit, as this author suggests. I loved the question he posed for organizations to consider: how much and when. Good stuff.