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>
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.