Jennifer A. Fell, IBM Corporation
Previous issues of this newsletter featured articles about how to help people who are making the transition from linear writing to topic-based writing. Moving from Narrative to Topic-based Writing, Helping the Strugglers: Thoughts About Making the Leap from Linear Books to Linked Topic, and Making the Leap to Topic-based Writingall contained excellent insights and suggestions. As I read each, I found myself cheering, “Yes!” With so many good ideas already put forward, I wondered what unique perspective I could offer.
Helping the Strugglers offered my lead-in: “Many writers don’t understand the architectural structure of the information they write.” This article offers my perspective as an information architect.
Think more, write less
Andrea Ames, Information Experience Strategist and Architect at IBM and former STC President, gives a presentation called, “Think more, write less.” In that presentation, she focuses on various ways in which stopping to think can help us make better choices, which ultimately can lead to both higher quality information and more free weekends.
Stopping to think is difficult. We are conditioned to believe that if our fingers aren’t dancing across the keyboard, then we aren’t writing.
To move to topic-based information, we must rediscover the truth that what we do is larger: We provide information solutions to user problems. We must rediscover that solving problems requires time to think.
Taking another tip from Helping the Strugglers, I consider us to be “information developers” instead of “technical writers.” For me, “information development” expands more readily to include the work that we do away from the keyboard.
Thinking about topics
It’s no wonder that the transition to topic-based writing has inspired so much discussion. Linear books have comforted us since before we could read them. We’ve been writing in a linear style since our first school assignment to pencil a page about our summer vacation. It’s natural. In fact, it’s so natural that we don’t think about it any more.
The structured nature of topic-based information has two sides:
- It enforces certain small-scale structures (tasks, concepts, and reference), so that we can spend more time on the content.
- It forces us to look at large-scale structures: webs of information that may cross subjects, features, and products.
I believe that a lot of information doesn’t have an intentional architectural structure.
To transition to topic-based information, we must rediscover the value and skill of designing those large-scale structures— not just the title, delivery mechanism, and schedule, but also the model for the information that we will deliver. Understanding the integral nature of information is essential.
Getting started with topic modeling
So how do we return to the practice of planning our information? How do we reinvent the art of outlining as a new art of information modeling? I can feel it already. The words “plan” and “model” feel heavy. It doesn’t have to be that way. Topic modeling can be simple.
First, I recommend updating your process to include a formal modeling step and a review of the model. Just insert these as review #0, before the first technical review.
Next, represent the model in a non-linear way. This is very important. As others mentioned in the original discussion behind this series of articles, it’s very hard to change your point-of-view away from linear books if you’re writing an outline in Microsoft Word.
Some people on my team use graphical tools such as Microsoft Visio, Task Modeler from IBM, or various Web-management tools. A cheap and effective alternative is index cards.
Select one color index card for each topic type. For example, you can use white for tasks, yellow for concepts, and light green for reference topics.
Begin with the tasks. On one index card, write the title and description of a single task topic. If you can’t fit the title and description on one side of the card, you might have more than one topic. Then create index cards for supporting reference and concept topics.
Lay out your cards in front of you. Look for relationships. Physically move the cards around, so that you begin to feel the motion through your topics. If you tape the index cards to a large white board, you can draw lines between topics to show the related links that will allow the reader to move through your information. Follow the use cases for the information. What question does the user have? What path might the user take to find the answer?
Throughout the lifecycle of your project, reinforce the interconnected nature of your topic model.
- If the information will be delivered in an online format, then provide the information online for reviews and edits.
- If the information is shared between two information products, then provide both for review at the same time, so that reviewers can see the dual use and understand the flexibility of the information.
- If you have use cases that guided your choices, make those available to reviewers.
- Above all, don’t read your information in a way that users won’t. Don’t impose a linear order just for review purposes or your own convenience. Always work through the topic model.
After my first several yoga classes, I complained to a colleague that I still couldn’t touch my toes. I was frustrated because I was stretching myself in new ways, and my body didn’t want to move in those new ways. My colleague simply responded: “That’s why they call it a yoga practice.”
Many thanks to the numerous colleagues who have contributed to my thinking on this subject. Special thanks to Andrea Ames (IBM) and Elizabeth Wilde (IBM) for their thoughtful contributions to this article.