{"id":4914,"date":"2016-04-08T10:56:00","date_gmt":"2016-04-08T15:56:00","guid":{"rendered":"http:\/\/www.encoretechresources.com\/insights\/?p=4914"},"modified":"2016-04-08T10:56:00","modified_gmt":"2016-04-08T15:56:00","slug":"ready-write-aim-no-thats-not-it","status":"publish","type":"post","link":"http:\/\/www.encoretechresources.com\/insights\/2016\/04\/08\/ready-write-aim-no-thats-not-it\/","title":{"rendered":"Ready, Write, Aim \u2013 No, That’s Not It"},"content":{"rendered":"

\"images\"<\/a>
\nWhat’s the most important element in starting a technical writing task? (Or any other, for that matter.) Why, it’s your aim<\/em>, of course. “What am I trying to accomplish with this? Where are we headed?” Putting first things first requires that you have a good fix on what you’re aiming for before you start doing it.<\/p>\n

Don’t be the kind of writer who just tries to fill space \u2013 that won’t have a worthwhile outcome. We used to do editorial writing, with a wide column of empty space to be filled daily. But filling that space wasn’t, or shouldn’t have been, our aim<\/em>. Having something to say was what benefitted readers, sharpened their perceptions and expectations of us. That was, or should have been, our real aim. <\/p>\n

Such thoughts occurred (again) while reading Neal Caplan’s post<\/a> “…You’re Not Good Enough.” Being judged by other people’s standards is okay, so long as you all have the same aim. But if you don’t, watch out. You may get to where they’re headed and find, pretty quickly, that it’s not where you need to be. It’s all in your aim. <\/p>\n

Taking careful aim shouldn’t be any different for technical writers than anyone else. What in the way of writing crisp, efficient documentation should be your intent on behalf of those who will be using it? Don’t just start spieling out directions. They may get pretty roundabout.<\/p>\n

“As nice as it is to hold a copy of a book that you wrote,” Neal notes, “it\u2019s not so nice to tell your customers that they MUST read that book before they can use your product. Or, more likely, that shelf full of books. This is the opposite of ‘just in time’ help: it\u2019s ‘become an expert on this product before you ever think about touching the UI.’\u201d<\/p>\n

Your aim isn’t to help colleagues become expert at what you’re<\/em> doing, but to become better at what they’re<\/em> trying to accomplish. There’s always more to discover, learn and know. The real question is: to what end? What are you aiming for, organizationally and individually? Keep focused on that; it’s what matters most. \u2013 Doug Bedell<\/em> <\/p>\n","protected":false},"excerpt":{"rendered":"

What’s the most important element in starting a technical writing task? (Or any other, for that matter.) Why, it’s your aim, of course. “What am I trying to accomplish with this? Where are we headed?” Putting first things first requires that you have a good fix on what you’re aiming for before you start doing […]<\/p>\n","protected":false},"author":7,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,5],"tags":[],"class_list":["post-4914","post","type-post","status-publish","format-standard","hentry","category-communication","category-the-writing-life"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t