It’s been a year of working from home. For some writers – parents, mostly – it’s been a year of zero focus. But for others, it’s been a revelatory year. One that showed them what work looks like when they control their interruptions. When no one can walk up to their desk to ask a quick question, or drag them into a discussion that doesn’t actually require their input, or just have a loud conversation in their vicinity.
It’s been a year of really good, built-in noise cancelling headphones.
Because we all know that we should ignore Slack and our emails for long stretches of the day. We all know we should block portions of our calendars so no one can splinter our whole days with meetings. But in an office, that only gets you so far. It only helps you focus so long as everyone else is focused. Once they start moving, talking, asking questions, turning off your notifications doesn’t provide you with writing time. Just loud, off-Slack interactions.
And those are fun, actually. I miss them. I want to sit down and have a coffee with someone. But on the flip side, I really enjoy being able to work.
So I’m going to start a series of posts about attention management. About how I structure my days and my laptop to make the most of this silence. These will be short, single-action posts: one thing you can do each week to improve your focus and – with it – your writing.
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 are precise, and the image isn’t.
To get back to writing, we need to sharpen that image. We need to make clear decisions: what are we talking about, what do we want to say about it, what details are we trying to bring into focus? A list helps. Not a pretty, well worded paragraph; a simple list of sentence fragments and single words that are all exact, decisive descriptions. When the decisions are made, writing can resume.
In a conversation about your user’s needs, it’s natural to start throwing out solutions almost immediately. Someone brings up an aspect of the user’s needs, and someone knows how to answer that aspect. But suddenly, that one aspect is all you’re talking about. You’ve just blinkered your view of the user to whatever can be handled by a single, almost random solution. Did you speak up first? Let’s talk about what kind of docs the user needs. Did the client engineer beat you to it? Let’s look at some UI bugs.
If you resist the urge to throw out solutions, the conversation stays focused on the user. You get a chance to fully articulate the user’s needs, free of the assumptions a proposed solution bakes in. It’s probably best, at this point, to take a break. Let people think for a while about everything they’ve learned about the user. A full understanding of the problem and some thinking time will lead to a creative and comprehensive solution.
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 a story from beginning to end? Where does it fit within the rest of the document set?
Always know, without a doubt: What is the document’s bottom line? What is the reader supposed to learn from it? And if you can’t draw a straight arrow from every word, sentence and paragraph to that bottom line – rewrite.
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. This demonstrates a misunderstanding of the product.
A misunderstanding of the product isn’t normally a big deal. It’s just a human mistake, often localised to the specific topic that was missed. But a misunderstanding of the audience is very often global: You simply don’t know your audience as well as you thought.
Gather user feedback about gaps, line it all up, and look for a pattern. What body of knowledge did you think your users have, that they clearly don’t? When you read the docs from the point of view of this newly reanalysed audience, what new gaps do you see?
That’s your backlog for the next quarter.
When you start a new job, you can’t really work without a mental image of the job: “This is my role. This is what I should be doing and how I should be doing it.”
But that image is about 90% wrong (yes, I made that number up), and you need to let go of it as soon as you can. It’s made up 50% of your dreams and aspirations and 50% of your old job (yes, I made these numbers up, too). In other words, whatever job you’re doing isn’t the job you were hired to do.
You need to update your mental image as soon and as often as you can. Not passively, by slowly noticing things, but actively by constantly questioning things. So for each behaviour, keep asking yourself: “Am I just doing this because it’s habit?” and “Am I just doing this because I’ve always wanted to?”
Unless, of course, you were hired explicitly to rock the boat. Then, by all means, pour out your bucket list and call it a job.
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 them from a common mistake? Save them an extra step most of them won’t benefit from? What kind of user, under what circumstances, would enable the option? What kind of user, under what circumstances, would want to enable the option and should be strongly warned against it?
Now consider explaining all that to your users. You’ll probably be helping them make the right choice.
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.
Continue reading “I Wonder That You Will Still Be Writing; Nobody Reads You”
Tools of the trade, 2014. Everything from bug tracking to HR.