Archive for August, 2009

Single Sourcing and the Naming of Parts

Wednesday, August 19th, 2009

The realization that information of all kinds is an asset isn’t new but it’s certainly gained popularity of late, perhaps because the tools to store, manage, and manipulate information are more readily available. It’s easier than ever before to manage what we call ‘content’, that is to say information that we decide may be useful to us or to our consumers. So now we can store all our help documentation, designs, meeting notes, e-mail messages, presentations and even phone calls – not simply because we can, but because in future we may be able to use that information in the creation of new content.

When you treat information as an asset it’s natural to look for ways to more efficiently extract value from it. Writers recycle information in periodicals, presentations and books. Engineers’ ideas appear in e-mail, design specifications and patents. It’s the same principle by which Honda builds a number of different cars from a common set of components. You increase the value of your work when you develop core reusable assets that can then be combined to build new deliverables. That’s the essence of single sourcing; create once, use many. If the whole is greater than the parts, then more wholes must be even greater.

Information Parts

These information parts must be as self-contained as possible if they are to be re-assembled in this way. For Honda, this may mean a chassis design that is generic enough to be used in a truck, two SUVs and a passenger car. For Microsoft, this might lead to a paragraph titled connecting to a network that appears in the operating system help, in Web browser popup help, and in internal user support documentation.

The key to maximizing reusability of these parts is to identify them clearly, and avoid unnecessarily limiting their reusability. In single sourced trap information parts, don’t mention mice when the same trap comes in three sizes: mouse, rat and gopher. Instead, compose your documentation from clearly labeled and distinct common trap, mouse, rat and gopher parts. Here’s an example:

The Gizmo trap is made entirely of exotic hardwoods and surgical steel, for years of trouble-free use. The trap comes in different sizes, depending on your pest control requirements. The mouse Gizmo traps house and field mice and has an integrated cheese dispenser. The rat Gizmo traps rats up to nine inches. The gopher Gizmo traps gophers the size of small dogs. Gizmo traps are guaranteed for five years, and come complete with instructions and a handy storage box.

The good

The gizmo company implemented single sourcing for all its information from day 1. When it develops the third version of its gizmo product, G3, the benefits are clear:

  • Information relating to all the features of G3 that it shares with previous G2 and G1 products can be reused. This information has, of course, already been edited and reviewed so it has built-in value.
  • Information can easily be converted into new online formats – blogs, on-demand, searchable, FAQs and so on — by the content management system, so publishing is to a degree future-proofed.
  • Existing information channels – FAQS, forums, and browser-based help – can be automatically updated with specific information relating to the new product. For example, the new location for the ‘on’ switch on the G3 can be inserted into an existing FAQ entry on “Turning on your Gizmo”.
  • Debate and decisions around G1 and G2 design can be retrieved and reviewed when the new G3 design team is making its decisions. Repeat debates, discussions, meetings and e-mail threads are avoided.
  • Customers receive all the information they need, and only the information they need, in the right form and at the right time.
  • Duplication of effort and information is reduced; FAQS, Getting Started guides, Forums, support documentation, browser-based and printable help can all be populated from a single repository of known-good information elements.

The bad

A single sourcing strategy means that poor information continues to be propagated until it’s identified. Also:

  • Consumers can get a disconcerting sense of déjà-vu when they read the same snippets of information in multiple places.
  • The context in which information parts are reused can’t always be completely foreseen. My entirely accurate part on how to use Gizmo feature X may become inaccurate if in future not all Gizmo users are licensed to use that feature.
  • We may be tempted to take advantage of single sourcing efficiencies and publish information before we are sure of the requirement for publication and its value.
  • We may focus on the efficiencies of our content strategy rather than the requirements of our consumers.
  • It may become less easy to identify information that should be retired, and in some cases difficult to get a complete picture of all cases where the retired information has been reused or referenced.

The ugly

Single sourcing hinges on the accurate and comprehensive ‘cataloging’ of information parts, if those parts are to be readily identified and reused. This leads to the generation of huge amounts of ‘meta information’, information about information, that itself then needs to be managed. In fact, in the age of the single sourcing, meta information is easily as important as the information itself, and must be used as carefully and as sparingly as possible. We need to be able to quickly ‘tag’ new information parts with meta information when we write them, and quickly identify those parts when it comes to re-use.

This problem is hard enough when we are starting from scratch with a new content strategy that is based on single sourcing. It’s compounded when we are faced with legacy content we need to distil into information parts.

Consider the previous example of the bad:

My entirely accurate part on how to use Gizmo feature X may become inaccurate if in future not all Gizmo users are licensed to use that feature.

A perfect single source implementation would of course have tagged the original content and the new licensing option such that the dependencies were clear. Introducing the licensing information would trigger a warning that the feature X part now needed an additional disclaimer part regarding licensing. But our composite documentation may still end up ugly and repeatedly betray its single sourced origins, much like the gun parts lecture in Henry Reed’s Naming of Parts:

This is the lower sling swivel. And this
Is the upper sling swivel, whose use you will see,
When you are given your slings. And this is the piling swivel,
Which in your case you have not got.

More on single sourcing and developing a comprehensive and usable meta information strategy in future posts, and in more depth in the rewrite newsletter which as yet you have not got – but it’s coming soon.