Yükleniyor...
For years, whenever I explained a bug or a new feature, I laid down 300-word monoliths; until I tested Basecamp's editing discipline in my workshop, I hadn't realized all those details comforted the author's anxiety, not the reader.
For years, whenever I had to explain a product bug, a new infrastructure migration, or a radical interface redesign, I exhibited the exact same reflex: I would sit down and draft monolithic paragraphs of at least 300 words, fortified on every flank with technical justifications. My core assumption was simple: if I laid out the architectural bottleneck, the midnight decisions of the engineering team, and every conceivable edge case in sequence, the reader would be convinced of just how transparent, competent, and honest I was.
Yet in the workshop, things never unfold according to the writer's intent. Nielsen Norman Group's eye-tracking studies clearly document that users read only about 20 to 28 percent of the text on web pages, quickly scanning the rest in an F-pattern. So while I assumed I was investing every word with deep meaning, the user on the other side caught my defensive tone within the first 15 words and abandoned the page. Those 300-word blocks were not informing the user; they were merely concealing my urge to plead: "Don't be mad at us, we had very valid reasons."
When I started examining the famously ruthless pruning discipline of the 37signals team and Jason Fried in Basecamp announcements, that was the first reality I faced: what I mistook for depth was merely the residue of anxiety the writer packed into the text to drown out their own inner critic.
The first path we tried wasn't rewriting the text from scratch, but stripping adjectives from existing sentences. That approach failed. When you delete filler words like "quite," "really," or "basically" from a 300-word paragraph, you end up with a clumsier, 210-word version of the exact same defensive structure. The text suffocates; because the conjunctions snap, the sentences turn into a telegraph dispatch.
So we reversed the method. We erased the paragraph entirely and applied a load-bearing column test similar to the structural backbone in Axios's Smart Brevity framework. The narrative triad Basecamp constructs in its product copy was the only legitimate scaffolding that could hold an announcement upright:
Every intermediate sentence that failed to answer one of these three questions—how exhausted the team was, how difficult the decision had been, what industry standards dictated—was cleared off the table.
Our initial draft announcing an email synchronization delay to users looked like this:
"As you know, due to asynchronous query loads on our database in parallel with our recent traffic growth, some of our users may have experienced periodic delays in new inbox message notifications. In order to permanently resolve this issue, our engineering team worked on a comprehensive architectural overhaul over the past week and restructured the background queue system. While a temporary slowdown may have been felt during this migration because legacy indexes needed to be transferred, our system is now running far more reliably and no action is required on your part." (88 words, packed with technical excuses that originally ballooned up to 300 words.)
When we ran this through our three-column pruning rule, here is all that remained:
"Over the past two days, new messages in your inbox appeared with a 5 to 10-minute delay. We migrated our queue infrastructure to a new server cluster designed for high traffic, returning data flow to normal. From this moment on, all your messages will continue to be delivered instantaneously; no settings adjustments are needed."
The first draft tried to soothe the writer's guilt; the second draft zeroed out the reader's cognitive load. Within 10 seconds, the user understood what happened, why it happened, and what was expected of them.
The biggest pitfall when cutting copy is killing cadence in the name of brevity. In Jason Fried's editing philosophy, every sentence needs its own breathing room. Mechanically hacking away words just to make it short (for instance, writing "Delay occurred. Server moved. Problem solved.") makes the prose feel crude rather than authoritative.
True editing isn't about subtracting words; it's about loading logical causality directly onto verbs. If you want to drop heavy conjunctions like "because," "therefore," and "in this regard," you must link the verbs of consecutive sentences through natural cause and effect. Otherwise, the reader has to piece the logic together in their own head, which breeds cognitive fatigue.
Like any craft rule, the three-sentence discipline has distinct boundaries. When you apply this method to discrete product updates, minor infrastructure tweaks, or UI guidance, you build trust.
However, during multi-stakeholder crises, data security breaches, legally binding terms revisions, or widespread service outages, radical three-sentence pruning backfires. In those scenarios, users do not read extreme brevity as clarity; they read it as an attempt to "conceal details and dodge accountability." Indeed, in one crisis experiment where we compressed the copy too aggressively, we watched users flood support queues to hunt down missing technical specifics, doubling our operational load. In complex, high-stakes situations, readers don't want staccato sentences; they want bounded, complete context.
When you put an announcement or product copy on the editing block, don't waste time hunting for weak adjectives. Wipe the paragraph clean and answer only these three questions in succession: What was the problem? How did the mechanism resolve it? What does the user need to do now? Any excuse that cannot be carried by those three sentences has no business being on the reader's screen.