- Improving First Run Quality
- Revision, Waste, and Evenness
- Reducing writer errors
- Dumb vs. Smart Revision
Several readers of my posts on revision have pointed out that content gets revised for many reasons. Peter Fournier suggest a distinction should be made between dumb and smart revision. I’ll attempt to do that here.
An initial distinction between dumb revision and smart revision might be that smart revision adds value and dumb revision does not.
Revision based on personal taste
The dumbest of dumb revisions would be a case in which a writer changes existing content because they don’t like the way it is expressed, but without adding any new information of value or making the content any easier to understand. This is just waste, and waste born of vanity. The waste becomes much worse if the content then needs to be re-translated and re-reviewed, which greatly multiplies the cost of the revision.
Telling the difference between smart revision and dumb revision is not always easy. Dumb revsion does not wear a dunces cap that makes it easy to spot. You have to look carefully to find in. Photo by Joe Mabel, Wikimedia Commons
Revision to fix errors
The next case is revision that occurs because the original writer made errors of fact, omission, or usability. The revision is not being done because the subject matter changed, but because the work of composition was done poorly in the first place. This revision is not dumb in the strictest sense, because it does add value. But it only adds value that was supposed to be created by the first writer. A process that allows work to be done poorly and then requires a second pass to fix it is a dumb process.
Revision in response to change
The next case is revision that occurs because the subject matter has changed. This is necessary revision, but we can still ask, was the original content written too soon, before the subject matter had stabilized. The answer to that may well be that the greater evenness is achieved by writing the content earlier even if some of it has to be changed later.
That is a good reason to tolerate some revision, but the question should still be asked, and the process carefully examined to make sure it is optimal.
Revision and the next product version
Sometime existing content is revised to create content for the next version of a product. Content is being revised rather that written from scratch because the version 1.0 content is being reused, with changes, for version 2.0. This is clearly more efficient that writing all the version 2.0 content from scratch, so this is clearly smart revision.
Even so, we can still ask some questions. For instance, if we anticipated that version 1.0 content was going to be reused with changes for version 2.0, did we create that content in a way that would best support that reuse. If not, then the revision process for 2.0 may still be inefficient. And have we thought about what will happen if an error has to be fixed that affects both the version 1.0 and version 2.0 instances of the content? Is our system set up so that revision can be made only once, or will have it have to be made twice? Making the same revision twice is probably dumb revision.
Revision in an iterative design process
Scott Abel notes that some revision is part of an iterative development process, either for the content itself, or for the thing the content is documenting. That can certainly be smart revision. In a good iterative development process, the point of each iteration is to produce new design information. The first draft of the content, then, is part of the experiment to generate that design information, and the second draft is part of a new experiment to generate new design information. Each draft adds value, and so each revision is smart.
Still we can ask, are we designing each revision to generate as much design information as possible. If the iterations are not efficiently designed, then the revisions may still have an element of waste about them.
Revision and feedback
Another case of revision that can add value is when the writer asks other people to review the work and to make suggestions. (I am currently doing this with my book.) If you get useful feedback from your reviewers, that clearly adds value.
Still, there are a number of questions we could ask:
* Is the feedback process optimally designed? For instance, are we selecting the optimal set of reviewers? Are some of the reviewers motivated more by power than quality considerations? Do we know what the incremental value add is for adding one more reviewer to the process.
* Are we capturing the value of the feedback in a way that can impact future content development. In other words, are we looking for patterns we should apply to new content, rather than relying on feedback to find the same issues over and over again?
* Are we assigning the right writer to the job in the first place, or does the assigned writer rely on feedback just because they don’t know the subject matter or the audience well enough?
Revision and the author’s thought process
Marcia Riefer Johnston suggests that revision is often part of the author’s thought process in creating the original draft. Leigh White suggests that:
… before the advent of word processors and computers, we wrote inside our heads and now we write outside of them.
This suggests that revision — moving words and phrases around on screen, has become an integral part of how we write even our first draft. Whether it is more efficient to write inside or outside our heads, this is not really revision. It is not picking a piece up and changing it later in response to some event, it is simply how writing gets done.
At the same time, I think it pays to look at what is going on when we write this way. When we write by moving snippets of content around, we are searching for the best way to organize the content, we are, in effect, designing the content — creating its order, shape, and logic. Many pieces of content have ad-hoc designs. You can’t take the design and reuse it for the next piece of content you create so you have to go through the effort and expense of information design for each item you create.
But technical communication, isn’t like that. Most of the content designs we create can be reused from one feature to another or one reference entry to another. If the writer is redesigning the content type each time they write a new instance of that type, rather than reusing an established, tested, and known-good design, that is very wasteful. Not only is the initial revision involved in doing a new design wasteful, but it is likely to lead to more revision down the road as the untested design passes through review and is published to customers.
All these cases suggest that a different definition of smart revision is needed. Smart revision is not any revision that adds value, because in many cases those revisions add value that could have been added the first time the content was written, or that could have been added in a more efficient and effective way by making other changes in the content creation process. Dumb revision adds value, but it does it inefficiently because it is part of a dumb process. Smart revision adds value because it is the optimal way to add that value in the overall process.
Can you suggest other examples of smart and dumb revision?
Excellent post. My example of a dumb revision is one I’ve encountered many times. My technical writing pieces are mainly announcements to our customers of something that has changed that affects our software or processes. For most teams that I have worked with, members of our client support team have had early involvement in the process, in order to ensure that our customers’ most likely questions are covered. One team, however, refused to get involved until (literally) the last review before publication. At that time, they ALWAYS decided that I needed to rewrite whole sections of the document. And then the document would go through evryone else’s approval all over again. That was clearly a bad process, and a textbook case of what constitutes a dumb revision.
Thanks for the comment, Darlene.
That is indeed a great example of dumb revision. It also sound like a classic case of lack of evenness across the production process. They uncooperative department may be optimizing their own process by this behavior, but they are cause inefficiencies for many other groups, thus creating more total waste in the system. A classic case, perhaps, of the fallacy of optimization in isolation.
I like reading your articles. You bring up some good points and offer ideas for enhancing our workflows and writing processes.
One thing has been bugging me and that’s the use of some of the terminology. It think using smart and dumb may be misleading. It could be inferred that a smart revision is somehow dynamic and more automated. But, that aside, I’d prefer to use terms that are more descriptive of the intent (at least the way I read it).
I suggest using Efficient and Inefficient. We are always striving for maximum efficiency, but when we encounter situations that you discuss in this article we are often inefficient. In my mind this also places focus on the process and not on the people. For some reason I take dumb a little personally (I’m smiling…).
Thank you for taking the time to share your insights!
Thanks for the comment, Suzette.
You raise a good point about “smart”. It is so often used to mean machines being smart that it has almost lost the connotation of people being smart.
Perhaps it might be best to borrow terms from Lean and refer to wasteful revision and non-wasteful revision. Or perhaps, since non-wasteful is a bit of an awkward phrase, wasteful revision and productive revision.