My tcworld11 presentation “Getting ahead as a lone writer”

You can download the PDF slides to my presentation “Getting ahead as a lone writer” at tekom/tcworld in Wiesbaden on 19 October 2011:

My tekom presentation "Getting ahead as a lone writer". Click to download the PDF.

My tcworld presentation "Getting ahead as a lone writer". Click to download the PDF.

For alternative formats and versions, see

The presentation itself went very well, I think: It felt a bit strange at first to be presenting in English to what seemed to be largely a German audience. But the questions and answers session at the end showed that for many the language barrier was not a problem.

I want to thank the attentive and helpful venue staff and sound technician for their professional, attentive help! They made me feel welcome and in good hands.

Auditing Documentation and Processes at tcworld11

Auditing your documentation, and your processes, can help you to gauge estimates and issues as you prepare for localization or content migration. That’s what I learned in Kit Brown-Hoekstra’s useful 2-hour workshop at tcworld (tekom’s international half).

You can easily do the audit yourself: Take a little time, step back from your documentation, and identify weaknesses and areas for improvement. Acting on your audit results, you can

  • Improve customer satisfaction
  • Decrease localization costs
  • Establish a baseline and a direction to develop your documentation
  • Calculate costs and benefits of changes

If you don’t have an express mandate for the audit, it can be worth it to do sort of a “draft audit”. It may come out a little patchy in places, but I think it can give you a first idea of where you stand. With the initial results and measures you can more easily get the time to do an in-depth audit. (But don’t be surprised if colleagues or managers hold you to the improvements you’ve uncovered… :-))

What to audit

The organization level

Perform a strategic SWOT analysis of Strengths, Weaknesses, Opportunities and Threats of your role in your organization. Internal strengths and external opportunities (mainly) will give you useful arguments to get buy-in from management for changes and further developments you plan. Internal weaknesses and external threats (mainly) help you to assess and manage risk as you proceed.

  • Strengths, for example, may include technical expertise and an understanding of user needs and tasks.
  • Weaknesses, for example, are poor self-marketing or resistance to change.
  • Opportunities, for example, can include agile development (which gives writers a better position in the process) and social media (if you adapt to them and moderate augmenting user-generated content).
  • Threats, for example, might be smaller documentation budgets or social media (if you do not adapt or cannot keep up with user-generated ontent).

Note how threats can be turned into opportunities, if you tackle them wisely! Or vise versa…

The process level

Assess your documentation process through all stages:

Requirements > Design > Writing > Review > Edit > Localization > Publication > Feedback > Modification > Deletion

Answer the following questions:

  • Are all stages well-defined?
  • Is it clear when and how you get from one stage to the next?
  • Do all participants in a stage know what to expect and what to deliver?
  • Can you measure the success of your process?

For the sake of an efficient process, imagine each hand-over between participants or stages as an interface and try to define what’s handed over when and how as well as possible.

The product level

Identify qualities and issues of the product you document to distinguish them from those in your documentation. Weaknesses in documentation often mirror weaknesses or issues in the product, e.g., a poorly designed user interface or a workaround that’s required to complete the user workflow.

You need to know about these issues separately, because they hurt your documentation, but you usually cannot fix them yourself. You can only supply band aid.

The documentation level

Assess the structural quality of your documentation (not the quality of a manual or each topic). Answer these questions:

  • Do you have a suitable information model? This is an architecure that defines the structure of your documentation on the level of deliverables (such as a manual or online help) and on module level (such as a topic or a section).
  • To what extent does your documentation comply with that information model?
  • Do you write documentation so the topics or sections are reusable?
  • Do you reuse topics or sections to the extent that is possible?
  • Do you write documentation so it is ready and easy to localize?
    • Do you use standardized sentences for warnings and recurring steps to minimize localization efforts?
    • Do you leave sufficient white space to accommodate for “longer” languages? For example, German and Russian require up to 30% more characters to say the same as English.

Also assess the content quality of your documentation (now look at some manuals and topics):

  • Is it appropriate for your audience and their tasks?
  • Is it correct, concise, comprehensible?
  • Remember to audit localized documentation, too.

It’s usually enough to audit 10-20% of them to spot 80-90% of the issues.

Audit for efficiency

  • Be objective. …as objective as you can, if you’re auditing your own documentation.
  • Collect issues. You can use a simple spreadsheet to collect your findings: Enter the issue, its impact, its current cost, and the cost to fix it.
  • Prioritize improvements. Ensure that a lower future cost makes the improvement worth doing, after you’ve added up the current cost and the cost to implement the improvement. Start with changes that cost the least and will save you the most.

Bonus tool

To really dive into quality assessment of your documentation, you can totally combine Kit’s audit process with Alice Jane Emanuel’s “Tech Author Slide Rule” which focuses on content quality. Use both and you have a good handle on your documentation – and more improvement opportunities than you can shake a stick at!

Your turn

Do you find this helpful to audit your documentation? Do you know a better way? Or do you think it’s not worth it? Feel free to leave a comment.

Join me for “Getting ahead as a lone writer” at tekom

If you’re attending the tekom conference in Wiesbaden, consider joining me for my updated presentation “Getting ahead as a lone writer” on October 19 at 8:45 a.m. in room 12C as part of tekom’s international, English-speaking tcworld conference.

tcworld conference at Wiesbaden, Germany, in October 2011

My presentation will be an updated version of the session I did at TCUK 10. I will talk about how to overcome neglect and raise your profile by running your job (more) like a business with best practices. Here’s the abstract:

Lone writers are often the only person in the company who creates and maintains documentation. They often operate without a dedicated budget or specific managerial guidance. In this presentation, Kai Weber will draw on his experience to show lone writers how to make the most of this “benign neglect”:

  • How you can still develop your skills – and your career
  • How you can raise your profile with management and colleagues
  • How you can contribute to a corporate communication strategy
  • How you can help your company to turn documentation from a cost center into an asset

Twitter meetup afterwards

Join us on Wednesday at 9:35 am on the upper floor in the foyer in front of rooms 12C and D for a #techcomm meetup after the session! @rimo1012 and I, @techwriterkai, are presenting at the same time in adjacent rooms, so if you know us from twitter, stop by and say hi!

I’ll be blogging from the conference, so watch this space…

Pattern recognition for tech comm at #TCUK11

Our presentation “Pattern recognition for technical communicators” by Chris Atherton and myself at TCUK11 was well-received and brought “Ah-ha moments a-go-go” according to one tweet. Read how it went or download the slides in PDF by clicking on the title image.

Link to PDF slides: Pattern recognition for tech comm

How the session came about

The session (see the abstract) got its start when I met Chris at last year’s TCUK where she spoke about “Everything you always wanted to know about psychology (and how it relates to technical communication) … but were afraid to ask”. She didn’t really talk about pattern recognition, and I didn’t really know what it was, but I had a notion this might be good for another presentation. I contacted Chris, she thought it was a great idea, and so over the year, we came up with this baby.

"Only Chris Atherton can have a picture of a dog's bum in her #TCUK11 presentation and make it relevant." - @robocolumn

And we brought the baby to TCUK11. 24 hours before our talk, Chris and I attended Karen Mardahl‘s and CJ Walker‘s fireside chat-like session “Content strategy year 1: a tale from the trenches“.  Their dialogue format really appealed to us, we decided to replace some of the scripted moments with more informal dialogue – and the baby had two godmothers.

Then we attended Andrew Lightheart‘s “How to be a riveting speaker” (more on that in my previous post) after which we couldn’t very well present something with reams of text-ridden slides. So we threw out most of the text slides – and the baby had a godfather.

By now, it was still the same content, but quite a different presentation. After all the tweaking, we didn’t have a measurement whether it filled the allotted 40 minutes or was longer…

How it went, a view from the lectern

Chris and I met in the auditorium, set up, added some last minute changes. Checking the watch: 2 minutes to go. Looking up: We had filled the place, a good 100 people were keen to recognise a pattern or two…

Karen introduced us, and off we went. I had decided to be extranervous because the session was being filmed and preserved (is my collar right?) – but I completely forgot!

"By creating and following patterns you help your reader understand..." - @dfarb

Through all the changes and tweaks, we had come to know the material so intimately that it seemed to flow quite smoothly. The omitted text slides were actually a relief, because we could focus on the story and the examples, without having to vindicate each and every sentence. We had picked out stories and examples which were easier to tell than some of the concepts we had thrown out.

Karen’s warning of 15 minutes left came around the time I had roughly estimated. We had to leave out the communal brainstorm of more examples and applications, but everything else fit in.

The feedback after the session was very kind and encouraging. I’m glad and proud if we presented something meaningful to our peers.

The slides

The slides are not the actual presentation we showed, but a variation with more text, so they work a little better as a self-contained slide show without the soundtrack.  Click on the image above to display or download. The video by the TCUK crew is forthcoming.

Chris and I sincerely thank the TCUK organisers for inviting us, our peer presenters for valuable inspiration, all attendees for helpful feedback, intentional or not, before and after the session!

Feel free to leave a comment, whether you were there or are merely curious what it’s all about!

Join us for pattern recognition at TCUK

Dr. Chris Atherton and I will be premiering our exciting interdisciplinary presentation on “Pattern recognition for technical communicators” at the TCUK conference near Oxford next week. You can find the session abstract on the conference web site or review my previous post.

Logo of the Technical Communication UK conference

Join us for a fun whirlwind tour through human perception and find out how you can apply pattern recognition:

  • Make sense of unknown subject matter
  • Overcome tech writer’s block and start writing
  • Chunk topics and find reuse opportunities
  • Help your readers to
    • Orient themselves in your documentation
    • Grasp individual topics quickly
    • Get the most out of navigation aids

Extra bonus! You’ll learn about apophenia, a concept that gives you something to talk about at cocktail parties and ranks high on most international geek scales… 😉

No previous experience required! If you’re at the conference and can get yourself into the right room on Thursday, September 22, at 10 o’clock, you have all the tools on-board that you need!

Next week I’ll be blogging from the conference, so watch this space…

All aboard! Onwards to structured authoring!

Our team of technical writers is embarking on a journey towards structured authoring. With 10 writers, we’ll move from an unstructured Word to PDF/CHM environment to a structured Flare to WebHelp/PDF environment. Or I should say “semi-structured”: We do have an information model based on DITA, but we won’t actually be able to enforce it with Flare (which we knew before we chose the tool).

It’ll be an interesting cruise, to be sure! Four writers already apply topic-based authoring rather than the previous free-form documentation guided mainly by common sense. The others have had training, but no real opportunity to write topics continuously. We have drafted tighter new processes to draft, write, review and edit topics to replace the previous loose processes of writing and reviewing, but they are not in place yet.

And then there’s the new tool, of course. Only one of us has worked with Flare before. Many of us are excited about getting Flare. Some really like it – what we’ve seen in several demos so far. Others just really loathe the current writing environment.

“Regarding the pain of others”

So as we’re about embark, I’ve been looking out for others who’ve taken the trip before. Scriptorium’s State of Structure webcast has been very helpful: Its results of a survey among 200 tech communicators helps to position us in relation to others who are currently implementing structured authoring or considering it. It also collects some mistakes respondents have gone through. I’ll just be quoting a few select points, but the whole webcast by Sarah O’Keefe is totally worth checking out, so thanks to Scriptorium for making this webcast available!

Reasons

The top reasons why survey respondents (consider to) move to structured authoring made us nod emphatically: Reuse, consistency and cost savings are also at the top of our wish list of achievements. Looking ahead, it’s promising that the majority of respondents achieve these goals.

We’ll also take other goals that respondents achieved, whether it’s to automate processes or to reduce content (oh, yes, please, we’re not even exactly sure how much redundant, almost identical content we have). So far we’re confident, we’re not only doing the right thing, but doing it for the right reasons, too!

Efforts

Savings have their own price, of course. Sarah’s survey confirms several cost points we’ve already identified in the project.

  • Converting legacy content is a biggie for us, simply because we currently have a lot of stuff.
  • Redefining output layout will take time, but will be worth it given what Flare is capable of doing with CSS in both web and print outputs.
  • Integrating a new system with its writing and publishing processes into our product and workflow systems will also take some time.

Mistakes

Mistakes have been made by others before us, and we’ll have plenty of chances to make our very own mistakes. If we’re lucky, we can avoid repeating the mistakes of others:

  • Planning and project management cause problems, maybe because most companies lack the experience of major documentation overhaul projects. Sarah specifically mentioned the lack of understanding of the project scope and of the need for testing. So we’ll look through our project plan again and ensure that the estimates are plausible.
  • Converting legacy contents can also get you into trouble, especially when you convert something that’s less than structured. It doesn’t help if you reserve too little time to do it or get inexperienced people to do, whether it’s off-shore labor or student helpers. That’s sound advice: GIGO (“garbage in, garbage out”) can certainly endanger the expected benefits. A new tool can help us be more efficient, but we still have to learn and apply structured writing in topics. So this confirms one of my two tech comm dogmas: Don’t get a new tool to fix your processes!

Setting out

What do you think? Is our crew well-equipped, given a tried and proven method, well-defined processes, a new tool and the words of warnings above? If you have additional advice, please leave a message.

Pattern recognition for tech comm

Chris Atherton and I will present a session on pattern recognition for technical communicators at this year’s Technical Communication UK conference near Oxford. The conference takes place from September 20 through 22.

Logo of the Technical Communication UK conference

Adding up Chris’s interest in evidence-based information design and her background in researching and teaching human cognition with my experience in designing and modelling technical communications, we’re sure it’ll be an interesting, thought-provoking session. Here’s the abstract:

Pattern recognition is one of the essential mental strategies for acquiring and disseminating knowledge, though most of us are not aware of it. This session presents some ideas and findings about human pattern recognition. It aims to help technical communicators think about how they can employ pattern recognition processes to develop their own documentation and user assistance.

The presentation combines the wit and wisdom of a cognitive psychologist and a technical writer who draw on examples and evidence in their respective fields to show:

  • What pattern recognition is and how it works
  • Which mental strategies we employ without knowing it
  • How technical communicators can employ those strategies
  • Making sense of new subject matter
  • Starting to build new documentation
  • Designing and structuring documentation
  • Supporting users efficiently

New conference trend: Collaborative sessions

It’s interesting to see collaborations appear at the conference that create a mushroom-like network of sessions:

  • Chris and I talk about pattern recognition.
  • Chris leads a session with Mike Smith and Karen Mardahl on statistics (without maths).
  • Karen joins forces with CJ Walker to tell about content strategy from the trenches.

Do you think joint sessions are a good idea or not? Have you had bad experiences that we should avoid? Feel free to leave a comment.