The Society for Technical Communication pledges to provide services to help its members practice at the highest possible level and to enhance the overall practice and status of the profession.
The Montreal Chapter is doing a fantastic job of meeting these goals, hosting an exciting and excellent array of workshops and seminars. To find out more about the chapter, I met with STC Montreal President Charles Roburn to talk about what is involved in the practice of technical communication, how to get started in the field, and how the STC works to support technical communicators here in Montreal.
STC Montreal wants to know more about your workshop needs. Please take
their 10-question survey
In order to explain a part of a process you’d need to visualise the entire process to a degree. How do you do that?
It helps to maintain contact with the overall product manager, because they’ll generally have the overall idea of what the product is for. And customer liaison, if there’s somebody who is in that sort of position, that can be very useful because they can say “Our clients want to have this new kind of feature because they need to be able to do XYZ, and these are the kinds of circumstances in which they are going to be using it.”
That can really give you a much clearer view of the big picture and where all the pieces fit in.
Do marketing materials help?
Well, that depends. I am a little leery of that myself because the goal of marketing is to help sell something…
But this is done by explaining benefits and features.
Yes, but often with a lot of additional… well, you know. As I say that is sometimes something that technical writers can be called on to do, but once you get to the manual, it’s most likely that the user has already bought the products so you don’t need to emphasise the special features in quite the same way.
The big difference is that you don’t have to sell the product any more. You just make statements of fact.
And the other thing is that when people use technical documentation they usually want to get through it as quickly as possible, there can be room for that in, say, a programmers guide; “If you want to see what you can do with this new function go to Chapter X…”
But if somebody is trying to get a specific task done, they just want to know how to do it. So the emphasis is really on finding it as quickly as possible and doing it and then getting back to whatever they were doing before.
In what ways have the processes and the language used to describe them changed over time? For example the various materials that would have come with a vacuum cleaner purchased in the 1950’s would be as different as the physical design of the unit compared to a similar appliance purchased today. The marketing concepts and language have changed dramatically. Is the same true in technical communications?
I don’t think there’s been that great a change in the language itself. In the time I’ve been doing this job, there has been a move from printed material to online formats. I guess there has been some change in user knowledge.
People now are more familiar with computers, so concepts like double-clicking an icon don’t have to be explained as painstakingly as they were before. You’re more justified in assuming that the average reader knows what you mean.
But technical writing should always be comprehensive, and you can’t really assume everybody is going to know a great deal about the product.
In fact this can be a problem when you are dealing with complicated systems, and it is definitely something I have come across before.
Subject Matter Experts may be so caught up in what they are doing that they don’t even think about how somebody else who is approaching the project for the first time might not appreciate certain elements of a product.
I find it really helps to have an introductory section that explains the context if that is necessary. For a lot of people it might not be, but the info is all there in one place and they can look through it and move on to the next chapter. That certainly applies to things I have been working on recently.
And knowing your audience is very important as well. Because if you are writing something that is to be used internally, by a programmer say, or by customer support, then you can make certain basic assumptions that you can’t really make for someone who buys, say, a phone, who may need to know things like “Where is the on/off button?”
So in a way is it easier to work with experts, because you can make that basic assumption?
Well, often it means that I have to learn about their work so that I can make judgements about what they need to know or don’t need to know. Programming is a good example. Some of the things I am working on now I have to be very careful about handling the information, partly because it is very specific information and partly because certain elements of the programming standards are new to me.
I don’t want to over-explain things to programmers who already understand a given process, so it’s a balance. That’s where the judgement comes in.
Sometimes you just have entirely different manuals. One of the products I worked on was a business intelligence product that would go into a database and then display data on the screen to help the end-user analyse what was going on in their business.
So there was one manual for helping the programmer and the IT people work out what information needed to be displayed and that was one level.
Then there was the user’s guide for the management executive who would be looking at the information. That would explain processes to the user, such as “To find out more information about X, click here” and another graph will come up. But, again, that graph that comes up needs to be prepared by the programmer…
So there are really two different levels.
–
Thanks to Charles Roburn for taking the time to talk with Mediaville.
To find out more about the Montreal Chapter of the STC
Be sure to read the next section of this interview, in which Charles talks about the Montreal STC Chapter and getting started in the field of technical communications.
