Connie Giordano has an interesting take (and a reader poll) on technical writing as a craft vs. a commodity. She’s writing something of a rebuttal to my post about the same topic. When I checked before posting this, the results were tilting towards “Tech writing is a hybrid profession,” slightly ahead of “Heck yes we’re craftspeople!” I voted for “hybrid” even though I’m not entirely sure what that means. But I think it’s closer to my argument.
And the answer is…
This result surprises me: I assumed that with the readership of Techwhirl would lean heavily towards the statement “Tech comm is a craft that requires skill, acumen, and ingenuity.” I mean, that’s seems like the most tempting answer for techcomm people (myself included). If only she’d written “requires skill, acumen, ingenuity, and breathtaking levels of sexiness,” then I bet the results would be leaning the other way.
Ok, I’m poking fun, and that’s not fair. Because her post is very fair, and she’s written a good analysis of the issue. This statement in particular got me thinking:
But the act of creating content is a far different thing than the act of delivering it to the targeted audience. Well-implemented standards to help structure and simplify content may drive efficiencies and improve the bottom line, but will that resulting content resonate with a user and make their lives easier or more enjoyable?
There’s a lot of stuff packed into those two sentences. It’s true that creating content (written, visual, video) is not the same as presenting that content to the customer who is turning to the help (knowledge center topics, videos, PDF manual, whatever). I think we’ve reached a consensus that content creation and content publishing should be separated, and the person doing one shouldn’t worry about the other (at least not while they’re engaged in either end of the process).
Creating vs. publishing
That’s a convoluted way of saying: when you’re writing the docs, you shouldn’t think about the formatting stuff. And when it’s time to publish that content, the person doing the publishing shouldn’t have to understand how the content was created.
But…we do, don’t we? We might not worry about the specific font that’s going to be used (but good luck finding a tech communicator who isn’t passionate about fonts), but we do need to indicate when something will be displayed in a different way. Whether you’re just applying bold to a word, or tagging it as a UI control, or building a video as part of a channel, or sequence of videos, you are determining how that content appears to the user. The details are defined separately, but we still need to make that determination during the creation process.
And then there’s this sentence:
Well-implemented standards to help structure and simplify content may drive efficiencies and improve the bottom line, but will that resulting content resonate with a user and make their lives easier or more enjoyable?
And I honestly don’t have a good answer. My immediate response is: No! Any content built from tiny blocks of carefully neutral (and neutered) language, stripped to the barest essentials to allow for maximum reuse and ease of translation, will not be engaging. It’s the techcomm equivalent of boiled vegetables: bland and mushy. All of the character and tone has been leeched out of it so the content can be slotted into any context without looking awkward. Or interesting. It’s just one of many bland, monotone building blocks used to construct the product documentation.
Except…Lego pieces are also bland and monotone (ok, not all, but work with me). And damned if you can’t build some amazing things with pieces that are pretty boring on an individual level.
Art vs. commerce
But I don’t think that many of us consider ourselves artists. Structured writing reduces any artistic idiosyncracies that can make each piece of content a little too lopsided to interlock properly with the other blocks. We’re doing a job, and we’re looking to maximize the quality of what we produce, and very often the quantity, too. While reducing overall costs.
But: “will that resulting content resonate with a user and make their lives easier or more enjoyable?”
I wish that “Yes!” was the obvious answer. But if you write a piece of content as a whole (a single workflow topic, or an overview and then a procedure), you build in a sense of flow. Assembling a document from sub-pieces doesn’t allow for that flow.
Every chunk of content is a commodity, to be tagged, cataloged, and used wherever and whenever possible. Will this resonate with the user?
Should it? We want to answer a question as quickly as possible. Our job is to help the user get back to work and produce value for their company (and thereby justify the value of our product, increase sales, and so on). The content needs to “resonate” with that user to avoid or calm the user’s frustration.
Maybe a sense of flow isn’t required. Maybe the readers don’t notice, or can accept a slightly disjointed topic in exchange for focused, streamlined information. And what would “flow” look like for an API reference, anyway?
Back to the death of technical writing
One last observation. Connie Giordano’s bio includes a skill summary that should be familiar to many of us:
She can change hats faster than a NASCAR driver at a press conference, switching between technical writer, knowledge manager, information designer, product manager, pubs manager, project communications lead, UI designer, communications consultant, and change management specialist, among others.
This is the point I’ve been trying to make: Even though she “serves at the Editor for TechWhirl’s Tech Writer Today online magazine, as well as a frequent contributor,” she’s clearly not “just” a technical writer. Connie lists an impressive array of skills, many of which fall under the “technical communicator” umbrella. But product manager and change management specialist are entirely different fields, and extend far beyond what the traditional Technical Writer role includes.
You don’t need to build a site like TechWhirl to stay relevant, but relying on writing and editing skills alone just won’t work anymore.