Using Analogies to Promote Understanding


December 2007

Using Analogies to Promote Understanding

CIDMIconNewsletter JoAnn Hackos, CIDM Director

When John Carroll’s team (doing their original minimalism research) developed the early “help” topics for IBM’s DisplayWriter, they used an analogy to assist the new users learning the word-processing system. Most of us with 20 to 30 years of experience recognize the analogy immediately. Carroll related word processing to using a typewriter. Users learned that the blank screen was like a blank piece of paper, without needing margins and tabs.

As writers, we use analogies to help readers relate something they already know to something new. I frequently explain that writing standalone topics is much like writing help topics that are viewed independently of one another. Writers with help experience seem more likely to adjust to the requirements of writing standalone topics. Their prior knowledge and experience helps them adjust to the new task.

Analogies need not be limited to explaining technical content in documentation. They also prove useful in helping senior management understand why we should be managing our content more effectively. Analogies help us build a business case for content management that is compelling to managers with backgrounds in engineering, product life cycle management, finance, and inventory control.

Analogies are equally useful when applied to the new writing processes that we hope to adopt in our organizations, especially when we ask writers to move from authoring books to authoring topics. Analogies enable us to build useful points of comparison from the current to the future state. They also help us, as managers, to understand more thoroughly the context in which we urge new behaviors.

In this column, I explore how to use analogies to benefit our organizations as well as our readers.

In an article referenced in Working Knowledge (November 2007), the newsletter of the Harvard Business School, Giovanni Gavetti and Massimo Warglien report on their study of analogy in strategic decision-making. They note that recognition lies at the heart of analogy. “Recognition refers to a class of cognitive processes through which a problem is interpreted associatively in terms of something that has been experienced in the past.”

Not only can recognition benefit each of us individually as we try to learn new ideas or new ways of working, they can benefit group processes and decision-making. Through analogy we begin with shared experiences on which the group builds. The shared experiences lead to extensions of the analogy to better analyze the required decisions. These extensions then lead the group to a more insightful understanding of the future state. Or, they can, under an intense pressure to conform, deteriorate into groupthink—leading everyone to agree to the wrong strategy.

Using analogy in making a business case for content management

In making the business case for content management and topic-based authoring for senior management, I recommend that you use an analogy to inventory control. When Xerox Palo Alto Research Center (PARC) first introduced component-level content management, they referenced an analogy to inventory control. They argued that each component of content, including individual paragraphs, list items, and notes, could be handled as a part in inventory. Each component should have a unique identifier that would facilitate its reuse in any context, just as each part in inventory might be used in any number of products. The key to efficiency in this analogy required storing each part only once and using it to build assemblies. The fewer parts in inventory, the more efficient the manufacturing process and the lower the costs. For example, one manufacturer learned that manufacturing costs could be significantly reduced if each of the development teams incorporated the same power supply into their designs.

I use the inventory analogy to describe creating topics or subtopic components such as warnings just once, storing them in a well-labeled and –organized repository, and using them in multiple assemblies. I reiterate that the goal is not simply “reuse” but having the smallest number of inventory items to manage. The more assemblies (documents or websites or help systems) that we can build from the smallest number of components, the more efficient we become.

This analogy to inventory control has been quite persuasive for an audience of engineers and business managers. They identify with the base analogy, add their own experience to build a deeper comparison, and recognize in our world of technical publishing their own world of manufacturing efficiency.

In their white paper, “Professionally Manage Your Content: Going Beyond Traditional Content Management,” writers at Inmedius build a useful analogy between authoring in topics and creating a motion picture. Films are not shot from beginning to end; they are built on the “cutting room floor.” Individual scenes, even parts of scenes, are developed during the course of production. Each snippet only appears in context when the editors start to work. Like information architects, they make the producer’s and director’s vision real by stringing the parts together after the filming is complete.

They write:

“This new paradigm is being facilitated by new technical documentation standards such as S1000D and DITA. The essential element of both of these standards is the ability to author a portion of a document, and not necessarily from beginning to end, but in any particular order. The old concept of creating a document from beginning to end, as a painter paints a canvas, has been shattered. The new paradigm of creating technical documentation uses a technique closer to the creation of a movie film. Films are created by aggregating sometimes disparate scenes (content) into a coherent order for the viewer. An S1000D

[or DITA] document is created much in the same way, by taking disparate data modules and manufacturing them into a coherent document from each of the fragments.”
Request this resource:

Only Alfred Hitchcock is famous for shooting only the amount of film that he needed in the final composition. But—he was also a celebrated cinematic genius with a vision of the whole that no one else has been able to imitate. Other directors shoot miles of film that is never used in the final production. Those of us who manage the often under-funded projects to produce documentation would be better served by the Hitchcock analogy. We need to plan our topics well in advance to avoid building mountains of rubbish on the cutting room floor. Would that software developers and product marketing managers do the same.

Unfortunately, few of us are as prescient about the final product’s design as we need to be. That means that we plan the topics, put them into thoughtful early assemblies, and remain ready to iterate our designs. When new information becomes available, we change the design to accommodate. However, if we design the assemblies based on the needs of the users, we are less likely to change the overall design in response to product changes. If we design the assemblies to mirror the functions and features of the product, the overall design is more likely to change. As we all know, we design best when we design for the actual users rather than the product developers.

Using analogy to teach topic-oriented writing

I am intrigued by an analogy that Renu Bhargava at Juniper Networks is using to explain topic-oriented writing to the staff. Renu plans to present her learning process at the 2008 Content Management Strategies conference (April 7-9, 2008, Santa Clara, CA). In her abstract, she uses an analogy to the playlist, the list of tunes you might have on your iPod or MP3 player. You break albums into individual songs, which are designed to be standalone (although the composer or singer might have a message in the set of songs in the album). Saving individual songs gives you more control over your consumption of the music than keeping them in their albums.

Renu argues that to give the user more control of our content, we “break up books into smaller pieces that can be individually consumed.” We design the modules and the assemblies together. We recognize that our users want to extract individual modules to address their own questions and needs. They may even want to reorganize them into a collection that is most useful to their work environment.

Just as we buy individual songs or break albums apart to create our personal playlists, our users do the same with the content we provide. They may still receive the individual topics assembled into books, or, they may “purchase” them separately through HTML versions on a website.

I find this analogy between topic-consumption and playlists to be an excellent example of using the power of recognition to help people participate in, learn from, and appreciate a strategic decision.

Using analogy to teach technology

I invite you to participate in a further discussion of analogy. After the December Best Practices newsletter is published, we will place this article on our new CIDM blog. If you have examples of using analogies to sell an idea to senior management, introduce a new process to your colleagues and staff, or explain a new technology to your users, I invite you to participate.

Look for the announcement of the CIDM blog soon. CIDMIconNewsletter