Rather than predict or comment on trends in our industry (which I already did here), I’d rather describe the actual directions I’m going in 2010.

Embrace a Collaborative Authoring Platform

I’m embracing collaborative authoring this year, with plans to entitle key authors in various departments for some projects and completely open up authoring for others. More and more projects I write documentation for require input from multiple subject matter experts spread out across the organization. The days when a single writer could accurately provide help for people in a department he or she isn’t even in seem to be over. I’m planning to use Mediawiki as the collaborative platform (because it’s on the menu of approved technologies in my organization). A collaborative authoring platform will also simplify interactions and exchanges when I have teammates working on the same project.

Let Customers Own the Documentation after the First Release

This year I’ve noticed another trend: customers want to own the documentation after I write the first release. When this first happened (and someone requested my source files), I was offended. But the more I thought about it, the more it made sense. As I write documentation for more and more projects and departments, I’m building a larger base of documentation to maintain. I can’t be effective when I’m maintaining fifteen different projects at once while working on three new ones. I prefer to have a dedicated handful of people with authoring capabilities to help with the maintenance. That just isn’t feasible with a proprietary and costly help authoring tool (in my situation), so this direction builds on my previous point about embracing a collaborative authoring platform.

Make Screencasts a Core Deliverable

The best feedback I receive about my help deliverables is with the screencasts I create. I plan to continue screencasting, perhaps dipping more into dynamic visuals with Adobe After Effects or Flash. I want to further hone my audio and visual skills in this medium.

Continue Team Design Reviews

In our agile environment, our team is spread out across various portfolios and departments. We lose out on a lot of interaction and camaraderie, but we recently started doing some biweekly design reviews in which we get together and critique each other’s help. The design reviews have been engaging and worthwhile – I hope we continue them regularly into 2010.

Participate More in Design

One of the situations I dislike is 9^th inning documentation. At this stage, the interface is frozen and I’ve been such a stranger to the project that the PM isn’t looking at me for any input other than to document “what is.” Instead, I’d like to make it my standard to get involved around the 4^th or 5^th inning so that I can contribute more to the interface and task flow. One reason I haven’t been able to jump in this early is because I’m so busy maintaining documentation for numerous projects that are in their second or third release cycles. Getting involved early with the design and earning a seat at the design table will require me to prove my worth, certainly, since we already have a fair number of interaction designers, business analysts, and project managers who perform this role.

More Story-Driven Blog Posts

On my blog, I plan to write more story-driven posts. I get more response and fulfillment from blog posts with well-crafted narratives than I do anything else. My daughter recently listened to about 12 hours of Storynory podcasts straight because of the mesmerizing power of story. I want to develop my skill at seeing story and building narratives that engage audiences.

More WordPress Consulting

I was a bit wishy-washy this year as to whether I would continue WordPress consulting or not, given the time it consumes. But I love working with websites, and the extra money helps, so I plan to do even more WordPress consulting in 2010. If I get too much work, I’ll outsource some of the development (I already outsourced much of it last year). This year I’m specializing in Woothemes more, since it seems to simplify the client’s decision-making process with themes.

More Basketball

For many years I’ve felt guilty about playing basketball. Compared to other forms of exercise, basketball takes three times as long, causes me to stay up too late, and seems to be an inefficient way to get exercise. But I’ve finally decided to succumb to it, because I love playing it and because life in IT is so sedentary. This goal feeds into my overall New Year’s resolutions to do more of what I love.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree

In our design review sessions, a couple of members from our eight-person team share what they’re working on and ask questions about challenges they’re facing. We provide feedback and critique their project.

These design review sessions are one of the coolest things we’ve done as a team. We don’t have a strict team style guide or set of standard deliverables. (We do follow the Microsoft Style Guide and, at times, a thin organizational style guide.) But as far as branding the help material, there can be a lot of variation among the online help files, quick reference guides, landing pages, context-sensitive help, interface text, e-learning, video tutorials, or other help materials we create.

If you’ve ever participated in a creative writing group, the design review works similarly. Team members use common sense and experience to guide their questions and reviews. Somewhat in contrast to a creative writing group, though, you don’t have to bring a finished piece to share.

For example, the other week I was coordinating who would share materials for our design review, and one of our team members told me he wasn’t ready to show it. What? I said. The design review is not about showing finished material. It’s better, in fact, to show what you’re currently working on, while it’s still early in the process, before you’ve cemented everything. Oh, he said. In that case, yes.

Parallels with Blogging

I find that the same mindset works with blogging as well. Often times we think we can’t publish a post until we’ve finished a cool thought, or until we’ve finalized a solution to something. But this past week, I added a couple of posts in which I wasn’t quite sure what I thought. In my Theme Parks and External and Internal Input post, I was only part way into a thought. Commenters added to the discussion and helped me better see insights and perspectives on the issue.

I also wrote a post on working with wikis, A Few Surprises in Using a Wiki for Documentation. I’m not an expert on wikis, especially Mediawiki, and there are many things about wiki authoring that I need to learn. But this didn’t stop me from posting about it. Instead, I shared some of the challenges and issues I was facing. And some of the commenters added information that proved incredibly helpful. For example, see this informative comment by Amalia.

Had I waited until I finished in putting together an entire strategy and methodology for authoring on Mediawiki before posting about it, I would have missed out on the guidance and direction early on. It’s from the helpful information early in the process, particularly with challenges I’m facing, that comments on a blog become the most useful. A blog is, remember, a journal, so it contains thoughts and ideas and experiments in progress — not always finished solutions, completed ideas, or tried-and-true methodologies.

What’s true in design review is just as true in blogging. Sharing the current challenges you’re facing will make your experience in the blogosphere or design review process more helpful and rewarding.

Blog Sponsors

• Webworks ePublisher
• Scriptorium
• Help Generator help authoring software
• Southern Polytechnic: Information Design and Communication
• Simplified English
• MindTouch
• Madcap Software
• Dr.Explain
• Adobe Technical Communication Suite
• Congree