Monday, November 5, 2007

Campbell - Chapter 10 - But That’s Not the Way We’ve Always Done It

Writing Effective Policies and Procedures: A Step-By-Step Resource for Clear Communication

Nancy J. Campbell

Chapter 10 – But That’s Not the Way We’ve Always Done It

Introduction

Despite all your hard work and effort, it’s important to recognize that new policies and procedures often invite resistance.

Don’t Give Up

Change is hard and takes time to process, so start at the beginning and try to avoid getting discouraged.

Dealing With Resistance

Most resistance to change stems from fear. There are many different types of fear. There are also six basic steps that you can take to help users manage the change.

  1. Involve
  2. Explain
  3. Listen
  4. Enforce
  5. Reinforce
  6. Evaluate

Early Communication

Always remember that early communication reduces later resistance. Involving users upfront is the best way to combat negativity. It is better to begin with involvement then to end with it.

Early Detection

Often your users may have been through a similar situation and think it will either fade away or end up to their disadvantage. Use open, honest communication to help address these concerns. Early detection also identifies the biggest resisters, so you’ll know with whom you’ll need to take a firm stand.

Advance Preparation

Consistently involving users in the development process gives them more time and knowledge with which to work through the issues, generally resulting in more cooperative behavior. Forewarned is forearmed.

Continuing Education

Running ideas by users and keeping them updated as to the status of the project will help them to remain stay involved and prevent the process from losing steam. This constant communication with users strengthens your final product.

Final Notice

As long as you have communicated and educated your users continuously throughout the development process, the final notice shouldn’t come as a shock. By acknowledging sensitive issues and honing your listening skills, you can demonstrate respect for their viewpoints. You can also mobilize cooperative users to help encourage wider acceptance of new policies and procedures.

Grace Periods

Grace periods allow for a more gradual transition between the old way of doing things and the new. These are especially useful in cases where there is strong resistance. They provide additional preparation time before full enforcement of the new rules.

How to Use a Grace Period

Using a series of notices helps to keep everyone informed as the date of full enforcement approaches. The first notice might inform users of the impending changes, and state that the rules will be enforced informally for a period of time. The second notice warns of the deadline for full enforcement. The third reminder states that the new rules are in full effect and the disciplinary consequences for breaking them.

Delivering Bad News

When a new policy or procedure is simply downright unpopular, continuous communication throughout the development process remains even more crucial. There are two very important strategies for delivering the bad news.

Preempting

Identify the likely objections that will be raised and begin the communication process by addressing those issues first.

Taking the Heat

It is important that those who enact new policies and procedures take responsibility for them and can defend their position. Again, patience and receptivity is key.

Here Comes Trouble

There are several perceptions that a new policy or procedure may invoke in users that are guaranteed to cause trouble. These include:

  • Unfairness
  • Negativity
  • Hypocrisy
  • Pointlessness
  • Unworkableness
  • Restrictiveness

When the Writer Is the Resister

If you as a writer have objections to a policy or procedure, be sure to deal with your own concerns in the same thoughtful, level-headed way that you would deal with users’. One way is to write down your concerns and frustrations, then write down the reasons for the new rules and the circumstances that are driving them. Be gracious and professional and abide by the organization’s rules.

Conclusion

Campbell concludes her chapter with a summary of its content, and several tools and resources. These include a tip sheet for overcoming resistance, guidelines for delivering bad news, guidelines for generating receptivity, and guidelines on resistance factors.

Robert R. Johnson - Audience Involved: Towards a Participatory Model of Writing

Audience Involved: Towards a Participatory Model of Writing

Robert R. Johnson

Introduction

Johnson begins his article by describing four ways in which technical communicators have responded to criticism that their pedagogy is based solely on the “unreflective use of formats”. These include increased attention to audience, invention, visual meaning, and ethics. Unfortunately, Johnson feels that in developing these ideas, technical communicators have borrowed theory from other disciplines while offering few contributions of their own. By exploring technical communicators’ unique relationship with their users, Johnson hopes to challenge general composition and rhetorical studies with a more reciprocal and participatory model of writing.

Writers and the Hegemony of Authority

The creation of discourse has changed from an individual model to a community model in recent years. This community model can be divided into two common sub-models. The first of these involves a writing process in which a single author produces a text with the planning and revision assistance of a group. The second sub-model involves “plural authors, singular text”, in which multiple authors collaborate throughout the entire production process to produce a single document. Missing from these models of collaboration is a discussion of audience. Historically, audiences have been viewed as either “addressed” – an external object to be acted upon by the text, or “invoked” – a fictional construct of the author’s imagination. Johnson argues for a conception of the “involved” audience, in which the audience participates directly in the production process. His discussion is informed by both the history of technology, and the history of rhetoric.

Technological Knowledge: Some History and Definitions

Technological knowledge can be defined in two ways. The first involves the history of technology, and includes models of technological determinism, science versus technology, and the social construction of technology. The second is grounded in the discipline of rhetoric, where technological knowledge can be categorized as a productive knowledge or art. Under this model, the effectiveness and quality of a product, such as an instructional document, is dependent upon the judgment of the users.

Usability: An Overview

Johnson defines usability as “part of an iterative process that allows users to provide feedback during the conceptual, design and production stages of a product’s developemnt. Usability is beneficial to technical communicators in that it argues for their early inclusion in the development process, helps them to assume a role on the development team (rather than being viewed merely as “scribes who ‘write up’ technical information”), and allows the writers to effectively implement user knowledge into the development process.

Users and Usability Specialists: How They Work Together

Here, Johnson presents two scenarios in which usability specialists collaborated with users to produce improved texts, which he defines as “virtually any symbolic representation that enables humans to interact with technological artifacts”.

In the first scenario, Johnson describes a classroom assignment in which he instructed his students to develop improved documentation for the university’s new voicemail system, which was very poorly documented. Working in teams, the students administered surveys, questionnaires, and interviews to targeted users. This resulted in an impressive amount of feedback. In analyzing this data, it seemed that the situation involved two different forms of knowledge: the knowledge of the developers and the knowledge of the users. Developers viewed the system with a “highly rational, hierarchical view”, while users inhabited a different knowledge space, in which their focus was limited to the object before them and the ways in which they needed to use it. It became the duty of the technical communicators to bridge this gap. The vendor of the phone system was so intrigued by the outcome of this user-writer collaboration that they sent representatives to the university to meet with the students involved in the project.

The second scenario Johnson describes involves usability testing of a computerized interview scheduling system. The graduate students involved in the project made use of “low-fidelity prototyping”, in which a mock-up of the proposed interface is fashioned from paper cut-outs. During a prototyping session, one of the students would play the role of the computer as the student interacted with the subject, manipulating user interface elements in response to the user’s input. This process helped to identify the most intuitive user interface design. Johnson describes this as a “turning of the tables”, that puts “the burden of production on the ingenuity of the programmers to create a usable system”.

Conclusion

Involving users in usability evaluation and testing can help technical communicators make design decisions. It may also foster increased user-awareness among system developers. Creating effective systems requires that users be allowed to participate along with writers and developers in the production process.

This involved audience model also has ramifications for the wider field of composition studies. Involving an intended audience in the writing process can have interesting effects on a writer’s conception of what they are producing. Johnson lists several ideas for activities and experiments that would bring the audience into the composition classroom. The learning potential under such an arrangement is endless.

Sunday, November 4, 2007

Barker Chapter 10

Designing for Task Orientation

In this chapter Barker discusses the importance of designing a manual and what to look for and what to include and where. He starts the chapter by talking about the table of contents. The table of contents creates an outline for the manual and should be easy to use, he states the following guidelines for creating a table of contents:

1. Create the table of contents
2. Match the user analysis with information design strategies
3. acknowledge production constraints in document design
4. test and review the design
5. follow a design process for online help

The next important topic Barker discusses is matching the user with the manual. What he means by this is knowing what the purpose for the manual is. He explains it as designing for different groups and to consider the following the elements:
  • Navigational aids: make sure the user groups get to the information pertinent to their needs.
  • Scenarios: give each group a role model, examples of usage help users identify themselves and their main workplace activities.
  • Icons: identify information for each group. They are eye catching and direct them to shortcuts.
  • Metaphors: make implicit relationships to the workplace explicit so users can see and feel like the document is familiar to them.
He also talks about designing for specific program issues, this helps the user meet the difficulties identified, Barker says to design your documentation to include:
  • Job performance aids: cover technically difficult or repetitive tasks. Usually stand alone documents.
  • Background information: this helps the users feel like you’re making sure they don’t fly blind.
  • Special forms: tear-out forms or printable documents can help users collect information in the field for later inclusion into the document.
It is also important to meet the user’s tasks needs, the following helps the user to do things:
  • Illustrations: show photographs, drawing, or clip art of users performing familiar tasks.
  • Layout design: make the document fit the user’s desktop.
  • Examples of usage: Include introductions explaining examples of use of the program.
  • Special document sections: Provide a “getting started” section with three or four useful examples.
  • Tips: include performance-oriented elaborations and introductions.
Meet the user’s information needs:
  • Explanations: explain why file naming and directory structuring of program files can help retrieve reports and files.
  • Examples: show program data imported into a word processing or database program.
  • Meet efficiency goals/command summaries for efficiency. provide shortcuts, quick-key combinations.
  • Problem Solving: encourage problem solving by suggesting options, encouraging creative solutions and thought-provoking problems.
  • Emphasis on information management and communication work: identify functions that relate to information management and communication.
Barker states the importance and knowing the user’s need and learning preferences and to recognize the user’s usage patterns. After deciding the features you would like to use
it is then important to realize the features you can afford and decide according. After the features are decided it is important to test and review the document.

Barker then discusses online help documents, he stresses the significance of naming the topics appropriately. With that he talks about interconnected elements. This means selecting topics that refer to another topic.

Barker finishes the chapter talking about the overall document. He states that within each manual there will be two or three manuals in one for the different levels of the user. He also talks about making the manual user friendly, what he means by this is to help the user navigate. He gives an example of placing the index in the front matter which is usually not done, the users rejected the manual because it didn’t meet their expectations. If you choose to switch things up, explain it to the user. He talks about the importance of headers and footers and layering on a page, which means having two forms of information on the page at once to satisfy more than one reader.

Monday, October 29, 2007

Barker Chapter 9 - Editing and Fine Tuning

In this chapter, Barker discusses the steps for editing and fine-tuning software documentation. He writes that these guidelines help develop good editing attitudes and adapt the types of editing to the needs of a project. Also, they offer practical tips, rather than a specific sequence.

Establish Project Guidelines

The first guideline Barker discusses is establishing project guidelines. Each project is going to differ from all others, so you should make sure you and your writers and other editors understand the roles and the goals of the editing process. Barker notes that depending on your organization, you may find yourself in one of the following situations: writer and editor’s roles combined, writer submitting to an editor, or editor of the work of another writer. Once you have an idea of your editing role, you can identify the objectives of your project. Barker provides some examples of editing goals, including: consistency in how the user perceives or experiences the document, consistency in the purposes of the information in the documents, applicability to multi cultural or cross cultural readers, correspondence of tasks and activities in a manual or help system, and smooth interaction among editors and writers.

Understand the Types of Editing
The next guideline Barker discusses is understanding the types of editing. He writes that there are four types of edits that roughly correspond to the stages in the writing process. These four types are managerial, substantive, copy editing, and proofreading.

Barker writes that managerial editing concerns itself with the documents and their planning and production rather than their actual format and content. This type of edit requires involvement during the entire documentation process because you are tracking and coordinating all the production processes, and the relationships with the other documents. In the managerial editing process, the document and design plans are looked at for consistency and accuracy. This is also where the style is set for the entire project.

Substantive editing involves editing language and information. In this kind of editing, you work very closely with the author to address the overall organization and structure of a document. Barker writes that the following are things you look for in a substantive edit: overall organization of the document, fluency of one sentence to another, parallelism in steps and lists, proper use of description, clarifying definitions, elements in right order, divisions of information are logical and consistent, maintaining correct emphasis on certain elements, minimizing redundancy and repetition, omitting irrelevant or inappropriate material, and finding instances of missing information.

Next, Barker writes that copy editing concerns itself with editing for grammar, mechanical style, and format. In this type of editing, you pay attention to all the surface-level elements of the words, sentences, paragraphs, pages and books. Barker also notes that copy editing is done on documents that writers have already tested and subjected to user and other reviews, and that this kind of edit doesn’t necessarily assume that you know a great deal about the reader of a specific document. The following are some of the things you look for when copy editing: spelling, subject/verb agreement, sentence fragments, incomprehensible statements, suitability of screen shots, typography, correct style, header and footers, margins, spacing rules, mechanics and punctuation, word compounding, form and use of acronyms and abbreviations, and cuing patterns.

Proofreading is the last stage you go through before printing the production copies of a document. In this form of editing, you look at the elements of a document, and it entails making sure that all the changes suggested during the copy edit were done. Barker notes that since this is a tedious process, it is often done with a partner. The following are some of the tasks you perform when proofreading: checking for consistency in the table of contents, checking lists of tables and figures, checking that navigation and routing sequences specify the correct location of the necessary information, cross-referencing the tutorial lessons, checking that screen shots and figure numbers are unique and consecutive, checking that numbered or letter sequences are correctly labeled, and checking that spine copy, bleed tabs, and index pages are consistent.

Plan Your Editing Tasks

Barker writes that planning for editing should begin at the beginning stages of a project, but that often, editors get brought in later as a last-minute quality control measure. If this happens, you will have to do some retro planning to accomplish the editing tasks. Scheduling depends on the kinds of editing work you will be doing on a project. Depending on how many writers and your editing role, you will have to schedule two things: time for going over documents as an editor, and meetings with authors and developers about your work.

Barker continues his discussion of planning your editing tasks by stating that scheduling editing work allows you to budget in the time you need to complete your editing task and match your activities with others on the documentation team. The time it takes to complete an editing tasks depends on a number of things, including: the quality of the work you receive for editing, and the nature of the material you’re editing. Barker goes on to discuss how to plan for each of the four types of editing.

For managerial, you should plan to attend meetings and edit documents such as the documentation plan, test and review forms, the style guide, and all the documents associated with the project. Communication is the key for this plan and editors need to plan for the following events: establishing styles for print and online documents, a meeting to review the documentation plan, occasional memos to communicate updates to the documentation plan, reminders of deadlines, drafts, reviews, and test activities, periodical updates to the project style guide.

For substantive editing tasks, you should check documents as they are being developed and advise the writer on how to organize and design the content of a document according to the reader’s needs. Barker writes that these editors need to schedule the following events: review the documentation plan and style guide for the project, deadlines for outlines and rough drafts, deadlines for returning outlines and rough drafts, meetings to discuss editing comments and suggestions.

Next Barker discusses what is needed to plan for copyediting. He writes that this type of editing typically only requires on session per draft and is done after all the document is completely written in draft form. Copyediting usually takes longer than substantive editing because you may have to make passes at a document looking for one feature after another. The following are events copyeditors need to schedules: start and end dates for editing sessions on drafts, and meetings with writers and drafters.

The last type of editing to plan for is proofreading. Because of its tedious nature, it is wise to schedule two people for this task. Working as a pair helps to avoid mistakes and letting errors slip. Proofreaders need to schedule the following events: arrange proofreading sessions with another editor, and scan documents for grammar, spelling, headings, graphics, figures, tables, layout, notes, table of contents and index.

Barker notes that you should confuse editing tasks with other tasks, and the following tasks should not be confused with editing: don’t supply missing material, don’t supply missing screen captures, don’t write more than short passages, and don’t edit a manuscript more than once.

Develop the Appropriate Editing Forms
Barker writes that because editing requires you to establish relationships with other persons on the documentation team, you will find that creating editing forms, or using existing forms, can help you regularize your procedures and communicate with others more clearly. During document planning, you should have planned what styles the project was going to follow during writing. You should consult your documentation forms when editing to update the project plan, and to identify styles it specifies and reuse as much of the original information as possible. Barker notes that one of the most important forms you can create is the style sheet, which is a way of recording information about your editing convention as you go along. Style sheets are not a substitute for a style guide, which specifies styles for a document ahead of time. Barker emphasizes the importance of a style guide by discussing the purposes it fulfills: regularizing the production of documents, and setting standards that the members of a documentation team can follow. To develop a style guide, you should first look at existing style guides and then consider constructing a style guide for a specific project.

Conduct Editing Sessions

The final guideline Barker discusses is conducting editing sessions. The number one requirement of an editing session is to have no distractions. It is also a good idea to have a checklist handy while you’re editing. To ensure productive editing, Barker suggests two techniques: editing with a partner, and shortening editing sessions.

Discussion
Barker then goes to write about editing graphics and how each of the types of editing relate to this type of editing. He also discusses writing versus editing, stating that when you edit, you should try to see your editing tasks as separate from your writing tasks. This discussion also includes editing for cross-cultural readers by using either a globalized or localized language, and editing for translation, which means writing that is easily rendered into another language.

Campbell concludes this section and the chapter by discussing knowing what is correct, taking a constructive attitude and consulting standard style guides. To know what is correct in your documentation, you should look to guides, users and the documentation plan. Finally, Barker notes that seeing yourself, as a partner instead of an adversary will help your attitude.

Tuesday, October 23, 2007

Campbell Chapter 9

No One Ever Told Me About That


You have three choices for notifying users about a policy or procedure.
  1. Announce in person
  2. Communicate it in writing
  3. Send it be e-mail
Which one you choose will be based on part preference and part circumstance.

Factors that determine how you notify your users depend on:
  • Amount of material
  • Nature of the material
  • Complexity of the subject
  • Organization's standards
  • Communication method
  • Size of user group
  • Urgency
  • Location of users

Notifying in writing

Pros to notifying in writing are that it communicates the policy or procedure in a uniform way to all users. It can be distributed in mass and reaches users at all locations, on all shifts. It serves as legal documentation. And it formalizes and reinforces the message.

Cons to notifying in writing are that remote locations and later shifts may get their copies late and feel slighted. It may sound rigid or bureaucratic. It eliminates personal contact and the ability to ask questions directly of the issuer.

Tips for notifying in writing:

  • You're writing for an external audience such as an accrediting agency or customer
  • The audience is large or widely dispersed
  • The material is complex or lengthy
  • The subject is noncontroversial
  • Personal contact is unnecessary

Notifying in person

Doing this can take many forms: group meetings, individual meetings, phone conferences, or videoconferences.
The main advantage of notifying in person is that is gives direct contact with the issuer, which tends in increase cooperation and reduce resistance.
The main disadvantage of notifying in person is that meetings can be both hard to coordinate and unpleasant to conduct.

Tips for notifying in person:

  • The subject is simple or the user group small
  • You need to convey a sense of urgency or importance
  • The policy is ambiguous and needs explanation
  • Unofficial expectations differ from official policies
  • The subject is controversial or sensitive

Notifying by e-mail

E-mail is a hybrid approach to notifying allowing the user to ask questions to a written announcement. E-mail is best used when you have on-line policies and procedures or most of the organization's communication flows through an e-mail system and users are comfortable with it.

What to put in your notices

Written notices

Identify the policy and procedure
Give a summary of it
Include logistical information (title, number, effective date, implementation time frame, who's covered, whom to contact with questions or problems)
Include a brief summary of the substance (reasons for it, basic provisions, user responsibilities, and the impact it will have on users)

Verbal notices

Will the information session be introductory (brief and very general), informational (lengthier, containing more substantial information), or a training session (lasting as long as necessary covering all operational details)

Notify managers first before issuing a general notice to the company. Getting managers on board will keep their staff in line behind them.

Campbell Chapter 8 - Did I Forget Anything?

I want to apologize for not posting this earlier. I guess I wasn’t paying attention yesterday, and I clicked ‘Save’ instead of ‘Publish.’ I think it’s quite fitting for the Did I Forget Anything? chapter. Oops.

Campbell begins this discussion by stating that the writer of a document is ultimately responsible for mistakes and errors. Therefore, a writer’s goal is to make both content and form as nearly perfect as possible.

To create a perfect document, it must go through a review process, which fine-tunes the document and double-checks for accuracy and spelling. Since this can’t be done at once, there are five different types of review, each dealing with a different aspect. These reviews include: verification, validation, editing, proofreading and approval. Campbell notes that these reviews can be combined, but it’s a much more demanding task and requires greater skill on the reviewer’s part. She suggests using multiple reviewers to speed the process, but the real key is to build adequate review time into the schedule up front.

Campbell then goes on to discuss verification. She notes that verification and validation are often skipped, but they shouldn’t be because they provide the foundation of the finished product and are the main concerns of both the reader and the organization. When you verify, you’re checking for accuracy. There are a number of different verification methods, which include: comparing the final draft to the original, checking it against source documents, confirming numerical and statistical data or assigning a content expert to do the review. Campbell writes that verification is especially important in procedures, where near perfection may note be good enough.

Next, Campbell discusses validation, which is checking for usability. She writes that you should read the policy completely through to see if it makes sense or if anything is missing. The best way to validate a policy is to have several people read through it and watch their reactions. Make notes of their reactions and ask them for honest feedback. Campbell also notes that validating procedures takes longer because you’re actually testing the steps and the sequence. There are numerous techniques for validating procedures, which include: walk-throughs, observation, focus groups, and surveys. Each of these methods require you to go through the basic steps of preparation, testing, debriefing, and documentation.

The next review process Campbell discusses is editing. She writes that it presents the unique challenge of improving the policy or procedure without changing the meaning. The main purpose of the review is to check for items such as format, wording, consistency, flow, cohesion, layout, and visual appeal. The number of edits you to through depends largely on the document and the project. Campbell notes that you should be careful not to confuse the function of editing with the functions of validation and verification. To edit, you must know what you want from your document. In the case of policies and procedures, it’s readability and usability. The mechanics of editing are largely a matter or organization and consistency. Campbell continues by writing that editing should be done with an eye to the important matters of mechanical correctness, because trivial ones will be caught in proofreading. When you edit, you should review the page layout, consider the design elements, and scrutinize everything for consistency and logic.

Campbell continues with the next review, which is proofreading. She writes that it is as important as the other reviews, but for a different reason, which is your audience assumes that if you let little things slip through, you’ve probably let some big things slip through too. She also writes that proofreading has a bad reputation because it is seen as boring, but it is actually a demanding, time-consuming step that requires discipline, concentration, and patience. Campbell notes that the secret to effective proofreading is decontextualizing, which means that you must reverse the learned habit of reading for meaning and concepts. There are a number of ways to proofread, which include reading backwards, reading aloud, reading into a tape recorder, reading to a partner or reading diagonally. When proofreading, you should look for every single imperfection, typographical errors, punctuation, spacing, spelling, agreement, page breaks, titles, misplaced words and phrases, alignment, names, numbers, typestyle, typesize and margins. Campbell also notes that you should be especially careful when proofing graphics, and to be aware of personal blind spots. When proofing your own work, Campbell emphasizes decontextualizing. If you are under time constraints, Campbell suggests having different people proof for different aspects simultaneously or using free-proofing.

The last review process Campbell discusses is approval. You should talk with your approvers throughout the process and not wait until the end. If you consult them periodically throughout the process, your writing won’t come as a shock to them. Your approval process should never be haphazard, casual or done at the last minute. Instead, your procedure should outline the approval cycle and time frames. It should also encourage approvers to solicit input and comments from within their own areas. Often, slow response from approvers causes a time problem. Campbell suggests using a well-designed form that’s fast and easy to fill out to help conquer these delays. According to Campbell, you shouldn’t be disturbed if your approvers don’t agree. This helps you identify differences of opinions before the policies and procedures are in force. Your job with differences of opinions is to coordinate and communicate. Campbell also writes that you should try to include unofficial approvers because they are influential people who give an unofficial thumbs-up or thumbs-down on the final product since they will use the product every day.

Campbell concludes this chapter by discussing who should perform these reviews. She emphasizes the importance of having other reviewers look at your work because they bring a fresh eye and a fresh perspective. They also bring their own marks and styles, so it is important to coordinate and communicate effectively with these reviewers. Campbell notes that at times another reviewer may not be available. In these cases, you’ll have to exercise twice your normal discipline since you’ll be the sole developer, researcher, writer and reviewer all at once.

Monday, October 22, 2007

Barker - Chapter 8 - Conducting Usability Tests

Writing Software Documentation: A Task-Oriented Approach

Thomas T. Barker

Chapter 8 – Conducting Usability Tests

Barker defines the process of testing documents as “procedures for gaining empirical data about [their] usability.” This is accomplished using three basic types of tests: procedure tests for task performance, tutorial tests for skill and understanding, and reference tests for access to information. The chapter presents a 10-step test plan for conducting these tests.

Guidelines

Good testing requires careful planning. Barker suggests the following 10 steps be followed.

Step 1 – Decide When to Test

Testing often occurs after a draft of the documents has been produced, however it can take place at various stages in the project depending on your testing goals. A Predictive Test can be conducted during the design stage, a Remedial Test during writing or development, and an Evaluative Test after the document has been completed and delivered.

You must also determine what parts of your documentation you want to test. Determining this can be assisted by relying on the objectives that you set for your documentation, and the user analysis that you previously performed.

Step 2 – Select the Test Points

Test points are issues or features that can interfere with the efficient and effective application of a program to a user’s work activities. These can include problems with content and problems with document design.

Try to identify points where a mistake on either of these levels could lead to user failure. Any procedure where the cost of user confusion or failure is high in terms of time or money would be a good candidate for testing. In addition to testing these procedures, you should also test the document design strategies employed to ensure that they are effective.

Step 3 – Choose the Type of Test

There are three types of tests. Performance Tests test whether users can successfully complete a given procedure. Understandability Tests test whether users can provide evidence of what they have learned. Read-and-Locate Tests test how effectively users can locate a given topic of information in a documentation set.

Step 4 – Set Performance and Learning Objectives

Performance objectives state how long a procedure should take or the frequency of correctness one can expect from users. They can be time-related, or error-related. The goal here is to collect numbers that can be analyzed and compared.

In order to produce objective test results, it is important to avoid letting the outcome of the test be skewed by bias. Prejudices can creep in as a result of various work pressures, a proforma testing atmosphere, or becoming too enamored with the product of your labors.

Step 5 – Select Testers and Evaluators

The tester is defined as the person who administers the test. The evaluator is the person actually taking the usability test. If you do not have actual users available, you will have to compromise by selecting individuals to stand in for users.

Step 6 – Prepare the Test Materials

The written and other materials provided to testers and evaluators can be very extensive. Barker lists multiple forms of test materials, both written and hardware/software based. He also discusses the importance of pilot testing, which basically amounts to “testing the test”, to ensure that the instructions, terminology, and time expectations are appropriate.

Step 7 – Set Up the Test Environment

The test environment can range from the user’s actual workplace to a controlled laboratory. A field test produces valuable real-world insight, while a testing lab offers greater control over the process. A combination of both environments is often the most effective approach.

Step 8 – Record Information Accurately

It is important to accurately record what you see and hear throughout the test. This can be accomplished using video and audio recording technology, in conjunction with copious note taking. Making use of additional observers can help fill in any details that you miss.

Step 9 – Interpret the Data

There are a number of phenomenon that can cloud the data obtained through testing. Once these variables have been accounted for, you can make changes to your document based on what the numbers reveal. These can inspire all sorts of design decisions that require skill and commonsense decisions on the part of the author.

Step 10 – Incorporate the Feedback

The final step is an obvious one. The information gleaned from the testing process should serve to enhance the document in a positive way.

Discussion

In this section Barker offers a variety of thoughts on the usability testing of technical documentation. These include topics such as:

  • The three components of usability testing: tester, evaluator, and subject matter.
  • The importance of user testing as part of user-driven design
  • Comparing field tests and laboratory tests
  • The cost of testing and making it a corporate priority
  • Various field testing methods
  • The trade offs between testing earlier and testing later
  • Distinguishing between problems with the documentation and problems with the product

Barker concludes the chapter with a glossary of terms and a checklist for use when planning and executing usability tests.