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.

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.