How To Write A Summary

Most summaries fail because people skip the most important step

I spent years editing technical documentation and legal briefs, and the number one reason summaries got rejected wasn't bad writing. It was that the person writing them never actually decided what they were summarizing for. You pick a source text, you read it, you boil it down. That's the version everyone shows you in writing guides. The version that actually works requires one more step that most people skip entirely. Before you write a single sentence of your summary, you need to answer three questions. Who is reading this? What do they already know about the topic? What decision or action are they going to take after reading it? I had a client once who sent me a 40-page product requirements document and asked for a summary. I asked those three questions. Turns out the summary was going to the executive team, they knew nothing about the technical architecture, and they needed to decide whether to fund the project. So I wrote a summary that barely mentioned the architecture at all. It focused entirely on timeline, cost, and risk. That's not cheating. That's the job.

How To Write A Summary That Actually Works

Read the source material with a highlighter, but don't highlight sentences. Highlight claims. A claim is a single unit of information that stands on its own. It can be a fact, an argument, a finding, or a recommendation. When you're done reading, your highlights should look like a mess. That's fine. Now go back and cross out every highlight that doesn't survive this test: if you removed this claim from the original text, would the core argument fall apart? Be ruthless. Most highlights will die. The ones that survive are your raw material. The mechanical process is straightforward. Take your surviving claims and group them by function. You'll typically end up with three groups: the context or background that sets up why this matters, the key findings or arguments that form the body of the work, and the implications or conclusions that answer so what. Write your summary in that order. Not because it's elegant, but because readers need the first group to make sense of the second, and they need the second to care about the third. Skipping context to get to the good stuff is the most common mistake I see. Readers who don't understand why something matters won't remember what the something is. Length depends on your audience's time budget, not on the length of the original. A 40-page report meant for busy executives should be 300 to 400 words. A 10-page paper meant for peers who need to evaluate the methodology might need 600 words. There is no universal ratio. The old rule of thumb about one paragraph per page of source material is garbage. I've seen people follow it and produce summaries longer than the abstracts they were supposed to replace.

Here's something nobody tells you about summaries: the first sentence is the most important sentence in the entire piece. Not the last one. The first one. If your opening sentence is "This paper discusses several aspects of machine learning," you've already lost the reader. The first sentence should state the central finding or recommendation directly. Lead with the answer. Everything else is support. I learned this the hard way when I spent two days writing a summary that opened with background context, and the person who received it forwarded it back with a note that said "get to the point." The point was on page two. By then the damage was done. There are situations where this approach breaks down and you need to know about them before you commit to it. Summaries of highly technical methodology sections don't benefit from the "lead with the answer" format because the answer is the method itself and the method can't be stated in one sentence. In those cases, lead with the purpose of the method and what problem it solves, then describe the approach in one or two sentences max. If you're summarizing a legal contract, the lead-with-the-answer format can actually create liability because it might oversimplify a nuanced obligation. Legal summaries should lead with a clear statement of what document is being summarized and under what circumstances it applies, then list the key obligations and constraints in plain language. Another edge case that trips people up is summarizing debate-style texts where there is no single conclusion. I worked on a project summarizing opposing expert testimonies in a regulatory hearing. There was no central finding to lead with because the experts disagreed on the core facts. I handled it by leading with the question both sides were trying to answer, then summarizing each side's position in parallel structure before noting where they converged and where they diverged. It required more words than a normal summary, but it was still shorter than the source material and far more useful than either expert's testimony on its own.

Write the summary, then read it in isolation. Cover the original text and read only your summary. Does it stand on its own? Can someone who has never read the source understand the main point and act on it? If yes, you're done. If no, you've left out something essential or you've assumed knowledge the reader doesn't have. Fix that and stop second-guessing yourself. The summary is not a diminished version of the original. It's a different document made for a different purpose. Judging it by how well it replicates the original is like judging a map by how well it replicates the territory. The process usually takes about 20 to 40 minutes for a document under 50 pages if you're doing it right. The reading phase takes the bulk of that time. The writing itself is often under 10 minutes once you have your highlighted claims organized. The most time-consuming part is the isolation test and the revision that follows it. Don't skip it. I've seen people rush through summaries and then spend three hours answering follow-up questions that the summary should have prevented. One final thing that separates decent summaries from good ones: precision over generality. "The study found significant improvements in user engagement" is weak. "The study found a 34 percent increase in daily active users over the 90-day trial period" is strong. You can't always include exact numbers, but when you can, do it. Vague summaries get forwarded without being read. Specific summaries get acted on.