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.
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:
Some demand a title and label every step as a step:
Printing a document
Step 1. Click File. The File menu opens.
Some use tables to lay out procedures:
Printing a document
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>