That dreadful moment (hour? day?) when the words won’t come. We think of writer’s block as something that is stopping a well formed image from settling into the right words. But in reality, a writer’s block happens when our mental image is a little hazy and abstract. We can’t put it into words because words …
Continue reading “You’re not suffering from writer’s block; you’re suffering from indecision”
Writing begins with awareness of the single word, then moves up. What can a word mean, and what does it actually mean in its current context? Does the sentence make its point as clearly as possible? Does the paragraph come together as a single point? Is it in the right place Does the whole document tell …
When users find a gap in your documentation – some jump from A to C that gets negative feedback – don’t just fix it. Ask yourself how it got there. Gaps happen because: Someone didn’t think users needed the topic. This demonstrates a misunderstanding of the audience. someone didn’t think about the topic at all. …
As a technical writer, one of the most important questions you can ask yourself is “what are the default values of the choices a user can make, and why”. For example, if an option is disabled by default, what does that tell you about the average user and their workflow? Are you trying to protect …
Continue reading “Quick writing tip: What’s the default, and why?”
Oliver Burkeman reviews the basics of thinking about writing.
Agile got (at least) one thing right: stop writing documents no one’s ever going to read. If you want to honestly assess what will or won’t be read – and therefore what should or shouldn’t be written – you should answer some basic questions.
The only way to improve, the internet keeps telling us, is to push yourself past your comfort zone so that you’re always learning new things. Writing day in and day out, however, can mean you start to churn out documents on semi-automatic, settling for your current skill level and never improving. In fact, some of your skills, …
Continue reading “Make Yourself a Better Writer: Treat Every Document Like a Writing Sample”
Here’s a quick writing tip for user manuals: don’t add your images to the manual until you’re done writing your text. This has two advantages. The first is that when you add images one at a time over the long course of writing a manual, it’s easy to overdo it. When you add them all …
Continue reading “Quick Writing Tip: Don’t Add Images Until the Text is Done”
There is a general problem in software, more pronounced in minimalist Agile efforts, of documents that look good at the time of writing, but do a poor job of transferring information. I call these “stump” documents because readers are stumped when they try to learn from them.
Some technical writers hate FAQs. I rather enjoy them, because they’re the only bit of technical writing most people will ever bother reading. But they’re not always an easy thing to write; since FAQs are never full explanations of the application or website, deciding what to put in them can be difficult.
