Improving the effectiveness of information

In an earlier post, I compared my work as a technical writer with Island hopping: going from one island to another. The truth is that to perform our job well we need information from different sources within an organization. And on the other hand people from different parts of the organization have a need for our skills when it comes to writing and presenting information. In a way we therefor function as information integrator within the organization: gathering information from different platforms and sources and creating output for different depatments (internal customers) and in different formats. As an example: When I created the documentation for my current customer, I gathered information about the product from different deparments and developed the on-line help. As a result, the Sales department became aware of my presence, noticed the quality of the information and asked me to create the Sales information. Currently I am working on a structure for the product specifications. In

In March 2008 my new article "The Flexible Intranet" will be published in Intercom, the monthly magazine of the Society for Technical Communication. In this article I will examine the typical problems found in a corporate intranet site and demonstrate how knowledge-driven design can improve the effectiveness of intranet sites. In the article I use the example of a helpdesk that delivers support for mobile phones. With this example I will demonstrate how an effective intranet site guides the helpdesk employee toward the information and presents the answers to the questions they are confronted with. Saul Carliner, an internationally known expert on technical communication, contributed to this article. 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

You probably recognize this situation: You have to write a manual, product leaflet or text for a website and you need some information about this specific topic. The information about the topic is available within the organization, but you have to gather it from different people from several departments. And they don't like you messing with their content. They want to keep control over it. Sometimes our job as technical writer is like moving from one island to the other, building bridges and demolishing borders. If you - for instance - need to describe a product, you first travel to the island of the product developers to gather the product specifications. Next you can go to the marketing department to get some of their sales statements about the product and you might want to hop to the Service department to get the ins and outs of their servicing approach. Does this sound familiar to you? I have found this situation in all kinds of organizations. In some cases these organizations

In the previous entry, I demonstrated three types of knowledge models. These models can help us structure the information we acquire from functional specifications, subject matter experts, the marketing department and - in some cases - our own observations. When combined they offer us different paths to our information. We have looked at: Thematical models Taxonomies / concept models Composition models A fourth model is called the Attribute model . An attribute model shows attributes and values: colors, specific characteristics, etc. An example is shown below: With the attribute model we can describe all possible characteristics of a product range and link them to the actual products. This makes it possible to make an overview of all variations within a productrange. The models can help us choose between products. Example: You call the service desk of the manufacturer of your TFT screen Service desk employee: "Do you know the exact product type?" You: "I am not sure, I c

Last time, we have discussed what the benefits of knowledge modelling are. Now it is time, to take a first look at knowledge modelling, starting with a simple hierarchical model: As technical writers we are used to work with these kind of content structures, as illustrated above. This is the type of structure we not only use in manuals, but also in most on-line help systems and even websites. In this example we see two levels of information. When we would put this content structure in a graphical model it would look like this: All content elements - we call them 'concepts' in a knowledge model - are related to the next level with a relation of the type 'Subtheme of'. This type of knowledge model is very suitable for navigating and is supported by a large group of documentation, Help and website tools. Another very common knowledge model is the taxonomy. This type of knowledge model shows classes of concepts and their sub-types. All relationships in the model are of the