Technical writing is writing that helps a particular reader do or understand something practical: set up a device, follow a procedure, call an API, run a test or choose between two designs. User manuals, standard operating procedures, API reference pages, specifications, lab protocols, technical reports and error messages are all technical writing. It is judged by one test: can the reader act on the page without having to ask the person who wrote it?
This page covers what the term means, the principles behind the writing and what the job involves. For complete sample documents, one per type, with notes on why each works, see the technical writing examples.
Technical writing, defined
The US Bureau of Labor Statistics, which tracks the profession, puts it this way: “Technical writers prepare instruction manuals, how-to guides, journal articles, and other supporting documents to communicate complex and technical information more easily.” The field is also called technical communication, and what it produces is usually called documentation. Three things set it apart:
- A named reader with a task. Not “the public”, but a nurse checking a dose at 3 a.m. or a developer making a first API call.
- Content that can be checked. A step works or it doesn't; a torque value or a dose is right or wrong. The writer's job is to leave nothing to interpret.
- Structure that follows the task. Numbered steps for a sequence, tables for values, headings named after what the reader wants to do.
US federal law states the goal well. The Plain Writing Act of 2010, which requires federal agencies to use plain writing in the letters, forms, notices and instructions people need to get a benefit or follow a rule, gives its purpose as “clear Government communication that the public can understand and use” and defines plain writing as “writing that is clear, concise, well-organized, and follows other best practices appropriate to the subject or field and intended audience.”
Before and after, sentence by sentence
The definition is easiest to see one sentence at a time. Each row rewrites an ordinary sentence as technical writing, and the last column names what the rewrite lets its reader do.
| Before | After | What it lets the reader do |
|---|---|---|
| BeforeThe file should be uploaded. | AfterUpload the file to the Contracts folder. | What it lets the reader doAct without asking: it's a command, and the folder is named |
| BeforeUsers may experience slowness under heavy load. | AfterWith more than 500 people signed in, pages take up to 4 seconds to load. | What it lets the reader doPlan around busy hours, with a measured threshold |
| BeforeClick Save if you want to keep your changes. | AfterTo keep your changes, click Save. | What it lets the reader doRead the goal first and skip the step if it isn't theirs |
| BeforeOpen the dashboard. The console lists your projects. | AfterOpen the dashboard. The dashboard lists your projects. | What it lets the reader doStay on one screen, because one thing has one name |
| BeforeSimply restart the router. | AfterRestart the router: unplug it, wait 30 seconds and plug it back in. | What it lets the reader doRestart it properly the first time |
| BeforeStore the samples somewhere cold. | AfterStore the samples at 2–8°C. | What it lets the reader doCheck the fridge's display against an exact range |
| BeforeAn error occurred. | AfterCouldn't save the invoice: the due date is before the issue date. Change the due date and try again. | What it lets the reader doFix the invoice without calling support |
| BeforeThe cover should be removed by a qualified person. | AfterHave a licensed electrician remove the cover. | What it lets the reader doKnow whom to call: the actor is named, in the active voice |
| BeforeUtilize the dropdown to facilitate region selection. | AfterSelect a region from the list. | What it lets the reader doTake it in at a glance, in plain words |
| BeforeDon't forget not to unplug the device during the update. | AfterKeep the device plugged in until the update finishes. | What it lets the reader doGet it right on the first reading, with no double negative |
| BeforeRinse the electrode and calibrate. | AfterRinse the electrode with deionized water. Then calibrate it with the pH 7 buffer. | What it lets the reader doPick up the right bottles, one action at a time |
| BeforeSet the timeout appropriately. | AfterSet timeout_seconds to 30. The maximum is 120. | What it lets the reader doType the setting's real name and a valid value |
| BeforeIt is important to note that backups run nightly. | AfterBackups run every night at 02:00 UTC. | What it lets the reader doSchedule other work around the backup, to the minute |
Take the error message. “An error occurred” leaves the person entering an invoice two moves: try again and fail again, or ask someone. The rewrite names the field and the fix, so she changes one date and saves. That is the test from the first paragraph, applied to a single line.
Types of technical writing
Technical writing is far older than software. Cookbooks worked out long ago how to tell a stranger to do something in a fixed, checkable order, and most of the recipes in Isabella Beeton's Book of Household Management (1861) use the same labeled parts:
INGREDIENTS.—1/4 lb. of salt to each gallon of water.
Mode.—Cleanse the fish, but do not skin them; lay them in a fish-kettle, with sufficient cold water to cover them, and salt in the above proportion. Bring them gradually to a boil, and simmer gently for about 5 minutes, or rather more should the fish be very large. Dish them on a hot napkin, and garnish with tufts of parsley. Serve with anchovy or caper sauce, and plain melted butter.
Time.—After the water boils, 5 minutes. Average cost for small whitings, 4d. each. Seasonable all the year, but best from October to March. Sufficient, 1 small whiting for each person.
Read it as a document. The materials come first, with a quantity. The method is a run of commands in the order you carry them out, and the one judgment call, a very large fish, is named where it applies. Then come labeled facts a cook looks up rather than reads: time, cost, season and yield. Swap the kettle for a server and you have the shape of a modern procedure.
The recipe already mixes two kinds of document, a procedure and a set of facts to look up. Technical documents come in a few such families. Each answers a different question, and most products need several of them.
| Type | Examples | The reader's question |
|---|---|---|
| TypeInstructions | ExamplesHow-to guides, quick start guides, SOPs, user manuals, work instructions | The reader's questionHow do I do this? |
| TypeReference | ExamplesAPI reference, specifications, data sheets, glossaries, configuration tables | The reader's questionWhat exactly is this value, option or limit? |
| TypeExplanation | ExamplesConcept pages, architecture overviews, design documents, white papers | The reader's questionHow does this work, and why is it built this way? |
| TypeReports | ExamplesTest reports, lab reports, technical reports, incident reports | The reader's questionWhat happened, what did we find, and what should we do? |
| TypeInterface text | ExamplesError messages, labels, tooltips, safety warnings | The reader's questionWhat is wrong right now, and what do I do next? |
| TypeProposals and plans | ExamplesDesign proposals, test plans, project proposals, grant proposals | The reader's questionWhat do you plan to do, and should we approve it? |
Documentation teams have formalized the split. DITA, the OASIS standard for structured technical content, defines concept, task and reference topics, plus glossary entries and troubleshooting topics. The Diátaxis framework, created by Daniele Procida, sorts documentation into tutorials, how-to guides, reference and explanation; the product documentation template plans a docs set that way. Both rest on one idea: a page that teaches, a page that instructs and a page you look things up in are different pages.
For an annotated sample of each type, see the technical writing examples; procedures have their own set of SOP examples.
Six principles of technical writing
Style guides disagree about commas and capital letters; the principles behind the rewrites above are far less disputed. Each one settles a decision you make while drafting.
1. Write for one reader doing one task
Before you write, name the reader and what they are trying to do. That decides how much to explain and which terms to define. “Users” is not a reader. “An office manager setting up the printer without help from IT” is, and you can test the page against her. For her, the step that sets the printer's network address says where to find the address on the printer's display and what to type; for an IT administrator, “Assign the printer a static IP address” would do. Same task, two different pages.
2. Use one term for each thing
In an essay, switching between “the tool”, “the app” and “the program” avoids repetition. In technical writing the reader assumes three words mean three things. Pick the term the interface or the specification uses and repeat it every time: if the screen says Workspace and the engineers say tenant, the page says Workspace. A short style guide keeps a whole team on the same words.
If you draft in Strokes, ask the Strokes Assistant to review the page, and it flags inconsistencies such as one setting under two names.
3. Write instructions as commands, in order
Start each step with a verb, give each action its own step, and keep the order the reader will follow. Put the condition first, so a reader it doesn't apply to can skip the line: “If you connect through a proxy, enter its address”, not “Enter the proxy address if you use one”. Google's developer documentation style guide says it in six words: “Put conditions before instructions, not after.”
4. Be exact about numbers, names and units
“Wait a few minutes” becomes “Wait until the status light turns green, about 2 minutes.” “Tighten the bolts firmly” becomes “Tighten the bolts to 25 N·m.” Name every button and field exactly as it appears on the screen, and give the unit every time. A reader who guesses the unit wrong gets a wrong result and may not know it.
5. Make the page easy to scan
Readers usually open a manual looking for one answer, not to read it through. That decides the headings: “Replace the filter”, not “Filter”. Use numbered lists for sequences, tables for values and code font for anything typed. Screen-reader users benefit too, since they can jump from heading to heading.
6. Choose plain words and short sentences
Use the short, familiar word: use, not utilize; after, not once, when you mean after. Cut “simply”: what is simple for the writer may not be for the reader, as Google's word list points out, and the same list calls “just” a filler word you can usually delete. Keep most sentences to one idea; these are the same levers that raise readability. Some industries restrict the language itself. ASD-STE100 Simplified Technical English, which began in commercial aviation, pairs writing rules with a dictionary of approved words to make technical texts easier to understand, especially for readers whose first language isn't English.
How it differs from other writing
Most kinds of writing inform someone. What separates them is what counts as success.
| Kind of writing | Its job | Usual reader | It worked if… |
|---|---|---|---|
| Kind of writingTechnical writing | Its jobHelp someone do or understand something practical | Usual readerA user, operator, developer or decision maker with a task | It worked if…The reader finishes the task or finds the fact |
| Kind of writingAcademic writing | Its jobAdvance and defend a claim with evidence | Usual readerScholars, examiners, peers | It worked if…The argument survives expert scrutiny |
| Kind of writingBusiness writing | Its jobInform, request or decide inside an organization | Usual readerColleagues, clients, managers | It worked if…The reader knows what to do next |
| Kind of writingCopywriting | Its jobPersuade someone to act | Usual readerProspective customers | It worked if…The reader buys, signs up or calls |
| Kind of writingJournalism | Its jobReport what happened and why it matters | Usual readerThe general public | It worked if…The reader understands the news accurately |
| Kind of writingFiction | Its jobCreate an experience | Usual readerReaders who chose the book | It worked if…The reader keeps turning pages |
The borders are open. A lab report is technical and academic at once, and usually follows the IMRaD structure. A white paper explains a technical problem in order to sell a solution, so writing a white paper takes both skills. The test stays the same: has the reader stopped reading and acted?
Common technical writing mistakes
- Writing for yourself. The writer knows the system so well that steps disappear, like the sign-in nobody mentions. Test the page on someone who has never done the task.
- Explaining before instructing. Three paragraphs of background come before step 1. Put the concept on its own page and link to it.
- Warnings after the step. “Click Delete. Note: this can't be undone” arrives one sentence too late.
- Passive voice that hides who acts. “The backup must be verified” doesn't say by whom, so nobody knows if it means them.
- Screenshots instead of words. Text inside an image can't be searched or copied, and the picture goes stale with the next redesign. Describe the step in text and let the image support it.
- Writing it once. Products change; documents often don't. Give every page an owner and a review date.
Practice: rewrite five sentences
Rewrite each sentence as technical writing. Suggested answers follow. Yours can use different words and still be right, as long as a reader could act on them without asking you anything.
- Once the machine has warmed up, you can begin printing.
- It is advised that gloves be worn when handling the solution.
- Click on the button at the top of the page if you need to export your report as a PDF.
- The app may not work properly on older phones.
- Make sure all the settings are correct before proceeding.
- “After the READY light comes on, load the first sheet.” The reader gets a signal to watch for instead of guessing what “warmed up” means, and “after” replaces “once”.
- “Wear nitrile gloves when you handle the solution.” A command, with the kind of glove named.
- “To export the report as a PDF, click Export at the top of the page.” The goal comes first, “click on” loses its “on”, and the button has its name.
- “The app needs iOS 17 or later, or Android 13 or later.” A requirement the reader can check, in place of a warning nobody can act on. Use your app's real minimum versions.
- “Check that Region is set to EU and Backups is On, then click Continue.” “Correct” becomes the actual settings and values.
What technical writers do
Technical writer is a job title as well as a skill. According to the US Bureau of Labor Statistics' Occupational Outlook Handbook, as checked in November 2026, technical writers held 46,400 jobs in 2025, and their median annual wage was $90,390 in May 2025. BLS projects employment to grow 1 percent from 2025 to 2035, slower than the average for all occupations. The largest employer is the professional, scientific and technical services industry, with 39 percent of the jobs, followed by manufacturing and the information industry at 13 percent each.
Writing is only part of the work. The BLS list of duties starts with determining “the needs of users of technical documentation” and includes studying product samples, talking with designers and developers, and collecting user feedback to improve the content.
Most technical writing, though, is done by people with other job titles. Engineers write design documents and READMEs, scientists write protocols, nurses write procedures, and support teams write the articles customers find when they search for an error message.
Frequently asked questions
Does technical writing have to be formal?
No. It has to be exact, which isn't the same thing. Google's developer documentation style guide asks writers to be conversational and friendly without being frivolous, and Microsoft's style guide recommends common contractions such as it's and don't for a friendly tone. Some fields are stricter: aviation and defense manuals may follow ASD-STE100, a controlled language with its own dictionary of approved words.
Is technical writing the same as content writing?
No, although the skills overlap. Content writing usually means articles, blog posts and web copy meant to attract and persuade readers. Technical writing explains how to use or understand something and is measured by whether the reader can complete a task. Many technical writers also write content, such as tutorials published on a company blog.
Do you need a degree to become a technical writer?
According to the US Bureau of Labor Statistics, the typical entry-level education is a bachelor's degree, and employers generally prefer English, communications, journalism or a related field. Knowledge of a technical subject such as engineering or computing also helps. In practice, a portfolio of documentation samples shows a hiring manager what a degree alone can't.
