Our unpredictable users

If 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.

Read More

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.

Read More