Getting mileage from a tech comm mission statement

If you have a mission statement for technical communications, you can use it to anchor several strategic and tactical decisions. I’ve suggested a few general reasons Why you need a tech comm mission statement in my previous post. The valuable discussion that ensued led me to think we can get some mileage from a mission statement in some high-level tasks further downstream.

Consider a mission statement that says: “Our product help provides users with relevant product information at the right time in the right format.”

Defining audiences and deliverables

You can keep your audience in focus with a mission statement. Do you write for end users? Maybe there are different types, such as professionals vs. amateur hobbyists? Do you also address colleagues who expect to find internal information in the documentation? The mission statement above doesn’t specify it – and hence can be expected to address everyone who uses the product.

You can also derive your deliverables from a mission statement. Do you publish to several formats or only to one? What is your priority of formats? Web help first, PDF second seems a standing favorite that’s recently been disrupted by the emergence of mobile output. The mission statement above merely mentions the right format – so you need to figure out what format is right for your audience types. You can use personas to determine how your users work with the product – or better yet: Observe or survey them!

Defining information model and processes

You can derive your information model, the structural standard of your documentation, from your mission statement. This model should help you to reach the goal described in your mission and serve your audience. For example, topic-based architectures have long been popular. If you need to retrieve small chunks of information, for example to share steps in a task or exception handling advice, consider a more granular standard such as DITA.

Your processes should outline a repeatable, efficient and effective way to create your deliverables so they address your audience and, once again, help you to achieve your mission goal.

Your information model can suggest which topics or elements to create need to be created and updated for a given product or enhancement. Together with your processes, this makes it easier to plan and estimate documentation efforts – in theory at least…

– But with some management support and some persistence, a mission statement and some strategic decisions piggy-backed on to it can help you get out of the proverbial hamster wheel.

What do you think? Can this be helpful? Or is it too far removed from real life? Do you have any experience with a larger documentation strategy based on a mission statement? If so, did it work?

Advertisement

Why you need a tech comm mission statement

A mission statement for technical communication can help everyone in your company (or you and your customers) to stay on track in pursuit of a common goal of what your documentation can and should achieve.

Just like a corporate mission statement, a tech comm mission gives all parties who are involved with documentation direction and a common goal. It describes the purpose and benefit of the documentation and how it is achieved. It helps to define processes for creating the documentation as well as metrics whether the documentation is successful. If the mission is well-conceived, it guides documentation strategy without prescribing it.

For example, if you want to focus on usability and speed, a mission for your documentation could be: “Our product help answers any user question about product use in no more than three mouse-clicks.” Your strategy would then aim for a well-structured, easily navigable context-sensitive online help – with printed user manuals and closely tied in training materials taking a backseat.

A more comprehensive mission could be: “Our product help provides users with relevant product information at the right time in the right format.” This would set you on a quest to find out who your user types are, which product information is relevant for them and which formats it can be provided efficiently.

A mission statement in itself cannot be right or wrong. But it must be useful in several respects. Specifically, it must help:

• Your customers and users by guiding you to provide useful documentation.
• Your company externally to provide documentation which improves the perceived product quality.
• Your company internally to anchor the importance and function of documentation.
• You as technical communicators to make appropriate strategic decisions about documentation, for example, which users to address, which deliverables and processes to define, which methods and tools to apply.

What do you think? Is a mission statement for tech comm necessary? Or merely helpful? Or a vain attempt at putting on corporate airs when the writers should just buckle down and get the job done?

(Edit: The discussion continues in “Getting mileage from a tech comm mission statement“…)

Top 6 reasons to consider speaking at TCUK 2013

TCUK 2013, the UK’s premier tech comm conference, has just opened its call for proposals – and here are some good reasons why you should consider applying to speak in Bristol in September!

What all reasons have in common is that technical communication as a field and TCUK as a conference are more versatile, lively and interesting than you may imagine!

Consider speaking because you…

1. Manage a tech comm team, project, migration or strategy. This year’s specialist stream is “The Management of Technical Communication” in all its variety. TCUK reacts to one of the industry’s megatrends of recent years which is to position tech comm, even within corporations, as a business which can prove ROI.
2. Commission technical communication. – That’s right: We technical communicators want to hear from people who engage tech communicators, in fact, we need to! One of tech comm’s mantras is “Know your audience” and that definitely includes those who ask us to create documentation in the first place.
3. Have something to share, even if you haven’t spoken at a conference before. TCUK is very welcoming to newbies! I know, they gave me my first speaking opportunity in 2010. And I have attended TCUk ever since and seen two newbie presentations last year which were met by a supportive audience.

Consider speaking because TCUK is…

1. A top 3 tech comm event in Europe. TCUK is the best opportunity to network, catch up with trends, trade experiences, mull over challenges, along with tekom in Germany and UAEurope in different countries.
2. Cozy and diverse. In my opinion, TCUK is the perfect combination of a cozy scene and a wide range of topics. It offers stimulation and inspiration of larger conferences without the intimidation that a dozen streams and several hundred participants bring.
3. Free for speakers! However, you will have to arrange for travel, accommodation, and meals yourself.

And if you don’t think you have enough for a 40-minute talk, you can still save the date and hold out for the annual “open stage” rant session. It’s not been finalised yet, but there was such a session for the last 3 years. All of the above reasons and benefits apply, except for the free conference attendance.

Just the facts, please!

• TCUK 2013 takes place 24 – 26 September at the Bristol Marriott City Centre.
• You have until 5th April to propose 40-minute talks or 3-hour workshops.
• See the call for proposals for details about topics and formats.

EPPO redux or: Mark Baker is on to something

“For users, Every Page is Page One,” says Mark Baker. Users can land anywhere in your documentation and start consuming away. That’s why structured authoring is more than one method among many – it’s an imperative to create meaningful content and to stay relevant as a technical communicator.

Few technical communicators have recently chipped away at unquestioned conventional wisdom as profoundly as Mark Baker in his blog Every Page is Page One (EPPO). Here’s his thesis in a nutshell – EPPO redux, if you will.

The following is my boiled-down edit of the session description of Mark’s workshop at the Intelligent Content Conference yesterday. I can only claim credit for the mistakes and misunderstandings I introduced, but everything below is essentially Mark’s wisdom. I share it because I find it sensible and highly relevant – if you do, too, I encourage you to follow Mark on twitter and on his blog.

Writing Every Page is Page One Topics
Mark Baker, President, Analecta Communications Inc.

For users, Every Page is Page One. So write good Every Page is Page One topics, even when you have a large amount of related subject matter to cover. Construct information so readers can meet their information needs, no matter where they land. When covering a broad array of subject matter, don’t design the information to be consumed sequentially or hierarchically like a book.

Successful Every Page is Page One topics

• Define a limited purpose: Do one thing per topic, do it well and completely.
• Stay on one level: Be broad or be specific in a topic, but pick one and stick to it.
• Establish context: Orient readers so they know where they are.
• Conform to type: Orient readers so they know what type of topic they see, help the writer be consistent and complete.
• Assume the reader is qualified: To help readers get qualified offer links in a topic, not details.
• Link richly: Encourage the reader to explore, anchor the topic in its context.
• Provide the big picture: Create explicit high-level picture, don’t bury the big picture in the htopic sequence or hierarchy.