ITauthor

I’ve been interviewing technical writers recently and it’s set me to wondering about the fundamental requirements for a tech writer. Here’s what I’ve come up with.

This is my list of skills, abilities and personality traits that no self-respecting tech writer should be without:

1. Communication skills

So much of the job is about communicating in one way or another – not just writing. Before you ever put metaphorical pen to metaphorical paper you’ve first got to be able to talk to people. You’ve got to be able to understand what people mean – which is not the same as understanding what they’re saying – and then you’ve got to be able to process information, digest it, store it up, remould it, present it, verify it and rework it.

2. Writing skills

You must be able to deliver a high standard of written English. This doesn’t mean you have a vocabulary to rival Anthony Burgess’s or you’ve memorised Fowler’s Modern English Usage. The tech writer's job is to take complicated things and make them easier to understand. Sometimes you’ll do this using diagrams and videos, but mainly you do this in writing. So the key skill here is being able to write in such a way that people can read what you’ve written, just once, and understand what you’re saying.

In technical writing we have little use for nuance and colour, light and shade, or even humour. It’s no good if what you’re trying to explain is open to interpretation, especially if it’s open to misinterpretation! Clarity and simplicity are everything.

Novice tech writers will often try to write in a way that sounds technical. Maybe they’re intimidated by being surrounded by developer gurus speaking a language they find difficult to understand. And they compensate by using technical words and long sentences. So  they’ll say “utilise” when they mean “use”. But the best technical writers are the ones who cut through the jargon, pare down the language and make complex procedures easy to comprehend by breaking them down into easy-to-digest chunks, framed in simple, well-formed English.

The motto of the help author is: "Make the reader feel smart." You want the reader to pull up a help page, find what they need to know,
read it quickly and understand it completely, and go away and do what they need to do, successfully. You want to send them away feeling good about themselves.

One of the keys to being able to do this is knowing your audience. Hopefully, you have a good idea of who your audience are. But most likely you’ll have several audiences. So, another of the writing skills you need is the ability to write at the appropriate level for an identified audience.

3. Attention to detail

It’s those little things that make all the difference. If you’re writing technical manuals for Boeing, or pharmaceutical guides for Pfizer, you will get the detail right because people’s lives depend on it. But even in other sectors, you can’t afford to make little mistakes. One small mistake in a help system and the person who went there looking for help will lose confidence and will probably decide that next time they have a problem there’s no point looking for assistance from the help system.

And it’s often those little things that people often only pick up sub-consciously that make them decide whether something is professional and dependable, or amateurish, and therefore unlikely to be reliable.

4. Interviewing skills

This is very much tied in with Communication Skills but I wanted to pull it out separately because I think it’s very important. By and large when you’re documenting software, you’re assigned to work on something that’s already in production. Other people know about this thing, and you need to find out all about it and quickly. So it’s very important that:

1. you can talk to people
2. that you can identify who you need to talk to
3. you can ask the right questions

You also must be able to listen. The art of the interviewer isn’t just in his clever questions, it’s in his ability to let the other person answer the question.

And you mustn’t waste people’s time. This is a law of software development: there is never enough time. Of all the subject matter experts you need to talk to, developers especially always need to get back to doing their job and you need time to write the documentation. So you can’t afford to waste your time – or theirs – by asking unnecessary questions. Avoid turning the discussion into a general chat, because next time you ask to speak to them they’ll assume it’s going to take a whole chunk out of their morning and you might find they are less willing to talk to you.

In a software company subject matter experts come in all sorts of guises. They’re often the developers, but they can also be product managers, QA engineers, support engineers, maybe (if you're lucky) they might be tame customers, or they might sometimes be your fellow technical writers. You need to be able to identify who the real subject matter expert is, and not just interview the person nearest you, or the person who talks the most.

5. The ability to grasp new information quickly

In my experience developers or subject matter experts are happy to tell you the stuff you need to know, provided you approach them in the right way and you don’t constantly bug them. However, they have no time for people who ask them the same question more than once. If they explain something to you once, they shouldn’t have to go over it again a couple of weeks down the line.

You need to be able to get to grips with how things work, assimilate new information and be able to extrapolate from what you know to make educated guesses which you can then verify with the experts. Good tech writers pretty much always like new stuff.

Part of the fun of being a tech writer is getting to work on new stuff, finding out how it works, and getting to explain it to other people. So the next must-have for a tech writer working in the software business is: 

6. An interest in (and preferably a fascination with) technology in general and software in particular

You have to be technical to a degree, although you don't need to be an expert. It helps to have an understanding of the technology you'll be working with, but it's also good not to have spent too much time in the minute detail of it, because it also really helps if you can think like someone who's never seen the system before. That way you can identify which bits of the system are likely to be difficult for non-technical people to understand. When I'm recruiting tech authors I always look for people who like to find out how things work.

7. The ability to structure information logically

Technical writers often deal with huge amounts of information. Manuals may have hundreds of pages, help systems may have thousands of topics. So you need to be able to analyse, plan and structure your documentation.

You’re going to have to think about how the information you’re supplying will be used, both by the reader (who may be reading this paragraph in isolation from anything else – or they may come to it after reading a couple of hundred pages before it) and in terms of how that information is used by you and your fellow tech writers (for instance, being shared between documents). You possibly also have to consider how the content you supply will be used by other departments within your company.

One of the key concepts in documentation over the past 10 or 15 years has been the idea of single source: writing something once, in one place, and then reusing it in different contexts, in different publications and in different media. For example, you might write a little section of text that will appear in several manuals, several help systems and on your company’s corporate Web site.

8. Patience in problem-solving/troubleshooting

Technical writers are usually working with things that are still in the process of being built. So, often, these things don't work properly, or they get changed without much, or any, warning. Sometimes technical writers get upset when this happens. They get stressed out because the fact that stuff doesn't work makes it hard for them to do their job. And sometimes they might get grumpy and narky because nothing ever seems to go smoothly.

These guys may be good technical writers, but they tend not to love their jobs.

So, if you’re not a technical writer right now but you’re reading this because you’re thinking it might be a job you’d like to have, think about how you’d react to working with immature, first-pass, partially built software. If you think it would annoy you being asked to document something and having to go through repeated attempts at installing, tweaking, uninstalling, reinstalling, reconfiguring, finding the right people to ask for help, figuring out the right questions to ask, try-try-trying again (Robert Bruce style) before you can even start to figure out what you need to document … If that's likely to annoy the hell out of you, then technical writing really isn't for you, because, in my experience, as a tech writer if something you’re working on is broken you usually can't just get someone to fix it for you. Generally you’re going to have to fix it yourself.  So you should have the ability and willingness to install and reinstall software, sometimes time and time again, without picking up the PC and throwing it at the wall when, at the fourth or fifth time of trying, the software still doesn’t work.

Basically, you need to do what you’re documenting. This means that if you’re writing instructions for how to install some software, you need to install the software several times, as you write,  and then when you think you’re finished you have to need (for your own peace of mind) to go through it all again (with your user’s hat on) and install it again, hopefully one last time,  doing only what it says in your instructions, and check that it’s easy to follow – and it works.

9. Graphic design skills

The first documentation manager I ever worked for had this habit of drawing diagrams. Whenever I went to ask him to explain something, he would, as likely as not, reach for pen and paper and start drawing me a diagram. At first this seemed really odd behaviour to me. Documentation was all about words, wasn’t it? Someone who had been a technical writer for years should surely be well able to explain things in words.

But after a while I realised how effective it was as a way of explaining things. And, more than that, I started to suspect my brain worked better in pictures than in words because I found that the habit was rubbing off on me. I realised that whenever I was struggling to get to grips with a concept – or just to piece things together in my head and make connections, and make sense of something – invariably I would feel the urge to sketch the thing out as a diagram.

Technical communicators are increasingly required to produce diagrams, annotated screenshots, videos with accompanying narration or even cartoons and animation. And if you don’t believe me about the cartoons, go and take a look at the work of commoncraft.com. Now, you definitely don’t need to be a designer to be a technical communicator. But I certainly think that you’ll be a better technical communicator if you have some sense of design and a facility with images and diagrams.

10. The ability to review other writers’ work

Technical writers often have to work alone. There are a lot of little software companies out there for whom hiring a full-time tech author is one of the first signs that they are taking the business seriously and thinking about user experience and they’re more than just a band of coders and a sales guy. However, tech writers perform better when two or more of them are working alongside each other, or at least: they’re working in the same organisation. Personally I hate sending my work out into the big wide world without it being checked by a fellow technical writer.

Product managers and project managers,  who review your work, will tell you if you’ve targeted your documentation incorrectly, or if you’re making false assumptions about the end users, and developers will pick up on details if you’re claiming the software does something it doesn’t. But there’s a level of editorial review that a fellow tech writer can give you, that no one else can. Because sometimes you just can’t see an obvious mistake for looking at it, and that’s where a peer review process can save you from looking like an idiot for letting something daft slip through to the customer.

So those are my ten must-haves for tech writers. Do you agree? What would you add to the list? Drop me a comment.

Note: This is an adapted extract from a talk on technical writing that I recorded earlier this month for The Writing Show podcast.

Podcast: Play in new window | Download

What's the difference between a programmer and a software developer?

Why are there so many programming languages?

What's .NET ("dot net")?

In the first of two interviews with Technology Manager Colin Paterson, I try to get some answers to these and other questions about software development.

Look out for part 2 of this interview, coming along soon(ish) depending on Colin and I coordinating a free lunchtime.

The music I play at the beginning and end of the show is by Amplifico. You can hear more of their music at Podshow.

I’ve been doing a few little tweaks to my web site recently. Nothing major, just trying to make it easier for people to find stuff that might be interesting, either tucked away in one of my posts from the past six years, or on someone else’s blog. So, today I added a page listing a truncated summary from the latest post on the blogs I like to read:

http://www.itauthor.com/articles/recently-posted-by-other-bloggers/

I realise this kind of entices people to leave my site, but so what? It’s kind of dumb to expect people to hang around your web site for very long. For example, I regularly go to the BBC web site. I never stay there very long. I don’t browse through lots of pages. I’ll look at two or three pages and then I’m off somewhere else. But because it’s well designed and has good content I go back again.

But I’ve been thinking about my web site and how I’ve pretty much just blindly gone along with the standard WordPress format, with a panel down one side with links to category and month archives. I sometimes click a month link – typically back a month or two but rarely further. But I never click a category link and I suspect nobody else does either. I don’t use tagging, but if I did I think it would be the same thing. Why would anyone browse through a tag or category archive?

The navigation that I think is useful is the collection of potentially similar posts at the end of each post. Sometimes this throws up something that I’d forgotten I wrote about and I’ll click to have a look. I think other people reading my posts might also click to have a look at an older “similar” post if it sounds interesting.

So I think I’m going to take the category links out of the side bar. I’ll probably leave the calendar links in there for now, but I’m tempted to get rid of that side bar altogether and go for a really minimalist look. On the other hand I was also thinking that the site looks quite austere. So I’m also a little tempted to try and make it look less utilitarian.

But I’d be interested to know if anyone finds tag/category lists useful on a blog. Aside from never using them on my own blog, I can’t remember ever having used them when I’m reading other people’s blogs either.

Don’t you just hate it when software tries to be helpful but just gets in the way?

I’m currently working on tidying up a migration of RoboHelp into Flare. I’ve got to say immediately that Flare does an excellent job of migrating RoboHelp projects – but only if you’ve only used RoboHelp from within it’s GUI and never gone and tinkered with the HTML or added your own Javascript.

Huh! What are the chances of that?

Any help project from a few years ago that was built in RoboHelp will definitely and certainly have some tweaking and augmenting to it – or it will look like rubbish and be clunky and unsophisticated. Things might be different in the current version of RoboHelp, I don’t know, I don’t have it – but previous versions of RoboHelp had some serious shortcomings that forced you into a bit of roll-your-own behaviour just in order to get things looking and working the way you wanted.

The trouble is, once you do a migration into Flare, none of this is handled for you. I’m not complaining about that. The guys at Madcap have no way of knowing what extra goodness you layered on top of your plain old RoboHelp projects. And fortunately, most of the time, Flare just leaves any stuff you added by hand. That way you can do what I’ve been doing over the past few days: you can run some crafty regex search/replaces to go and convert those things into something that’ll work in Flare.

Unfortunately though, the philosophy of “if you don’t understand it, don’t touch it” hasn’t been extended to the TOC processing. The TOCs in the projects I’ve been migrating use anchor names at the end of topic file names, to pass a value to a redirect file, which then sends the browser off to display the appropriate page. Why would you want to do that then, I hear you ask. Well it’s a nice little Rob Chandler trick that allows you to decide which entry in the TOC gets highlighted where there are multiple TOC refs to the same topic. If you don’t use this method, the TOC will always jump to the first reference to the topic.

After some laborious debugging I’ve discovered that, at build time, Flare is taking my TOC file, seeing references such as redirect.file#sometopic and stripping off the anchor. So, within the generated .chm the reference is just redirect.file, which results in no redirection happening because the Javascript never finds out where to redirect to.

Flare does the same with query strings, like redirect.file?param=value. Annoying! Very annoying! It’s like when you were a kid and your mother tidied up your bedroom and chucked out your favourite comic. “Well it was lying on the floor. How was I to know it was important?”

Something I’ve been preaching for years, to any software developer who’ll listen, is: don’t use a tree view control in the user interface if your users are not highly technical and there’s another way of allowing the user to do the thing they actually want to do (which there usually is if you put some thought into it).

So I was delighted to hear Jeff Atwood and Joel Spolsky’s views on the Stack Overflow Podcast #45:

Atwood:   … programmers love hierarchy, to a degree that they don't even understand how different they are than the public in this regard. Like they love putting everything in this little bucket, that goes in this little bucket, which is this sub-bucket of this and this, and normal people hate that. And threading is totally a manifestation of that and it drives me crazy that a lot of programmers can't see that they're like immediately like: "Oh, threading is good. I love threading. What are you talking about?" You know? They can't see it at all.

Spolsky:   Right, right.

Atwood:   It's like myopia.

Spolsky:   Yeh. I mean it's really a function of the size of the group, and one thing I've learned through years and years of usability testing is that anything that smacks of a hierarchy or a tree is not going to be understandable to the average, non-technical user.

Atwood:   Yeh.

Spolsky:   You just have to learn that: if it's a tree, or a hierarchy, like eighty per cent of the regular people are going to get confused and not quite get it.

Hierarchies are great at showing nested relationships, and they make sense to programmers, who are used to them – but most of the time the relationships don’t matter to the user. Usually the user just wants to find something and yet the tree view forces them to “drill down”, clicking down into a hierarchy that becomes increasingly complex as they click.

My request to all programmers placed in the position of having to design a user interface: avoid hierarchies unless you truly believe the end users really need the hierarchical information.