Companies learn how to do things by hiring smart people and paying them to figure out how things are done. Sometimes, even after they figure it out for themselves, they hire other companies to do the work for them. In either case, what needs to be figured out gets figured out, and what needs to get done ultimately does.

But what happens when the smart people don’t have the time or knowledge required to figure out how to do what needs to get done? Simple, you hire someone else to do the work, right? Well, what if that too is not an option? Ignore the need and hope it goes away?

No, of course not. If you don’t have the time or knowledge to complete the task yourself and you can’t outsource the work itself, why not consider outsourcing training that will give your smart people, well, even more smarts?

It’s an attractive compromise for a few reasons:

• Lower overall cost. It’s generally less costly overall to pay for the training required to perform the work than it is to pay for the work itself.

• Job and requirements-specific training. These might sound like buzzwords or jargon, but there’s a real point here and this can make a huge difference on the true effectiveness of your training. In our world of content development for example, we would much rather offer training on the use of Frame Maker as it applies directly to the performance and within the context of an individual’s day-to-day job, not as an overview to the sum total capabilities of the software. With outsourcing of the training you have the huge advantage of ensuring the training is 100% applicable to your process and your content. The significance of this distinction cannot be overstated.

• No long-term commitment to outsourcing. When you target the training you need specifically to your unique requirements, it takes less time to train overall since the objectives of the training are very clear and understood up front. No time is wasted covering irrelevant material. It can be everything you want and nothing you don’t, and this means less redundancy and cost. Once the training has been completed and you now have the skills you need to complete what needs to get done, there’s no commitment to further expenditures on outsourcing, unless you decide you want additional training.

Another way to look at it, (and I’ll apologize in advance for the terribly overused cliché), when you have to get something done would you rather pay for a fish, or learn to fish for yourself?

Outsourcing can be both an incredibly cost-effective and efficient way of getting additional work done without adding the cost of new equipment, software, or additional talent. At the same time, outsourcing can be looked upon negatively in that it can sometimes mean that a job that could potentially be done internally is now going to be outsourced. But it doesn’t have to. There is a middle ground through targeted skills training, and its worth looking into.

This is a challenge that presents itself to organizations frequently,  and while not much of a stretch to accept, the question then becomes “how?”.  If you acknowledge that yes, we have a need to capture our tribal knowledge and then make it accessible to and train others on within the organization,  you probably understand all too well that this is not something you are going to be able to purchase off-the-shelf. Therefore the next step is determing how to get it done.

The “how” depends greatly on the organization. A large company equipped with an internal training group may have access to tools, personnel, and budgetary resources that a smaller, mid-market manufacturing company does not. The challenge is the same, but the approach can be vastly different.

I call out this differential in organizational size for a reason. Again, the challenge to capture and make use of tribal knowledge is similar, but the problem can be more difficult for the mid-market company. Their business is manufacturing; most of the organization is dedicated to making product. They often lack the resources of a larger organization, so the requirement to not only solve the problem, but to do so in a way that has a minimum impact on the budget and sans dedicated internal training resources. Which is not to say that any of these suggested tips would not be beneficial for the larger organization as well; I just feel it’s important to acknowledge the often overlooked and unique challenges that the mid-market faces.

Here’s some tips to keep in mind as you develop your own program to capture and train on tribal knowledge:

1. Acknowledge the need. Well, duh. Seems obvious, but you can’t develop a plan to capture the tribal knowledge that exists within your organization until you’ve assessed that there is a need.

2. Make a clear business case that shines a spotlight on the need and will help win support for the initiative.  Is a good percentage of your workforce of retirement age? Are organizational silos preventing the exchange of critical business process information? Make a list and write down the specific reasons why developing a system to capture and train on tribal knowledge will benefit the organization. The process of writing down and working through the “why” will help shape and hone the eventual “how”. This can be a long and drawn out process; be prepared to remind everyone why you’re undertaking this effort, especially in those times where it gets difficult and progress seems slow at best.

3. Implement a workflow process that encourages sharing. Sounds pretty vague, but the basic idea here is that you need to shift away from the old way of communicating. This will no doubt be very difficult, but instead of sending an e-mail to Joe down the hall to ask about a specific process that needs to be documented for training, send him a link to a intranet or web page where he can enter the information. Done the old way, Joe believes he’s told someone how something is done, but that’s part of the problem, he’s told someone. Really take the time to think about how you can facilitate a collaborative method of capturing knowledge. This way, even in-process, the information that will eventually be developed into some type of formal training program can be accessible and useful to others. We’ve seen greater frequency of the use of internal wikis that can be incredibly useful in this regard.

4. Go talk to people, but don’t hassle them. Not everyone in the organization, especially in a manufacturing environment, will have access to the company intranet. Therefore, you’re going to have to go talk to those people that often times, know “the real story” about what makes your company tick. Be smart about it though, you’ll get little cooperation if you just hang around and randomly appear to pick their brains. Instead, make a plan of what information needs to be captured. Identify those individuals that are likely to be the most knowledgeable by talking to the person responsible for maufacturing operations. Schedule time to meet with those people and have a clear agenda of the type of information you need to capture before sitting down with them.

5. Determine how you will present the training information and make it accessible.  As a manufacturer, you may not have the staff resources or know-how to develop an effective training program, but don’t panic. The good news is that there are numerous options available these days to help with the technology side of your training program. Break the technology requirements into pieces that correspond with specific goals rather than trying to find one application that will do everything.  In this way, you can focus on tools that are right for your specific requirement, rather than pay for a single service or suite of tools that are more than what you really need. 

• Composing the content. Widely reviled by training experts everywhere, there’s a good reason Power Point remains prevalent. Organizations exactly like mid-market manufacturers already have it, and most everyone knows or can figure out how to use it. There is no shame in using PowerPoint, especially now that there are many training development applications that will allow you to directly import .ppt files. Is it the best or most capable application in which to develop training? No, not by a long shot. However, if software selection is the obstacle preventing  you from starting the process of formalizing captured training content, by all means fire up Power Point.

• Distributing the training. Your company intranet is an obvious, simple way to start. Share Point is particularly well-suited to the delivery of training materials. Or, you could create a simple HTML-based portal to display links to the training content. Microsoft and Adobe also offer applications that allow group collaboration that can be useful for hosting real-time instructor-led training directed to a group of people. Dedicated learning management systems sure offer some great functionality, but don’t let that stop you from finding other ways to distribute your content.

• Measuring retention. How do you know if someone has actually acquired the knowledge you’ve attempted to pass along? You’ll want to develop quizzes, tests, or practical hands-on skill evaluations. These can be accomplished in many different ways. Be sure to think about not only the format of these retention-measuring devices, but how they will need to be managed as well. What adminstrative requirements will there be?  Most professional training development software, like Adobe Captivate for instance, integrate the ability to add quizzes and tests into the training course, as well as allow for the  delivery of these results. However, get creative and see what low-cost or free services are out there as well. These may not be permanent solutions, but a Google search for “develop online quizzes” should get you started and perhaps thinking outside the software box as well. Again, when cost is a primary concern, try to identify simple services to meet specific requirements for each major function of your training course.

6. Be realistic and patient. Most of us can appreciate really great training when we see it, and most of us always want to create the best we can. However, understand that all the bells and whistles have some cost associated with them. It might be nice to have an interactive, exploded view of equipment for the maintenance technicians, but how realistic is that today? Think of your tribal knowledge capturing and training project as a living one. True that the 3D animation of a process might make it easy for some learners to visualize, but it’s not worth stalling out the development of your training. You may have to settle on a handful of static images or engineering drawings for now, but that’s ok.  As the organization as a whole recognizes the importance of and progress made on capturing and delivering tribal knowledge training, these things will come. It is far more important now, during the first stages of formally developing this training that something gets done as opposed to nothing at all.

Granted, this is not the sum total of the concerns you’ll be dealing with as you take the first steps towards developing your own tribal knowledge training program, but I hope you find these items useful as guidelines.

Good luck, drop us a note here if you’d like further information or need some help.

If you’ve spent any time thinking about, developing or using technical documentation, it is likely you’re familiar with this old chestnut. The reasons behind this dismissive utterance may vary: too much information, not enough information,  problems with accessibility and navigation, language translation issues, etc. but any or all of these reasons are assuredly more than enough to relegate “the manual” to dust-collecting duty on a shelf somewhere.

Those responsible for creating technical documentation bristle at this sentiment, even as a generality. We are very quick to counter and extol at great length ( just ask next time you’ve got a few hours to spare…) the absolute critical necessity of quality technical documentation and the positive business benefits it can bring.  Yet somehow and despite this fact, there is no shortage whatsoever of product support documentation that yet again, will elicit from the user a resounding “huh?” at best.

It’s the “why” of this that remains of great interest to me. If the people who write the documentation know that there are ways to create something that would be more well-received, why aren’t they doing it?

It is because at the end of the day, the organization creates technical documentation through its business processes and policies, not the technical writers. Technical writers learn from day one that “above all else, consider your audience.”  However,  the vast majority of technical documentation we encounter on a daily basis would never lead you to believe that the user was of much concern at all.

By and large we accept this. Poor or unusable documentation perpetuates the notion that most of it is terrible, and therefore it’s not news nor a surprise to anyone. It’s just the way it is. The attitude that “nobody reads these things anyway” persists.

Why does this happen? What’s going on inside the organization which clearly places some measure of value on the importance of technical documentation, yet continues to put out materials that their customers aren’t using?

Well, here are some of the more common symptoms and causes that we’ve observed:

• TMI (Too Much Information).  Apparently, if it has been written down and has to do with the product, then it must be included. All of it. Not only does this super-level of content make it extremely hard on the user, it makes the documentation development process extremely time consuming. The focus shifts away from usability to making sure there’s enough time to pack everything possible in, regardless if its quality or usefulness. “Better to have it in there than not!” is the default decision on questions of content and all too often this just makes things worse.

• Writing style “of the engineer, for the engineer”. Often times when dealing with documentation that covers a particularly complex product, the end result can end up looking like a mildly breathed-on series of engineering white papers. However, if the user of the product is not a design engineer, but perhaps a technician or operator, this documentation will be of little use. It is the job of the technical writer, as the advocate for the audience, to make this information as accessible as possible. However, not all documentation is created by professional technical writers, and sometimes there’s just not time to properly re-work the content to a level that is sufficiently palatable for users. If the former is the case, perhaps those responsible for the development of the technical documentation should be trained on how to interview technical subject matter experts.

• Failure to focus on the audience.  This dovetails in with the above, but much of the technical documentation we see regularly would benefit greatly simply by assessing it through the eyes of the user. If I am told that it is my responsibility to maintain a piece of equipment, then I, as the user of the manual that came with the equipment  want to be instructed on how to troubleshoot and repair. Chapter and verse regarding theory of operation will mean very little to me. Tell what to expect from the moment I open the box through installation, configuration and maintenance. Any information beyond that may be of little concern to me right now, so simply tell me where to find the rest and if I need it I’ll go looking for it. Most often, this lack of focus on the audience happens because it gets squeezed out in favor of trying to get every possible piece of information included as a priority. It is absolutely worth questioning and re-evaluating who the users of your technical documentation really are.

• Deadlines and Industry Specification Requirements. For those companies that manufacturer many and diverse products, there’s simply not enough time to pay too much attention to usability. It’s hard enough to keep up with getting out any sort of documentation much less pieces that really focus in on and work for the users in a meaningful way. If you manufacturer certain products that are subject to regulation, it’s easy to fall into the routine of just meeting the minimum requirements for the documentation; requirements that do not necessarily account for what might work best for your users.

All of the above are symptomatic of the widely-held opinion that technical documentation is regarded as a “necessary evil” .

The realities of business processes and policies often limit the potential advantages that technical documentation can offer both the manufacturer and their customers. However, this can only be properly addressed when the organization chooses to make a proactive change. Otherwise the cycle of “it’s no good but no one reads these anyway/no one reads these anyway so it’s ok if it’s not that good” will continue to persist.

“Simple”, the engineer explains. “$1 dollar for the screw, and $99,999 for knowing where to install it.”

While intentionally exaggerated (much to the satisfaction of engineers everywhere), there’s an oh-so-true reality here. The $1 screw was not singularly responsible for fixing the problem. In fact, that $1 part is completely useless without the additional benefit of the engineer’s knowledge. Therein lies the real value.

However, this type of knowledge that is acquired over a long time and through the benefit of great experience is notoriously difficult to capture. Which is precisely why that in the story above, the engineer was able to command a ransom for what he knew. It clearly did not exist anywhere else inside the organization.

This is exactly the situation that many companies find themselves in today. Part of the workforce owns a great deal of the information required to keep the ship afloat and pointed in the right direction, but what happens when the individuals who make up that part of the workforce retire or move on to other jobs?

Some types of knowledge can be passed on to the organization-at-large through the use of off the shelf training. There are services that client companies can subscribe to that will give their employees access to training resources on all sorts of relevant topics. Software training, personal and soft skills training, sales training, safety training, even generalized machine tool operational training. You name it, there’s likely training available and accessible via the web. You can sign up and assign your entire staff to attend and complete the training courses of your choosing. Sign up, sit down, get trained and Bob’s-your-uncle. Done and done. Trained.

Right?

Well, sure. Sometimes. If you needed your accounts receivable staffers to brush up on Excel 2007, probably. If you needed your plant personnel to better understand current OSHA regulations, sure. Off the shelf training programs certainly do have some clear value, no question.

However, if you have the challenge of conveying the type of knowledge that only comes from years of experience and interaction with your operating conditions or processes, it may be hard to bridge that gap with off the shelf training. That type of knowledge, the “oh-no-the-line’s-gone-down-and -Jim’s-on-vacation” mission-critical and specific type of knowlege, has to come from within.

And while that can seem to be a daunting task, to capture that knowledge and then create and deliver training information to the larger organization, the long term benefits in terms of prevention alone will be enormous.

So next time line #6 goes down, it won’t matter that Jim went on on vacation, Steve knows that sometimes all it takes is to check the connection on the back of the optical sensor to get things up and running again.

But how exactly can your company do this? I’ll outline some basic project steps in the next entry.

A structured document organizes paragraphs (elements) in a logical hierarchy, provides a means to attach tags (attributes) to individual paragraphs (elements), and gives you the ability to view the document in multiple ways.  FrameMaker ® (and other editors) also gives you the ability to manipulate the content of structured documents so that you can supply different outputs from the same document.

For this discussion, I will be using Adobe® FrameMaker® as my editor.  FrameMaker’s what-you-see-is-what-you-get view of structured documents is called the Document View.  If you have worked in unstructured Frame, this should look very familiar:

Note, that all text is enclosed in brackets.  These brackets indicate element boundaries on the WYSIWYG view (Document View).  This correlates to the Structure View hierarchy described later.

The second way to view the document is called Structure View in FrameMaker.  The Structure View shows all elements (paragraphs) arranged in a hierarchy.  Each box represents an element.  An excerpt of the element text is displayed to the right of the element.  Below each element are Attributes assigned to the element.

The example highlighted below shows that the first element Bullet1 is assigned a value of 1 for the attribute Output.  The second element Bullet1 is assigned a value of 2 for the attribute Output.

In addition to managing the attributes and hierarchy of elements, you can also perform some edits in the Structure view.  If you right-click on an element, a context menu appears that describes several possible actions.  Typical shortcut buttons (ctrl+C for copy, ctrl+v for paste) function normally.  You can also drag-and-drop elements to move their location or to change their place within the hierarchy.

Most users who are accustomed to unstructured FrameMaker are used to working with the formatting toolbar.  Structured Frame does have this functionality; however, it also introduces an Element Catalog in place of the paragraph catalog.  The Element Catalog lists elements that may be selected to insert into the document and provides a tool-set for managing elements as you create them.  Using this catalog, you can insert an element into an existing element, wrap an existing element inside of a new element, and change the type of an existing element.  This tool set helps to minimize the complexity of managing the content from the Structure View.

Once you have an element in place, you can assign attributes using the Attribute Editor.  The editor displays potential attributes for a selected element and lists the predefined values that may be assigned.  Select the desired attribute, assign an attribute value, and then select the Set Value button.  This assigned value is then visible in the Structure View.

Using the Structured FrameMaker tool set helps to make management of complex single-sourced documents easier.  Creating a functional hierarchy allows you to manage content at all levels.  Attributes allow you control several output levels and types while ensuring that you are able to maintain accurate content.

Product disclaimers are everywhere. Presumably crafted by very smart people wearing suits, who know much better than the rest of us, these little nuggets of wisdom caution us against all sorts of things. Tossing an aerosol can into an open flame for instance, or using hot sauce to rinse out our contact lenses. Essentially, they remind us of what a product isn’t intended for, and what bad things might happen if we don’t pay heed.

However, you’ll find no such disclaimer on a piece of content management software…but there should be, and I’ll explain why.

In our line of work, we talk to mid-market manufacturers on a daily basis. When discussing product support documentation, a remark that we hear all too frequently goes something like this:

“Well, we bought this popular content management system/authoring tool a few years back, but we don’t really like it/use it/are getting away from it.”

Time and time again, we hear the same story. These mid-market manufacturers, by all accounts successful and staffed with intelligent people, decided to move into managed content using a software application, and then at one point, stopped. Why is this?

Was the application faulty or flawed? Did the software company makes dubious claims that simply weren’t true?

In reality, no, neither. Assuming the mid-market manufacturer did a modicum of homework and purchased an application from a reputable software vendor, the application was likely perfectly functional.

The problem is the disclaimer, or more precisely, the lack thereof. It’s what the software can’t do that’s the real issue.

Were I to write a disclaimer for a content management software application, it would have to at a minimum include the following:

“The use of this product implies no remedy nor correction of the following issues, included but not limited to:

• Continued, excessive use of your engineering team’s time spent developing and reviewing product support documentation may result (Product support content will not research, review, and edit itself)
• May require considerable and ongoing dedicated training resources to ensure proper implementation and maintain consistent use over time
• It is the responsibility of the user to both identify and structure legacy content for re-use; the software only allows for the potential of this functionality
• It is the responsibility of the user to establish and maintain an internal process that supports the flow of information into and out of the software
• The software vendor makes no claim regarding the quality or usability of the content managed within.

Your individual results may vary.”

Content management software companies have done an excellent job making sure they have exposure; it is their job to exist in the spaces where people that have the challenge of developing and maintaining content live.

However, in doing so the line between content development and content management has been blurred and this especially true in the mid-market. It’s one thing to have the ability to single source and manage content, quite another to improve the way it is developed, integrated into internal workflow processes, and then maintain over time.

So after you’ve read all the website materials, sat through the webinar, and heard everything there is to hear about what the software can do, make sure to stop for a minute and consider how’ll you address what it can’t do, too.

“Our company frequently revises our engineering drawings.  Several of these drawings are included in our product guides.  How can we efficiently ensure that the latest drawings are included in our manuals?”

PPI Answers…

We use a repeatable method to ensure that our customers’ latest drawings are always included in documentation.  The key lies in the way we import images.

When you insert a drawing into an Adobe® FrameMaker® document, you have the option of either embedding or referencing the image file.  If you select the embed option, the file is imported as a static part of the document.

Instead, selecting the Import by Reference option tells FrameMaker® to check the source file each time you open the document.  This means that if you change your drawing, save it in the same location by the same name, then FrameMaker® will display the updated image next time it opens the document. 

Voila! Automatic drawing updates!   The tricky part is building a sustainable file structure that allows you to manage the images while retaining revision control.  Most organizations use the name of their drawing files to track revisions.  This can still be done while setting up a file structure that promotes referencing vs. embedding image files.

 A common file structure might look like this:

Each file name includes a brief description of the file and shows what revision.  Users can tell at a glance what file is the latest revision.

 In order to make the best use of the Import by Reference option, you might consider adding an Active folder to your file structure.  The files in the Active  folder should not have the revision information in the title.  For example

When you update a drawing, follow these steps;

1. Save the file as you normally would.
2. Save a copy of the drawing to the Active folder
3. Rename the file so that it has the same name as the previous revision.  This way, FrameMaker knows what drawing files should be displayed. 

Managing your files this way saves you the nightmare of hunting through existing documents and replacing images every time a drawing is revised.

Police work? No, something far more adrenaline-fueled and dangerous. Documentation.

Picture this:

A manufacturer is scrambling to finish up and prepare for delivery the latest iteration of one of their most popular pieces of equipment. Three weeks before it is scheduled to ship, someone realizes they forgot to prepare the operator and service documentation that is required to accompany the equipment to their customer overseas.

Internal resources are tapped. Engineers and technicians work day and night preparing the machine for shipment and delivery. In an office adjacent to the assembly floor,  the engineering manager and product line manager furrow their brows with growing concern. Completing the documentation on time is only one-half the problem. The other half is doing so in such a way that corresponds favorably with the quality and innovation of this new piece of equipment. A hastily assembled three-ring binder full of notes and photocopied vendor-supplied spec sheets just weren’t going to cut it this time.

What do they do?

They call in a SWAT team. Well, ok. Maybe not the guys with the bullet proof vests and flash-bang grenades, but a documentation SWAT team. (Which, let’s face it, is almost as cool.) This team shows up in khakis and button-down shirts, armed with notebooks, digital cameras and laptops loaded with high-power publishing software.

And like the real SWAT, this documentation team is equipped with special training.  Armed with the education and real-world experience of mechanical and electrical engineering as well as computer science and communications, a well-rounded team of specialists that is singularly focused on the mission of getting in and getting back out with minimal long-term cost.

When the team shows up on site, they rapidly assess the situation and map out a plan. In short order, a project scope is hammered out, and the team goes to work.

The team descends on the equipment and rapidly determine how it works, what the major components are, and what needs to be included in the documentation. Encounters with engineers and technicians might prove troublesome for some teams, but not this one. They speak the language; fluent in “engineer” and well-versed in the world of equipment manufacturing. At the same time, the teams’ offsite support are already preparing a template to house the content.

The team supplies everything. Need a picture of this component? No problem. Need to facilitate the inclusion of  CE warning labels but can’t find all of them? They’ll find them. Need an engineering drawing converted or modified? They’ve got you covered. Need to facilitate the upload of  large files for inclusion into the documentation? The team will have a secure file transfer site up for you in minutes. Want to design a completely new documentation layout to better represent your company? The team will provide you with samples to choose from, or create a completely new one. Have a requirement for an additional language? They have specialists for that, too.

Digital cameras flash. The rapid firing of keystrokes punctuates the noise of the assembly floor. Notepads are exhausted and pens run dry.

It’s the end of day one, and the team is ready to present a working outline. By the end of week one, the team will have draft content ready for review. By the end of week three, the documentation has been completed and delivered. Along the way, the team has reported daily and weekly progress, organized and facilitated review meetings, and managed the process of seeking out, capturing, and maintaining content edits.

Wouldn’t it be great if such a team existed? A team of specialists that you could call in to respond to your product documentation needs without having to hold their hands? A team that has the skills, know-how and appreciation for your time and resources? A team that could get in, get out and provide you with a quality and on-time deliverable with no long-term investment? Sound too good to be true?

Some questions for equipment manufacturers out there:

Have you ever wished for a documentation “SWAT” team? What would prevent you from utilizing such a team? What questions or concerns might you ask or want to discuss with this team?

I’d love to hear your thoughts. Drop us a note here or feel free to use the comments feature.

When designing the single-source document, one of the first considerations has to be how you will manage the content.  To this end, there are two primary methods:  Conditional Formatting and Attribute Filtering.  What is the difference between the two?  What circumstances would make one more appropriate than the other?  These are some of the questions that we are frequently asked.  To address these questions, let’s take a look at each of these methods.  For these examples, I will be using Adobe^® FrameMaker^® as my editor.

Conditional Formatting

Conditional tags can be applied to individual characters, words, sentences, or whole paragraphs.  You can then display or hide the tagged text within the document with a few clicks of the mouse.

Before you begin to write your document, make a list of the conditions that you may need to set.    For the purposes of this example, I have identified two conditions: Condition A, and Condition B.  Once these conditions are identified, you can create condition tags.  Some editors allows you to designate text colors that will be displayed once a tag is applied.  These colors are called Conditional Indicators.  You can turn these indicators off globally before you print or export your document.   I chose to use Green for Condition A and Red for Condition B.

As you develop your document, mark content that you would like to manipulate with a conditional tag.  First, select the text, and then apply the predefined conditional tag. 

Once your document is complete, you can manipulate it by showing or hiding certain conditions.  In the example below, I have hidden both Condition A and Condition B. 

 The next example shows Condition A and hides Condition B.

This method of manipulating a single sourced document makes it easy to manage multiple input combinations; however, it does not lend itself well to multiple output levels.

Attribute Filtering

Attribute Filtering provides more options than conditional formatting; however, it is applied at a higher level.  Where conditional text could be applied to a single character, word, or sentence within a paragraph, attributes are applied to the paragraph itself.  If you have to change just one character in a paragraph in order to achieve the desired output, you will need to duplicate the paragraph, make the change, and apply different attributes to each.

To apply attributes, you must be working in a structured document.  As you develop your content, set the appropriate attributes and their values.  For example, you could have an attribute of “Condition” with possible values of “1“and “2.”  Additionally, you could have an attribute of “Level” with possible values of “A “and “B.

1. Attribute = Condition
   1. Value = 1
   2. Value = 2
2. Attribute = Level
   1. Value = A
   2. Value = B

Once your attributes are assigned, you can develop filter expressions.  Filter expressions are Boolean expressions that dictate what content is displayed or hidden.  Some possible filters for the above attributes and values are:

1. Common Text Only:

NOT (Condition=”1” OR Condition=”2”) AND NOT (Level=”A” OR Level=”B”)

2. Condition 1 + Level B

NOT (Condition=”2”) AND NOT (Level=”A”)

3.  Condition 2 + Level A

NOT (Condition=”1”) AND NOT (Level=”B”)

4. Level B only

NOT (Condition=”1” OR Condition=”2”) AND NOT (Level=”A”)

As you can see, attribute filtering is a powerful means of controlling various outputs; however, it works best when there is a singular input.

To further illustrate, let’s take a look at two hypothetical clients.

Hypothetical Client A

Client A produces one basic type of heavy industrial equipment; however the machine is customized for each customer.  There are 82 possible features and options, giving them an almost limitless potential for customization.  It is impractical to pre-write individual user manuals and product guides for every potential configuration.  It is ineffecient to create a draft-to-print custom manual and guide for each possibility.

The output will always be either a pdf or a printed document, and will always be delivered to a consistent audience level.

Using conditional text is the correct answer in this case.  The output is always the same level (ie. there is only one audience), it is the input that changes.  Manipulating the document by setting conditions allows you to precisely control the features and options that are included.

Hypothetical Client B

Client B produces a few different industrial machines.  Each machine requires three levels of publications: a Product Operation  Guide, a Preventative Maintenance System, and an Installation Manual.  Each of these manuals will focus on different aspects of the same machine.  Some of the content in each will be common; however, the steps that are required for various processes will vary greatly from one user level to another.

In this instance, the input is constant while the output changes.  Attribute filtering would be appropriate for Client B.  Manipulating the document by filtering attributes allows tight control over the documents that are produced, ensuring that the correct information gets to the correct audience level.

Choose Wisely

Each of these methods requires a different approach to writing your document.  Before you begin to develop your content, ensure that you have selected the best method of managing content.  Choosing correctly makes it easy to produce the desired results.

In today’s world of user-friendly and largely free social media tools, it’s understandable that this trend continues. In relatively little time, with relatively little cost, manufacturers large and small can stake their claim on the web and create a fresh,  forward-facing identity to engage potential customers with a whole new strategy. Manufacturers across the country and the world are scrambling to become experts in the brave new world of social media. Facebook, Twitter, and YouTube used to be banned during working hours, now they’re almost a requirement.

And let’s not forget the more traditional methods of marketing, including the entirety of various MarComm initiatives, as well as ad buys in the aforementioned trade journals and/or banner space in e-newsletters, trade websites and the like.

However you as a manufacturer define your strategy of getting the word out about your products, it adds up to a significant, concerted series of costs and efforts designed to generate leads, and from leads, sales.

But what happens after the sale? Have you considered that your product documentation is letting the side down? Or even worse, could your product documentation be preventing a sale?

For your consideration:

• Given all the time and effort that go into creating a brand that properly targets and engages your customers, does your product documentation support the perception of your brand? Is the gleam of your world-class marketing effort being dulled by a ratty binder of photocopied sheets that you affectionately refer to as the “operator’s manual”? At a minimum, stop and consider what kind of impression is left on your customer by your documentation after the sale.

• Are you using your product documentation to sell after the sale? If your product requires consumables, service parts, or optional upgrades, you should be.  From the correct contact information for service reps to detailed information on the benefits of genuine OEM consumables to instructions on how to get spare parts, it’s always worth your while as a manufacturer to ensure you are taking advantage of this opportunity to make these additional sales. Do you offer product or process-specific training for customers? Why not include this type of information in your product documentation as well?

• Is your product documentation available online? Many people use the availability and quality of product documentation as a factor in their purchase decisions. Is yours available online, and if it isn’t today, would you have any reservations about making it available online as it stands today? Could be one more reason for your customer to decide to buy from you. Even if you deal strictly in custom equipment, it may be worth creating a “generic” sample and make it available to potential customers of an example of your world-class products and support.

• Take a look at your competitors’ product documentation. Is yours comparable? What things do you think they do a better job of, and what things do you feel you do a better job of? Next time your boss asks you to sit in on a marketing strategy session, it would be worth your time to have this list or some examples handy.

Product documentation is often overlooked or dismissed as a necessary evil, yet it should have just as an important role as every other play in your marketing strategy playbook. Don’t make the mistake of allowing it to let your side down.