Standards: What’s In It for Me?

By Ray Gallon | Senior Member

Standard Deviation is a column all about standards—a subject that affects most of our lives, but that we seldom think about. As the title implies, I want to keep the conversation lively and engaging. I’m always looking for guest columnists, and we welcome feedback with comments or requests for standards-related topics to cover. Email me at rgallon4stc@culturecom.net.

Standards—big yawn, right? Let’s face it, hardly any of us wants to plow through the dense text in which standards are written. If nobody reads the manual, even manual writers don’t read standards, right?

Wrong.

Somewhere in your organization there is a person dedicated to “compliance,” or, quite simply, you have a legal department. You likely have product managers who want to sell into countries where meeting specific standards is obligatory. If you work in a regulated industry, the regulations may point to certain standards as well.

Technical communicators are sometimes called upon to write standards, and we are not exempt from following them, either. Like it or not, it’s important for us to understand how they affect us, and how we can influence their development, so that published standards adopt best practices of our discipline.

Untangling the Rat’s Nest

If you read Annette Reilly’s overview of standards in a previous issue of Intercom (http://intercom.stc.org/2013/11/standards-101/), you begin to get a feel for how diverse the world of standards is. Standards that affect technical communicators exist at many levels:

• Standards for technical instructions
  • Software documentation
  • Machinery documentation
  • Regulated industries documentation (health care, transport, law, accounting, etc.)
  • Military documentation
• Industry- or product-specific standards that include a section on documentation
• Documentation management and development standards
• Content management and knowledge management systems standards that include documentation
• Localization standards that include preparation of source content
• Learning and instructional content standards
• Standards governing the display of content that we produce.

This list is far from exhaustive. Standards developed by different organizations, or by different groups in the same organization, might conflict with one another.

The trick is knowing where to look for the standards that we need to know about, and having criteria for deciding which standards to apply in our situation.

Standards Are Not Laws

What if they gave a standard and nobody came?

It happens. Even publication by such erudite bodies as the International Organization for Standardization (ISO) does not guaranty adoption. Unless government regulations require adherence to a certain standard, compliance with them is voluntary.

All the same, without them, we would have no interoperability. Mobile telephones in one country would not be able to communicate with those in another. The World Wide Web could not exist. We wouldn’t have email, or television, or the Olympics. A generalized standard often becomes obligatory in effect, if not in law.

We cannot know in advance if a standard will find wide adoption. We can only assess, before beginning work on a new one, what is the need and are people asking for it? In many cases, the “people” involved are industries or individual companies, many of whom want to push their own protocols or inventions forward as standards. IBM, for example, created the original DITA standard. The oManual standard was developed by iFixit.com and adopted by the IEEE.

This is why it is important for an organization like STC to participate in standards development, when a standard might directly influence how we do our jobs. If we want to ensure that standards for technical communication are developed by experts in the field, we need to be involved.

Aren’t Standards Obsolete by the Time They’re Published?

We live in a world where information changes in the time it takes to be verified. Standards development is a long, often tedious, often pedantic process. A case might be made that the whole business is obsolete.

But standards are intended to provide a baseline from which to start. Following the rules of HTML and HTTP will not guaranty you a great or successful website, only that people will be able to receive pages from your server and display them in their browser of choice.

All the major standards organizations have mechanisms that require standards to be reviewed at regular intervals, and if necessary, updated or withdrawn.

A standard is not a guide to the latest and greatest. It provides the layer of common understanding that we can have inside our own organizations, and between organizations that might be partners or competitors. It is a foundation on which to build your own methods, best practices, and innovations.