It's STC not STW

There’s been a lot written lately about the financial and operational crisis that the Society of Technical Communicators is facing.

A lot of people have posted some great ideas on Twitter (Identified by the #stcorg hashtag), and bloggers such as Sarah O’Keefe and Tom Johnson have outlined several ideas and observations that I agree with, and don’t intend to repeat here.

However there is an aspect of this institutional crisis that I believe needs a little more exposure, and one I’ve raised during several recent presentations at different regional STC events.

The third letter in our professional organization is C. C for communicators. It isn’t W for writers, yet that society is overwhelming sold to technical writers, its publications are aimed at writers, and not surprisingly the vast majority of its members are writers.

But what about the other “technical communicators”? Where are the technical illustrators, the animators, the graphic designers, the video producers, the script writers, the podcasters, etc.?

When I’ve mentioned this before the answer I’ve invariably received is “Oh we have SIGs for them.” – Special Interest Groups – really?

They aren’t a marginalized “special interest,” they are the future of the industry.

When I joined my first technical publications department in the mid 1980s the ratio of writers to illustrators was 2:1, add in other people who contributed to the production of the technical documentation and the number of writers was actually less than 50% of the total departmental head count.

In the opening decade of the 21^st century when more people receive information visually than ever before a Society of Technical Communicators should be full of people who think, and deliver information, visually.

If the STC is to survive, it needs to attract and embrace the practitioners of the visual arts.

The same goes for those who are as comfortable working in the sound medium too – and the training folks who are developing interactive documentation, and – well the more you think about it the more the list grows.

As a writer, I would be delighted to see the day when the membership of the STC resembles that technical documentation department I joined over 20 years ago – where writers are actually in the minority.

Truth in Marketing is not an Oxymoron

“I’m a writer; I take the truth and give it scope.”

– Paul Bettany as Geoffrey Chaucer in A Knight’s Tale (2001)

If I have one underlying tenet that I try to live by, it’s to tell the truth. It’s a philosophy I also apply to my writing. Most of my published work to date has been non-fiction, and by its very nature involves a lot of research and fact checking to make sure that what you are presenting is the “truth.”

The problem with doing research based on historical events, and particularly in the case of biography, is that the “truth” is often what the person telling the story believes to be true. For that reason, as much as possible, I try and go back to original sources and documentation. The same thing applies when I’m writing fiction, I always try to stay truthful to the established rules of the fictional world I am working in. With a licensed property that also means doing a lot of research into the facts that other writers have established.

So what has this got to do with corporate communications?

Most of the corporate writing I do these days is marketing communications. From blog posts, to Twitter, white papers, product literature, websites, and press releases. And, as with my other writing, I always try to tell the truth. Sure, as the quote at the start of this post mentions, I sometimes take the truth and give it “scope.” Yes I’m perfectly happy saying that 10% is “double digit growth” or that 51% equates to “most,” or “the majority,” because beneath the spin they are still verifiable facts.

Where I have problems is with marketing spin that uses absolute terms like unique, best-ever, ultimate*, or first. if you want to use those terms, that’s fine – but do some research and some fact checking to make sure that you really are the “first to market”, or that what your product does really is “unique,” and if what you are offering really is the “ultimate,” are you really intending to never improve it.

This is even more important when you are marketing to an audience whose daily job revolves around words and the use of language. Say the wrong thing, use the wrong word and they will go check. If what you claim isn’t true – they will call you out on it. That will undermine every other marketing message you put out.

One perceived falsehood can undermine the credibility of everything else you do.

Oh, and one more little thing that drives me crazy, if in a press release, article, or whatever, you refer to another company by name, or one of their products – make sure you get the names right.

In this day and age, fact checking has never been easier, all it takes is a few clicks of the mouse.

There is no excuse for any marketing material not to tell the truth. Sure your readers may have to read between the lines, or decipher the spin, but the foundation of what you are saying should always be verifiable.

================================

* The misuse of the word “unique” is one of my all time pet-peeves. Every time my wife watches one of those house buying TV shows and I here the presenter talk about a “unique feature” that we’ve seen 100 times before, it makes me want to scream.

5 Ways to Make Executives Love the Publications Department

“Publications never gets any respect,” is a refrain I’ve heard over and over again during my time in the Technical Communications industry. In fact I’ve even said it myself a few times. The refrain is often followed by, “no one really understands what we do, or the value we provide.” The unfortunate thing is that in a lot of cases these refrains have some justification, but it needn’t be that way.

As an example over the years I’ve visited literally hundreds of publication teams in a variety of companies and industries, but one of my most striking memories is the sheer contrast between two publication departments at a couple of luxury car manufacturers.

At the first company, the documentation department had a nice modern office, in a new campus setting. They had all the latest computers and access to great technology. In the parking lot outside the publications office was a fleet of not only their own cars, but those of their nearest competitor. Any member of the publications team could use any of the cars, in exchange for filling in a small usability report. The publications team were a high profile part of the customer support organization and were considered by the marketing team as part of the product “life style” branding activities.

At the second company, the publications department was in an old hut (in fact it was an old coal bunker) at the back of the factory, far removed from the production line, engineering, or any other function it needed to interact with. Although cars were parked outside, the team had no access to them. They had only a handful of computers and their technology was at least five years behind their competitors. The sole mandate was to produce a small defined set of hardcopy manuals. And that’s all they did.

So why the difference? In short the team at the first company acted like they were part of the company and projected a positive image of their skills. As such they were recognized and rewarded. The team at the second company stuck to the “we are only tech writers,” approach. They were, in many ways, responsible for their own position.

So if you feel that your publications team is “in the coal bunker” – how do you change things so that you get the keys to the luxury cars?

The following presents a basic five point action plan to help you raise the profile of what you do and make your executives love the Publications Department.

1. Realize exactly what it is the Tech Doc team does. - Before you can raise your profile, you need to know what you have to offer. Chances are that most Publications teams have talents and skills that exist no where else in the organization, and I’m not just talking about the ability to write. Also most often the Publications team is the only place in a company where all the company’s intellectual property comes together. Publications isn’t about “producing user manuals,” it’s about managing your organization’s greatest asset - knowledge.

2. Tell a good story. – People react to stories on an instinctive level. It’s easier to remember stories than it is dry facts and figures. Publications is the natural bridge between the end user and the company design, engineering and production teams. Gather stories and tell them – repeatedly. Come up with your own stories that illustrate the importance, frequency and impact of your own work. Develop fun trivia about what Publications does that people will remember and repeat.

3. Offer your services for fun and profit – Develop an in-house user community, not just an external one. Look around for other functions that you could work with or offer your expertise to. Develop an entrepreneurial mind-set and you’ll find opportunities to transform publications from an overhead cost-center into a profitable contributor.

4. Hook an executive sponsor – Find an executive’s pet project that could need some creative input, e.g. a little wordsmithing, or some graphic design work, and get involved. While the work is progressing make sure to bring the executive into your environment, and show off what the publications team can achieve.

5. Change attitudes. – If you go around say “I’m only a tech writer,” or “publications never gets any respect,” then people will believe you and act accordingly. Be aware of what you do, what you can offer and be proud of it. Treat your team (even if it’s only you) as if it was your own business. Build brand awareness, market and promote what you have to offer, and sell yourself, your team and the profession.

Over the coming weeks I’ll take a expand on each of these and provide some examples and suggested strategies.

2009 Conferences - Never mind the quantity, experience the quality.

In the current economic climate one of the first items that get cut in any budget squeeze is usually travel, and subsequent attendances at industry conferences. But, judging by my experiences at the two industry conferences I’ve attended so far this year, DocTrain West and WritersUA, this is a false economy. Yes attendance was down at both, due to aforementioned budget and travel restraints, but they were two of the best conferences I’ve attended in years.

Simply put, those people who were at the two events, were fully engaged in the conference. The conversations were compelling, interesting, relevant, and thought provoking. The speakers seemed to be of a higher quality and all the presentations were equally worthy of note and attention. The organizers of both conferences had put together excellent sessions with distinct themes. Most of the time I found myself attending one excellent session while at the same time wishing I could have been at a different concurrent session that sounded just as interesting. The most difficult aspect of these two conferences was scheduling your time.

Having spoken to several people who also attended either one, or in some cases both, of these conferences, it seems that I am not alone in these opinions.

So why in a time of economic belt-tightening are the conferences so much better?

Firstly I believe that the majority of people who at the conferences, speakers and attendees alike, most likely had to give a good justification for being there. While you should always have a good reason for attending any conference, having to justify the expense can be a great motivator and help you to determine a real need. Everyone who was there, was there to learn. And if I perceived one over riding sentiment from both conferences, it was that they were unparalleled opportunities to learn from industry experts and peers alike.

It was noticeable that attendance at sessions on the last day was just as high as those on the first day, and that conversations started over breakfast continued on into the evenings. Conference attendees put in much longer hours than they do in the office.

Secondly, the organizers and presenters have realized that sessions that are little more than thinly disguised marketing pitches very quickly lose you confidence and respect. The result is that most sessions today are highly focused on presenting real world results, or best practices based on experience.

Everyone I spoke to at both conferences also believed that by being in attendance they had given themselves, and their companies, a competitive advantage. Whether it was new technologies that they hadn’t considered before, like wikis; learning how to apply industry standards like DITA; or new techniques that could save time and money, such as the application of controlled languages, or a greater use of graphics; all had come away with something that more than justified the cost of attending.

In a couple of weeks I will be at the STC National Summit in Atlanta, and I will be interested to see if the trend towards increased quality and excellence continues.

[If you are at the STC Summit I'll be speaking on Tuesday 5th May at 1:30pm in the Hanover AB room, or you will be able to find me at Booth #109 for most of the show.]

NOTE: This blog entry was first published as part of my WebWorks blog

The Future is Today

Back in December I posted an entry on this blog about how observing my daughter do a homework assignment had made me rethink the way we need to approach presenting information. In business we are still bound to the book paradigm that was created in the nineteenth century, and that we, as "adults," are more comfortable with because it's the way that we were taught to find and assimilate information.

My conclusion was that today's generation approaches information gathering and learning based on a different more chaotic model, where social interaction is more important than structure. In short to survive and prosper we should start designing information not for ourselves, but for the next generation.

Today I came across this video - which makes the point much better than I ever could - the video's focus may be education, but it applies just as well to the future of corporate communications.

Writing about Wiki - New Book Project

I mentioned this in passing on my Twitter account the other day, but as it was officially announced today, I thought I'd post a few more details.



WIKI: Grow Your Own for Fun and Profit
by Alan J. Porter

Looking for a way to increase team collaboration, manage your company’s knowledge? Do you need a way to manage projects with customers or suppliers outside your company firewall? Would you like your customers to provide feedback on the information you publish? Then a wiki might be just what you are looking for.

Perhaps you have already decided that you should use a wiki, but are not sure how to go about it. Maybe you have a wiki but would like to encourage more people to use it. Or you would just like to learn more about the practical applications for this fast growing technology.

Then this is the book for you.

WIKI: Grow Your Own for Fun and Profit will introduce the concept of wikis, and show why they are becoming the must-have communications and collaboration technology for businesses of any size.

The book will also include several case studies highlighting the ways that various companies are using wikis to solve differing business and communications issues, and the resulting benefits in terms of both efficiency and customer satisfaction.

WIKI: Grow Your Own for Fun and Profit will be available early next year, but we will keep you informed with excerpts and news along the way.

The official web site for the project is HERE, and it will be updated as the project progresses.

Why Technical Writers Shouldn't Be "Writers" - Slides

Technical writers love the written word. Perhaps, we love it a little too much? We need to ask ourselves is the written word the best thing for documentation? Is it the best thing for us as an industry, and is it the best thing for you as a content developer.

Over the last several months I've delivered a talk entitled Why Technical Writers Shouldn't Be "Writers" at several STC regional meetings and conferences (such as last week at DocTrain West)

The presentation was inspired by an earlier post on this blog, and takes a look at why we are so focused on the written word, and presents a few ideas about better ways for us to deliver our message to the end user in a way that increases customer satisfaction.

What can we as documentation professionals learn from just observing the world around us, and how people communicate? What is the impact of new Web2.0 technology and social networks, and how they will change the way we need to view documentation design, distribution and usage?

Several people have asked for copies of the slides I used, so here they are.

However the slides are not full of text and bulleted lists, in line with the central theme of the presentation, they are mainly graphics used to illustrate an idea or to serve as talking points. This is a "performance best seen live."

If anyone is interested in me delivering this presentation to their STC group, the writing team at their company, or a conference - then just send me an email, and let's chat.

Why Technical Writers Shouldn't be "Writers"

View more presentations from 4JsGroup.

Should Customers Pay for the Manual?

Yesterday a friend of mine posted the following on his Twitter feed

OMG! (Company Name) actually charges for their owner's manuals! That's absurd.

Absurd? Really? Is that the common expectation - that all the manuals associated with a product should be "free"?

Over the years I have, at different times, worked with two companies that have almost directly identical competing product lines. In general they each have around 50% of their given market (although actual market leadership tends to fluctuate between them on a year to year basis). Yet they have two diametrically opposed philosophies when it comes to supplying documentation.

Company A has the philosophy that when you buy their product you get everything included to run, maintain and operate it (but not to repair it) so they include the cost of producing the documentation in their product pricing. They make their money on spare parts.

Company B has the philosophy that when you buy their product, you just buy the product and then pay extra for the bits and services you need, as you need them, so they have a lower product price and charge for their documentation (and their spares too).

The total cost of ownership for both products over the normal operating span turns out to be just about the same.

Let's take a look at the two scenarios in more detail.

COMPANY A - Documentation Included

This is perhaps considered the more traditional model. A content development team writes the various manuals , help sets etc. and publishes a complete suite of documentation. The whole suite is then delivered with the product. That suite can range from one small manual to literally (in the case of an aircraft) hundreds of large volumes. The cost of producing those manuals is covered in the product cost, and the customer perceives them as being "free."

That's how it should be. I've been amazed at the number of times that I've done consulting work for companies that don't even consider the cost of the documentation. They don't calculate it, they don't consider it a development cost and they don't cover it in the price of their products. Often companies like that consider documentation to be "a necessary evil" (a phrase I have heard more than once) and an uncontrolled overhead. As a result the content development is not considered an integral part of the design and production process and is poorly funded (if at all). The result is usually poor quality documentation. As a general rule of thumb, if you buy a low commodity priced product and it includes "everything," then there is a fair chance that the manuals will be next to useless. (I know this is a broad stroke statement, and there are always exceptions to it).

COMPANY B - Documentation Sold Separately

In this scenario the cost of producing and distributing the product documentation is usually well understood and managed. Most products in this case will ship with a small "free" documentation set that covers the basics of getting started, and simple opertaion (like the books in you car's glove box for instance) with the expectation that if customers want to know more they are prepared to spend money. Again think of the car analogy - most people who want to maintain and repair their own cars will go and buy a book on how to do it. There are whole companies who write and sell sepcialist manuals for car dealers and repair shops. The vast majority of customers will never access a full documentation suite, so why provide it to everyone? The manufacturer can focus on producing the documentation that 80% of its customers need, and the other 20% can be covered by a recognizable revenue stream from selling the specialist manuals.

One area of opportunity where I believe that the "pay as you need it" model breaks down is that currently most manuals you pay for (including the one that my friend was complaining about) are PDFs of traditional print manuals. You still end up buying the complete book even if you only want one or two sections of it. - If you have a pay to download the manual model, why not publish it based on topics (DITA?) and use a system of micro-payments. Instead of asking customers to pay $10 (the amount that outraged my friend), $15, or $20 - why not charge $0.99 a topic?

So which one is the right approach? I think they both are. Whether or not you charge for documentation is a product of many factors such as the business plan, the content development team's role in your organization, customer expectations, etc - but one underlying thing that applies is that the cost of documentation development should be correctly calculated and factored into the product development costs. You need to recoup that costs somewhere - it just becomes a matter of deciding where in the product life cycle and how.

BUT... if I had to favor one, I'd say go the separate charge route. - it gives more flexibility for delivery, it gives the customer choice, it lowers product prices, and it turns the content development team from being an overhead into a profit center.

On a personal note, when I switched one documentation department from being an overhead to being a revenue generator it completely changed the way the role of documentation, and the people who produced it, was perceived.

And the customers liked it too.

Don't educate...learn!

Earlier today I came across the following post on a Tech Doc related discussion list.

We still use X and while we (the tech writers) think they are useful, I think our users mostly rely on Y. We've attempted to educate our users on the value of X, but based on the questions I get I don't think a lot of our users think of using X on a regular basis.

(AJP - Quote edited to remove names of specific processes)

Wow - so if I get this straight, the users of the information like to use it one way (Y), but the content creators think they should be using it another way (X) so they make every effort to "educate the users" as to how it should be done.

If the majority of the people who uses your content are following the same behavior pattern, isn't it better to look at why they are doing that, and the value that THEY find, rather than the value that YOU think is there.

Learn from your customers. Find out why they prefer Y to X, and then do what you can to make Y even better. If that means dropping process X, then do so.

Those of you who have heard me talk will have heard this before, but the documentation industry is not about us as content creators, it's about our customers and how they access, assimilate, and use that content.

10 Commandments of Storytelling as applied to Tech Doc?

One of the topics I am slated to deliver at various conferences in 2009 is my presentation on why I think “Technical Writers Shouldn’t Be Writers.”

Towards the end of that presentation I have a slide that mentions four recommended books as “must reads.” One of those four is Robert McKee’s “STORY: Substance, Structure, Style and the Principles of Screenwriting.”



Anyone who reads this blog will know that I’m a strong advocate of storytelling in all forms of communications. I believe that it applies as much to technical or marketing communication as it does to your favorite novel or movie.

It seems I’m not alone in that thinking. Over at the excellent slide:ology blog a recent post applies McKee’s “10 Commandments of Storytelling” to PowerPoint Presentations.

Picking up on that thought I decided to see if I could apply McKee’s 10 Commandments to Technical Documentation.

1. Thou shalt not take the crisis or climax out of the protagonists hands.
So who is the “protagonist” of your documentation? It could be your product, but the most likely candidate is that your “protagonist” is the person using your documentation. Your documentation should be written in such a way that your protagonist can use the information so that they feel that they have solved the crisis (or put more prosaically, overcome the problem they have) themselves based on the knowledge you have presented. Another story telling trick, often cited by screen-writer Todd Alcot, that is worth remembering – ask yourself “What does the protagonist want?”

2. Thou shalt not make life easy for the protagonist.
This seems contrary to the very purpose of Technical Documentation. Isn’t it our job to make life easier? Yes it is. But in certain types of documentation, such as training materials, you may want to include challenges, and then guide the reader through them. This way you can build a sense of accomplishment as the reader progresses through the material.

3. Thou shalt not use false mystery or surprise.
Don’t hold back anything that is integral to full understanding of the product or service you are writing about. But also make sure to reveal information in a logical manner that is considerate of the reader’s needs. Make sure they have the information they need to know, at the time they need it.

4. Thou shalt respect thine audience.
The first rule of any sort of writing is “know your audience.” Know them, and respect their level of knowledge. If you are writing something for experts, then you may not need to include the basic information that you might use for a more general consumer market. The use of conditional text is a great way to handle different topics and statements designed for different audiences within a common documentation set.

5. Thou shalt have a god-like knowledge of your universe.
A joke I often use is “What’s the definition of an ‘expert’?” – The answer is “it’s a person who has read two more pages in the manual than you have.” So what does that make the person who wrote the manual in the first place? We may not know everything about what we are documenting, but we should give the reader the confidence that we do.

6. Thou shall use complexity rather than complication.
Most of what we write about in Tech Doc, is by its very nature, complex. We should take that complexity and break it down into logical steps and topics that can guide the reader. We should never use complexity as an excuse for making the documentation complicated.

7. Thou shalt take your character to the end of the line.
We learn in grade school that every story should have a beginning, a middle, and an end. The same applies to documentation too. The narrative should guide the reader through the process, or information, in such a way that it flows logically, and that at the end they know more, or have achieved more, than when they started.

8. Thou shalt not write on the nose dialog.
Wait, I hear you asking, there’s no dialog in Tech Doc – so how does this apply? Well the definition of “on the nose dialog” relates to the scene when a character says aloud, exactly what he is thinking or describes what is happening around him. So how does this apply to Tech Doc? Do you have sections of doc that are restating the obvious? Try reading your docs out aloud? Is it boring and repetitious? Try altering sentence lengths. Don’t think anyone ever listens to docs as if it was dialog? As a teenager I spent hours working under cars while a buddy nearby would read the steps from the manual for me to follow. How about a visually impaired customer using a reading device?

9. Thou shalt dramatize thine exposition.
Put simply “show don’t tell.” In prose this means have your characters reacting to an event, not talking about it. But isn’t our job to tell people how to do something? Yes it is, but the key word is “how.” Replace long descriptive texts on operational theory with a few active steps the user can take themselves, that demonstrates the product, and they will gain a quicker understanding. People learn more by doing than they do by being told.

10. Thou shalt rewrite.
Do I need to explain this one? Plan your schedule with time to write, have someone else review, and rewrite. Best of all scenarios is to write, have someone actually use your draft to accomplish the tasks you have written about, get feedback. Better yet, watch them try to use your docs. Then go back and rewrite based on your observations. They say that any good piece of art is never finished. Writing is art, even Tech Writing. You can always improve on what you’ve done.