1.       Your technical writer may have written a 500 page manual on how your product works but you sure don’t have time to read that beast. Why not ask the author directly? Your technical writer probably knows more about the product than anyone else at the company.

2.       Who is constantly interviewing marketing and upper management for the latest product definitions and behaviour? Not you.

3.       When Quality Assurance finds a bug they don’t cross-check your code, they check out the documentation. Guess who wrote the documentation.

4.       Does your product spec give little insight into the user interface? Your technical writer thinks like a user. They do not think like you. Trust me on this.

5.       Or maybe you have a really great idea for a product improvement but the thought of writing a proposal to the decision makers puts you off as much as writing an essay in English class did. Technical writers love writing essays. In fact, if they’re on-board with your idea you cannot find a better advocate.

Yes, it’s the phone system I’ve been writing those 400-page Internal Product Specifications for. Synapse is basically a VoIP-based telephony network that integrates into an existing LAN network. What this means is that you don’t have to buy fifty phone lines because it runs over the internet. I won’t bore you with the details, so why don’t you take a look at a promo video cooked up by the AT&T marketing guys (Quicktime). BTW, I also worked on the text in the User Interface (the display) and I can honestly say that this is the most user-friendly business phone you’ll ever use.

1. End users need documentation.
2. Technical communicators look at the product with a user perspective.
3. Technical communicators help with quality assurance.
4. Having quality documentation reflects positively on your organization.
5. Documentation provides a record.
6. Documentation saves on support costs.
7. Technical writers have a versatile skill set.
8. Technical communicators’ information gathering gets the team to think critically.
9. Technical communicators are specifically trained.
10. Technical communicators lighten the load.
11. Technical communicators can provide training and support.

I agree with all these points. The only thing I’d add is that the audience for technical documentation can be far more diverse than just the end user. Engineers, marketing managers, stakeholders, product testers, and just about everybody involved needs the goodies. Documentation is important at all levels of the production cycle.

Also, technical writers might get a kick out of this photo essay of classic instruction manuals. What I found interesting was what Dan Winters, the photographer who compiled these, had to say: "I actually think that modern manuals are unreadable," Winters says. "Visually speaking, they probably peaked in the ’30s." What rot. Seriously – is this guy part of the MTV generation or something? End-user documentation has never been cleaner and easier to understand. In fact, most help is migrating to interactive web-based apps that even a child would coo at. I understand he’s speaking as a visually-biased photographer – not a writer, but the overly intricate diagrams in his photo essay (as cool as they are in a retro sort of way) hardly represent the peak of information architecture.   

Lyndsey Amott, in an article on her website, stresses that industry knowledge should not be a primary deciding factor when mulling over suitable candidates. Her top three must-haves are:

1. design a document that looks good both on paper and on-line
2. design a document that can be updated easily
3. write instructions that are easy to understand

She goes on to say that the proof of a good writer lies in the way they organize their thoughts and that inexperienced writers shouldn’t necessarily be dismissed.

Technical writing consultant Jean Weber makes some good points in this article. She agrees that the writing is more important than the software or technical expertise. She advises companies to look for problem-solvers who keep digging until they find all the answers. But they should be somebody tactful, not abrasive.

Employers are always concerned with costs and staying on budget. If you can relay the value of creating relevant content in a specific context and to a specific audience, you’re on the right track. Remember that as a technical writer you’re the bridge between subject matter experts and the stakeholders, the marketers, and the end-users. Without you, knowledge could not be channeled into capital gain. 

So, if you find your head on the chopping block, start thinking like your employer and ask yourself why they should keep you around. The answer could just save your neck.

The goal is to provide the engineers with a base line so that they can move forward with the design process. This means I’m also creating screenshots of what the man-machine interface (MMI) will ideally look like. I’ve been doing these in Photoshop, but there is talk of moving to a program called Axure, which offers a much richer functionality and the ability to create master modules (so that you don’t have to re-generate a hundred screenshots every time a small change in the MMI is made).

All in all, it’s very interesting being involved at this stage of product development, although I was hoping to do some end-user documentation as well. At this point that looks doubtful as that’s the tech writer in Oregon’s baby.

Some of the work is a bit dry – for example, today I was determining how many characters to allocate a word for translation. The English interface has to be translated into French and Spanish, but there is a limited amount of pixels on the display screen on the phone, so I had to figure out how much wiggle room to allow the translators, in case their translation of “Answer”, for instance, turns out to be a five words long.

The company culture is quite rad – lots of barbeques and once a month there is a social with buckets of beer and an assortment of greasy food (no organic juice like at alive unfortunately). In the lunch room is a sweet gaming setup -two widescreen hi-def TVs – one hooked up to an XBOX 360 and the other hooked up to a Wii. On the table sits a couple of Guitar Hero axes and steering wheel controllers. There’s also a pool table, ping-pong table, and foosball. Basically a geek’s paradise! 

The company usually outsources their documentation to the States. Presently, however, they’re developing a completely new product line (sorry, I can’t say what it is) and need a writer in-house. This is a new position, so the challenge for me will be in ensuring that I get the information I need from the engineers without taking too much time away from their primary tasks. There are other challenges which I won’t get into, suffice to say I’ll be involved in some hardcore digital asset management and interface design…

If the position works out, I could get a permanent position down the road. Anyway, It’s exactly what I’ve been looking for, so I’m excited to start next week!

Great people, good food, and leading-edge content. Kudos to the organizers and to the Marriott Pinnacle for hosting this terrific event. And a huge thanks also to the Westcoast STC for the opportunity to attend.

Here’s the best of the rest:

Document engineering in user experience design
Robert Glushko (University of California at Berkeley)

With little collaboration between designers (front end) and information architects (back end), the result is a poor user experience. A brilliant mind, Glushko coined a new term today: the content choreographer.
What’s hot:  Doc or Die

| View | Upload your own

Social media 101: Now everyone’s a technical writer
Darren Barefoot (Capulet Communications)

From Youtube to Twitter to Facebook, social media is about two-way conversations, collaboration, sharing, community, transparency, and authenticity. It also means we have to relinquish control of our content.
What’s hot: Web 2.0 in plain English

View slides on scribd

Changing the rules of the game for the benefit of the user
Joe Sokohl (Keane, Inc.)

In his talk, Joe emphasized knowing your end user – especially when training customers. Qualitative research is the key to giving end users what they want, not what you think they want.
What’s hot: The Kobayashi Maru approach to solving problems

| View | Upload your own

How an author and editor used a wiki to write a book
Stewart Mader (Atlassian)

Stewart wrote his book using only a wiki. He found that communicating with his editors using a wiki was far more efficient than using email.
What’s hot: WriteRoom (Mac only…grrr!)

The many-armed starfish: today and tomorrow in social media
Darren Barefoot (Capulet Communications)

I can’t get enough of Darren – he’s a terrific speaker. He expanded on social media tools and explained which ones were most effective for use in marketing strategies.
What’s hot: Brightkite

What technical communicators need to know about flash
Sarah O’Keefe (Scriptorium Publishing)

Flash is finicky, but useful if you need to explain difficult concepts using animation. From motion to shape tweens, we got the basics in this tutorial.
What’s hot: Brain games

Living multiple lives: The new technical communicator
B. Noz Urbina (Mekon)

In the closing keynote, Urbina gave practical advice on how to create documents more efficiently and save your company money (the reason companies pay for employees to fly to these conferences in the first place).
What’s hot: Fly me to London

| View | Upload your own

That’s a wrap. Now go outside.

So without further ado, here’s my take on the presentations that I attended.

 Bringing the Video Revolution to Technical Communication
RJ Jacquez (Adobe)

RJ spoke about how we live in a highly visual world where videos are the primary content delivery method – especially for Gen Y.
What’s hot: Adobe Air

XML in the Wilderness
Joseph Gollner (Stilo International)

The importance of XML cannot be underestimated in the design of content technologies. In fact, web 2.0 is a consequence of the ‘openness’ of XML.
What’s hot: Douglas Engelbart and the Mother of All Demos 

| View | Upload your own

Wikis are wonderful, or are they? A real-world story of using wikis for user information
Alan Porter (WebWorks)

Wiki evangelist Alan Porter showed how his company uses wikis for their intranet as well as for project management with clients.
What’s hot: Wiki mavens

| View | Upload your own

A comparison of three visual help authoring tools
Neil Perlin (Hyper/Word Services)

Neil reviewed three authoring tools: Captivate, Camtasia, and Mimic. Each tool possesses a different feature set, so it depends what you need them for.
What’s hot: My vote for the most user-friendly tool is Adobe’s Captivate.

| View | Upload your own

 
Putting everything back together again: delivering effective information products
Joseph Gollner (Stilo International)

With DITA and S1000D emphasizing small multi-purpose units, consideration must be given to what end configuration will most benefit the user.
What’s hot: DITA online community

| View | Upload your own

Meet the bloggers: Not nearly as disastrously funny as the movie
Anne Gentle, Darren Barefoot, Tom Johnson, Scott Abel, Aaron Davis, and Scott Nesbitt

This was a fun session where we got to meet some of the world’s most prolific technical-writing bloggers in person. You can find some of them in my blogroll.
What’s hot: Made to Stick

The implementation of STE involves developing a company-specific dictionary and using documentation software to aid in the mechanical side of ensuring uniformity of language across the board. The goal is to ultimately reduce costs and facilitate quality assurance. If you’re interested, here’s an abbreviated version of Berry’s powerpoint presentation:

| View | Upload your own

I found this presentation quite interesting, especially as there is little standardization when it comes to documenting software. Berry actually dismissed Microsoft’s style guide, and even the Chicago manual of style, as incompatible with the goals of STE, but did commend them for the attempt. Some of the audience thought that STE could become too stilted and robotic. Personally, however, I could see the merit of choosing vocabulary, for example, that is completely unambiguous when it comes to reducing workplace accidents.

A case in point – a manual in the aviation industry asked the mechanic to “cut the power” (ie. turn it off), whereupon a mechanic literally cut a power-line with sheers and died from electrocution.