Ever get the feeling that no-one reads your documentation? It’s a frequent issue amongst Technical Writers and the general stance reflects the approach many take to make sure that, when someone finally picks up the documentation, they can get to the information they need as quickly as possible.

Given that, there is little worse than to have errors reported in your documentation. After all, if they’ve only just started using it to help them solve a problem and one of the first things they spot is an error then it’s understandable that confidence drops and that they are less likely to go to the documentation in the future.

Of course we all do the very best job we can, yet the fact remains that mistakes happen, errors occur. The reason that this tends to be a bigger issue for information is down to how we process the knowledge we have.

Without getting into too much detail, learning is a continuous process and most of that happens when you are doing things, using the tools at your disposal and figuring out how they work and how they help you achieve what you are trying to complete. By the time you decide to check the documentation, you’ve (usually) got a good bank of knowledge already, and it’s building all the time.

So, when the documentation is wrong (regardless of whether the reader spots the mistake immediately or only realises it after trying out the instructions) it seems to be an obvious mistake. After all, if I can figure out how to do X, why is the documentation wrong for Y, it’s just the same process?

Software applications that have minor errors in them are tolerated because they are the tool and sometimes there isn’t an alternative. You learn how to accomodate those errors in the application and work around them. You can’t do that with documentation, it’s either right or wrong (ambiguous documentation is presumed wrong) so confidence in the rest of the information is linked to those initial few instances of usage.

We all have review procedures that should capture errors in the documentation, we do our best to think about how the user will be interacting with the product and base the structure and content of our documentation on that information, and we all receive that email that says “On page XY of the User Guide, it states that…” and our hearts drop a little.

However I think we should embrace those moments, be positive about them! You have a user who cares enough about the documentation to complain and I think it’s worthwhile thanking them for pointing out the error, tell them that it will get fixed, and encourage them to continue to let you know if they spot anything else.

So next time you get one of those emails, or a bug in the documentation is raised, be sure to follow up with the user and thank them. They are proving that people do RTFM.

I spent most of the weekend laying, re-laying, cutting and swearing at laminate flooring. I read the provided instructions, measured twice (hell, four or five times in most cases) but still it proved problematic. I re-read the instructions, googled a little and then, after some experimentation finally figured out what the problem was… me.

Well not just me, but my interpretation of the instructions which were a little vague in one key area. Namely, where to start. This is crucial as, most laminate flooring needs to be laid the correct way to make it possible to snap all the pieces into place. It’s a one-directional jigsaw puzzle, if you will.

The details here aren’t important, but what it taught me (for the umpteenth time I guess) is that documentation needs to be complete, unambiguous and for hardware related matters at least, a picture tells a thousand stories.

I keep going back to the assumed knowledge angle, and it rings true for this example. One of the forums I found during a frantic Googling session yielded a comment along the lines of: “The professionals know this but it’s not something you’ll find in the instructions”.

I have been guilty of this in the past. Presumption is the silent virus that can kill an otherwise excellent piece of documentation stone dead. All it takes is one presumption to render an entire document AND THE PRODUCT IT IS SUPPORTING, next to useless (or at the very least “problematic”). Introducing that kind of negative thinking at an early stage of the product lifecycle makes it very hard to undo.

Although that, itself, is a presumption. I’m presuming that most people only read the documentation when they are still novice users. So maybe that is another presumption that I need to work on removing.

Why would you choose to make something difficult to use? Are you deliberately putting barriers in the road? Or are you just forgetting the main reason why people pick up a document or manual?

Long ago, when I had just started out as a technical writer, I attended a course on designing for Print. It covered many things, from typography to layout and I still use some of the basic design rules I learned way back then.

Whitespace, choice of font, and hierarchical indentation can help make a document more readable. Clearly delineating the structure of a document without explicitly stating it as such, leaving visual clues to help the reader navigate the page (presuming you’ve covered the multiple navigation routes they’ll take to get to that page of information).

Such considerations will continue to become more important as more and more information is moved online, and is then available in a variety of media formats and devices. Structuring your content, and using visual clues to convey that structure clearly, will become ever more important.

At this point there starts to become an obvious overlap with usability, pushing technical writers to start thinking more in terms of the user experience than simple task analysis allows. Understanding the reasoning behind a user action will become equally important, and can be passed to development to influence the UI as well as directly impacting on how we present technical information in the future.

Beyond that I’m not sure where else this may take us but I do know that part of the reason I love this job is the cross-over we have with so many other professions/industries, and I can’t wait to see what is next over the horizon.

Recently I’ve been toying with some software tools to try and focus my writing a little better, stumbling across an application called Q10. A full-screen text editor which is, according to the website, “a simple but powerful text editor designed and built with writers in mind.”

Whenever I start a new piece of work I tend to write up notes in text files first, before moving them into FrameMaker for formatting and publishing. This was largely borne from limitations in Structured FrameMaker, and sits well with our usage of an internal Wiki for content collaboration. Q10 helps with this approach by doing one thing very well.

Like most well-designed products, the features are usable out of the box, but there is enough scope for tweaking things to get a system that suits you. The full-screen aspect of Q10 is the most important, blacking out the rest of the screen and leaving you with a blank slate on which to focus your thoughts. There is no menubar, with options only available through keyboard shortcuts, including one to turn off the typewriter noises which I’ve left on as they are somewhat soothing… oddly.

You can set the file encoding, a target number of words (handy if you are writing an article), change the font and colour settings, and it supports quick text allowing you to replace given character combinations with whatever you specify (I use this for product names, although you have to search and replace on the underlying text file if the name changes).

At first I was only really using Q10 for writing blog posts and articles, but I’ve started to extend it into my set of ‘work’ tools and it’s proving very useful. Sure it gets some odd looks as people glance at your screen but I certainly seem to be more capable of focusing on my writing these days.

I’ve tried a few other full-screen text editors (for Mac and Windows) but as the bulk of my writing time is spent on Windows machines, Q10 is proving very useful. Best of all it’s free!

If you are working in an Agile environment, and don’t have “single source” in mind when you write then you are slowing yourself down.

Working in an Extreme Programming environment (an Agile methodology that our Development Group follows) brings a unique set of challenges. During the early stages of a release, we spend a couple of days thinking about what we will be building, writing out the requirements as customer-focussed stories and breaking down those stories into discrete, small, chunks of work each of which has an estimated time for completion.

We don’t have a project plan, and as we work in tight iterations with functionality being released on a regular basis, there is always the chance that the scope will change at some point, generally with little warning. The system is built to deal with this so it’s not as bad as it sounds but it does throw up some challenges for the technical writer.

However with a little thought and awareness it’s a very easy system to work within, but does mean we need to push into other areas a little more.

First up you need to get involved when the developers are writing up the stories. Sit in the customer meetings and any planning meetings. Be the user advocate. Ask questions now. Stories are written from the perspective of the customer (with that customer being the person who requested the functionality) and you can (should!) help to craft these properly, making sure each story remains customer and real-world focussed. Every story, regardless of the functionality that will eventually support it, is a high-level requirement and should be stated as such. The actual work might be to make an object persistent, but the story will only say “The customer wants to be able to view previous transactions for each account”.

You should also be present during the break down of the work. At this point, with each story being broken down into small chunks of work for the development team, you can gain a better understanding of the functionality, including any presumptions and dependencies that may be added. Each piece of work should be no longer than a few days, less is better, and you can start to build an idea of the scope of work during these discussions. As yet I’ve not found any direct corrolation between X days of development work to Y days of documentation work.

So, from the stories, you should have a good idea of the high-level functionality that is being produced, and you can create an outline of the documentation that is required. You should also, having sat in on the discussions, understand the requirements of the customer and the reasoning as to why a certain piece of functionality is, or isn’t, being developed.

The chunks of work can help to feed into each section in your outline, and working to the same principles as the development group, you can estimate each section. Even if the figures are never published, it’s a good idea to take a stab at guess-timating the work based on what you know, allowing scope for research and playing with the software. These guess-timates also re-enforce the fact that you will be working on discrete chunks of work at a time, which should help you cope for descoping of functionality by the development team.

The speed of change is what makes Agile development so popular. If Agile development is the speedboat, the more traditional development approaches are most definitely the oil tanker. Slow to get moving, and hard to stop if a change of direction is needed. Understanding how the work breaks down, and writing in a style that helps encourage and support that, you should be writing discrete chunks of information that can be used anywhere.

In other words, you should be writing as if you are in a single source environment, even you don’t have a database or CMS in place, even if all that content is being held in one document. The principles and structure that single source systems promote will allow you to keep pace with development.

Be the speedboat!

“There is no such thing as too much information”

We’ve all heard this statement at one time or another, and in the internet age it’s accepted as a statement of truth. Which is shame as it’s completely wrong. Turns out, that you only need enough information, not all of it.

A while ago I wrote up some thoughts on how to integrate an authoring team into an Extreme Programming (Agile) development group. The post Trickle vs Traditional outlined a basic way of building up the required content throughout the various stages of an XP release and, to save you re-reading that post, let me grab the crux of what I was saying:

The trickle method relies on the ability of the technical author to retain a “big picture” view whilst working on multiple chunks of information at any one time. The information will not come in a set order, nor from a definitive source, instead it will trickle in from various parts of the development team, testing, and so on. Your job is to monitor the flows of information, position yourself within a stream (or two) and divert the information you need into the documentation.

In reality this means that you need to develop a good technique for filtering information, knowing when and what to leave out of the documentation and relying on your knowledge of the product to help you make decisions and make them quickly.

Quite simply, to remain agile in such a system you need to be able to make decisions. A decision can be wrong, as long as you make the decision to fix it as soon as possible.

In a way, you start to write by instinct, trusting that you properly understand all the myriad of factors that influence what information you are creating and letting your talents as a technical writer take over. As Malcolm Gladwell, who wrote an entire book about this type of decision making, suggests:

We live in a society dedicated to the idea that we’re always better off gathering as much information and spending as much time as possible in deliberation. As children, this lesson is drummed into us again and again: haste makes waste, look before you leap, stop and think. But I don’t think this is true. There are lots of situations–particularly at times of high pressure and stress–when haste does not make waste, when our snap judgments and first impressions offer a much better means of making sense of the world. [source]

All of that sounds slightly scary if you are currently working in a process-heavy environment, with requirements and specification documents been seen as a way to provide all the information everyone needs, and which are typically a rather slow cumbersome way of handling information.

Anyone who has written such a document knows how hard they are to do as you can’t know everything at the start of a project and over time things change. Having previously worked in ISO regulated companies, where the audit history of a document was almost more important than the information in the document itself, I know how onerous, time-consuming and false those systems can end up being. Many is the time when everyone in a discussion knows what is going on but you still have to write it up, review and approve it, before it can be officially logged in a system that is rarely referenced.

Monitoring the flow of information, trickling it into your documentation as and when needed, making quick decisions and trusting your instincts certainly feels like a more natural way to work. It does mean that there is no such thing as a final document and there is a chance you will publish something that is wrong; yet it is the very possibility of that happening which keeps itself in check. Allowing people to make their own decisions instills a higher level of professionalism and lowers the number of errors.

It’s not suitable for everyone and some industries wouldn’t enter it but it’s an interesting way to work. Limiting the amount of information you have available, and making decisions based on those seems wrong but it does work. You just need to be brave.

I’ve spent the last couple of days writing an article for an industry magazine. It’s not something I’ve done before and I thoroughly enjoyed the challenge. It was aimed at CEO/CFO level, so was heavy on business aspects and lingo, not something I’m comfortable writing to be honest, I prefer plain english.

However, what really surprised me was how quickly I got into the mindset and soon I was “dynamically leveraging” and “interactively promoting” all sorts of things. Now I need shake myself to make sure it doesn’t creep into my normal technical writing.

Still, it was an interesting exercise and the skillset is the same, it’s only the language that differs. I still needed to write with the correct user in mind, needed to phrase and structure the information in a way that makes sense to them, and I needed to pitch the technical level of the article correctly.

Of course, as the article is for a magazine, the tone could be a little lighter and it was fun to experiment with this. For example, I opened the article with a first-person scenario which although I’ve been writing a blog for a few years now was still a challenge, for this humble technical writer!

I’m waiting on feedback from the PR company, but hopefully it’ll get published. Fingers crossed.