T. R. Girill
Society for Technical Communication/Lawrence Livermore National Lab.
Technical Writing: Authentic Text Engineering
One way to find authentic technical writing advice for students is
to explore what working professional scientists say to each other
when they complain about the poor writing of colleagues or try to
encourage their peers to write better. In 2017, Public Library of
Science (PLOS) published an open-access editorial that reveals such
shared advice for free for any reader:
Brett Mensh and Konrad Kording, "Ten simple rules for
structuring papers," PLOS Computational Biology, 2017,
Most of the comments here address writing a formal research article
for professional colleagues--suitable for college students interning
at a lab, perhaps, but not really focused on high-school writing
tasks. However, two specific suggestions within this editorial apply
much more broadly, and benefit struggling writers of any age. Both
promote "text engineering" as a helpful, insightful writing strategy.
Draft Like a Designer
One broadly helpful suggestion from Mensh and Kording is to "think
like a designer" when one writes nonfiction (p. 2)..."for each [text]
element, determine the IMPACT that you want to have on people and
then strive to achieve that objective."
Many novice technical writers forget that in life beyond school,
every text has an audience. Working backwards from the cognitive
needs of those readers/users reveals the content and presentation
decisions that the writer needs to make--everything from vocabulary
choice to level of detail, topic organization, and text labels.
As any engineer knows, projects that fail to meet user needs just
fail, regardless of their other superficial features.
Mensh and Kording also note that writers-as-engineers need to
pursue such text usability "at multiple scales." Individual
sentences, topical paragraphs, and overall text structure all
benefit from taking the designer's perspective. This responsibility
can get a little intimidating for novice writers, of course,
which is where their second text-engineering suggestion really
Writing as Text Optimization
Inexperienced writers often assume that drafting text is like
breaking an egg, with no way to repair or backtrack. Hence, they
hope for perfection on the first draft and lack a plan for
improving after that.
Mensh and Kording point out that instead nonfiction "writing is
an optimization problem" (p. 8), where backtracking and repair
are always in play. From the text-engineering perspective, every
nonfiction draft is a PROTOTYPE open to refinement and revision,
which should be cultivated as opportunities rather than avoided
as trouble. Regarding one's drafts not as personal "failures"
but rather as prototypes that enable further optimization can
also help teen/tween writers overcome general confidence problems
or excessive fear of mistakes.
Iterative improvement, often through several adjustment cycles,
is standard practice to optimize engineering designs, for both
software and physical devices (medical, mechanical, even
chemical). The same strategy benefits technical writing.
Perceptive self-critique is a life skill worth cultivating
whenever one writes. Even more helpful and shortcome-revealing
is feedback from others during revision, especially from
test readers/users astute enough to offer constructive suggestions
on draft text rather than merely complaints.
Finally, as already noted above about audience analysis, such
iterative text optimization needs to occur at all scales, from
fixing grammar flaws through adjusting content details to focusing
the overall theme. (But naturally, one should fix the grammar
last to avoid wasted work on whole paragraphs later deleted.)
Even young students now meet engineering design through
NGSS-compatible lessons. Recognizing their own text as yet
another domain in which to apply good-design principles can be
both helpful and comforting.
[Want more background on technical writing in science class? See
Want to help students see their writing as another case of
engineering design--as "text engineering"? See