Essay Online

OVERVIEW

Most product documentation sounds like their product is the only thing in the User’s life. Such thinking results in User confusion and dissatisfaction. This article presents three real-life examples of this attitude, and what should be done to remedy these unfortunate situations. The article concludes with some techniques for the writer.

BACKGROUND

There are two important facts that User Documentation ignores:

1. Your product is a only minor item in your User’s life

2. Your User Documentation must help fit your product into the User’s life

User Documentation that is written with awareness of these facts results in a better user experience. Here are three examples of where the writers (always incorrectly) thought that their product was the only thing in the User’s life.

EXAMPLE 1: Shoe Cleaner/Protector

Most people know about polishing and perhaps cleaning their leather shoes. This cleaner/protector product is meant to clean, protect and shine shoes. The instructions simply tell the User how to apply the product.

What the User is Used to: I polish my shoes with regular wax (or liquid) shoe polish.

The Problem: If a User wants to polish his/her shoes as well as use your cleaner/protector, then what order should the polish and the cleaner/protector be used? The instructions merely tell the User how to apply the cleaner/protector. It’s like the cleaner/protector is the only shoe product in existence.

Possible Solutions: The the cleaner/protector instructions could say (as appropriate):

* Use the cleaner/protector instead of your normal shoe polish.

* Use the cleaner/protector after you polish the shoes with your regular shoe polish.

* For a deluxe shoe treatment, use the cleaner/protector first on the shoes. Wait a few minutes, then wipe off any excess with a clean cloth. Then polish the shoes using your regular shoe polish, in the usual way. Finally, use the cleaner/protector again, but do not wipe it off.

These would make for much more effective instructions, and they could easily fit on the package.

EXAMPLE 2: DVD Player didn’t realize that I had a VCR

People buying a DVD player a few years ago were in the following situation. They had a VCR connected to the single video input of their TV. DVD players’ instructions described how to connect the player to a TV using a video input. The instructions ignored the situation of how to connect the player if there already was a VCR connected to the TV ’s only video input.

What the User is Used to: The VCR is connected to the only video input of my old television.

The Problem: My new DVD player needs to be connected to the TV’s only video input. Do I have to buy a switch or manually switch the DVD player and VCR?

Solution: The writer should provide some tips or instructions how to set up the DVD player in the customer’s real-life situation. These instructions may include how to connect the DVD video through the VCR. Or connecting the DVD to the TV’s video input, and connecting the antenna of the VCR to the antenna input of the TV. Both devices can be connected with no need to buy additional parts. The instructions should mention how. It would improve the User’s experience in setting up the new device. (The instructions should also mention that these methods of connecting the devices would yield a less than optimal picture.)

EXAMPLE 3: A 2 in 1 Shampoo and Conditioner Product

A User normally shampoos his/her hair and then may use a separate conditioner product. He/she just purchased your product, a 2 in 1 shampoo and conditioner. It has no instructions.

What the User is Used to: A shampoo is used on the hair and immediately rinsed. A conditioner gets left in the hair for a few minutes, then rinsed.

The Problem: Does this 2 in 1 product get left in the hair, or does it get rinsed out immediately?

The Solution: Provide correct instructions on the package. Or, if it does not matter how long the 2 in 1 product gets left in the hair, then say so. Don’t leave the User guessing. If the User wanted to guess about something, then they would be reading a novel, not your User Documentation.

BOTTOM LINE: What to Do for Your Documentation

Examine your product in the light of how it will change the way that the User currently does things. How will it fit into the User’s life? How does the product fit with other products your User employs?

Make sure that your User Documentation helps the User to effectively fit the product into his/her life. By ignoring the reality of your User’s situation, you are forcing him/her to solve problems that you could easily solve. If you provide the solutions, then you will create a better product experience for your User.

Fitting the product into the User’s life presents the writer with a duty and an opportunity:

* The duty to ease the User from what he/she previously did to the new product’s situation

* The opportunity to explain your product by using the User’s experience as a background.

OVERVIEW

To create an effective User Document, the writer must know who he/she is writing for. This article presents four dimensions (Skills, Attitude, Knowledge and Experience) for describing the User of your product (your Documentation Reader), and how to build a Persona that turns your generic User into an almost-real person. The article stresses the need to actually USE this information when structuring and writing your User Document.

GETTING INFORMATION ABOUT YOUR USER

The marketing department or product development team should be able to tell you who the intended User of the product is. (If they cannot, then the product is in big trouble.) Ask them to provide you with a complete description of the User. Ask them if their description can be make less strict (requiring fewer skills, ect.) and thus be applicable for a wider audience. Ask them how sure they are of their intended Users.

Ask them if they created a “Persona” (see below) to design the product. If so, ask them for the description of that Persona.

We will use this information to analyze your User in four dimensions. We will then re-build the ideal User into an almost-real person, who you can use to help design and write your User Document.

Timing: My estimate is that if the communication paths between you and the marketing and development teams are effective, then you should be able to complete this series of steps in a few hours spread over several days. This description of your User/Reader is an essential element in structuring and writing your User Document.

THE FOUR DIMENSIONS OF YOUR USER (Reader of your Document)

Four dimensions define your User/Reader. These dimensions are:

* Skills

What skills do you assume that your Reader must have in order to understand your User Document? (These are the skills that you assume that they have when they START to read your User Document… not the ones that you will teach them in the User Document.)

In a classic example of failure, a company that taught software programming did not specify that its students had to know how to use a particular computer word processor. As a result, students spent 80% of the class time learning how to use the word processor, rather than learning to write programs. The class was a failure.

List the skills that you expect your Reader to have.

* Attitude

Your Reader’s attitude is almost always a combination of anger (impatience at having to read this stuff instead of using the product), and fear (something is not working the way your Reader expects it to). Write with compassion for your Reader. Are there other attitudes that may affect how your Reader uses the product and your documentation?

* Knowledge

What information do you expect the Reader to have when they read your User Document? Is there something that you expect your readers to understand or to have to figure out for themselves? If there are such items, then you should tell your Reader where to get the needed background information.

* Experience

Skills plus practice, yields experience. Are there any experiences that you expect your Readers to have, so that they can understand how to use the product or understand what you are writing? BEWARE of your Readers’ experiences that may negatively affect how they use your product. One example is a product that radically changes the way that the User currently does things. Devote some space in your User Document to overcoming these problematic experiences.

WRITE FOR THE SAKE OF YOUR READER

These four dimensions spell out the word “SAKE.” This reminds us to write for the SAKE of our Readers. You use these four dimensions when generating the topics for your User Document, as well as reviewing the material that you have written. These are topics for other articles in this “New Technical Writer” series.

Make sure that you tell your Reader about any SAKE assumptions that you make about them. Thus if you assume them to have a special skill, such as “welding steel” then tell them your assumption early in the User Document. If possible, tell them where they can get the background SAKE items that they might need. For example, if you assumed that your Reader has the skill to identify a certain bird, then tell them were to learn to identify that bird (perhaps with a link or reference to a birding authority).

You want to avoid situations like the one in the example above: the unstated requirement for knowing a specific word processor that ruined a programming class. Is the assumption that everybody knew how to use that esoteric word processor a reasonable one? The course developers should have checked with their sales department, since they sold the course to students who could not possibly have known about that esoteric word processor.

You really must clearly state (early in your User Document) any out of the ordinary assumptions that you make about your Reader.

YOUR READER AS A REAL PERSON

From the SAKE dimensions, and from the descriptions of the typical User of the product that you got from the marketing or development teams, you will create a real-as-possible person to represent your typical User. Such a representation is called a Persona in the product development industry. The Persona is also your User Document Reader.

If the marketing and development teams use a Persona, and they provided a description to you, then use their Persona. You may have to add some description to it.

If you have to create a Persona, follow these steps (overview):

1. Imagine the generic User of your product.

2. Focus on this User. Describe the User. Think about his/her background, education, family, hobbies, interests. The goal is to make your generic User as tangible as possible.

3. Perhaps give the User a name, and even spend a minute or two to find a photograph of this Persona.

4. Evaluate for yourself if this Persona is a good representation of the User. Make changes as necessary.

Think about how the Persona got your product (for example, did they purchase it, did it come bundled with some other product, was it a gift, etc.). Think about what they are most likely to want to do with your product.

Later we will use the Persona to help define the topics of the User Document, and to help you write the actual text.

CHECK

Once you have generated the SAKE items and the Persona, write them out, and let members of the product and marketing teams check them for accuracy. “Accuracy” means “how closely your Persona coincides with their (product and marketing teams) view of the product’s User.” Discuss these points and make modifications as needed.

USING YOUR READER

Unfortunately most courses and books about technical writing stop here in their instructions about “knowing your Reader.” These courses and books expect you simply to keep your Reader in mind when you write.

But you can and should do much more with the description of your Reader. The Persona will help you structure the information in the overall User Document; it will also help you write each of the topics.

The SAKE dimensions will help you as you revise your writing. Here the SAKE dimensions will

* help you avoid using language your Reader might not understand, and

* help you avoid jumps in your writing that your Reader will not be able to make.

Other articles in the “New Technical Writer” series will describe how to use your Persona and SAKE dimensions to design and write your User Document. See the “Resources” or “Author Information” section of this article to find links to related articles.

Overview

Incomplete User Documents disappoint your Readers. Two attitudes of many Technical Writers result in incomplete User Documents. These two attitudes are:

. “Everyone Knows That”, and

. “The User Can Figure It Out”

This article describes these attitudes and presents methods for overcoming them. The result is more effective User Documents and more satisfied Users.

1. “Everyone Knows That”

The “Everyone Knows That” attitude makes assumptions about your Reader’s knowledge. These assumptions cause your Reader grief.

Here’s an example of a possible “Everyone Knows That.” Do you know this:

Tomatoes. Most of us keep them in a refrigerator. However, storing them in a refrigerator will ruin the taste and nutrition of tomatoes. Tomatoes should be stored on a kitchen counter at room temperature, until they are cut. Once cut, tomatoes should then be stored in the refrigerator.

Does everyone know that? What do you assume that everyone knows about your product?

Sometimes your User Documents have to overcome previous User experience. Everyone thinks that they know how to properly (safely) shut off a barbecue…they don’t! The safe shutdown method is described in most barbecue User Documents, but it is not “advertised” (forcefully presented) in the User Documents.

It’s rarely true that “Everyone Knows That”. Just because you find something to be obvious, it does not mean everyone knows that something.

Here’s another example: How do you use a (combined product — ‘2 in one’) shampoo and hair conditioner? When shampooing, the shampoo is massaged into the scalp and immediately rinsed. When conditioning the hair, the conditioner is massaged into the hair, and remains on the hair for about two minutes. Now, what do the Users do for the combined product: rinse quickly, or let the product remain in the hair?

If you have the “Everyone Knows That” attitude when you write, you will tend to leave out needed material from your User Document. You will be doing a disservice to your Readers, and to your writing.

When in doubt whether “everyone knows something,” assume that they do not. Then,

. add some text explaining the topic, or

. tell the Reader where to find information that will explain the topic

Another Caution

Be careful about assuming that just because you explained something earlier in your User Document, your Reader will remember (or even have read) that information. It is rare for Users to read product documentation from start to finish.

When in doubt, add a reference to that earlier (background) information. Tell your Reader where to find it, or provide a link to it if your document is electronic.

Here’s a Thought Experiment: You are a User of products: How often do you read the product documentation from start to finish? If you always do, then ask some other people. (The great thing about this fact — that Users do not read the documentation from start to finish — is that it results in great flexibility in writing, formatting and editing the product documentation.)

2. “The User Can Figure It Out”

The User does not want to have to figure things out. The User is not reading a mystery novel or any other literature, where he/she wants to think about what is happening.

When someone uses your product, they are using it to meet their own needs. Your product may be central to your life, but to your Users, your product is a means to an end. And they do not want to have to decipher your product documentation.

Here’s a simple example. An e-mail tells you to call someone, but the message leaves out the phone number. You are expected to find the phone number on your own. The writer probably knew the phone number, but left it out. This “information oversight” gets expensive within a company when the e-mail is sent to many employees…each looking up the phone number on his/her own.

My favorite pet peeve: dates. Within recent memory we “survived” the Year-2000 transition. Yet we still write dates sloppily. We use “06″ for a year, instead of “2006.” When we see things like “07/11/04″ what is the date it is referring to? Is it November 4, 2007, April 11, 2007, or some other permutation of the numbers. The standards for the format of dates vary around the world. This is an example of both assumptions:

. “everyone knows that” (because there is a “standard” date format — there is not), and

. “the User can figure it out” (by seeing if my other dates provide clues to the format)

Don’t leave things for the User/Reader to figure out for themselves. It takes you only a few moments to include the material your Reader needs, and will save many Readers many hours in figuring things out.

Do It:

The writing literature tells you to “know your Reader.” Here is where you use that knowledge to improve your writing.

Either

. find someone who is like your intended Reader, or

. “do your best” to act like your intended Reader (you can do it if you need to)

In reading and evaluating the document, look for places where

. the writing assumes that “everyone knows that”

. the writing expects the Reader to be able to “figure it out”

. the writing makes jumps that your Reader cannot follow

. the writing makes the assumption that the Reader has read and remembered the entire document

Fix these places. It only takes a few words or sentences.

Everyone will be happier.

OVERVIEW

For small companies, creating their product’s User Documentation in-house, provides benefits to the company, to (idle) staff, and to the product. This article describes the benefits and some downsides of producing User Documents in-house.

THREE OPTIONS

If you have no in-house writing staff you have three options:

1. No User Document for the product. This is NOT a valid option. Every product needs User Documentation. It completes your product package, and enhances the User’s experience with your product. Here are two examples of non-existent User Documentation:

* Tomatoes. Most people don’t know that before use, tomatoes should not be refrigerated. Refrigerating tomatoes before use will reduce their flavor and nutrition value.

* A Manual Can Opener. This can opener clamps on the can, thus the user does not have to squeeze the handles while operating the can opener. It came with no User Documentation, as “everyone could probably figure out how to use it.” This is wrong. After a few uses, the blades become slightly dulled, and the handles are very difficult to clamp and lock.

The simple tip of turning the knob while squeezing the handles makes the can opener easy to use. That tip could form the basis of a User Manual for the product. The manual should include instructions for care of the can opener. The absurd situation is that this clamp feature was the unique aspect of the product; but the feature becomes unusable because of no User Document.

How have you felt about products that came without User Documentation? Were you confused about the product and getting the most from it? User Documentation adds to the value of the product. Let’s look at how we can get it created.

2. Use an outside writing service or consultant. Technical writers may be an excellent choice to create your User Documentation. However, there may be downsides to using them.

* When documentation changes have to be made, the company has to re-hire the writer. If the writer were unavailable, then you have to wait or search for a new writer. When the new writer gets hired, a new orientation to the company and the project would have to start. Delays, delays, delays.

* An even more horrible thought is that the outside writer used some fancy piece of software to create the User Document, and you do not own that software. Thus you could not make any changes until you bought and learned that software, or hired an outside writer who uses the same software. (Most technical writers are enamored with a particular piece of esoteric writing software.)

Using the outside writer will force you to batch your documentation changes, making the literature out of date. (How many times have you seen product documentation that does not match the product? This happens because the company was waiting for the next major upgrade to update the User Documentation.)

3. Using idle employees in your company to create the User Documentation. The remainder of this article will focus on this option.

STAFFING BENEFITS

In most organizations, there is some staff down-time. By assigning these staff to create User Documents you benefit from effective use of this down-time, and the employees benefit from experience in a new field.

These staffing benefits include:

* Use staff who may be idle between projects

* Your staff know the company’s culture and their fellow staff

* Your staff use existing company-wide writing tools (your word processor)

* No time needed to get oriented with the physical aspects of the job

* You have created a new resource within company

BENEFITS TO YOUR USER DOCUMENTS

If you have in-house writers (even if they are not formally trained as “technical writers”) you can just say “Sue, could you or Tom update the document where the sign-in window is presented.” Much faster and more flexible then having to go to an outside source. Sue and Tom have ownership of the document, and would work to improve it. They would use software resources available in your organization.

The benefits of in-house writers to your User Documents include:

* You can make corrections as you find the errors.

* You are able to update your User Document when you update your product.

* Better control of timing and resources

* No fear in dealing with the User Document in electronic form. From your word processor or add-ins, you can publish your User Document as a portable data format (.pdf) file, or as HTML for display on the Internet.

DOWNSIDES OF IN-HOUSE WRITING

The primary downsides of in-house User Document creation are the attitude and emotions of your newly-appointed writer. These include:

* Fear (”I don’t know how to write”)

* Anger (”Why me? This is unfair”)

* Uncertainty (”I don’t know what to write”)

* Isolation (”I’ve been cast into this writing thing”)

You can reduce these negative emotions if you encourage and support your New Writer.

SUPPORT YOUR NEW WRITERS

It is unfair to assign a non-writer to create a User Document without supporting him/her. You have to support your writer with:

* Training;

* Access to the development and marketing teams for product information;

* Use of the development team to evaluate their writing (small chunks);

* Access to the product, industry literature, and marketing materials;

* Style manual;

* Editor — your writing expert;

* Time to do a good job.

Other articles in this series (see the links in the “Resources” or “About the Author” section of this article) present more information about supporting your New Writer.

OVERVIEW

A good User Document includes sections on how to set up, use, and care for the product. However, to create a great User Document , the technical writer should use the Persona, generated in the analysis of the User/Reader, to create the topics for the most useful section of the User Document. This article describes this procedure.

THE MOST USEFUL SECTION OF A USER DOCUMENT

The most useful section of a User Document is the one that helps the User get what he/she wants/needs done right now!

Writing such a section might seem to be an impossibility. How do you know what the User needs to do now?

The only thing that you, as a writer, can do is to play the odds. That is, determine the topics that have the highest probability of being of interest to your User. And “of interest” means “getting what the User wants done, right now.”

We created Persona (an almost-real representation of your product’s User) in another article in the “New Technical Writer” series (see the links in the “Resources” or “Author Information” section of this article). We can use the Persona to create a topic list for this section.

USING YOUR PERSONA

This step in using your Persona is missed by almost all User Documents that I have seen. Yet this step will result in a User Document that is most satisfying to your Reader. Here it is:

Imagine your Persona using your product. Now, what are the main things that your Persona will want to do with your product.

As an example we will use a photo editing program (Acme FotoPhixer, a hypothetical product from a hypothetical company) that comes bundled with a point and shoot digital camera. Our Persona is a typical user of such a camera.

Ask: What does that Persona want to do with Acme FotoPhixer?

The short answer is that they want to improve their photos. HOW can they improve their photos with Acme FotoPhixer? In OUR words (not the words of the User) we could tell them how to:

* Rotate

* Crop

* Red-eye removal

* Adjust brightness & contrast

* Removing unwanted items from the photo

* Focus/Blur

* Save

* Print

* Share

These names are what we, the photography experts might use. However, “crop” may be meaningless to our Persona. In fact, we could move crop into “Removing unwanted items from the photo.”

The “Focus/Blur” topic is interesting. If a photo is out of focus or blurred, there is really nothing that our software can do to improve it. However our Reader does not know this, but still wants to do it. We should include topic with this text: “It is impossible to fix the focus or remove blurring in a photograph. You might be able to improve this using the [Sharpen Effect] tool in FotoPhixer.” (The [] specifies a reference to the topic in the User Document.)

DON’T HIDE THIS SECTION

If your Reader cannot quickly find what he/she wants to do in your User Document, then the document has failed. Since we created this section to answer the User’s pressing needs for the product, then we must make this section very accessible to the User — they have to be able to find it easily.

“Fixing (Improving) Your Picture” is a PERFECT, User-oriented title. That is the correct title for this section. Don’t bury this gold under titles such as: “Tutorial” or “Use FotoPhixer’s Tools.” These titles do not suggest answers to the User’s questions.

You should make this section very easy to find in the User Document. It’s the key section of the User Document. It has the information that most Readers want, most of the time (by your analysis). Place it prominently in the User Document.

SATISFYING THE READER IS EASIER THAN YOU THINK

Producing this section is easier than you think.

First, imagine that you were NOT going to include this section. Your User Document would still have to cover all of the features, tools, and user interactions for the product. You need to do that to satisfy your boss. It’s also logical. If a feature is not described, then why is it in the product?

Thus you have created a topic list for a “classical” User Document.

Now we create our User-oriented section, “Fixing Your Picture.” Here are the steps:

1. List each of the topics for fixing a picture, using titles that the Reader will understand.

2. Provide a brief overview, perhaps with a picture showing before and after the use of this fixing method.

3. Then list the steps for that topic, and provide links to the documentation for the relevant tools for each step

Done!

Actually, I would recommend using what I call a “Visual Index,” which is described in the links in the “Resources” or “Author Information” section of this article.

Within Document Re-usability

We could call this organization method “within document re-usability.” Here the writing for a topic exists as an item in the “reference” section of the User Document. By referring to that item when it is needed for performing a User-oriented task, we make the text do double duty. This results in reusability within the document.

HOW TO GET THE TIME TO WRITE THIS SECTION

Put less detailed effort into the documentation for the product’s features that will be rarely used. For example, FotoPhixer includes tools to make the image look like it’s made of stone, or produce 3D effects, etc. These are rarely used, and have a similar set of controls. Instead of detailing the use of each of these rarely used features, write a global usage, describe the controls, encourage the User to experiment, and remind them of the un-do and cancel capabilities.

You can create the “most useful” section with the time you save by not thoroughly documenting these rarely-used items.

THE BOTTOM LINE

You can make your User Document much more effective if you think about your User/Reader and what he/she wants to do with the product. Use this information to create an easy to find section in your User Document that meets your Reader’s needs.

The User-Product Life Cycle (U-PLC) is a powerful tool for the User Document writer. Use the U-PLC to generate the high-level topics for your User Document.

THE USER-PRODUCT LIFE CYCLE (U-PLC)

Usually, when we think of a Product Life Cycle, we think in terms of the development and production of the Product itself. When writing User Documentation, consider the U-PLC to help you generate all the topics necessary for a complete document. User Documentation should support your Users in all of their interactions with the product.

The User-Product Life Cycle refers to the full range of interactions between the User and the Product itself. This is more than simply “how to use the product.” As you will see below, “Use the Product” is only one stage in the U-PLC.

STAGES IN THE U-PLC

Here are the stages IN the U-PLC (assuming that the User as acquired the Product):

– U-P LC Stage: Transport the Product to its working location

– U-P LC Stage: Unpack the Product

Transport and Unpacking of the product are listed here just for completeness. These are currently displayed on the packaging itself, usually in pictorial form, and do a good job.

– U-P LC Stage: Overall knowledge about the Product.

This is information that is presented to the User early in the User Documents.

Topics here include safety, legal, and disclaimers related to the product.

The description of the product should indicate how the product may change the way that the User currently does things. For example, an analog voice recorder will require the User to listen to all the stored items to find a particular one; a digital voice recorder will enable the User to quickly jump from one message to another.

– U-P LC Stage: Set up or Install the Product

* Environments

It is important for the writer to think of the various environments where the product will exist. For example, how should a computer program be installed in a Windows, Mac, or Linux environment?

“Environments” includes other things that the product must work with. For example, how should a DVD player be installed in a system currently composed of a TV and a VCR? How about installation to a TV & VCR system where the TV has only one video input?

* User Capabilities.

The capabilities required for the User to set up the product are also important. Since the assumptions related to the User for set up may be different from the assumptions about the User in using the product, the wise writer will present the skills (and perhaps regulations) needed to set up the product. A section entitled “Can You Set Up This Product?” will enable the User to make the decision about whether to set the product up themselves, or find outside help.

For example, suppose the product is an electrical light dimmer that is intended to replace the light switch in the User’s home. Using the product merely requires adjusting the dimmer’s single control to set the desired light level. Installing the product requires experience with home electrical wiring–does the User have these capabilities?

Sometimes, the limitation may be legal. In some jurisdictions — Quebec, Canada, for example — only qualified electricians are permitted to install or modify electrical circuits in the home. Thus in Quebec, the general User of the dimmer will not be able to (legally) install the light dimmer.

– U-P LC Stage: Use the Product

This component is the focus of most User Documentation. It should contain at least these three sub-topics:

- Starting the product

- Actual Use of the product

For most products “Actual Use” is the central focus of the User Document.

Ideally, this should be divided into basic or common product functions, and advanced functions. A good example is photo-editing software. Most Users want to crop, rotate, and adjust the brightness and contrast of the image. These are basic functions. More advanced functions might be combining the parts of one picture with another.

- Shutting down the product

Is there any maintenance to be done at shut down? List it here and in the “Maintain” section.

– U-P LC Stage: Maintain the Product

Consider breaking this down into time periods, such as: after each use, weekly, monthly, yearly, as applicable.

– U-P LC Stage: Move the Product

For a computer software program, how the User should move the program and its data to another computer; computer users often upgrade their computer hardware. While it is often assumed that the User should re-install the product on the new computer, there always is the question about moving the data related to the product: where is it located, and how should it be moved so the newly-installed program can recognize it on the new computer?

For a physical product, are there any special considerations in moving the Product to another location?

– U-P LC Stage: Discard the Product or its By-Products

Here I would like to mention only selling the used product. It might be wise to mention that by keeping the User Manual, the seller may find it easier to sell, and possibly get a higher price, for the used product.

USING THE U-PLC IN YOUR WRITING

As you generate the topics for your User Document make sure that you keep the U-PLC in mind. Ensure that you include topics in your User Document Outline to assist your User in all phases of the U-PLC.

Great User Documents can assist in the UP-LC section that I did not present here: acquisition of the product. Your marketing department may be able to use your GREAT User Document as part of its marketing campaign.