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.

Advertisements

When redundancy is good: Online help navigation

Redundant navigation can help users find what they’re looking for.

Redundancy in documentation is usually bad: When you have the same content (in different words) in two places, you pay twice for localization – yet you probably only remember to update one of the items. So you risk inconsistencies, extra costs and general havoc.

Not so when it comes to navigation! Redundant navigation can offer your users different paths to get to the one place where they find what they need. The reason this works is because users want to do different things at different times in your help system. (See my earlier post “Top 10 things that users want to do in a help system“.)

Tom Johnson’s recent post got me thinking about this when he asked for “Examples of Help Systems that Provide Users with Multiple Entry Points?” His approach is a bit different, however, from what I have in mind. Tom thinks about “adding metadata to help topics so you can sort them into different arrangements for different audiences”.

My idea is to offer a few additional entry pages with layers of pointers to get users to the appropriate part of the help system quickly. Only some of the options require tags on topics.

Here’s a design I once did for the rather comprehensive online help navigation of an asset management system, we’re talking several thousand topics. (Click on the image for a larger version.)

Example for redundant navigation in complex online help system

The idea is that different personalities of users come to the help with different kinds of questions:

  • Some users focus on their roles and approach the system from that angle, whether they work in front, middle or back office of a bank or asset management company.
  • Other users focus on the task they need to execute – which in an asset management system can be boiled down to five main types of tasks.
  • And some users expect to find certain forms of documentation, such as release notes, tutorials, manuals.

Depending on your choice, you would get through 1 or 2 more selection screens until you wind up at a specific help topic. And you could take different paths to get to the same topic.

For example, if you wanted to set up a fund, you would need to get to the topic “Set up a fund definition”. Of course, you wouldn’t know that. But you could get there in various ways.

For example like this:

  1. I’m working in: Back Office
  2.  > Fund accounting
  3.  > I need to set up fund accounting
  4.  > Set up a fund definition

Or like this:

  1. I want to: Set up static data
  2.  > For a fund
  3.  > Set up a fund definition

Or like this:

  1. Show me: Tutorials
  2.  > How to set up SimCorp Dimension
  3.  > Fund accounting
  4.  > Set up a fund definition

So the idea is to anticipate some of the most common questions and approaches users have to the system and to make the right entry points easy to find. This does not to offer so many paths through the forest of topics as to confuse users, but only signposts to topics we expect every user will hit (as long he is using a particular module at all.

Your turn

Could you, would you use such a help portal that offered different paths or would you bypass it in favor of the tabel of contents on the left and the search? Do you know other help systems that use such a structure? Please leave a comment.

Top 3 reasons to attend Congility 2011

Relevant topics, great speakers and a price that’s hard to beat (for at least one person) make Congility 2011 a great conference to attend.

Conferences are a great way to keep in touch with fellow tech communicators, content strategists, UX experts, e-learning pros and user assistance speecialists – as I’ve pointed out before.

Congility 2011

One conference worth going to this year is Congility 2011. Here are just a few of the talks which will be good and worthwhile. (I’m fairly certain because I’ve heard the speakers on related topics before, and am convinced they know what they’re doing.)

Other talks I’m curious to hear are:

Bad news and good news

The bad news about Congility is that I won’t be able to go – they won’t hold up the production cycle for the writer to attend a conference, and the deadline looms. 😦

The good news is I can give away

one free conference ticket (valued at 495 GBP) and
a 20% discount for everyone else

Thanks go to the newly joined conference sponsors who make this new last-minute offer possible. Here are the details:

Congility 2011, May 24-26, just outside London, England, is for content professionals looking to advance their organisation’s goals with better content strategy, management and process. It is the only European platform bringing together such a diversity of content experts and learning opportunities under one roof. Learn from ‘The Mother of Content Management’, Ann Rockley, renowned content strategist Rahel Bailie, and case studies from eBay, Nokia, AMD, IBM, AGFA and more.

As part of an arrangement with this blog, you could attend completely free, by taking advantage of this unique discount code. The first person to use the code below will be given access to the conference (but not workshops) at no cost to them besides travel and expenses. Everyone else who uses the code will be entitled to the 20% discount*:

KAWCA11BLG20SD

* If you can’t go even at 20% discount, you can cancel your registration without commitment or penalty.

How (not) to use documentation checklists

Checklists can be great aids, but they won’t guarantee that you create good and complete documentation. – That’s my experience, and I’d appreciate your input whether you agree or not.

The Valuable Content Checklist

Content strategist Ahava Leibtag published the “essential Creating Valuable Content Checklist (TM)” last month, along with a step-by-step guide:

With this checklist, you can ensure that your web content is

  • Findable – because it has a headline, title, keywords, links, etc.
  • Readable – because uses chunking, bulleted and numberes lists, etc.
  • Understandable – because addresses user personas and their proficiencies, context, etc.
  • Actionable – because it gives readers incentive to act, comment, share, etc.
  • Shareable – because it gives readers a reason and the means to share, etc.

I think Leibtag’s checklist covers a lot of essential features of good documentation, so it should also work well for technical communications. (The book Developing Quality Technical Information by Gretchen Hargis, et al., also contains great checklists for documentation.) But then I had second thoughts…

Clear and simple

The good thing about checklists is that the best ones are clear and easy to use. They remind you of things you may forget otherwise. One of the most impressive recent examples of their benefits has been in medicine: Peter Pronovost’s checklists have shown to improve the delivery of critical care. (Atul Gawande reports on them in the New Yorker of 10 Dec 2007.)

Seductively simplifying

The bad thing about checklists is that they are so clear and simple, it can be seductive to rely on them for things they cannot do. You can check off all items on your checklist, but you may still create

  • Incomplete documentation, when you’ve missed a sub-topic, keywords, links, a persona or a use case.
  • Useless or bad documentation, when you describe an unintended or even dangerous way of using the product.

In other words: You get what you measure. If checklists are your tool, you will get formally complete documentation, which may or may not be helpful to customers.

As simple as possible, but no simpler

I think the solution lies in the quote attributed to Albert Einstein: “Everything should be made as simple as possible, but no simpler.” That’s good advice for documentation in general, and for checklists in particular. This means to me:

  • Use checklists only after writing a topic to verify that it satisfies formal completeness standards.
  • Avoid checklists while writing a topic when I focus on content and quality, specifically on usefulness and applicability for users or personas.

I also appreciate that structured writing already separates layout and content, so I can use my “freed-up brain cycles” to focus on content and not go on auto-pilot and simply fill in topics with bits and pieces while ticking off check boxes.

Your turn

Do you think checklists do more good or harm in technical communications? How do you use them to make sure they improve your documentation, but don’t compromise it? Please leave a comment.

@techwriterkai popular posts, part 2

My blog is taking a spring break and is due back on May 9.

I thank you for reading and commenting. Your support and feedback is the lifeline of this blog and makes it all worthwhile!

As I’m taking a break, I invite you to check out (or revisit) a few of my all-time popular posts:

Top 3 success factors in online help systems

… in which I apply usability tips based on research to online documentation and come up with three success factors: Speed, structure, and spacing.

Top 10 reasons for tech writers and trainers to collaborate

… in which I explain why and how technical communicators can and should collaborate with trainers to offer customers a unified and cost-effective learning experience.

Ragged-right or justified alignment?

… in which I argue for the preference of ragged-right over justified alignment in print and point to several sources where research supports the argument.

Bonus insight

Buzzwords in post headings do work: Of my all-time top 10 posts, four are “Top X something” and two include the word “trend” in the heading…

Your turn

Which older blog posts do you find worth revisiting (whether it’s from my blog or any other tech comm-related blog out there)? Feel free to leave a comment!