I was very impressed by Ellis Pratt’s presentation at the 2012 STC Summit, “What Should Technical Communicators Do When Products ‘Just Work’?” (If you missed it, and you didn’t purchase Summit@aClick, he’s repeating it as an STC-sponsored webinar on July 10.) He identifies a product trend away from “big and scary and likely to break” to “it just works,” and discusses how that trend affects user information. His ideas sparked some of my own in two areas: on levels of information and on the idea of letting customers document products for you.
Levels of information
I have documented products with big and scary interfaces that were likely to break. (If you only knew how easily…) I agree that today’s products effectively hide their complexity. The programmable interfaces of early computers were hidden and eventually replaced by command-line interfaces, which in turn were hidden and ultimately replaced by graphical user interfaces. The touch interface hides even GUI complexity, and it will soon be more correct to say that touch interfaces don’t simply hide but replace GUIs. (Already, when my son shows me something on his laptop, I find myself trying to touch the screen, which annoys him. “Stop doing that! It’s not your iPad” he says. “Doing what?” I say, momentarily nonplussed.) Today’s products are more powerful than ever, yet their user interfaces are simpler. But the complexity still exists. Today we’re learning the difference between touching a tablet with one, two, three, or four fingers. (Can five be far behind?)
Looking at software products, there are obvious examples of products that are common and “just work.” Every browser has a search box, and most of them point to Google. Using Google has already become a verb (“I googled the answer”).
There’s no Google manual or Google online help. But do we need it? By now everyone knows how to perform an effective Web search using the Google engine, right? Not so. There are powerful search features hidden under the surface, including Boolean searches, searches with exclusions, searches limited to the body of Web pages, proximity searches, and a lot more. (What does adding a minus sign to a keyword do? How about a plus sign? Are you sure?) Not one person in ten knows more than the first of these features, and not one in 100 knows even what I listed here.
(An aside: Why bother paying a technical communicator to document ubiquitous products when everyone is posting tips and tricks to the Web? Let me turn the question around. Posting tips and tricks a few at a time is very inefficient. Why do users feel compelled to do it? Is it because they can’t find them from the vendors? And another thing: Google paid many talented software engineers to create those features that arguably few users know about. They apparently didn’t pay to have these features documented, but they paid to create them. And they’re hardly alone in this practice. If paying to document features nobody uses is a waste—and I agree that it is—how about paying to develop and test them?)
I think Pratt has definitely identified a product shift we as technical communicators must deal with: the simplification of user interfaces, at least for computer-related products. As I said, by now we’ve seen several generations of simplification. Nothing is ever really intuitive, but over time people generally learn how to use common product interfaces. Until the next big thing comes along, which we’ll have to explain, this is not where we should concentrate our energies.
But there are levels, or layers, of information. How to manipulate a product’s user interface is only the lowest level. Unless the interface is unique, we can strategically retreat from that level and still find plenty of ground to cover. The next level is how to work the product; that is, what tasks can be accomplished using the product. You could write a generic description of a web browser interface and use it verbatim for ten thousand products. But what information the user has to enter in the fields… ah, that’s the second level, and there every product is different. We still need to document that second level.
There’s also a third level, which is the description of local procedures specific to one set of users. We cannot even see that level when working for OEMs. For example, when I want to take a day off from work, I have to create a paid-time-off request in my company’s HR database. It’s an off-the-shelf Oracle application, but customized by my company, so the Oracle writers can’t tell me what code to enter.
The wisdom of crowds?
Google and other search engines represent both a threat and an opportunity for technical communicators. We are increasingly asked to provide online information amenable to search, even to the extent of abandoning indexes and tables of contents; or to outright post user information to the Web so search engines can find it. And, some actually say, why even bother? So many people are posting to forums and to YouTube with product information that we might as well let the magic of the marketplace document our products for us. (You can pick up your last check on the way out.)
It’s true that for certain classes of consumer products plentiful information is available online. There are some distinct advantages to third-party information. Use cases are best coming from actual use. You may not be allowed to describe problems with your product, but the crowd will find it. I daresay most of the product information on the Web is accurate, and, for well-regarded products, I daresay most of it is positive. But any company that relies on its customers to provide free documentation will get what it pays for, and by doing so it abandons control of the message. Even for consumer products that I know are federally regulated and carefully documented, such as lawn tractors, you can go on YouTube and see videos of misusage that would make their corporate lawyers’ heads explode. No company that sells a product that can injure or kill their customers can ignore legal liability and let the crowd teach each other how to use it. Can yours? It depends on whether you think something like this inspires caution or emulation. (If it were my company, you’d have me at “legal liability.”)
Go to the Apple support forums with a problem and search for a solution. (Believe me, I have.) You will find lots of posts from people with the same problem, perplexed and angry and exchanging ideas that don’t work. A heroic few know what they’re talking about and struggle to answer the questions. With luck you can discern which ones are which. It doesn’t leave a favorable impression. And this is for the company that enjoys the highest customer satisfaction ratings in the industry! Your product will do worse. Remember, a dissatisfied customer will talk to more people than a satisfied one; the ratio I’ve seen is three to one.
Speaking as a consumer, then, I regard information posted to the Web as suspect, because it isn’t uniformly positive or even correct. This is equally a problem for information producers. If you don’t control the message, you might not like the result.
Finally, if I haven’t yet disabused you of the notion of crowdsourcing, if your product is regulated, not a consumer product, proprietary, military, or (in my case) the user community is small, you can’t even dream of crowdsourcing, because you just won’t have a crowd!
So, all in all, are you sure you want to leave your documentation to the crowd? I didn’t think so. If someone suggests it, I think these are all persuasive counterarguments.
Steven Jong 