cft

From the astrolabe to software: The history of technical writing and its impact on UX

Technical writing as we know


user

Julia Forneck Pinheiro

3 years ago | 4 min read

Technical writing’s history had its start hundreds of years ago and can be traced back to A Treatise on the Astrolabe, a medieval instructions manual on the astrolabe and its use, written by Geoffrey Chauce in 1391.

Another example of early technical writing work were English seamstresses’ manuals, which language was plain and direct in order to convey instructions, a writing style known and used still nowadays.¹ These are just two out of many technical writing examples and their place in our development history.

Among the many studies in this area, it’s stated that the Renaissance still is one of the most important periods for technical, commercial, and scientific communication. As mentioned by Elizabeth Tebeaux, “the period between 1641 to 1700 saw technical communication gain prestige in an age that recognized the value of solving practical human problems in scientific and technical fields.”²

Humans first started writing because of the necessity to communicate, organize, teach and remember. Throughout history and the inventions that came with it, documentation has always been essential in order to record and teach about a new device, ensuring its best use.

But, after thousands of years of rich history, we’re going to focus on the ’40s and the beginning of computer software technology and its documentation.

Technical writing as we know

An example of early user documentation created in the USA was for the Mark I ASCC computer, entitled A Manual of Operation for the Harvard Mark I Automatic Sequence Controlled Calculator, written by Grace Brewster Murray Hopper in 1944.¹

She was part of the team responsible for developing the computer, as well as documenting it later, which meant a big contribution to what we now know of software documentation and common practice at the time when documentation was created by the developers.

Another example is what’s now famously known as the world’s first electronic computer manual, the Operating & maintenance manual for the BINAC binary automatic computer, written by Joseph Chapline in 1949. It created a standard and became the model for many other computer manuals written in the following years.

Operating & maintenance manual for the BINAC binary automatic computer built for Northrop Aircraft Corporation — 1949
Operating & maintenance manual for the BINAC binary automatic computer built for Northrop Aircraft Corporation — 1949

These two works served a huge purpose and stand through the test of time — a test that’s really tough with software documentation, since its purpose it’s not to be lifelong, but read and discarded as soon as there is a new feature or version, which makes it harder to evaluate and study throughout the years.³

It’s also noteworthy to mention that, although these two examples date from the 1940s, it was only in the ’60s that software documentation became more popular and accessible to the broader public (non-technical users), as explained by Henrieta Nickels Shirk:

“It was not until the Third Generation of microminiaturized integrated circuit computers in the late 1960s that the use of problem — and procedure-oriented languages made any sort of documentation necessary. It is here that Technical Writing’s roots began.”

The impact of instructions and user guides has become clearer over the years, and what we as communicators have achieved in the last 60 years is of great importance. However, even though a few decades have gone by, some pain points never change.

Raise a glass if at least once you’ve had to fight for documentation during a product’s development and play the d̶e̶v̶i̶l̶’̶s user’s advocate. It can be due to many reasons, but the fact is that sometimes the human factor is left aside during development, and it’s necessary to once again show how valuable user-centricity and documentation are. This situation isn’t unprecedented — in fact, it’s recurrent from the early days, as Henrieta mentions:

“Needless to say, documentation was not considered a serious endeavor, unless management mandated its creation. Even then, the effort was likely to be sabotaged through inattention, the excuse of pressing deadlines, and failure to maintain documentation once it was created.³”

What about experience?

From the two early examples mentioned above to the field of UX and, especially, UX writing, we’ve come a long way, and it’s easy to see how technical writing’s history is closely intertwined with user experience.

This comes as no surprise at all, since technical writers have always been the user advocates, whose focus was on clarity and usability.

It’s also easy to find technical writers that transitioned to the UX field because of its similarities and their backgrounds — technical writing counts on research, testing, analysis, and according to Mike Markel’s, you can evaluate excellent technical writing based on eight criteria: honesty, clarity, accuracy, comprehensiveness, accessibility, conciseness, professional appearance, and correctness. Do any of these terms sound familiar to you?

What first started off with user manuals and guides, is now a cross-channel field in which we work and focus to deliver the right message in the best way. Technical documentation isn’t read for the sake of pleasure, but it serves as a tool for an objective, so while it is a requirement, it’s in our hands to make it as meaningful and appropriate as possible.

Studies, new developments, and trends keep coming at a faster rate than which we can keep up with at some times, and it’s important to look out for them and what the future holds, but sometimes, it’s also useful to sit back and see how history brought us here.

Upvote


user
Created by

Julia Forneck Pinheiro

Technical Writer and Advertising student learning more about words, people and tech. Find me on LinkedIn https://www.linkedin.com/in/juliaforneck/ ;)


people
Post

Upvote

Downvote

Comment

Bookmark

Share


Related Articles