The tool is not important. The tool is not important. The tool is not important.

I have been repeating this mantra in my head for the past week or so, over and over, like a broken record. I’m in the middle of pulling together the requirements and scope for a new technical community website for our users, which will become the key focus of our technical information. The more traditional product documentation set will be maintained as we move forward, so there is some thought to be given towards how we manage the information as well as how it is published, or rather where.

I must stop considering the how. The tool is not important.

At present I have a list of requirements, all of which I’m thinking through from the point of view of how the process will work as far as creating and maintaining the information. Who will be access the source, who will be viewing the published information, who can edit what, how will the information be used by the audience? All the while there is a part of my brain dragging me towards HOW this will work. What tool will be able to handle our requirements?

The tool is not important.

I enjoy a challenge, and this is most certainly a new venture for me, but the basic foundations of this idea are rooted in things I know well, single sourcing content, developing online communities (I run a website for Scottish Bloggers (currently dead after our hosting service disappeared)). As such I’m confident I can get this off the ground, but even so I’m being careful to properly gather requirements, and fully understand the impact of changing our publishing model. Note I said “model”.

The tool is not important.

So with a list of requirements, and a full understanding of the processes that will be involved both to maintain the main documentation set and the development of other supporting information (culled from internal Wikis, mailing lists and anywhere else we stumble across something useful) one change is the way in which we plan, design and write product documentation.

As I’ve said, this is all about the processes that support the way we work. I’m being quite deliberate in how I pull together the requirements, focussing discussions on the audience, the expectations, the information and processes, with no mention of the technology which will need to support the new website.

The tool is not important.

Last year’s X-Pubs conference drilled this message home, and it’s good to be able to draw on the information and knowledge gained there. Get your requirements sorted out and agreed, understand the impact of changing the way people access information, and the impact of changing how people work, figure out how best to handle the reaction to change and agree the expectations and limitations of your system. Decide which models you will follow, how the processes will hang together and outline the various roles that will be required, and make sure they understand what is required of them.

Then and only then should you consider what tools you require and make sure they are serving you.

Deliverables are dead. Long live multi-format, anytime, anywhere delivery of information!

The more I think about it, the more I am beginning to see that creating content, writing and styling and planning, for “print” is no longer valid.

Quick caveat: Know your audience and the requirements. Many places mandate printed documentation in one format or another. I am purely talking about my own experience in a software environment.

I’m the first to admit that whenever I start thinking about updating a manual I think in print terms. I think of entire chapters of information, I think of how the user will be able to navigate and understand the layout and construction of the document. Changing those habits is proving hard but I’m slowly getting there.

Part of that change has come about by focussing on the information types we are going to be using as the building blocks of our single source system. Making each topic unique and complete within itself requires some thought and planning, and with that planning being focused on tasks, you soon get a simple outline of the required documentation including the type of information that you’ll be writing for each chunk.

As that realisation begins to sink in, the possibilities of re-use suddenly make themselves clear. It becomes a simple matter of drag and drop to create an entirely new manual, and a new delivery method becomes a simple matter of publishing to a new format.

The latter fits nicely with some current thoughts around how we get our technical information to our customers. Whilst I don’t think Author-IT would be the best solution, or at least the complete solution, I can see us focussing more on a web-based delivery of information, pulling other available content (from mailing lists and wiki pages) into an MSDN-like community website. Add in a blog and some interaction and it could very well be the shape of things to come.

As I’ve mentioned before, for a lot of people in the software industry, the internet is THE source of information. So rather than try and force how we want the information to be delivered (maintaining legacy documentation) I’m looking at how we can deliver something our customers will use, without succumbing to the Web 2.0 crazies. Yes it could have a blog, but does it need one? Yes we could use Twitter to provide ‘from the floor’ thoughts from the development group but who would sanitise them first!

Wikifying the doc set (to borrow a phrase) is a possibility of course, but that would only be part of this solution, and would have to include the ability to package it up as a different deliverable (PDF for example) so the information can be accessed when the internet isn’t available, a requirement of our documentation.

There are other considerations of course, all of which are still being thought through and will need discussion and buy-in.

Exciting times ahead I think. More on this as it develops.

As a technical writer, I often find myself bemused by the design decisions made by developers and product designers. Any time I find myself bemused by a product I tend to look towards the supporting information.

However, the technical writer also has guard against such things, as evidenced by the instruction manual I received with my new watch. The watch itself has four buttons, and like most digital watches each button will do different things in different modes.

The buttons are not labelled on the watch itself and so the instruction manual is the only place to figure out what button does what. OK, I’ll admit it, I did play with it for a while before turning to the manual at which point I became a little confused.

There are four buttons, and in the instruction manual there is a simple diagram showing that they are labelled A, B, C and D. So far so good.

However, and bear in mind this is a watch so when you look at it the cognitive suggestion is “clockwise”, the buttons are labelled in an anti-clockwise order. Now if each button only did one thing, this wouldn’t be that big a deal. Yet because of the non-intuitive way they had labelled the buttons, I continued to find myself confused as to which button to push, returning to the manual at every point to check which button was next.

This is not a flaw in the hardware (the watch) but in the instruction manual.

Why do I mention this? Two reasons:

1. We are the interface to the interface. We can break the “product” as easily as we can enhance it.
2. Making sure co-workers realise that the documentation is part of the product can be tricky, and this leaped out at me as a good example. The product suffers because the documentation is poor.

I’m pretty sure this could have been avoided if the writer had spent more time with the product as there is little better way to fully understand how a product works, than sitting down and using it yourself.

That said, it is a very nice watch…

Recently, Tom suggested that:
if someone can figure out how to make help whallop the user with wonder and awe, it will be the creative innovation of the century. Once we begin to establish a standard and a precedence, people’s beliefs will change from feeling that “all help is useless and unimportant” to “the help at my company is exceptionally good and useful; I will explore it more often.”

And I completely agree.

But.

Whilst he goes on to list ways in which the future of online help may expand – personalized help, feedback options, audiovisual options and such like – I think that is only one side of the coin.

While, without a doubt I could work harder to improve the content offered as online help, I think technical communicators need to expand their view a little, step back and see a bigger picture. I’ve touched on this before, and it is by no means original, but ultimately we are at a point where it is beginning to be realised that the information provided with a product is a most valuable commodity. With that in mind, the time is ripe for what Tom suggests, a new way of presenting information is surely on the cards. However I think it’s wrong to limit it to online help or documentation alone.

I’m lucky that, presently, I’m part of a company that allows the Publications Team (MUST change that name!) to be part of the softare design process. As such I can see, from inception to release, the decisions and design thoughts that go into producing our software, and I influence them as much as I can. Making the on-screen text useful is one thing, the next step is to think “task task task” during any discussions on design. Developers, rightly, take a requirement and start thinking about how THEY can implement it, yet just by repeating the “task task task” mantra I was able to get them to start thinking about how it should end up, rather than the finite possibilities of how it could be implemented.

Just to clarify, I don’t sit at my desk and chant. Instead I tend to start discussions about our software with “OK, I’m [insert user type], what am I trying to do here?”.

I’m not ramming this down anyone’s throat, but my choice of language during discussions has started to rub off, resulting in some design decisions made because they were thinking about the task the user is trying to complete, not the fact that it would need to get info from database A and publish it to form B.

In response to Tom’s post, I said:

Perhaps the radical shift is helping to address issues without presuming that people will “end up in the help”. Instead of being the last resort we should be striving to stop people having to get to that point.

That said, if they do end up in the help then yes, it should have a sufficient “wow” factor without being useless. Ultimately, make sure the information they want is findable by whatever means they choose.

Being the customer respresentative, the interface to the interface, is part of that.

I once told a Technical Support Manager that, ultimately, the aim for my team was to put his out of a job. Obviously that will never happen as the myriad of platforms, hardware, and user issues that surround every software product couldn’t ever be documented (unless development of the software had ceased, in which case I wouldn’t be working for the company).

I guess the aim for a usability team, or anyone interested in improving the user experience, is to put the documentation team out of a job. If the interface is well enough designed that the user doesn’t get stuck, and if it includes enough information in the UI to help the user make decisions, then why would they ever need documentation? Of course, similarly to the Support team scenario, documentation will be required to support the less travelled paths through the UI, to help the user who wants to do things her own way.

And that is where Tom’s suggestions come in. If we can improve the information we provide, making sure the customer experience is maintained (bettered?), then they are more likely to come back.

As I mentioned previously, the opening presentation at TICAD was by Adobe and featured their vision of the future of Technical Communications and information development. Apparently that future includes video.

Video has been available to many for a few years now, yet it is never really the main focus of a documentation team. Tom has questioned this as well:

“For too long I’ve minimized the importance of the audiovisual. Captivate — the industry standard tool for creating screen demos — is actually a relatively simple application. Mastering it and integrating audiovisual into user help will take it to the next level.”

This echoes what Adobe suggest, no big surprise there, but I have to admit that I don’t fully agree.

As a quick learning tool, I’m sure videos (screen demos) are useful, but I wouldn’t really know as I’ve never used one as a primary source for learning about a product and I’m not sure I know anyone who has. Of course that’s not to say they don’t have value and with some research into the intended audience I’m sure it can be proven that they have a valid place in the product documentation set.

However my initial thoughts on the matter are hard to shake.

It may be one of the unwritten rules of documentation, the rules that few people question and may well be inaccurately applied, but I’ve always operated under the assumption that people only use the documentation when they are stuck.

Of course this is a broad sweeping statement but I believe that it is true for the majority of software users. So, if that is the case, what is their mindset when they finally give in (having asked a co-worker and searched Google to no avail) and fire up the online help or open the user guide? Typically they will be annoyed and want an answer or fix pretty damn sharpish.

Why, in that case, would they even consider sitting through a 2 minute video that explains how to use the functionality with which they are currently battling?

To be fair, Tom isn’t suggesting this approach but I think it’s wise to counsel against this trend lest it be used too heavily. A few short demos of how to complete core tasks, accompanied by a comprehensive help system or user guide is the best balance.

My fear is that the “cool” effect will override sensibilities and we’ll be plagued by popup videos and worse in the future.

The written word certainly isn’t the only way to effectively communicate information, and as technology progresses we will all need to carefully match the available delivery mechanisms with the information we need to deliver. The key word here is “carefully”.

I’d love to hear from anyone who is already doing something like this, I’ve not used Captivate, nor offered any form of video as part of a documentation set before as they didn’t match the audience profile but I’d be interested in hearing how successful they were.

Just visited the McAfee website and on one of the forms encountered a, shall we say, anomaly presented itself.

I am a patriotic kind of guy, and I’m not in any way anti-American (I’m well aware that the percentage of idiots over there matches the numbers we have here), and when you actually consider what I’m about to tell you isn’t really about patriotism, jingoism or somesuch.

Rather it’s a wonderful piece of bad programming that I’ve seen before, centred around the fact that (at least for the purposes of this discussion) the country I am identified with is known as both the United Kingdom (UK) and Great Britain (GB).

I’m Scottish, and my country is part of Great Britain (which is the main island mass which also includes Wales and England). Add in Northern Ireland and you have the United Kingdom. It confuses me but that isn’t really the issue here.

When selecting my nationality in an online form, invariably I have one option: United Kingdom. On some forms I am delighted to be able to select Scotland, and on others I have to hunt for Great Britain.

However, the McAfee form in question proved a little troubling.

On highlighting the Nationality list, and tapping the U key, I was taken down to Uganda. A few more taps of the DOWN arrow key is usually all that is required to get me to “United Kingdom”. Not this time though, so I clicked the list top expand it, just to make sure I hadn’t keyed too fast but no, there was no United Kingdom.

No problem, I think, I’ll just tap the G key to get me back up the list towards Great Britain. This time I expanded the list first and scrolled down to… hang on… no Great Britain either? Great! Must be an option for Scotland!

Nope.

Somewhat puzzled now I double-checked that there was no entry for Scotland. There wasn’t. United Kingdom? Not listed amongst the rest of the nations of the world that begin with U. Must be Great Britain then?

And there it was, nestled away amongst the Gs. “United Kingdom”.

Now technically I can figure out what has happened, the label which is displayed to the user is “United Kingdom” but the value, on which the list being sorted, is set as “Great Britain”.

I have to wonder if this was tested at all and if so they have missed a fairly obvious set of test cases. If you are a global company then you need to consider these things.

OK, admittedly it is a tiny mistake amongst a large and complex website but it does serve to remind me to take the unhappy path through our own software now and then. I have a tendency to check through screens and processes presuming a lot of knowledge and taking the happy path.

Footnote: I worked for Dr. Solomons for a year before they were purchased by McAfee. One of the projects (ditched by McAfee) concerned a global company update system, during which many long design meetings centred around just this kind of “international” issue. But hey, I’m not bitter that they made me and 250-odd other people redundant almost immediately after they bought us, honest…

I started this blog to have a separate place to write about my “professional” thoughts and I guess I thought I could maybe add a little value to the cluttered world of technical communications, or at the very least raise my profile a little. Yes, I have an ego, but it’s kept in check for the most part.

However, like my other blog, the main reason this blog exists is to give me a place that I can consider and process my thoughts. I’ve always found writing things down helped me get a good sense of what they were, even if I didn’t necessarily start with a cohesive picture in mind. Sometimes the simplest issue, one that has eluded me for some time, leaps into focus when I start writing. I’m not sure if it’s always been that way or I’ve now trained myself into such a habit but I’m not complaining, it works for me and I’ll admit that I still get a little buzz when something “clicks”.

If I were in a cartoon a light-bulb would *plink* into existence above my head when that happens. Reality can be such a disappointment.

Today brought a good example of such a moment and rather than deleting my thoughts, I’d thought I’d post them here. Sharing is power after all (badly paraphrasing remains inexcusable).

One continuing theme on most of the mailing lists I follow and in various blog posts across the land, is that of knowing your audience. Knowing why you are writing, and who you are writing for are the fundamental tenets of our profession. They are so fundamental that, if I’m honest, the incessant reminders about them do start to grate somewhat. After all I’m a professional, how many times do I need to be told to consider my audience? How many times do we need to restate something we all know and understand.

I’m happy to admit that some will know more about their audience than others. Some will make do with a rough approximation of what their audience expects, whilst others will interview and analyse their customers and gather requirements and direction directly.

Regardless of your level of commitment to understanding them, anyone who is writing must (surely) consider their audience. Yet, at every turn, the answer to many questions all stem from that presumption, and are presented in simplistic terms. Know your audience they say. OK OK, I get it!

The thing is, after reading such a response for the umpteenth time it suddenly struck me that yes, we do need to be reminded of this basic fact, time and again.

We all have pressures on our work. Whether those pressures come from commitments made to others, from our own professional integrity, or directly from the customer, they all serve to focus us on the end goal and usually to start thinking in terms of quantity. We know we need to document the new interface to the ACME Widget and when pressure is exerted their is a temptation to take shortcuts, and the easiest shortcut is, by and large, to forget the audience.

The cardinal sin allows us to omit information on the presumption that they will “probably know it”, to structure the information according to UI rather than task, and ultimately to regress to a “if you can click it, document it” mentality. That may be a valid mode in certain circumstances but that will depend upon, yeah you guessed it, your audience.

Audience analysis, the use of personas, call it what you will, if you don’t have at least a rough idea of the type of person you are writing for then why bother? You won’t be structing the information correctly, you won’t be pitching the level of information appropriately, and you most certainly won’t be thinking around the various conceptual models your audience are likely to use and understand. The more you know, the better you can focus your documentation, drilling down into the tasks they need to complete and what they need to know before they begin. The better your knowledge of your audience the more likely it is you’ll produce documentation that they can use.

Put it this way, if you aren’t writing for a specific audience, who ARE you writing for?

Ooops.

I’ve gone and done exactly what I said annoyed me, lectured you all on knowing your audience when you already know that you need to know that. You know?

Next time I read yet another “Depends on your audience” response in a mailing list I’m going to try and remember that advice and apply it to my current work.

Addendum: Charles Cooper has been considering the same thing.