Zen and the art of Help files

I've finally received my copy of Garr Reynolds' excellent book, "Presentation Zen". This book is about creating better, clearer presentations in a Zen-like frame of mind. If you have seen any of my presentations, then you'll know I prefer his photo-image style to the bullet point style that is more commonly used.

I would argue that "Presentation Zen" contains ideas that are also relevant to technical communication.



So how can the approach espoused by Garr Reynolds be applied to the online Help and the user manuals that technical authors create?

He proposes presenters connect with the audience to inform in a meaningful, unique moment in time. His philosophy includes these beliefs:

- Prepare with three words in mind: simplicity, clarity and brevity.
- Simplicity leads to clarity and can be obtained by reducing to the nonessential.
- Target both the readers' creative and logical sides of their brain.
- Start with the beginner's mind.
- Ask the right questions.
- See the big picture.
- Design and layout are important.
- People remember visuals better than lists.



I believe most online Help (that has been developed by a professional technical author) has most of those boxes ticked. However, I think there are some areas of Garr's ethos that are often missing from user documentation:

1. The "art of being completely present" when delivering the content. The last thing on a user's mind when they call up Help or read a user manual is a Zen-like state of mind! The way in which Help is normally delivered to the user is frankly weak - requiring them to press F1 and admit failure.

2. Targeting the reader's creative side of their brain. The technical author's content is nearly always logical. It's rare, too rare perhaps, to have content that encourages play or experimentation. Manuals rarely reveal any passion in the writer.

3. Seeing "the big picture". I think technical authors do see the big picture, but sometimes miss out on explaining the big picture. Perhaps there's a pressure to dive into the nitty gritty of describing tasks? There's clearly a need from users to understand the big picture. I know someonewho makes a tidy living "explaining anything in less than ten minutes". He does this on paper, within the confines of an A3 poster.

I recommend technical authors take a look at this book and consider whether they could apply these ideas to their work.