Newsletter of the Society for Technical Communication, San Francisco Chapter April/May 2008 |
At the March 2008 meeting of the San Francisco Chapter STC, Andrea Ames discussed the concept of moving from tactical information architecture to radical, or strategic, information architecture. Andrea, who is a full-time information architect at IBM, shared her radical vision of how strategic IA results in thinking more, writing less, and providing customers the information that they need when they need it.
Do you have what it takes to be an information architect? Andrea had us look for answers to this question in our sock drawers, browser bookmarks, and response to new technology. You have the rage for order of tactical IA if you organize your socks by color, function, or some other organizing principle, or if your browser bookmarks are neatly divided into subfolders. You have the strategic mindset if your response to a new technology is to think of the problems of tomorrow resulting from implementing this new idea today.
What is radical, or strategic, IA? At Andrea’s current position in IBM, she owns portfolios of 30 products and manages their information experience. The IA specialist is a valued, full-time respected technical leader. This role requires the following:
Tactical IA is the level at which most technical communicators operate – when they give IA conscious thought. It involves writing an outline for a book or navigation for a help system. It can also involve having several writers coordinate the content that they produce to reduce repetitive writing. IA is a part-time job, at best. Tactical IA is a good starting point for strategic IA.
Strategic, or radical, IA is a better way. Andrea defines radical IA as the conscious, strategic application of tactical IA to create a model that drives information delivery for the company. Building this model requires an understanding of customers and their task domains, as well as an understanding of the overall product strategy. Strategic IA is a radical idea because only a very few companies, such as IBM, have a culture that facilitates implementing strategic IA.
A dearth of customer contact is typical for technical writers. Andrea asked people who have regular customer contact to raise their hands, and only a few people did. But IBM has done surveys, and its customers consistently want the following: retrievability, examples, solution-oriented materials, and seamless integration across products.
Radical IA allows technical communicators to add value to employers in the following ways:
By adding value, we increase the chance of continuing to be employed and elevate the status of technical communication.
Andrea and several audience members discussed the importance of
focusing on business problems when designing software systems. Often,
customers fall into the cognitive trap of simply automating the old
process. People in the audience labeled this practice papering the
design process and paving the cow path. New business models require new
systems. Remember the Biblical admonition about putting new wine in old
skins.
A similar problem can occur in documentation. Technical communicators
can end up servicing the software by documenting features just because
they are in the software. Instead, documentation should focus on
providing customers the information they need to solve business
problems, which, for example, may mean that a user guide deliberately
excludes system administration tasks that are irrelevant to solving
business problems.
A major goal of radical IA is to think more and write less. “Think more” means taking the time to identify what customers need to know. “Write less” means writing what is important and forgetting about the rest. Technical communicators are information professionals, so we should take ownership of architecting and delivering information. When implemented correctly, thinking more and writing less results in delivering the information customers need when they need it – and no more.
Thinking more means getting information about what customers need from all relevant sources, such as the following:
What if your present job does not allow direct access to customers? Andrea suggested doing what you can, such as talking to marketing people or spending a day either observing or doing customer support.
When dealing with customer input, caveat emptor. Sometimes customers ask for something just because it was part of a previous software system or manual process. Do not take specific suggestions at face value. Instead, focus on the nature of customers’ concerns and attempt to ascertain the root cause. We are the professionals, and it is our job to evaluate comments and implement them wisely.
Writing less could mean a new relationship between technical communicators and the community of customers. Customers tend to trust documentation that comes from the community more than that produced by professional technical communicators. Andrea cited the example of MySQL, which has a very high satisfaction rating. Members of that community perceive their own documentation as better than the “official” documentation from the vendor.
Here is a scenario to think about. What if technical communicators provided only an installation guide, overview, and embedded help? After that, technical communicators respond to questions on the forums. Eventually, the forum posts could become part of formal documentation, or else they could become part of a knowledge base with hit counts that provide a basis for knowing what is truly important.
This approach has several advantages:
This example is one of many approaches. Radical IA does not provide cookbook answers, but it does provide a framework for deciding how to respond your company’s situation.
In most companies, strategic IA is not the modus operandi. What can we do to be radicals who work toward realizing the Platonic idea of strategic IA in the quotidian reality of our jobs? Andrea suggested the following steps:
The first success establishes credibility and opens the door to additional opportunities. A journey of a thousand miles begins with one step.
Marc Smircich is a technical writer who specializes in user documentation for financial systems and system administration guides. He is also the treasurer and newsletter editor for the San Francisco Chapter STC.