It’s always entertaining to read about non-lethal lapses in security at a major event. Remember the debacle at the 2010 Winter Olympics? A man with false ID got within a few yards of U.S. Vice President Joe Biden before being arrested at the opening ceremony. You’d figure after spending almost a billion dollars on security, the organizers would be able to hire people who could spot phony passes. (I also wonder if the intruder got a refund, because, hey, opening ceremony tickets are expensive!)

Another security breach also involved the White House, where an uninvited couple crashed a State dinner, and actually met the President and Vice President. Security officials admitted there was a breach but said not to worry; the couple didn’t have any weapons. Gee, that’s a relief…

These incidents are actually symptoms of a much larger debate: balancing security with democracy. This has been a problem for society long before terrorists or 9-11, however modern terrorism has made the balancing act much more difficult.

On the one hand, governments have a responsibility to stop attacks and ensure their citizens are protected. On the other hand, they have to ensure they don’t turn their nations into police states.

On a more personal level, regular people face the “security vs. freedom” question. Having a credit card is convenient, but can expose you to fraud. Driving a car gives you mobility, but you run the risk of death or dismemberment. Every day, we’re always making trade-offs between safety and convenience.

Technical communicators are no different. One of the most difficult tasks in our profession is deciding what information to give to users, and what to withhold. Make no mistake – it is often in the user’s best interest not to tell them everything possible about the product you are documenting.

For example, you may be documenting a web-based product which has a particular task that can be reversed or “undone”. However, you may want to withhold that information, because by telling the user they can “undo” one function, they may assume they can undo other tasks, leading to disaster.

Another example relates to FrameMaker. If I were documenting this product, I would probably not tell users that they can:

• combine conditional text conditions
• include text insets within insets

because either of these actions actually creates further problems.

However, there is something much more valuable that the security debate teaches us: the importance of proper information gathering. 9-11 was a failure to properly gather, consolidate and evaluate information. The right questions were not asked of the right people.

Contrast that failure with how an Israeli security agent questioned Ann-Marie Doreen Murphy, a 32 year-old Irish woman who was trying to board an El Al flight to Jerusalem in 1986.

The conversation went something like this:

Agent: Did you pack your bags yourself?

Murphy: No.

Agent: What is the purpose of your trip to Israel?

Murphy: For a vacation.

Agent: Are you married?

Murphy: No.

Agent: Traveling alone?

Murphy: Yes.

Agent: Is this your first trip abroad?

Murphy: Yes.

Agent: Do you have relatives in Israel?

Murphy: No.

Agent: Are you going to meet someone in Israel?

Murphy: No.

Agent: Has your vacation been planned for a long time?

Murphy: No.

Agent: Where will you stay while you’re in Israel?

Murphy: The Tel Aviv Hilton.

Agent: How much money do you have with you?

Agent: Fifty pounds.
(Note: This is less than what a single night at the Hilton cost.)

Agent: Do you have a credit card?

Murphy: Yes.

However, she did not; instead, she showed the agent an ID for cashing cheques.

The agent sent her bag for additional inspection. A bomb was discovered hidden in her bag. Her lover had planted the bomb, unbeknowst to her. (Something tells me they’re probably not still a couple.)

Note that the bomb was discovered without any technical devices or sophisticated electronics . The agent simply used proper interviewing and behavioural observational techniques to discover the truth.

This is precisely what technical communicators need to do. Fancy documentation tools are nice, but they are no substitute for intelligent investigation.

When researching a document, you may have a conversation like this with a SME:

Writer: Is X true?
(where X is any statement of fact about the product you are trying to document)

SME: Oh yes, absolutely X is true.

Writer: Is it true all the time and under all circumstances?
SME: Uh yes, I think so. I’m pretty sure it is.

Writer: Well, what about in situation Y, or if you were to do task Z to get to X?
SME: Actually, in those cases, X is not true.

Writer: Thank you.

This happens all the time. It’s not that SMEs are stupid or don’t want us to do our jobs – it’s that they are trapped in their world of code and are often not able to see beyond it. They often lack the holistic, big-picture view that technical communicators must have in order to successfully document a product.

People who are studying technical communication in school should also take courses in detective work and investigative journalism, because all tech writers are really detectives and reporters.