Content Engineering is Not Technical Writing

By | 2013/11/13

My last post, I am a Content Engineer, was taken by several people as yet another attempt to rebrand technical writing. I’m honestly a bit mystified by how people could interpret some of the examples of content engineering that I listed as being examples of technical writing, but Hi Ho. Let me set the record straight:

  • Content engineering is not technical writing.
  • Tool building is not tool using.
  • Bridge building is not bridge crossing.
  • Loom building is not weaving.
  • Car design and manufacturing is not driving.

Now, it certainly helps enormously if the people who build tools also understand the task of the people who use the tools. Bridges designed by people who have never crossed, looms by people who have never woven, cars by people who have never driven, are not likely to be very good.

A loom.

Content engineering is not technical writing, any more than designing and building looms is weaving. Photo by Aranel, Wikimedia Commons, CC BY-SA 3.0

On the other hand, the mere experience of crossing bridges, weaving, or driving does not remotely qualify you to build bridges, looms, or cars. Each of these, bridges and cars in particular, require a high degree of knowledge about materials, structures, and mechanics that no amount of bridge crossing or car driving will teach you. They require, in short, engineering knowledge and experience.

Someone who does content engineering, similarly, benefits greatly from experience in creating content, but such experience is not sufficient. They also require appropriate engineering knowledge: knowledge we might sum up as an understanding of the computability of content.

An example is probably the best way to make the distinction. Consider how procedures are typically formatted. Different companies have different styles. Some use simple lists:

  1. Click File. The File menu opens.
  2. Click Print. The Print dialog opens.
  3. Click Print. The Print dialog closes and the document is sent to print.

Some demand a title and label every step as a step:

Printing a document

Step 1. Click File. The File menu opens.
Step 2. Click Print. The Print dialog opens.
Step 3. Click Print. The Print dialog closes and the document is sent to print.

Some use tables to lay out procedures:

Printing a document

Action Result
Step 1. Click File. The File menu opens.
Step 2. Click Print. The Print dialog opens.
Step 3. Click Print. The Print dialog closes and the document is sent to print.

Typically, whichever style is preferred by the company will be specified in a style guide. It is then up to the writers to remember to use this approved style each time. This is a craft process, not an engineered process. Writers are free to deviate from the approved style, and will not receive any feedback or warning if they do so. The only way the error gets caught is if a human editor reads the copy and spots it. A fair degree of style variability is almost certain in such a process unless a lot of time and money is spent on manual verification.

Engineering a process is very much about reducing variability. Not only does reducing variability (of this sort) improve quality, it also improves process by enabling greater automation. An automated process is one that runs without human inspection and intervention. To create a reliable automated process, you have to eliminate variability in the inputs. Garbage in, garbage out.

A simple approach to engineering the format of procedures is to create a style template in your word processor or desktop publishing application. This can help improve consistency, and reduce the work required to produce properly formatted procedures, but you will still experience a pretty high degree of variability because some people will forget to use the style, or will use it incorrectly.

The next step in engineering the creation of procedures is to adopt a structured writing approach, perhaps using XML. In this case we could create markup specifically for procedures which might look something like this:

<procedure>
  <title>Printing a document</title>
  <step>
     <action>Click File.</action>
     <result>The File menu opens.</result>
  </step>
  <step>
    <action>Click Print.</action>
    <result>The Print dialog opens.</result>
  </step>
  <step>
    <action>Click Print.</action>
    <result>The Print dialog closes and the document is sent to print.</result>
  </step>
</procedure>

From this markup, any one of the formats above can be generated by a simple script. Since the formatting is now being done by a script, it is impossible for the author to get the formatting wrong. If authors write using this markup, they no longer need to know how to format a procedure, and you will get little if any variability in the formatting of procedures.

And this markup not only removes formatting concerns from the author. It also captures a specific style for writing procedure steps: the action-result style. The table-based formatting above enforces this style visually, but the other two formats do not. If the company wants all procedure steps written in action-result style, that would be another entry in the style guide, and another item that would not be implemented consistently by busy authors, again leading to undesirable variability.

The markup version no only abstracts out formatting concerns, it also enforces this style of procedure step writing. (True, an author can deliberately subvert this style requirement if they want to, but they can’t forget the requirement. This example does not engineer out deliberate vandalism, but it engineers in enhanced reliability for authors who are willing to comply but might otherwise forget the requirement.)

Another advantage of the markup approach is that it allows you to present the procedure differently on different devices. On paper, you might want to use the table style, but on a phone screen, lacking the space for a table, you might want the use the simple numbered list style. Here we are engineering the content creation process to build in flexibility on the output side.

This is a very simple, low-level example of how content engineering can engineer out variability on the input side and engineer in flexibility on the output side. We could take it a lot further, and I will show you how in another post.

This is also pretty small scale content engineering. Content engineering can concern itself with the content lifecycle on a grand scale. But in fact content engineering starts with small things like this, because driving out variability and building in flexibility are the foundations on which successful large-scale content engineering is based. The more reliable the content data that enters the content workflow, the more fully and more reliably the rest of the systems can be engineered. Huge amounts of cost can actually driven out of the systems simply by driving unwanted variability out of the source data through simple techniques like this.

But none of this is technical writing per se. It is tool making and process engineering for technical writing. A deep knowledge of technical writing is certainly important for people doing this kind of content engineering, but the content engineer is not writing the content themselves, they are creating the tools and processes to allow the content to be created more efficiently and with less undesirable variability. This requires a different set of tools and a different set of skills.

Certainly some technical writers are also content engineers, in small ways and in large. I have always tended to engineer my own tech writing environment when I was working as a tech writer. But the two roles remain clearly distinct, even if occasionally practiced by the same person.

23 thoughts on “Content Engineering is Not Technical Writing

  1. Keith

    I disagree on one point: reducing the degree of variation does not automatically improve quality. That may be true in machining and assembly-line production, but it is not a given in documentation. You can standardize and homogenize things so far that the result is boring. Even technical people don’t like reading something that bores them. People become mentally numb and stop actually thinking about what they’re reading when they have to read the same thing over and over and over and over and over and over and…And some people will go the other way and be ready to scream and throw the manual out a window when they read “Step 1: Start the…” for the 89th time.

    In documents, even technical documents, a little bit of variation can make the results easier on the reader by preventing monotony.

    Reply
    1. Mark Baker Post author

      Thanks for the comment Keith.

      As a writer, I sympathise with your point, but looking at the total content strategy picture, I’m afraid I can’t agree with it.

      For one thing, people don’t read tech comm to be entertained. They read it to solve a problem, and their fundamental engagement is with the problem, not the text. They want a text that is useful, not one that is entertaining.

      For another, the cost of the variability you are talking about is extraordinarily high. It increases costs all down the line from content creation to content management to translation. It can create confusion for readers, particularly for those who are not reading in their native language.

      So while variability is a desirable part of literary style (at least in English, with its monstrous vocabulary) it really is too wasteful, and too incidental to the value being created, to be considered desirable in tech comm.

      Reply
    2. Roy MacLean

      One thing that certainly needs to be ‘standardized and homogenized’ is terminology. I observe in general writers a – probably unconscious – tendency to ‘synonymize’. For example, one sentence refers to ‘the payment’; the next to ‘the transaction’ – are these the same? Probably, but who can tell? If consecutive statements refer to ‘the payment’ (and no ‘it’, either), then that’s good, not boring.

      Reply
      1. Paul Hanson

        My favorite is when I read release notes that include a change to 3 different menu options. You can tell 3 different people wrote the release notes when you see something like this:

        [Menu Option A] – Modified the program to add XYZ functionality.
        [Menu Option B] – Changed the program so that XYZ is available when …
        [Menu Option C] – Altered the program to allow XYZ …

        I would love to read “boring” release notes so I don’t have to figure out the the difference between “modified”, “changed” and “altered”?

        Reply
        1. Mark Baker Post author

          Thanks for the comment, Paul.

          Yes, I’ve seen that a few times. This is the sort of thing I try to factor out when I create a structured writing system. These are boilerplate sentences that just need a variable substitution for XYZ. Why make authors type them over and over?

          Reply
      2. Mark Baker Post author

        Thanks for the comment, Roy.

        I agree. I don’t know if this is unique to English prose style, where we have so many close synonyms to choose from, but people trained to write in English tend to have this drummed into them both by teachers and by example. We don’t like to repeat the same word, so we choose synonyms, sometimes several in a short passage. Fine for literature; bad for tech comm.

        Too little is said about how much writers need to unlearn before they can become good technical writers. Another thing they need to unlearn is the idea that a writer is supposed to grab and hold the reader’s attention for as long as possible. Again, fine for literature, but in tech comm the goal is to get them back to work as soon as possible, not to keep them reading.

        Reply
        1. Gene Kim-Eng

          This is one place where starting out “technical” helps. Engineers don’t worry about whether using the same size screw, washer or nut over and over again is repetitive.

          Reply
  2. Gene Kim-Eng

    I don’t disagree with the idea. I just hate that title because I think it SOUNDS like an attempt to rebrand technical writing, and I think the fact that you need to defend it like this within our own profession proves that I’m right about that.

    Our profession is based on the clear delivery of concepts and information. A title that is confusing even to us is bound to be even more confusing to outsiders.

    Reply
    1. Mark Baker Post author

      Thanks for the comment, Gene.

      It is certainly true that the constant (and uniformly unsuccessful) attempts to rebrand technical writing have left many in the field hypersensitive to yet another name for the same old profession. (In this respect, I think it is apt to be far more confusing to insiders than to outsiders who have no idea technical writing — if they have even heard of it — is ever called anything else.)

      Be that as it may, content engineering seems to be the term that has stuck. It has certainly been in use for over a decade and seems to have been independently coined in more than one place. (I was midwife to one of occasions where it was coined, so I bear some responsibility.)

      And because we are now increasingly dealing with larger integrated content sets which cannot be successfully wrangled using traditional craft methods, I think we are going to be hearing the term more often.

      Actually, as the term becomes more widely used and more widely recognized, perhaps the confusion with technical writing will disappear.

      Reply
  3. Chris Despopoulos

    I think the fact that a discussion about content engineering has the resonance (positive or negative) that it has is indicative… Exciting times, and big changes to how we think about content!

    Since Ted Nelson brought hypertext into the popular vernacular, we’ve been confronted with content that is more than a static artifact. For static content artifacts, management and control is largely social — determining incentives to produce (royalties), production and distribution chains (lots of people moving STUFF), controlling access (book burning/banning), freeing access (libraries usually funded socially), and so on.

    When content is increasingly dynamic, that changes the equation. You either manage those dynamics or you get managed by them. Authority is hard to pin down, filter bubbles proliferate (http://www.thefilterbubble.com/ted-talk), content piles up, and it’s more difficult to tell knowledge from rumor, information from data, fact from fiction.

    All that is highbrow, but we have immediate and concrete issues. Content dynamics should match situational dynamics. A developer wants different dynamics than a casual reader. Marketing wants different dynamics than tech support. Some choices are stylistic and aesthetic, but even style serves a distinct purpose. Graphic designers know that, and balance legibility with impact when designing a message. When designing content, we now have to balance dynamics with whatever else we throw into the mix.

    You can imagine all the dynamics you want, but to realize them you need engineering. Just like engineering is required to mass produce color copy — first in the printing industry, then later in the desktop printer industry — engineering is required to have your content:
    * Perform visual dynamics (show/hide, blink, link, etc.)
    * Include other media (video/audio)
    * Support collaboration (reader inputs)
    * Support re-use in all its flavors (role-based dynamics)
    * Incorporate on-the-spot changes and system states (IETMs)
    * Execute processes (forms)
    * Other???

    All these things are possible, now more than ever before. It takes project managers or creative staff to work out the WHY — Why bother implementing this stuff? What’s the goal? It takes engineers to work out the HOW, including methodology, maintenance, ongoing process, and cost. But the point is, we now have lots of reasons to ENGINEER our content. And maybe we have enough reasons to justify a separate discipline — we may as well call it Content Engineering, eh?

    Reply
    1. Mark Baker Post author

      Thanks for the comment, Chris.

      I agree entirely. And I think you provide a very important insight on why content engineering is increasingly important. Traditionally, the final format in which content was presented was determined by the pen of the author inscribing the final form on parchment. Ever since, we have been progressively moving the determination of final form further and further away from the author. The printing press moved it one step, single sourcing another, reuse another, and true dynamic publishing moves it further still.

      Thus the author can no longer continue to work in a craft environment in which they can judge the correctness of their work by its immediate appearance. The final format of their content is now unknown and unknowable at the time of authoring and it is therefore essential that they work in an engineered authoring environment in which the judgement of correctness is done in engineering terms, not by visual inspection.

      Reply
      1. Gene Kim-Eng

        Authors haven’t scribed the final form of their work since before the days of Gutenberg. What you’re essentially talking about is turning back the clock a bit to the days when writing, illustration, page layout, camera work, typesetting, etc., were done by different people. I certainly wouldn’t object if there was another warm body available to take the design and implementation of information delivery off writers’ hands so they can concentrate on the research, writing and verification of information. I just am not terribly confident that we will see all that much of it being signed off on by management that already is reluctant to spend money on technical writers.

        Reply
        1. Mark Baker Post author

          Gene, yes, since Gutenberg, which is why I listed the printing press as the first step away from final form being fixed at authoring time.

          I suppose there is a sense in which this is turning back the clock, in the sense that the author is no longer doing all those other steps. But in this case we are talking about them being done by algorithms, including algorithms that run at read time, not print time, so that is a pretty substantial difference.

          Lots of people are getting this sort of thing signed off by management, because they can show significant savings and significant quality improvements. But there is still a long way to go before everybody catches on.

          Reply
  4. Jonatan Lundin

    So is an information architect a sort of content engineer? And is a content engineer a sort of technical communicator (or is a technical communicator a sort of content enginner)? Hi ho

    I have always thought that the wording “content” feels kind of awkward. Content engineer becomes a kind of a paradox (or any other role including “content”). “Content” implies that your are dealing with “something” in a bucket and you do not really care about or know what it is, but it is the something in the bucket you are engineering, in contrast to “Information” that implies that the something in the bucket is what you care about. Information engineer? Hi ho

    Reply
    1. Mark Baker Post author

      Thanks for the comment, Jonatan.

      No, an information architect is not a sort of content engineer, though they should have some content engineering skills. But your question inspired a whole post to answer it: /2013/11/18/we-cant-use-in-tray-definitions-for-content-roles/.

      Personally, I am with you on “content”. I hate the word. It should have been “information”, but a bunch of bit jockeys beat us to it (though somehow the information architecture folks managed to claw back a piece of it). It might also have keen knowledge, but knowledge management also means something different. So Hi Ho, it is the word we are stuck with.

      Reply
  5. Joe Pairman

    Great post, Mark. Very clear (though I felt the previous one was clear enough too!) I think there comes a time to accept that a term, even if not perfect, is the one that’s widely used enough and descriptive enough to be the best one for the job. Like you, I feel that “Content Engineering” has reached that state.

    Jonatan, lots of people in this role are indeed called “information architect”, but it could invite confusion with the role of web information architect, which is primarily concerned with the organization of content on websites. Regarding your qualms about “content”, there has to be some word that’s broad enough for the range of media that we deal with. (“Information” doesn’t really cover entertainment content, for example.) And having such a word doesn’t necessarily imply disrespect or commoditization. Rachel Lovinger wrote a good piece on that here: http://scattergather.razorfish.com/1401/2013/10/29/the-trouble-with-content-part-1/

    Reply
    1. Mark Baker Post author

      Thanks for the comment, Joe.

      Agreed: at a certain point terminology sets hard and after that there is not much to be gained by trying to change it. For good or ill, “content engineering” and “content” are here to stay.

      And there is always something wrong with every choice of terminology. There are not enough words to go round, and every word you could possibly choose has an array of distracting connotations. I have long subscribed to the notion that words don’t have meanings. Words have denotation and connotation, but the sentence is the smallest unit of actual meaning.

      Reply
  6. Pingback: We Can’t Use “In Tray” Definitions for Content Roles | Every Page is Page One

  7. Michael Andrews

    Mark, Your example in this post clarifies your point nicely. Separating content fron presentation does allow for content to be expressed in multiple ways, which might be valuable for both content editorial staff and audiences that prefer different styles or formats. You can take your engineering argument further by applying to your ideas on content behavior. For example, some audiences want interactive content while others don’t.

    Reply
    1. Mark Baker Post author

      Thanks for the comment, Michael.

      You raise an important point about user preferences. Users are increasingly free to consume content in the way that pleases them. This creates a challenge not only for content design, but for the content engineering necessary to provide all the choices that users might want.

      Reply
  8. Pingback: The Best Job I Ever Had | Every Page is Page One

  9. Henry Smith

    Writers should be vibrant and should be able to change style of writing as per requirement. This will not only make every articles or content interesting but also inspire you to do more innovative works than what you are doing now.

    Reply

Leave a Reply