Technical writing is a very specific kind of writing. It's often dry, rooted in facts and short, simple instructions, because it's meant to be used as a resource. It's not marketing copy, it's not personal opinions, and it's not an essay. Rather, it's more like documentation, tutorials, and manuals.
Some people may find it challenging to understand what is and isn't technical writing or how to take information and compile it in a form that is recognizable and usable as a technical document. To assist with that, I've taken it upon myself to find a series of examples you can use as study materials, training guidelines, and inspiration.
For those of you who aren't writers (that is, the businesses who read my content when learning how to hire writers), examples of technical writing can help you learn exactly what you need to look for in your own assignments and what you want to ask for in your writers, to make sure you get precisely the kind of work you need.
First on this list is a user guide. This is a "getting started" guide in the help center for Ahrefs, which is a SaaS platform, so their documentation is online. It is a compilation of questions and answers written by the authorities at Ahrefs, who know their product inside and out.
It serves as an excellent reference guide and tutorial on how to get started and what all of the data they provide actually means. For something as complex as site audits or SEO, it's a welcome resource.
Google has tons of documentation online for the wide range of products they offer. This is a page dedicated to their flagship phone, the Pixel. On it, you can see an index of topics that might be relevant to a user, as well as instructions on how to find and access information on the devices, how to configure and use them, and even safety and user warnings.
You'll note that some of this looks like boilerplate legalese: that's technical writing too.
When you purchase a car, it comes with a user manual. That manual includes operating instructions, documentation about every little button and dial, and even information necessary for simple repairs. This is an example of user-focused technical writing. Haynes manuals are much more technical and go into much greater detail about every part of a vehicle because they're meant for specialists, specifically auto mechanics.
Both are examples of technical writing, and the difference between them (look up your car, and compare it to the manual you own) is an example of how different audiences affect technical writing.
This is an example of technical documentation that is usually packaged in with a product but is also available online for those who lose or misplace their copy. In fact, it's better than the packaged-in documentation because it takes more time and uses more illustrations to explain steps in detail, which is often pruned out in paper for space and printing considerations.
Note how it's all written authoritatively, with no room for opinion, anecdote, storytelling, or any of the trappings of content writing. It's purely factual and utilitarian.
PACER is the United States Public Access to Court Electronic Records system. In it, you can find documentation from virtually every legal case and court battle seen by federal courts anywhere in the country (as long as the records aren't sealed.)
These records are an interesting, specific branch of technical writing, written and prepared by lawyers familiar with the laws relevant to the case. Additionally, if you look at filings self-prepared by sovereign citizens, you can see the difference training and skill make.
PubMed Central, part of the National Library of Medicine, and itself part of the National Center for Biotechnology Information, is one of the most centralized and authoritative international sources of medical information available online.
It aggregates papers and journal publications from a wide range of sources and is widely cited on health-focused websites. When you look at specific papers, like the one linked above, you can see a particular kind of academic writing in the medical field. In particular, you can see how dense and poorly-formatted these publications can be.
White papers are interesting because they're an intersection between technical writing and content marketing. They are often aimed at a more technical audience and tend to be more factual and authoritative than the average blog post, but they also have a lot more room than most technical writing for storytelling, anecdotes, and informal writing.
They're meant to convince, not instruct, so they have more leeway to be persuasive. Often, writers who focus on white papers are a special breed with a rare skill set.
This is the formal name for the Starbucks employee handbook. It's a comprehensive guidebook that outlines the behaviors expected of employees working for the company, as well as upper-level policies relating to giving feedback, conflicts of interest, and other items.
It's written formally and authoritatively, and more importantly, it's compiled based on legal policies, employment laws, and the results of conflicts that have arisen over the years. As such, it's not the kind of document you produce out of whole cloth; it's built over time.
Computer hardware like graphics cards will typically have technical specifications you can find which are relevant to many people. This information can be anything from the physical size of the card (to know if it can fit in a case) to the clock speed of the onboard processors, to the kinds of technologies and software it supports or uses.
Most of it isn't relevant to most people, but all of it is relevant to someone. Of course, a chart with numbers and a few names in it isn't exciting, but it needs to be produced by someone who can integrate it with the rest of the documentation about the device.
APIs are important for interconnectivity between software, and as such, they need to be well-documented for use by software developers who need to know how data is handled. It's absolutely essential that such documentation is robust and complete, with a minimum of editorializing and a maximum of technical facts.
This is a demonstration of how technical writers must have knowledge of the subject of their writing and how they often need to interview and ask questions of specialists (in this case, Facebook software engineers) to know precisely how it all works, inside and out.
While this case study is gated behind an opt-in, it's one of many examples of data compiled and presented in a compelling way. It's technical writing because it takes factual information and data harvested in a study and presents it in writing.
It's also marketing copy because that technical writing is presented in a way that is meant to convince and convert new users. Case studies are one of the most common forms of technical writing and, ironically, also one of the least technical.
This is another example of a white paper, but it doubles as an industry report because it's not about any one product or service but rather a whole industry's offerings and developments at an annual conference.
It's also another example of how technical writing is often about more than just writing: it's about presentation. Graphic design often plays a large part in compelling technical writing, though you will likely have two people creating it: a writer and a designer.
Similar to the employee handbook from Starbucks, this is a piece of documentation created by a large entity (in this case, a university) to help guide the behavior of an employee. However, in this case, it's documentation meant to be analyzed and followed by a new hire.
As such, it has less in the way of individual policies and legalese and more in the way of tutorials, steps to follow, and checklists to work through. It's meant to be an actionable handbook, which requires a specific kind of technical writing that can convey complex subjects in a simple way.
Product user guides have already been mentioned on this list, but there are two things to bring up about this one. First is that the manual is robust and has a logical flow of content, even though it's technical content. It starts with critical safety information, goes into installation, then operation, and then into repair and troubleshooting. Anyone who purchases a new device will start at the beginning and read the most critical information first.
Secondly, this manual has a Spanish version; remember, many businesses operate internationally or in bilingual areas, so providing technical documentation in multiple languages can be a great idea.
Every single time you set up a new piece of software or enroll in a new service, you're essentially signing a contract. That contract is governed by a EULA, an End User License Agreement.
We're all more than happy to click through them without reading a word these days, but they are all carefully written by technical writers (and lawyers) to set forth the terms of a contract. Much of it is templated today, though.
Press releases are another form of technical writing that generally requires a unique skill set and a unique kind of voice. This press release is largely factual and includes a ton of useful and relevant information that people who are interested will enjoy having at their fingertips.
It's also not as rigidly templated as many press release examples you can find online and yet is perfectly effective.
Annual reports are part and parcel of operating a large company, and they are typically produced as a way to keep shareholders and stakeholders informed about the year's dealings.
Cisco's is a well-designed document that includes a letter directly to their audience, information about their financial highlights for the year, and more technical information about governance, responsibility, leadership, engagement, and more. It's meant for businesspeople and shareholders and delivers them exactly what they need to make decisions for the coming year.
A business plan is another form of technical writing, but it's interesting because it's not as often meant to be written by a technical writer. Rather, a business plan is meant to be a guidepost and a living document, created by business owners and stakeholders and developed over time as a plan changes.
Thus, only a sample/template plan here, as real business plans are generally internal documents anyway.
Competitive analysis is another kind of technical business document that is meant to be internal. Unlike a business plan, however, a competitive analysis is generally delivered to a technical writer in the form of lumps of data and individualized reports.
The writer then compiles, produces, and analyzes the data in conjunction with a data analyst. Technical writing is a team sport, after all.
Who says technical writing needs to be writing at all? IKEA is famous for packaging their products with instructions for every language because they don't actually use words. However, behind the scenes, this documentation is created using technical guidance from writers who know how to convey what needs to be conveyed.
It takes quite a lot of writing skill to create a document with no actual writing in it.
Leave a Reply