Three long-time STC members answer four questions about the past and future of technical communication
By Saul Carliner, Janice (Ginny) Redish, and Karen Schriver | Fellows
Editor’s Note: What has propelled technical communication to its current point and what’s on the horizon for the field?
On March 15, 2023, the three authors (all STC Fellows who have been active in research, practice, and teaching for decades) shared their thoughts In a webinar, Reflecting Backward, Thinking Forward: A Conversation About 70 Past and 70 Future Years of Technical Communication, in honor of the 70th anniversary of STC.
This is the first of a two part series, transcribed from the webinar. In this part, the three look backward, exploring the most important and overrated developments in the field over the past 70 years. In the second part, they look ahead with their concerns and hopes.
The authors have edited the transcript for length and clarity.
What is the most important development in the field over the past 70 years?
Saul: I’m going to cheat and list five innovations.
- Computer technology and all other related digitalization endeavors because that’s really what has led to our employment.
- Rise of the professional community and, more particularly, the rise of research in our field.
Here’s where I want to give a shout-out to my co-panelists. The Guidelines for Document Design that Ginny Redish and her team at the American Institutes for Research produced back in (let’s just say a few years ago) was done in conjunction with Carnegie Mellon University (CMU) when I was an undergraduate there.
Some of the research done at CMU looked at the writing process, and a lot of things that Ginny’s team looked at were some writing properties. Together they really have influenced how we write.
- Word processing. One of the things the CMU team discovered in researching the writing process was that really good writing is revised writing. You may have seen the T-shirt “Write, Revise, Revise.” Word processing made it possible to do that.
- Professional associations themselves because they nurtured communication of all these other developments and the collection of all this stuff. And that led to Karen’s landmark 1997 book, Dynamics of Document Design.
- Shift from lifetime employment to lifetime employability. In the earlier lifetime employment, you would see a lot of people become tech writers within their company because they had some facility with the technology and they could explain it to people. Now, people move among employers, tending to stay in the same career. And that led to the professionalization of tech comm.
Ginny: I agree with everything Saul said. And I agree with what I’m seeing from our webinar attendees about the internet, the move to digital computing, personal computing. But I also want to add the idea that we as technical communicators have always been user advocates.
One of the great innovations has been the spread of a user-centered focus, user-centered design, usability testing.
This is what Karen has called reader-focused evaluation. It contrasts with readability formulas and other means of looking at text in which the person who’s going to actually use the text is not included.
Having a research base has made us more credible to be able to say we must be user-focused. And all the other developments that Saul mentioned have led to a greater understanding, not only among technical communicators, but also among our colleagues and clients that we must be user-focused.
But in the end, I decided that the most important thing that has happened over the last 70 years was the professional development of the modern technical communicator. Today’s communicator has really benefited from educational programs and from professional organizations such as STC.
Roughly from the 1950s through the 1970s, members of the field saw themselves pretty much as technical writers. The computer revolution that Ginny was just talking about led us to change our vision of ourselves more as communicators rather than just as writers. In the early 1980s, user-centered design took off. And we started thinking about design as well as writing. Not only did our processes and our products change, but even the people who made up the field changed.
I remember when I went to my first STC conference in 1982, I went to the opening party, and on one side of the room was this large contingent of men dressed in full military uniforms, looking rather grand, I have to say. At first, I thought I must be at the wrong party. But then I realized that those men formed the core of the field at the time.
Today, the demographics have shifted. Women outnumber men; and, slowly, men and women of color are joining our field. Today, we’re better at what we do across audiences, genres, media platforms. And users like our stuff.
What is the most overrated development?
Karen: The most overrated development for technical communication is the inclusion of readability statistics in Microsoft’s MS Word. Adding readability output to MS Word led many people to believe that running the Flesch or Kincaid formula would tell them if their document was understandable or not.
Many writers and even non-writers look to readability output as a kind of one-button solution to understandability. But as research on usability has clearly shown, the output was really overrated in terms of what it told us about text quality. And here we are many years later still haunted by the same formula in Microsoft’s Office 365.
Additionally, readability formulas form the basis of many editing software programs like Grammarly, Visible Thread, and Acrolinx. So, my vote on this question is that readability formulas, no matter what platform they lurk on, or what fancy clothes they wear, are vastly overrated.
Ginny: Karen, you took my first answer to this question about the most overrated development. Readability formulas are the opposite of the user-centered focus that I talked about before.
I’ll just add that all the computer-based formulas have tremendous problems. They use different algorithms to get at what they consider readability. They differ, in fact, on whether they count a year like 1997 as three words or as one unit or whether they count semicolons as if they were sentence-enders.
But, because Karen talked about readability formulas, I’ll mention something else.
Another overrated development is the focus on tools. And that’s sad for many of us in the profession because a job announcement might say nothing about being user-focused. Instead, it might say you have to know Figma.
So, we have to continually talk to our clients and HR people to say, “I can learn the tools. What matters is my ability to communicate clearly.” We should think about ourselves as a profession that is not tool-oriented, but user- and process-oriented.
Saul: I was going to say something regarding tools. And I decided not to, so I’m glad the two of you mentioned various aspects of that.
To me, the number one overrated development, because it didn’t do what it was supposed to do, was IBM’s use of the job title “information developer.” And this one is personal to me because within about six months of starting my very first job, which happened to be at IBM, my job title changed from being a junior writer to being a junior information developer.
The idea behind it was that we were going to try to combine the job descriptions of the information writer, the illustrator, and the editor, add an advocacy role to that, and use a single job title. The hope was that people could move among writing, illustration, and editing all while advocating for users. At the same time, the name of the function went from Technical Publications to Information Development.
It was a really interesting idea, but …
I was talking to somebody who worked on an experimental program where they were trying to have writers and illustrators who could be equally competent and confident with visual tools and with verbal tools. But what they found, in the end, was that the visual communicators became more sensitive to the words but not a whole lot more verbal, and vice versa.
The Information Developer job title eventually went away. And as I have been told (I had left the company by then), they ended up with two broad categories, which is really concerning to me. The lower-level people were reclassified back as writers and editors, and the higher-level people were classified in some sort of business analyst role. So, we ended up with this class system in the field, which to me is even worse for long-term professional purposes.
If you look at the history of technical communication, we’ve always had issues with the name. We were technical writers. Then, people became fixated on being technical communicators.
We need to start celebrating the terms that are already in wide use outside of our field, not create new names. We need to promote the good work we do and the unique perspectives that we bring to our projects and our clients.
This concludes the look back. Part Two looks forward, exploring concerns about and hopes for the future.
We thank Nicky Bleiel for chairing the STC 70th task force, inviting us to do the webinar, and moderating our discussion. We also thank Erin Gallalee for technical support of the webinar. And we thank all the STC members and others who spent time with us, listening and contributing to the webinar.
For a list of relevant references and resources on technical communication, see the bibliography compiled by Karen Schriver at Ginny Redish’s website: https://redish.net/wp-content/uploads/2023_Resources_about_technical_communication.pdf
Saul Carliner is a Professor of Educational Technology at Concordia University and a Fellow, past president, and long-term volunteer of STC. Contact: firstname.lastname@example.org.
Janice (Ginny) Redish is a “semi-retired” consultant in content strategy, plain language, and user experience. She is an STC Fellow and recipient of several STC awards. Contact: email@example.com, https://redish.net.
Karen Schriver is a researcher and consultant on information design, plain language, and professional communication. She is an STC fellow who is contributing to a new ISO standard for plain language and document design. Contact: firstname.lastname@example.org, https://www.karenschriverassociates.com/