Three Types Of Writing

The Three Types Of Writing You Actually Need To Know

Most people overcomplicate this. I used to think there were dozens of writing styles depending on the audience, the medium, the platform, the year. Then I got tired and started paying attention to what actually happened when something went wrong. The pattern was always the same: someone mixed two types in one piece and confused the reader, which meant they confused the stakeholder, which meant the project blew up three weeks later. There are three functional modes of writing that cover nearly everything you'll ever produce professionally. The first is explanatory writing, which exists to transfer understanding. The second is persuasive writing, which exists to change a decision. The third is instructional writing, which exists to produce a repeatable action. That is it. Everything else is a decoration on top of one of these three. I learned this the hard way in 2019 when I was asked to write a product launch doc that was supposed to excite executives while also explaining a technical architecture shift and including deployment steps. It was all in one document. The executive summary read like a tutorial. The technical section tried to sell a roadmap. Nobody knew what they were supposed to do after reading it. I spent three days rewriting it into three separate documents. Each one did exactly one thing. It took four hours.

The reason this framework matters is that each type has different success criteria. Explanatory writing succeeds when the reader can restate the concept accurately. Persuasive writing succeeds when the reader changes their mind or commits to an action. Instructional writing succeeds when the reader can follow the steps without asking follow-up questions. These are not interchangeable. You can have beautiful prose and still fail at the type you're attempting if you don't check the right success criterion. Explanatory writing is the most abused type in my experience. People treat it like an excuse to dump information. Here is the trick most writers miss: you do not explain everything. You explain only what the reader needs to understand in order to reach the next step. Everything else is noise. When I write explanations, I start by identifying the exact decision or understanding the reader needs to walk away with, and then I work backward from there to find what they must know first. This usually cuts the draft from fifteen pages down to three. Persuasive writing fails when it relies on emotion without evidence, or on evidence without stakes. The counter-intuitive part is that data alone rarely persuades anyone. Data confirms what people already believe. What actually changes minds is connecting data to a specific consequence that the reader cares about. I once wrote a memo recommending we switch from one API provider to another. I led with cost savings. Nobody moved. I rewrote it to lead with a specific outage that had cost the engineering team forty-eight hours of debugging, and I attached the cost savings as a secondary benefit. It passed in one meeting. The content was the same. The framing was different.

Instructional writing is where most people lose control of quality. The problem is that you cannot tell if your instructions work until someone who has never seen them tries to follow them. I have a specific workaround for this. Before I consider a document done, I send it to one person who is unfamiliar with the process and ask them to execute without interruption. No answering clarifying questions. No editing as they go. Just watch where they hesitate, where they re-read, where they ask for help, and that is your edit list. I usually find five to eight gaps in a fifteen-minute test that I completely missed during writing. This takes about twenty minutes total and prevents three to four hours of support tickets later. There is a specific edge case with instructional writing that almost nobody talks about. Version sensitivity. When you write instructions for a system that changes frequently, the instructions become outdated before they ship. I encountered this when documenting a deployment process for a service that released weekly updates. By the time the guide was approved, three of the five steps referenced deprecated commands. The workaround was to make the instructions reference interface behaviors rather than specific commands, and to link directly to the live reference docs instead of embedding the references inline. It costs more to write that way upfront, maybe thirty to forty-five minutes longer per document, but the lifespan of the guide goes from two weeks to six months or more. Another thing that goes unmentioned is how these types interact in practice. Most real documents are hybrid. A product spec is explanatory and persuasive. A runbook is instructional with explanatory sections. The mistake is not hybridizing, it is failing to signal which mode you are in so the reader adjusts their expectations accordingly. A well-designed document uses visual cues, section headers, or even brief opening statements to tell the reader what type of thinking they should be doing. "This section explains why." "This section tells you what to do." That simple signal reduces misreads significantly.

Here is where the model breaks down. There are domains where the three-type framework does not apply cleanly. Legal drafting operates under constraints that override all three types. Creative writing exists outside the framework entirely. So does poetry. The framework is for professional communication, not artistic expression. If you try to force legal documents into this structure, you will miss required language. If you try to write a novel this way, you will produce something that reads like a manual. Know the boundary and stop there. Another failure mode is applying the same type to every audience. Explanatory writing that works for engineers will fail for executives and vice versa, even though the underlying document type is the same. The fix is audience-specific explanations, not type-specific explanations. The type stays constant. The depth, vocabulary, and reference points shift based on who is reading it. I keep a simple matrix in my head: type on one axis, audience familiarity on the other, and I adjust the third variable accordingly. Familiarity ranges from expert to novice, and I never write at the reader's actual level, I write at the level they need to operate effectively, which is usually one step ahead of their current understanding. One more practical note on tools. Most word processors and markdown editors do not help you check whether you are staying in one type. I use a simple technique that costs nothing. I highlight every paragraph and ask myself one question: is this transferring understanding, changing a decision, or directing an action? If the answer is mixed, I split the paragraph. It takes longer on the first pass but cuts review cycles roughly in half. Reviewers stop telling you that the document is confusing because they can point to the exact section that switched modes unexpectedly.

Bottom line, the three types are explanatory, persuasive, and instructional. Pick one per document. Check the success criterion before you consider it done. Test instructions on an unfamiliar reader. Build version tolerance into your procedural docs. And stop trying to make one piece of writing do everything. The people who get faster at this are not the ones who write better sentences. They are the ones who stop mixing types and start separating them cleanly.