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.
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:
- Click File. The File menu opens.
- Click Print. The Print dialog opens.
- 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
||The File menu opens.
||The Print dialog opens.
||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:
<title>Printing a document</title>
<result>The File menu opens.</result>
<result>The Print dialog opens.</result>
<result>The Print dialog closes and the document is sent to print.</result>
In the closing keynote of the 2013 LavaCon conference, Ann Rockley talked about the rising importance of content engineering in content strategy. A content engineer, Ann explained, is someone with one foot in the technology world and one foot in the content world. Last year I wrote a pair of posts on my hesitation about taking on the label of content strategist (Am I a Content Strategist?, I Am a Content Strategist). I have no such hesitation about the label of content engineer. I am a content engineer, and I have been one for many years.