Welcome to the high school science teacher leaders group! Ask questions, start a topic, or share information related to high school science teaching and learning, or leadership.
Technical Writing: Interpretive Clues That Good Writers Provide
T. R. Girill
Society for Technical Communication/Lawrence Livermore National Lab.
Technical Writing: The Interpretive Clues That Good Writers Provide
How do readers of technical text manage to find answers to the questions
in their heads? By watching for signals within that text placed there
by the writer to help them. When three IBM computer scientists tried
to see if software could also answer questions from text (for example,
finding procedures buried within much larger reference documents), they
exposed just how two separate but parallel sets of writer signals
complement each other to help readers in their hunt. Their software
became 80-90% effective and the analysis that they used to design it
offers a lesson for student writers in what text signals they need to
provide to enable such reader success (S. Agarwal, S. Atreja, and
V. Agarwal, "Extracting Procedural Knowledge from Technical Documents,"
arXiv.org/abs/2010.10156, October 2020).
So what interpretive clues did the IBM team exploit to enable their
software to (learn how to) locate procedural knowledge amidst other
technical text? One type of signal they called "structural"--physical
text features that the program could detect and use without
understanding English at all:
1. Headings that visually marked the start of sections or subsections
where instructions lurked.
2. Bulleted or numbered lists (or sublists) that often contained
itemized steps (or substeps) comprising a sought procedure. The
nesting of such lists physically revealed the step hierarchy in
3. Paragraphs with signal labels such as "procedure" or "step n,"
where again nesting on the page visually reflected content
These signals involved other ways that writers crafted and presented
technical discourse, but based on meaning rather than look. Using
these clues requires understanding the text:
1. "Actionable" statements.
Assertions that state how "to solve a problem or do a thing" may
actually be procedures if their
* tense is present,
* voice is active, and
* polarity is positive.
Clearly, linguistic interpretation is required to appreciate such
text features ("Insert your card into the marked slot").
2. Relatedness/cohesiveness signals.
Procedures involve agents using entities to perform actions, not
just stray facts about the world, however correct.
3. Goal announcements.
The point of performing any procedure is to achieve some goal,
so verb combinations that suggest goal/subgoal hierarchies often
signal a procedure embedded in a paragraph.
The IBM team that mined out these two kinds of clues so that their
software could reliably detect latent procedures actually called
their own work "feature engineering" (section 3.3). What they
really did, of course, was REVERSE feature engineering, looking
for text features--structural or linguistic--that other writers
had previously crafted and installed in explanatory technical
documents, placed so that readers would later find and exploit
them to usefully interpret what they read. In true engineering
fashion, such features are adjusted iteratively as drafts are
edited to maximize their helpfulness to (later) readers.
Different Clues, Different Benefits
Younger writers can benefit from reviewing the list of textual
features that enabled the IBM software to succeed--it reveals
their own diverse responsibilities to their own future readers.
More experienced students may appreciate the complementary but
different roles that the two types of clues--structural and
linguistic--played as the text-analysis program executed. The
IBM team found that as their software analyzed a technical
document, the "linguistic" clues primarily boosted RECALL--they
helped the program detect genuine procedures that lacked otherwise
revealing physical signals. The "structural" clues, on the
other hand, primarily boosted PRECISION--they helped rule out
linguistically possible apparent procedures that really were
something else. So deploying both kinds of signals is important
for writers who want readers to fully understand their text.
[Want more background on technical writing in science class? See
For a closer look at how to help your students approach writing
as engineers approach software design, see