Improving the effectiveness of information

In my last blog I explained how we can distinguish three phases in the development of documentation. The first phase was a very product centric one, while in the second phase we see a more process driven approach. Re-use gets more and more important as is collaboration with other writers. But what about the users? How do they benefit from this move to single sourcing? Sure, creating and translating documentation becomes cheaper and easier to manage, but having documentation in your own language is for most people normal and not seen as a usability feature. And then there is the issue with information overload. Maybe we should ask our users what information they need, instead of just providing them with everything we want them to know. To really help our users, we should move on from our process centric approach to a more customer-centric one. A customer-centric approach Documentation 3.0 is all about offering the right documentation at the right time. It is customer-centric, which mea

The trends in documentation of the past 20 years are under heavy influence of the development of internet technology. Like with the web – where we distinguish between Web 1.0, Web 2.0 and 3.0 - we can see three phases in documentation. Product centric documentation The first phase is the phase in which we technical communicators worked with tools like Pagemaker, QuarkXPress or Framemaker. In this phase we are very much focussed on a single product and there is a constant struggle between task and function based documentation. If our customer needs a manual for a product, we write one – as an isolated process. Our focus is on the product and generic audience groups and not on things like re-use or efficient use of available information. Compare it to the story of the little prince, where the author makes three drawings of a sheep – each sheep could be a version of a product; with us technical communicators writing a separate manual for every version. Sure we see the similarities and do

The trends in documentation of the past 20 years are under heavy influence of the development of internet technology. Like with the web – where we distinguish between Web 1.0, Web 2.0 and 3.0 - we can see three phases in documentation. I will call them Documentation 1.0, Documentation 2.0 and 3.0. Where Documentation 1.0 is - like Web 1.0 - very much centered on individual products and information, brings Documentation 2.0 a process-driven approach with a focus on re-use. The customer-driven approach of Documentation 3.0 is a logical next step. But why should we change the way we create documentation? First of all the world is changing and so are our users! Things that seem obvious to one individual, don't make any sense to others. Take for instance this photo (shown to the left). It shows a young model holding a camera. In her perception, you hold a compact camera this way. Truth is that she is holding a 1970's Olympus Pen EE-3, a camera with a viewfinder instead of a LCD scr

Well, it has been a busy 6 months since I wrote my last blog. In the meantime I have visited two conferences and worked out some interesting stuff about the topic of using semantic technologies in documentation. I will post my ideas in the coming weeks. What did I work on? I was hired by Be Informed to create an overall knowledge infrastructure - in models. You can see a part of it on their website: http://www.beinformed.nl/ . Untill the end of the year I will be working on this. In January 2009 I will start as a Senior Information Advisor at USG People The Netherlands. After 12 years of working as a consultant in the ICT world, this is a welcome change. The core business of USG People is employment services and I will be working in their internal ICT department and advising the management of the operating companies on their ICT plans and projects. USG People is a specialized provider of employment services in Europe, focusing on the market segments general and specialist temporary em

The March edition of the Intercom features my article about using knowledge technology for more effective intranet sites as the cover article. In this article - "The Flexible Intranet" - I examined the typical problems found in a corporate intranet site and demonstrated how knowledge-driven design can improve the effectiveness of intranet sites. In the article I used the example of a helpdesk that delivers support for mobile phones. With this example I demonstrated how an effective intranet site guides the helpdesk employee toward the information and presents the answers to the questions they are confronted with. Intercom, the magazine of the Society for Technical Communication , is published to provide examples and applications of technical communication that will promote its readers' professional development. Intercom is published for the benefit of STC members, each of whom receives a subscription to the magazine. Subscriptions are not available for non-members.

When creating the models for a Knowledge Solution for an organization, the first two steps are: Making an overall model of the information goals, audiences, types and sources within the organization and look for possible similarities Defining the rules for the models that you are about to create. Making the overall model As mentioned before, my task was to design and create a knowledge bank in which the product architects and developers could easily find and compare product requirements and relevant specifications. This little project was part of the overall project that I am working on: creating a series of knowledge banks for my customer, covering all aspects of the product life cycle. I had already finished the (initial release of the) product documentation, so it was a logical step to design this particular knowledge bank in a way that it could benefit from the models and descriptions from the product documentation. All knowledge models - the ones already created and the ones plann

A couple of weeks ago I started really enthusiastic with structuring the product requirements and product specifications of my customer's products. The goal of my work was to create a knowledge bank in which the audience can see both the product requirements and the relevant specifications next to each other. Last week I have finished the knowledge bank and presented it to the product architects. What did I learn from this project? Don't use your documentation project to restructure the whole organization First of all: it is impossible to capture the whole world in just one set of models. When you have to think of a documentation solution for a whole organization, it is tempting to restructure everything into one consistent overall structure. The truth is that in an ideal world this would be an excellent solution. In the real world you can't just change everything to get the desired result. Make a series of models for every single department or organizational unit that has

In my article "How knowledge becomes usable" - published in the Winter edition of Communicator - I explain how you can incorporate knowledge-driven design in information products. The Communicator is the quarterly journal of the Institute of Scientific and Technical Communicators (ISTC). The article is a follow-up on my presentation at the ISTC Conference 2007 in Liverpool. If you are a member or a subscriber of Communicator, you automatically receive this issue. Otherwise, if there is something of interest to you, contact the ISTC Office to purchase a copy. The ISTC is the largest UK-based society for professional communicators. If you are a technical communicator and working in the UK - or Europe in general - I can strongly recommend membership of the ISTC. Look for more information on their website: www.istc.org.uk .

I mentioned in my last article of 2007, that as a technical writer you can expect to be asked for several kinds of documentation within your organization. Recently I started to structure the product requirements and product specifications of my customer's products. The intended audience consists of the product manager and product architects on the one hand and the developers on the other hand. The goal of my work is to create a knowledge bank in which the audience can see both the product requirements and the relevant specifications next to each other. At this moment there are two types of documents: A functional requirements document: This is a 27 pages long Word document, including some illustrations. It has a thematical structure. This document is written and edited by two product architects. Component design documents: These are detailed functional and technical descriptions of parts of the product, first written by developers and then edited by two functional designers. The co