Our unpredictable users

Image result for peopleIf you’re reading this, you are probably a human being, and if so, you are member of a most strange and unpredictable species.

Trying to predict human behaviour in order to change it is big business. Governments impose laws trying to get their citizens to conform. Companies create products and services trying to get people to buy them. The problem is that people often behave in a way that is completely opposite to what you would expect.

Let’s start with the government. Our dear leaders want us to drive safely so that we don’t kill or maim ourselves or each other. To encourage this, they enact various driving safety laws, including speeding limits, mandatory seat belts, and in some jurisdictions, mandatory winter tires. The idea is that these safety measures will result in safer driving. But often, it actually reduces safety. How is this possible?

Studies have shown that drivers who perceive their car to be safer will drive more recklessly, because they believe that the car’s safety features will protect them. In other words, safer cars can actually make drivers less safe.

While it is true that the number of winter accidents in Quebec’s have declined since snow tires were made mandatory, this is probably due to the province’s high unemployment rate. Fewer people working mean fewer drivers, and fewer accidents.

There are a few solutions to this conundrum. To encourage safer driving, governments could offer lower vehicle license renewal rates to accident-free drivers. A stranger “solution” would be to make cars more dangerous. If a sharp spike pointing towards the driver was placed into the steering wheel, you can be sure the driver would drive very carefully.

Predicting people’s behaviour is big business in business, too – it’s called “marketing”. Marketing involves understanding a person’s core beliefs in order to determine their actions so that ultimately they will be convinced to purchase a specific product. This often means developing products with characteristics that are counter-intuitive. There are many examples:

Those “inefficient” Japanese
A Japanese manufacturer can assemble a custom-made bicycle in a few hours. However, they do not deliver the bicycle to the end user as soon as it is ready. Instead, they store the finished bike for several days, then contact the customer for a pick up. The reason for this delay is that customers are hungry for the anticipation of the product – it is part of the joy of the purchasing process. Picking up the bike only a few hours after ordering it would diminish this joy.

No pain, no gain, no sale
A medical supply company created an antiseptic that did not sting. Sales were terrible, forcing the company to add alcohol to the product in order to make it sting. People associate pain with sterilization. Because the antiseptic did not hurt, people thought it did not work. Similarly, Buckley’s, a vile-tasting cough medicine, promotes itself with the tag line: “It tastes awful. And it works.”

The package is the product
Steve Jobs not only designed Apple products, he also designed the packaging. When Macs were first introduced in the 1980s, people were not familiar with the computer mouse. Jobs designed the packaging of the mouse to deliberately slow down the unpacking process, in order to force people to become acquainted with this strange new accessory. Even in the packaging, Jobs was creating a full user experience.

Increased price; increased sales – what the…?!
When China increased the import taxes on Porches, sales actually increased. The luxury car became even more a status symbol, because everyone knew how much more valuable they were. It is one of the few examples where raising the price of a product actually had a positive effect on sales.

Unpredictable docs

Knowing that people are unpredictable has a direct impact on documentation and product design in the business world. Again, there are many examples:

Does she or doesn’t she?
Years ago, Clairol introduced products allowing women to colour their hair at home. The product only had to set in one’s hair for two minutes, compared to the thirty minutes it would take at a salon. However, the instructions that came with the product stated that the user should keep the colouring material in place not for two minutes, but thirty minutes. Why?

Women were used to the fact that colouring their hair took 30 minutes. They simply would not have believed that a two minute set time would be effective, so Clairol actually stated to keep the product in their hair fifteen times longer than required. Behaviour trumps practicality every time. 

Rock that doc
When the rock group Van Halen arranged tours, they relied on a most interesting 53-page document: their contract. In addition to various technical specifications regarding the stage setup, the contract had an obscure clause stipulating that a bowl of M&Ms was to be provided backstage with the brown ones removed. Failure to comply with this demand would result in the show being cancelled. Was Van Halen really so picky about candy?

The reason for this exotic request was to ensure safety. Van Halen’s onstage equipment was massive and had to be assembled to strict specifications. Failure to do so could result in injury or death. The “no brown M&Ms” clause was there to ensure that the intended readers of this document complied with the stage setup instructions. If a brown M&M was detected, it probably meant the backstage staff had not followed the other (and much more important) instructions.

May I take your order?
A online enterprise developed a simplified product ordering process, reducing the number of screens required to place an order from five to one. It failed completely – users wouldn’t use it. They wanted the safety and security of being able to easily back out of an order at any time. Giving the user only one screen to complete a purchase, while more efficient, scared away potential buyers.

Let’s be charitable
Often when you receive requests from charities asking for a donation, they will include a form with several suggested amounts. There is usually a small amount, a medium-sized amount, and a large amount, for example, $5, $50 and $500. The target amount that the charity really wants is the middle amount. $500 is too much for most people, so they will ignore it. $5 is too cheap. $50 is “just right”. The design of the document (the donation form) influences the behaviour of the donor.

When designing documents, we must understand how thoroughly unpredictable our readers will be. They will do things like:

  • not open the help even when there is a clear link to it
  • not search the help or use the index, even if these functions are clearly visible
  • be unable to find a button or other user interface element unless you tell them where it is
  • completely skip over a critical introduction to a procedure, in which case you may need to restate the information within the procedure
  • ignore headings at the top of a topic or within a topic
  • look up an item in an index using a term or phrase that you could not possibly imagine

There will always be two things which will remain difficult to predict: the future, and our users. The more we can predict the irrational behaviour of our users, the greater the quality of our documents will be.

Own up to your docs

Managers often ask: “Who owns the documentation?” Our response, of course, is another question: “What do you mean by own?”

Legally own?
If by “own” you mean, who legally owns the documentation, the answer is the company that you work for. They hire you to create the document, therefore they own you, or least the time that you spend working for them. Everything that you create during that time is theirs.

Owning the maintenance?
If by “own” you mean, who is responsible for maintaining and updating the documentation, the answer had better be the technical communicator. However, this question leads to a more important one: Who is responsible for ensuring that the technical writer is made aware of all the changes so that the writer can make the necessary documentation changes? This question is a bit more complicated to answer.

In a perfect world, the writers would be made aware of all the changes. In the real world, this simply does not happen. It’s not that the changes are deliberately withheld; it’s simply that the product development group is often so busy that they do not have time to make the writers aware, or that they are not aware that they need to make the writers aware.

In addition, even when writers are made aware of a change, it can result in other documentation changes which development would not know or care about. These kinds of changes writers must own.

For example, I was documenting a product that had two types of search functions: simple and complex. I was told that the simple search function had been removed. However, the change to the documentation was not just simply removing the topic that described the simple search function. I also had to update other related topics that referred to both of these function types so that the documentation simply described “searching” and not “different ways to search”. I also had to update the TOC and index, and various cross-references.

Development owns the responsibility of informing the technical communicator about product changes, but the technical communicator owns the responsibility of making the change in all the areas that it applies. However, the situation becomes more complicated if the content is shared by more than one technical communicator.

In a workgroup environment, where several technical communicator have access to the content through a content management system (CMS), ownership is even less clear. If any one can edit the content, then who is the owner of the content? That is why every doc team must have a leader who either makes the change or has the authority to delegate it to someone else. This leader then becomes the owner.

Owning the final say?
If by “own” you mean, who has the final decision as to what appears in the released document, the answer is whoever has the authority to make the final decision as to what appears in the released product. Typically, this is a product manager or business analyst. This means that they can make decisions you may not agree with, but so what? They also make decisions that product developers may disagree with; why should it be any different for information developers?

So, if the product manager insists on including text such as “the system knows that you are logged on”, you can advise against it, but ultimately it is not your decision.

The question behind the question
This question is actually a cover for the real question that managers want to ask:
Who is responsible for the quality and accuracy of the documentation so that we know who to blame if there is a screwup?

There is no simple answer to that question. However, because the principles that apply to product development also apply to information development, we can restate the question as:
Who is responsible for the quality and accuracy of the product so that we know who to blame if there is a screwup?

And the answer to that question is: everyone is responsible: development, QA, documentation,  product management, and so on. The danger, of course, is that if everyone is responsible, no one is.

The only solution is to be as proactive as possible in discovering and destroying all potential problems. Although development should make the documentation department aware of all changes, we cannot assume that they will. Therefore, we should, if possible, proactively review the current version of the product to see if there are changes. You would be amazed what you discover accidentally.

Now, often there may not be the time to review the product, especially if it is large and complex. However, if you can discover changes without relying on others, you will greatly increase your value as a technical communicator. You will gain a reputation as as a “fixer” who solves problems before they start. If everyone in a company relied less on others, the quality of the product would improve, because more defects would be found and fixed.

So returning to the original question: who owns the documentation? Although the technical writer can technically answer: it depends what you mean by “own”, this answer will not get us far in the business world. The better answer is as: as much as we can, we own the documentation.

Documentation has value. If we don’t own it, we have no value.

And if have no value, we have no worth to a company.

A Technical Communication Occupation

The Occupy Movement hurtles towards its expected demise. With the Occupiers (a.k.a. urban campers) now evicted from their various parks, this movement is headed the way of the hippies. As New York City mayor Bloomberg eloquently stated: “Protesters have had two months to occupy the park with tents and sleeping bags. Now they will have to occupy the space with the power of their arguments.” What they shall they do to occupy their time?

Has the Occupy movement had any effect? As the Premier of China said when asked in the 1970s about the effect of the French Revolution 100 years prior: “It is too soon to tell.”

Still, there’s lessons to be learned from this movement for technical communicators:

Lesson #1: No leader, no way

Without a leader, a group cannot succeed. The Occupy movement prided itself on having no leader, thereby laboriously deciding everything by committee. Everyone was a leader, so no one was leading. A group with no leader has no future, because there is no one with the vision, authority and responsibility to move the group toward its goals.

That is why every documentation team must have a leader, someone who can guide, enhance and develop the group. With no leader, there is no place for the group to go but off into the various directions each communicator wants to take it. With no leader, there is no way.

Lesson #2: Pursue clarity

The Occupiers had too many demands, and the ones they had were vague, among others: a redistribution of wealth, the restructuring or elimination of capitalism, world peace, a change in the system of government, and protecting the environment. Exactly what the protestors thought each of these entailed and exactly how they were to be implemented is not clear.

Clarity is the essence of effective technical communication. If your documentation is not clear, then you are not clear. If you cannot explain to a stranger a topic you have written, then you are a stranger to clarity.

Go clear, or, like the occupiers, go home.

Lesson #3: Ask Hard Questions

When evaluating news stories such as this, we must do what technical communicators do best: ask what the real, practical effects are.

Regarding the recent evictions, there were only two possibilities before they occurred:

  1. The occupiers would all be evicted, destroying or least severely weakening the movement. Without a physical presence, there is no mental presence. This is exactly what is happening.
  2. The occupiers would be allowed to stay. If this had happened, then the worst thing that could have happened to the movement would have happened: the public would have become used to it. When people get use to something, they forget it, until the NBT (Next Big Thing) comes along.

Now, when evaluating the contents of the document and the document management process, we must ask the same hard questions:

  • Does this make sense?
  • What is the practical value here?
  • What are the logical outcomes of the various choices we can make?

 When evaluating the contents of a document, we ask:

  • What does this contribute to others?
  • Is there a better way to express this?
  • What is missing here?
  • Is anyone really going to care about this?

Similar tough questions need to be asked when looking at the process by which the documentation is created, reviewed, updated and managed:

  • Is there a better way?
  • How can we manage this document more effectively?
  • What are our options, and what is the potential outcome of each?

Companies often fall into a trap of producing poor documents or having poor documentation processes. Their response is often: “That’s how we’ve always done it,” to which our response should be: “Well then, you have always done it wrong.” Another excuse is: “That’s how other groups do it,” to which we respond: “Those other groups are also wrong.”

To effect change, you need to have COP: Creativity, Objectivity, and Perseverance. Specifically, the only way to bring about change in a document or the documentation development process is to be (in this order):

  • ruthlessly objective of the current state
  • incredibly creative when offering the solution
  • mercilessly persistent in actually fixing it

About one in a hundred technical communicators have these three traits.

Are you one of the 1%?

A Note on the New Notes

Related imageWhen not wanting to pay cash, we “put it on plastic”. In Canada, plastic will soon be the only choice, as our paper bills are replaced by polymer ones.

The new polymer bills, to be rolled out over the next few years, contain a number of security features to inhibit counterfeiting. These features include clear panels, metallic images and hidden numbers that appear when the bill is held up to a light.

Because the bills are made of polymer, they will last longer than paper bills. They should also survive being accidentally washed if you forget to take them out of your pocket, giving new meaning to the term “money laundering”.

The Bank of Canada (like all agencies that produce money) plays a constant cat-and-mouse game with counterfeiters. They release new versions of cash, the counterfeiters figure out how to duplicate them, and the cycle continues.

Paradoxically, government agents specializing in spotting counterfeit money don’t usually study it. Instead, they intensely study real money, so that when a counterfeit bill appears, the agent can easily spot it.

Counterfeit docs exists in our profession. These may be legitimate documents included in a product, but are nonetheless forgeries because they:

  • contain errors
  • are missing critical information
  • are unclear or difficult to understand

Studying counterfeit documentation will not make you a better writer. It will only teach you how to be a poor one.

Studying legitimate documentation that is well-written, clear, simple, accurate and easy to understand and navigate might.

How do you like them Apples?

Image result for Steve Jobs logo

The world is mourning the death of Steve Jobs, founder of Apple. He has been hailed, quite rightly, as a creative genius, a brilliant and revolutionary designer, and a bold visionary who completely transformed the world of personal technology. (Full disclosure – my first computer was an Apple IIc, way back in 1985. It was also my last.)

As brilliant as Jobs was, he was also stubborn, arrogant, and an extremely demanding perfectionist who was openly abusive towards his employees. In fact, his arrogance and hubris probably killed him. He refused medical treatment for nine months, insisting on treating his cancer with diet, acupuncture, herbal remedies and a psychic. This delay most likely shortened his life.

Jobs was influenced by Buddhism, which explores the connection between mind, body, and soul. Given how cruel he could be to others, and his frequent violent rages, one could say he had a “cancer of the soul”. Buddhism suggests that a disease of the soul can morph into a disease of the body. It’s a medical fact that some diseases have a psychological basis. Whether this was the case for Jobs, we will never know, for he now resides in the iCloud.

(Speaking of life and death, we now know why Apple devices don’t have an on-off switch. Jobs felt that an off switch represented death. It symbolized for him the terrifying prospect that we’re all machines that simply “power off” at the end of our lives.)

These observations are not meant to criticize or judge, but to point out that no-one is perfect, and that there is more to a person than their technical abilities.

An Untechnical Communicator
A technical communicator may be a technical genius, like Jobs. They may have extensive experience managing a wide variety of complex documentation, thorough knowledge of all the major tools, and can speak twelve languages, human and computer. But if that person comes across as arrogant, obnoxious, highly critical of others and emotionally unintelligent, they will not succeed at job interviews. Even if they do land a job, they may have a tough time keeping it. Jobs himself was fired from Apple, and it was a long road back for him to regain control.

I’ve had the misfortune of knowing a few individuals like these. In the end, they either change or they go, or else every who works for them goes!

All of this means that you can win a job in an interview even if you are not the most technically qualified. The truth is that most software apps can be learned in about a week or two. The more difficult skills to acquire are non-technical:

  • interviewing and listening
  • working well with others
  • oral communication/public speaking
  • time and project management
  • negotiating
  • teaching
  • planning
  • objectivity, seeing the “big picture”
  • being open to criticism
  • handling change, conflict and stress
  • creativity, flexibility and adaptability

If you can show that you have these skills, and a genuine passion for the job, this will greatly increase your chances of getting it.

Research? We don’t need no stinkin’ research!
It’s interesting to note that Apple conducted no market research – no focus groups, no interviewing, no surveys – nothing. They simply designed products that they thought were cool and useful, then unleashed them on the public.

This seems to contradict to one of the tenets of our profession: to actively design with the end user in mind based on their needs and wants. Presumably, this involves working directly with our readers and having them test our documentation to see if it’s useful.

The problem is that we often don’t have the resources to do this. The good news is that we don’t have to, for reasons that are similar to those at Apple.

Users ‘R Us
The fact is – we are users. We should have a good idea of the kinds of information our users want, and the way it should be presented.

When you need information, you want it to be clear, understandable, and easy to find and use. That is precisely what our users want.

Jobs believed it was meaningless to ask customers what they wanted because they didn’t know what they wanted! This was true because the products Apple created were so different from anything that the users had previously experienced. How could users be asked about something for which they had no form of reference?

In many cases, our customers may not know exactly what information they are looking for. The example I always like to give involves the mail merge process.

That Mail Merge Thingamabob
If you were documenting the mail merge process for a novice user who had never even heard of it, you couldn’t simply create a topic called Mail Merging, with a corresponding mail merging index entry. Instead, you’d need to think about all the ways a user could refer to what they want to do, and then frame the topic accordingly.

For example, you might title the topic: Creating Multiple Personalized Copies of Letters and Other Documents or Personalizing a Document that is Sent to Several People. Your index entries could include:

  • addressing one document to several people
  • copies of one document, customizing
  • customizing a document to be sent to several people
  • different names, entering on a document for several people
  • documents, individually addressing to several people
  • mailings, sending customized documents to several people
  • mass mailings, performing
  • multiple copies of a document, personalizing for each person
  • names, changing each on several copies of one document
  • personalizing one document sent to several people
  • sending one document to several people
  • single documents, changing the name on several copies of
  • specifying different names on several copies of one document

You should be able to develop an extensive list of index entries like this without having to ask the user first.

But take great care with each entry – because one bad Apple can ruin the whole bunch.


See the source imagePresident Obama recently proposed an intriguing solution to deal with his country’s ever-growing debt: a “failsafe” trigger. Here’s roughly how it would work: if the debt as a share of the economy (the debt-to-GDP ratio) does not drop below a certain ratio by a certain date, then spending cuts, tax increases, or both would automatically be implemented.

Politically, it’s a brilliant solution, as it transfer the onus of decision-making from the politicians to the bureaucrats, as they are forced to make the deep but necessary cuts to lower the debt, currently a nightmarish $14 trillion.

A failsafe system can be applied to any process. It is comprised of:

  1. a specific, measurable goal to be achieved
  2. a date or time period by which the goal must be met
  3. a specific, measurable action that will be taken if the goal is not met

A simple example is weight loss. For example, you could set a goal of losing 3 kg. in two weeks. If you fail to meet this goal, you would have to lower your intake by 300 calories, exercise an additional 30 minutes, or both. You would repeat this failsafe system until you have reached your ideal weight. Then comes the tough part: maintenance. A second failsafe system ensures you stay on track.

Could a failsafe system be developed for documentation? It could, if we can define a measurable goal. However, objectively measuring the quality of documentation can be difficult. To obtain an objective, measurable goal requires carefully observing a user interact with the documentation.

Some of the measurements of documentation could include:

  • the success rate at which the user finds the relevant topic
  • the length of time required for the user to find the relevant topic
  • the average rating given a topic by the users

Another measure could be the number of contacts (phone calls or emails) to technical support. This could be broken down further into:

  • contacts made due to incomplete or inaccurate documentation – for example, a procedure is missing or a field is not explained clearly
  • contacts to report specific documentation problems – this occurs when users give direct feedback on the documentation

After deciding what it is you are going to measure, you can then set a goal based on a specific date or time period, for example:

  • improving the success rate by 15% over the next 3 months
  • reducing the topic search time by 20% over 6 weeks
  • reducing technical support contacts by 10% by August 1

Finally, you need to select an “action item”. That is, what specific action will be taken if the goal is not met?

Ideally, the action would be be implementing a thorough review of the documentation (or portions of it) based on feedback from users or internal staff such as QA, Business Analysts, Product Managers, and so on.  This could include creating a “closed feedback loop” whereby users can directly comment on any topic; the results are then sent to the appropriate writer who will make the necessary changes.

Is this idealistic? Yes. Many technical communicators are already stretched to the limit, so asking them to set aside time to improve their existing documentation is not always realistic. However, for those who are fortunate enough to implement such a failsafe system, the end result is documentation set that actually saves a company money.

The Medium is The Messenger

Related imageKudos to Kik Messenger, a new messaging app for smartphones, with a twist. It tells the user when a message has been sent, delivered, read, and even when the other user is responding. In doing so, it converts regular text messaging into real-time conversations.

It runs on all types of smartphones: Blackberry, iPhone, iPad and Android.

And it’s free.

(No – I have not been paid by Kik to say this – I own a dumbphone, not a smartphone.)

The technology behind this app is not new: it’s similar to Blackberry’s messaging software. However, not everyone owns a Blackberry – something Kik’s creators realized and took advantage of.

These new messaging apps are excellent examples of what I call meta-info apps. Meta-info is information about information. Sending a piece of information (such as a text) is one thing; getting information about that information’s delivery, reception, content and response is quite another. It adds a whole new layer of complexity and value to the original information.

In this case, the original information we are dealing with is quite simple: a text message. But what would happen if you applied meta-info technology to a user guide?

The result could be an online user guide with meta-info that could be visible to the author or the public such as:

  • the number of people who have read (or are currently reading) a particular topic
  • the search terms the user entered to find a topic
  • how much time the user spends reading a topic
  • a ranking of the quality of a topic; that is, whether the topic was useful
  • notes or comments from readers about a topic
  • an overall rating of the entire guide and its ranking compared to other guides

Can you even begin to imagine how valuable this information would be in helping to improve the contents of the guide?

Some of this feedback technology exists today, but most guides are still in the old flat, one-way format. A document is delivered to the user, and it’s the last we see or hear of it. Documents using meta-info, or meta-documentation take information to the next level.

Meta-info is here to stay. Kik Messenger has been downloaded over two million times in the past three weeks.

How many users have “downloaded” your documents? The fact that most of us cannot answer this question raises many more questions.

You Lift Me Up

Related imageThe Marriott Marquis is one of the busiest hotels in New York, but it had a big problem. With so many visitors and guests, the wait for an elevator was painfully long.

To add more elevators would have been very expensive and messy, because the building itself would have to be ripped apart. So instead of adding elevators, Marriot made their elevators more intelligent by implementing a new elevator control system called destination dispatch.

Under this new system, instead of choosing your floor in the elevator, you enter your floor number outside the elevator using a keypad located in the elevator lobby. The display on the keypad then tells you which elevator to board, for example, Elevator A. As you step into the clearly labeled elevator, your destination floor number is displayed near the elevator to confirm your floor. You simply enter the elevator (which no longer needs its own floor buttons) and travel to your floor.

Before this system was introduced, the elevator control system did not know where people were going until after they boarded the elevator. Now, when passengers enter their floor number on the keypad before they board, the system uses totally different formulas to control which elevator should be used.

The system takes the information from each of the waiting passengers, and groups people together who are going to common destinations on the same car, minimizing the number of stops. This has reduced elevator travel times, and improved the capacity of the system by 30%.

The only downside to this system is that some people may feel they are losing control, because they are unable to select their floor once they have boarded the elevator. However, like with any new technology, it can take some getting used to, and the benefit of a faster ride clearly outweighs any old habits.

Destination dispatch is a marvelous example of using creative thinking to an age-old problem. However, it’s more than that – it’s actually an application of a basic information development principle to the physical world.

Before a user reaches their “final destination” in a document (the specific topic they are looking for), they will usually have been directed to it in one of three ways:

  • using a search function
  • using an index
  • using a table of contents

Each of these methods correspond to the destination keypad of the elevator system. The reader first enters or looks up where they want to go (the specific topic), and then actually go to that topic by following the resulting link.

A reader arriving at an incorrect topic is like the elevator user who enters an incorrect floor on the keypad. However, in the case of the keypad, it is user error. With the document, it is more likely the author’s error.

This is why it is absolutely critical that the indices and tables of contents you develop are explicitly clear, otherwise they will send users to the wrong topics.

Who knew indices and tables of contents could be such a ride?

Information and Other Risky Business

Related imageThose of you who perceive information management as a rather dry affair should examine the strange case of Gabriella Nagy.

Ms. Nagy had a cellphone plan with Rogers. Her husband subscribed to Rogers TV cable service, and decided to add Internet and home phone services. “No problem,” said Rogers, who were only too happy to oblige. “In fact, we see that your wife already has a cellphone plan, so to save you money (and make things more efficient), we’re going to bundle your cellphone, TV and cable services under one account, and send you one big, juicy consolidated bill!”

Some time later, the husband received the first invoice, which included a detailed listing of all his wife’s calls. “That’s strange,” he noticed while perusing the listing, “there seems to be several rather long phone calls to one number.” He called the number, and discovered, much to his dismay, that it belonged to a man who was having an affair with the husband’s wife. (The man having the affair was also married.)

After discovering the affair, the husband promptly left his wife, who became so depressed that she lost her job. In May of 2010, she sued Rogers for $600,00 for breach of privacy, claiming that their invoicing process ruined her marriage and destroyed her life.

In informational design and management terms, this occurrence is sometimes referred to as an “oops”.

It’s hard to know where to begin with all this. On the one hand, Rogers could have taken more care to advise Nagy that her account was about to be consolidated with another, resulting in a shared bill. On the other hand, to blame a communications company for a failed marriage is quite a stretch. Where would the lawsuits end? What about someone who simply uses a cellphone to yell obscenities at another person? Is the cellphone company liable for providing the medium for the message?

This case is similar to one faced by an airline years ago. To promote business, the airline offered a “fly your spouse for free” program. Loving husbands could take their wives on dream vacations, at no extra cost for the second ticket.

The program was quite successful, and being good corporate citizens, the airlines sent thank you letters to all the couples who participated: letters that many of the wives would open (since it was addressed to them and their husband) and read, and who would then wonder aloud: “Gee, I don’t remember flying recently with my husband.” For it turns out that many husbands did not travel with their wives, but with other assorted female companions.


Information development and delivery, much like life, is a balance between security and convenience. The moment you create information, you are also creating risk:

  • risk that the information is incorrect
  • risk that the user will not interpret the information correctly
  • risk that you are exposing the user to information that they should not be exposed to

However, should you decide not to include the information, you are taking another risk: that you have withheld information that the user really did require.

There is no school, no program, and no teacher who can instruct you on how to always strike the right balance. Each instance has to be judged on its merits. Whether Rogers or the wife acted immorally is irrelevant. The fact is they are now both embroiled in a costly and very public legal battle. Many other philandering cellphone users are now quite worried that they will be exposed.

When her family’s accounts were bundled, a simple automated email sent to Ms. Nagy could have saved her (and Rogers) much grief:

Dear Ms. Nagy:

Please be advised that your household has requested additional services. These will be bundled under one invoice, which will include a detailed list of your calls. However, if you would like this list to be mailed separately to you, please call us within the next 7 business days so that we can update our mailing records.

(This should keep you out of trouble with your husband as you pursue your illicit affair with your hot lover, whom we have been tracking in real time. However, for a nominal “filtering fee” of only $499, we with withhold this information from your husband.)

Better still, there should have been an opt-in option to have her call details included in the master bill. If no action was taken, the call details list would continue to be sent to her directly.

Yes, Ms. Nagy is ultimately responsible for her downfall. However, Rogers and all those who create and disseminate information also have a responsibility to avoid informational disasters such as these by striking the right balance between disclosing and screening out sensitive information.

The Thrill of "Top Kill"

Image result for british petroleum logoBritish Petroleum (BP), responsible for the worst oil spill in U.S. history, should be given an award. Not for their oil drilling abilities (which one could fairly say are a tad below par), but on their naming abilities.

Specifically, whoever coined the term top kill to describe their latest failed effort to plug the ruptured oil line is a genius. It beautifully and succinctly describes an incredibly complex process.

Technical communicators are often asked to name things, specifically fields and other elements in a user interface. Giving objects clear, simple and self-descriptive names is often quite a challenge.

As an example, several months ago I reviewed the interface of a file migration utility. This application migrates files of one type into another. The interface consists of just one large dialog box. The user enter various parameters, then clicks a button to start the process. The question is: what should the button label be?

Initially, this button was simply labeled Go, but that’s not very self-descriptive, is it? Also, Go only has two letters, making the button rather small in stature. The label I suggested, and which was implemented, was: Start migration. It’s not as sexy as Top Kill, but it does the job.