What Experienced Collaborators Say About Collaborative Writing
Nancy Allen, Dianne Atkinson, Meg Morgan, Teresa Moore, and Craig Snow
Introduction
The article begins by explaining how recent research into writing on the job has uncovered the interesting issue of collaborative writing. There exists very little research focusing specifically on this topic, however. Information about collaborative writing, the authors state, is “fragmentary and unfocused”. The authors then cite studies that allude to collaborative writing in the workplace. These include research by Paul Anderson; Faigley and Miller; Odell; Paradis, Dobrin, and Miller; and several others. The peripheral nature of collaborative writing information in these studies cause the authors to state, “from these studies we gain little in the sense of the details or range of variation in the processes collaborative writers user, few clearly articulated reasons for employing a collaborative effort…and no coherent evaluation of collaboration from the writers themselves.”
The scant research that does exist on the topic of collaborative writing reveals a range of activities in which these writers engage. These include scenarios such as staff-written/supervisor-edited documents, collaborative planning with individual drafting, individual drafting with collaborative revising, and coauthoring, among others.
These many different forms of collaborative writing compel the authors to clarify their definition of the topic. They cite a paper by Wiener, who distinguishes between “group work”, a basically individual effort that is supported by a group, and “collaboration”, in which all group members share responsibility for the final product and must achieve consensus in order to produce it. This is the form of collaboration on which this article chooses to focus.
The article identifies two problems in reviewing the existing research. The collaborative writing process itself is poorly understood, and studies have not focused specifically enough on collaborative situations involving group authorship. For this reason, this study focuses on answering the following questions:
· What kinds of people form collaborative-writing groups and what kinds of tasks do they undertake?
· What are the writing processes used by experienced collaborators?
· What significant group processes emerge in collaborative-writing groups?
· How do experienced collaborators feel about the costs and rewards of collaboration?
Methods
In this section the authors discuss their research methodology, describing the project as “an exploratory study of the experiences of active collaborative writers from the business and professional worlds.” The participants were chosen to represent a wide range of collaborative settings and projects. The authors go on to provide specific demographic data about the subjects. They then discuss the structured interview form that they made use of. This form began by soliciting demographic information about the participants, then when on to ask questions about the membership of the collaborative writing groups that they have been a part of, the roles and contributions made by members, the writing process used, the types of group interaction that took place, and their overall evaluations of the experience as a whole. These questions were asked over the course of a two hour interview.
In the first stage of analysis, transcripts of the participants’ responses were referenced to produce basic demographic profiles of the members and their projects. In the second stage, the participants detailed observations and evaluations were collated.
Research Findings
The authors concede that their small sample size makes the information gleaned from their study incomplete. Demographically, the participants represented a wide variety of collaborative writing tasks, covering many different forms of professional documents. They also note that participants tended to want to talk about projects that they deemed successful, versus failures. The types of groups with which the participants had worked were diverse in nature in that some were made up of members with very different backgrounds and skills, while other groups had very similar membership. Most groups knew the type of document they would be producing and its general format, while others had higher or lower levels of task restriction.
The group writing processes that the participants engaged in always began with collaborative planning activities. This was usually followed by relatively independent research and drafting. Different participants reported different scenarios. Some produced drafts after heavy group planning, then revised based on group discussion. In some groups, everyone produced a draft, and in subsequent meetings members attempted to merge them. In other groups, the members contributed sections based on their specialties. Sometimes group members attempted to write collectively, word-for-word, a practice which often led to frustration.
Most participants reported significant interaction between group members early in the project, usually face-to-face. The article identifies three important aspects of group interaction:
Group as First-Line Audience
The group often served as an initial audience for the piece that they were writing, unconsciously or consciously.
Group Conflict
Conflict seems to be a given with collaborative writing (or as one respondent put it, “collaborative fighting”), but can benefit the process in many ways.
Computer-Aided Interaction
Computer-mediated communication was not nearly as prevalent at the time this article was written as it is now, however, some of the participants in the study had made use of computers to communicate with other collaborators on writing projects. This included both text-based communication, and sharing of drafts.
Decision-making power in the collaborative writing groups was shared in that anyone in the group could contribute suggestions or object to any idea. This power, however, was completely limited to the writing task at hand. There was a great deal of commitment to the process and the group among members.
Most of the groups were structured around group leaders who primarily seemed to serve a coordinating function. However, there were leaderless groups which prove that this is not necessarily a defining feature of collaborative writing.
Most respondents greatly appreciated the benefits of collaboration, finding them well worth the costs of time, energy, and ego. The documents that they produced collaboratively, they rated as “satisfied” or “very satisfied”. The subjects all recommended collaboration.
Discussion
The research results suggest three important points.
Functions of Conflict
The authors present several studies that support their participants’ suggestions that conflict increased group creativity. These include Janis, Weick, Rothenberg, and others. “When the group can tolerate some disharmony and work through divergent opinion to reach a consensus, their work is enhanced,” the authors conclude.
Distinguishing Shared-Document Collaboration
Here, the article presents a new term for describing a certain form of collaborative writing: shared-document collaboration. Such writing must involve production of a shared document, substantive interaction between group members, and shared decision-making power and responsibility.
There are many advantages to forming collaborative writing groups. The authors found that such groups are formed primarily because of the size of the task, the scope of the task, or a desire to merge divergent perspectives.
Questions for Further Research
The authors conclude their article by conceding its exploratory nature, and reiterating that their small sample (many of whom have academic affiliations) can only yield partial results. They also point out that since their subjects chose to speak mainly about successful projects, they have little data regarding failed collaborative writing projects. Future research on this topic could explore the influence of leadership styles, the use of multiple group types and writing processes on a single project, new technologies, and the interaction between organizational hierarchies and the hierarchy of collaborative writing group members. From business to academia, more information on collaborative writing would be immediately useful. The authors hope that they have pointed the way to future research.
Wednesday, October 3, 2007
Monday, October 1, 2007
Barker - Chapter 5 - Analyzing Your Users
Writing Software Documentation: A Task-Oriented Approach
Thomas T. Barker
Chapter 5 – Analyzing Your Users
Intro
Barker begins the chapter by giving an overview of what user analysis entails and why it is valuable. User represents the “basic research phase of the documentation process”, and involves “contact with persons who might use the software that you want to document. It involves inquiry into eight areas:
1. Tasks and activities the user will perform
2. User’s informational needs
3. User’s work motivations
4. Level of the user’s computer experience
5. User’s knowledge of the program’s subject matter
6. User community
7. User’s learning preference
8. User’s usage pattern
The answers to these questions will assist throughout the documentation process, informing the goals for the documents and what they will cover.
1. Choose Users Carefully
You begin this process by listing every potential type or group of potential users of the software as possible. You can then narrow down this list to those whom represent typical users and with whom you can form a working relationship throughout the documentation process. This selection process should involve consideration of each user’s unique culture.
After assembling this list of users, you will conduct a series of interviews with these individuals to build a list of common job tasks that would benefit from documentation.
2. Anticipate Transfer of Learning: Study Users Before and After Tasks
You should begin by determining the activities of users, “without the benefit of your program”. When you understand about the duties and skills of your users, you can craft your documentation in such a way that facilitates the transfer of these pre-existing skills to the operation of your software.
It is also important to build up a repository of tacit knowledge about users, which includes all of the small facts, attitudes, artifacts, interactions, and values that guide them in their job duties.
3. Research Professional Behaviors
In situations where direct user contact is impossible or insufficient, it is possible to research professional behaviors to construct a “mock-up of the user”. There are many resources for learning about the job duties of individuals in a particular position or industry, including occupational guides, industry-specific guides, placement services, or company job descriptions.
4. Write Use Cases
Use cases are descriptions of typical job scenarios, based on the tacit knowledge that comes from uncovering the “motivations, behaviors, values, and knowledge pertaining to your users that might not be visible on the surface.” By employing use cases in your documentation, you provide role models for your users. Use cases can also be included in the documentation plan to illustrate the types of activities that will be supported.
Work flow diagrams, which graphically depict organizational processes, are often a useful accompaniment to a use case. Barker also suggests that you should be mindful of your limited resources, and restrict your documentation accordingly.
5. Plan Interviews Carefully
Effective software documentation should “encourage [users] to learn the features of the program and put the program to useful work.” To this end, interview questions should involve users in the whole documentation cycle, using a usability approach.
Familiarity with the developers of the program and the program itself should help inform the questions you will have for users. Investing time in an interview plan can greatly increase their productivity. General steps for interview planning include:
1. Do preliminary research into the user’s job and programs already in use.
2. Review the software program and indentify the issues.
3. Establish the scope of your interviews.
4. Make a list of interview questions.
5. Get permission.
6. Set up and interview schedule.
7. Plan a follow-up.
Barker also recommends attempting to assess the verbal style of the users and reflecting it throughout the interview process to solicit better answers.
In addition to interviewing, observation can be a useful tool for gathering data about your users. This involves shadowing users at their place of work and recording their various actions, while taking care to avoid:
· Getting too involved – such that you distort their activities.
· Not getting involved enough – such that you focus on the wrong details.
Questionnaires are also valuable in that they allow you to gather information from a variety of users, increase the chance of identifying unique concerns, and identify wide patterns of use. For best results, these questionnaires should make use of open-ended questions, include clear instructions and plenty of room for filling in responses, and avoid negatively-worded questions.
6. Involve Users in All Phases of Project
A full user analysis should involve users in every stage of the documentation process, including writing, reviewing, and testing. This results in many benefits, including:
· Increased accuracy
· More appropriate information
· Increased usability
· Improved relationships
The relationship between the documentation writer and the users is an important one. Including them in the process yields valuable information regarding their specific situated action in the organization. This allows you to become a user advocate, bridging the gap between the software program’s users and developers. This relationship will also benefit from embracing the work culture of the users.
Conducting focus groups is another way to involve users in documentation, and are a good way to spark new ideas. Tips for conducting a successful focus group include:
1. Locate potential participants.
2. Develop and administer a telephone screening questionnaire.
3. Confirm invitations in writing.
4. Draft open-ended questions and follow-up questions, then revise.
5. Plan any hands-on activities.
6. Make reminder calls.
7. Pilot-test the questions with one or two group members.
Encouraging user participation in this way helps “extend the possibilities of user-centered design.”
7. Identify Document Goals
It is important to communicate your documentation goals early in the process. These consist of statements expressing specific objectives describing how the documentation will encourage users to learn the program and use it effectively. “The clearer your objectives,” states Barker, “the better the chance that you will achieve them.”
8. Tie the User Analysis to Documentation Features
It is important that the features that you document are chosen based on specific user needs. By tailoring this information to specific users, a more usable document results.
Discussion
User analysis is of central importance when composing task-oriented documentation. It incorporates the users’ workplace context, personal needs, organizational goals, work culture, and many other factors. This can assist you in a number of ways, such as by revealing ways in which users will use the software, providing scenarios and examples for use in tutorials, and identifying potential topics for testing, among others. Ultimately, a well-done user analysis will help “unify your document set”.
Software use is always situated in a user’s workplace and cultural context. Effective documentation will take this into account, and reflect “the user integrating the program instead of just the program.” Eight questions that help provide this tacit knowledge include:
1. What tasks will the user perform with the program?
Knowledge of job roles provides a starting point in describing user actions. Workplace activities exist in a context of information. Barker suggests focusing on a few key tasks to use as cornerstones within your documentation.
2. What are the user’s informational needs?
Often, software users may require some knowledge that is outside the realm of the program itself in order to use the program effectively (e.g. graphic design principles for a user of page layout software). It is useful to identify any such information and direct your users to the relevant resources.
3. What are the user’s work motivations?
Awareness of how users’ tasks shape their information and communication needs will help you to identify users’ underlying motivations. Interface elements should therefore take this awareness into account, and be arranged into “meaningful sequences leading to an objective” that is of value to the user.
4. What’s the user’s range of computer experience?
There are many differences between novice, experienced, and expert software users. It is important to pay attention to these differences and target your documentation to the learning patterns of the appropriate audience, or multiple audiences, when necessary.
5. How much does the user know about the subject matter of the program?
Subject matter knowledge influences the amount of supporting detail required when describing operations. This professional knowledge is also referred to as domain knowledge.
6. What’s the user’s workplace environment?
Various forms of user communities can often provide a great deal support to software users. These include help forums, special interest groups, newsgroups, user groups, web resources, newsletters, third-party documentation, FAQs, web rings, and mailing lists. You should strive to direct your users to these resources when appropriate.
7. What’s the user’s preferred learning preference?
Individuals accumulate knowledge in different ways based on a variety of factors. Whether the information is being delivered by an instructor, manual, or computer-based system, it is important to take into account factors such as the learning setting, the source of information, variations in information delivery, and the various forms of media used.
8. What’s the user’s usage pattern?
Usage patterns describe how users interact with the software over time. These can be: regular – involving daily use, intermittent – regular and frequent but at irregular intervals, or casual – an immediate need for use exists, but with little or no formal training yet received.
Barker concludes the chapter with a glossary of terms, a checklist for performing a user analysis, and some case studies with which to practice.
Thomas T. Barker
Chapter 5 – Analyzing Your Users
Intro
Barker begins the chapter by giving an overview of what user analysis entails and why it is valuable. User represents the “basic research phase of the documentation process”, and involves “contact with persons who might use the software that you want to document. It involves inquiry into eight areas:
1. Tasks and activities the user will perform
2. User’s informational needs
3. User’s work motivations
4. Level of the user’s computer experience
5. User’s knowledge of the program’s subject matter
6. User community
7. User’s learning preference
8. User’s usage pattern
The answers to these questions will assist throughout the documentation process, informing the goals for the documents and what they will cover.
1. Choose Users Carefully
You begin this process by listing every potential type or group of potential users of the software as possible. You can then narrow down this list to those whom represent typical users and with whom you can form a working relationship throughout the documentation process. This selection process should involve consideration of each user’s unique culture.
After assembling this list of users, you will conduct a series of interviews with these individuals to build a list of common job tasks that would benefit from documentation.
2. Anticipate Transfer of Learning: Study Users Before and After Tasks
You should begin by determining the activities of users, “without the benefit of your program”. When you understand about the duties and skills of your users, you can craft your documentation in such a way that facilitates the transfer of these pre-existing skills to the operation of your software.
It is also important to build up a repository of tacit knowledge about users, which includes all of the small facts, attitudes, artifacts, interactions, and values that guide them in their job duties.
3. Research Professional Behaviors
In situations where direct user contact is impossible or insufficient, it is possible to research professional behaviors to construct a “mock-up of the user”. There are many resources for learning about the job duties of individuals in a particular position or industry, including occupational guides, industry-specific guides, placement services, or company job descriptions.
4. Write Use Cases
Use cases are descriptions of typical job scenarios, based on the tacit knowledge that comes from uncovering the “motivations, behaviors, values, and knowledge pertaining to your users that might not be visible on the surface.” By employing use cases in your documentation, you provide role models for your users. Use cases can also be included in the documentation plan to illustrate the types of activities that will be supported.
Work flow diagrams, which graphically depict organizational processes, are often a useful accompaniment to a use case. Barker also suggests that you should be mindful of your limited resources, and restrict your documentation accordingly.
5. Plan Interviews Carefully
Effective software documentation should “encourage [users] to learn the features of the program and put the program to useful work.” To this end, interview questions should involve users in the whole documentation cycle, using a usability approach.
Familiarity with the developers of the program and the program itself should help inform the questions you will have for users. Investing time in an interview plan can greatly increase their productivity. General steps for interview planning include:
1. Do preliminary research into the user’s job and programs already in use.
2. Review the software program and indentify the issues.
3. Establish the scope of your interviews.
4. Make a list of interview questions.
5. Get permission.
6. Set up and interview schedule.
7. Plan a follow-up.
Barker also recommends attempting to assess the verbal style of the users and reflecting it throughout the interview process to solicit better answers.
In addition to interviewing, observation can be a useful tool for gathering data about your users. This involves shadowing users at their place of work and recording their various actions, while taking care to avoid:
· Getting too involved – such that you distort their activities.
· Not getting involved enough – such that you focus on the wrong details.
Questionnaires are also valuable in that they allow you to gather information from a variety of users, increase the chance of identifying unique concerns, and identify wide patterns of use. For best results, these questionnaires should make use of open-ended questions, include clear instructions and plenty of room for filling in responses, and avoid negatively-worded questions.
6. Involve Users in All Phases of Project
A full user analysis should involve users in every stage of the documentation process, including writing, reviewing, and testing. This results in many benefits, including:
· Increased accuracy
· More appropriate information
· Increased usability
· Improved relationships
The relationship between the documentation writer and the users is an important one. Including them in the process yields valuable information regarding their specific situated action in the organization. This allows you to become a user advocate, bridging the gap between the software program’s users and developers. This relationship will also benefit from embracing the work culture of the users.
Conducting focus groups is another way to involve users in documentation, and are a good way to spark new ideas. Tips for conducting a successful focus group include:
1. Locate potential participants.
2. Develop and administer a telephone screening questionnaire.
3. Confirm invitations in writing.
4. Draft open-ended questions and follow-up questions, then revise.
5. Plan any hands-on activities.
6. Make reminder calls.
7. Pilot-test the questions with one or two group members.
Encouraging user participation in this way helps “extend the possibilities of user-centered design.”
7. Identify Document Goals
It is important to communicate your documentation goals early in the process. These consist of statements expressing specific objectives describing how the documentation will encourage users to learn the program and use it effectively. “The clearer your objectives,” states Barker, “the better the chance that you will achieve them.”
8. Tie the User Analysis to Documentation Features
It is important that the features that you document are chosen based on specific user needs. By tailoring this information to specific users, a more usable document results.
Discussion
User analysis is of central importance when composing task-oriented documentation. It incorporates the users’ workplace context, personal needs, organizational goals, work culture, and many other factors. This can assist you in a number of ways, such as by revealing ways in which users will use the software, providing scenarios and examples for use in tutorials, and identifying potential topics for testing, among others. Ultimately, a well-done user analysis will help “unify your document set”.
Software use is always situated in a user’s workplace and cultural context. Effective documentation will take this into account, and reflect “the user integrating the program instead of just the program.” Eight questions that help provide this tacit knowledge include:
1. What tasks will the user perform with the program?
Knowledge of job roles provides a starting point in describing user actions. Workplace activities exist in a context of information. Barker suggests focusing on a few key tasks to use as cornerstones within your documentation.
2. What are the user’s informational needs?
Often, software users may require some knowledge that is outside the realm of the program itself in order to use the program effectively (e.g. graphic design principles for a user of page layout software). It is useful to identify any such information and direct your users to the relevant resources.
3. What are the user’s work motivations?
Awareness of how users’ tasks shape their information and communication needs will help you to identify users’ underlying motivations. Interface elements should therefore take this awareness into account, and be arranged into “meaningful sequences leading to an objective” that is of value to the user.
4. What’s the user’s range of computer experience?
There are many differences between novice, experienced, and expert software users. It is important to pay attention to these differences and target your documentation to the learning patterns of the appropriate audience, or multiple audiences, when necessary.
5. How much does the user know about the subject matter of the program?
Subject matter knowledge influences the amount of supporting detail required when describing operations. This professional knowledge is also referred to as domain knowledge.
6. What’s the user’s workplace environment?
Various forms of user communities can often provide a great deal support to software users. These include help forums, special interest groups, newsgroups, user groups, web resources, newsletters, third-party documentation, FAQs, web rings, and mailing lists. You should strive to direct your users to these resources when appropriate.
7. What’s the user’s preferred learning preference?
Individuals accumulate knowledge in different ways based on a variety of factors. Whether the information is being delivered by an instructor, manual, or computer-based system, it is important to take into account factors such as the learning setting, the source of information, variations in information delivery, and the various forms of media used.
8. What’s the user’s usage pattern?
Usage patterns describe how users interact with the software over time. These can be: regular – involving daily use, intermittent – regular and frequent but at irregular intervals, or casual – an immediate need for use exists, but with little or no formal training yet received.
Barker concludes the chapter with a glossary of terms, a checklist for performing a user analysis, and some case studies with which to practice.
Campbell Chapter 5 - Is There a Certain Format I Should Use?
In chapter 5, Campbell begins by discussing how to choose a format for policies and procedures. The best format depends on whom you’re writing for, what kind of material you’re dealing with and whether management accepts the format.
When determining your format, you should first ask yourself who your audience is. Campbell writes that certain formats are better for particular types of people. Engineers, scientists, and those with a technical background prefer flowcharts, while they might confuse other people. Readers respond better to formats they’re familiar with. However, unfamiliar formats don’t necessarily mean a bad choice. If the old format is ineffective, it is wise to switch. If using an unfamiliar format, Campbell suggests making time to introduce and explain it to your readers. Sometimes an organization requires a certain format, but if it seems confusing, occasionally organizations will make a parallel document, which is more user-friendly.
Another thing Campbell says to consider when formatting your document is the material. The nature of the information narrows your format options. Safety procedures require absolute clarity, so you want a format that is clear at first glance. In this case, a standard narrative format won’t help the reader much, and a flowchart could work much better. Campbell writes that you should examine the nature of the material closely before you settle on a format.
The final aspect of format consideration is management. Since upper management authorizes the policies and procedures, they must also understand and support the document and its contents. Campbell writes that you must ensure management’s comfort level, which is just as important as that of other readers.
Campbell then goes on to discuss how to decide a page layout for your document. She writes that the page layout gives the reader certain information about the policy or procedures, such as title, number, or effective date. This information is usually found in the header. A full header with all of the information typically appears on the first page, and a shorter version appears on the remaining pages. If the information is substantial, it is sometimes split into a header and footer. In other page layouts, certain parts of the text are standardized and are put immediately preceding the policy or procedure but outside the header. Campbell writes that the amount and types of information you standardize are up to you. The goal is to keep the document simple so the standardized information doesn’t detract attention from the policy or procedure itself. Once you decide what the readers need to know, you decide where and how to place it on the page.
Next, Campbell discusses choosing a format among the options. She writes that once you decide on a page layout, you are ready to choose a format from the main text. The primary options are: narrative, outline, playscript, or flowchart. These options are often used in combination with each other. The secondary options are: question and answer, troubleshooting, matrix table, and list. They are known as secondary because they can’t be inserted into the main document format. Campbell notes that once you choose a primary format, you must use it consistently throughout your document.
Campbell then goes on to discuss the primary formats in-depth. She first discusses narrative, which is the standard sentence-and-paragraph style. Standard narrative format is usually a single column, but two-column formats are also common and are used to break up sold horizontal lines of print. Narrative format is used more for policies than procedures. Campbell notes that narrative is not effective with complex, difficult, or lengthy material.
The next primary format Campbell discusses is the outline, which is a variation of the narrative format. The text is separated into shorter sections and subsections. These sections are labeled with numbers, letters or alphanumeric combinations. Campbell writes that the outline formats can vary widely, and that the format depends on the material you’re working with. She also notes that it is used in both policies and procedures because it is easy to follow.
Next, Campbell writes about the playscript format, which is great for procedures that involve more than one person or department. In the simplest form, a playscript has two columns. The first column tells who’s responsible while the second column describes what’s required. This format can be adapted for more complex procedures. The playscript is clear and provides an instant visual clue to the reader so they know what’s relevant to them. Campbell notes that when you use a playscript for the first time, you should explain it briefly to the readers.
The final primary format Campbell discusses is the flowchart, which is a diagram of process that uses symbols and arrows to indicated flow and action. Flowcharts are more commonly used in procedures than policies. Campbell notes that a danger of flowcharts is that they can quickly become cluttered and hard to read.
Campbell then goes on to discuss using secondary formats. The main purpose of these formats is to deal with other possibilities that may arise and special conditions that may exist. Campbell begins by discussing the question and answer format, which are used in both policies and procedures. They contain questions that a majority of readers might ask and are designed to simulate a personal conversation.
The next secondary format Campbell discusses is troubleshooting, which are used primarily in procedures so users aren’t forced to reread the entire document to get help when there’s trouble. Campbell writes that troubleshooting sections are often presented in chart format so the problem can be solved quickly.
Next, Campbell discusses matrix tables, which connect one variable to a second variable. She writes that matrix tables are a good format when readers need to refer repeatedly to the information periodically over time because they eliminate the need for constant rereading and searching.
Campbell then goes on to discuss lists, which should be used often because the eye loves lists. Campbell writes that lists break up the denseness of the printed page and let the eye skim quickly. An indented group of related items is known as a displayed or vertical list, but there are also other types, such as paragraph, nested and parenthetical. Lists allow you to use shortcuts what would sound odd in a regular sentence. These include leaving out the subject and starting with a verb, leaving out articles, and using partial sentences or only key words. Campbell notes that the main purpose of the list is to shorten, organize and clarify.
Campbell concludes this chapter by writing about combining formats and experimenting with different formats. She notes that you can switch among the formats for clarification, but to be cautious as to not overwhelm the reader. The formats should be experimented with in a search for better ways to communication important information with clarity and speed.
When determining your format, you should first ask yourself who your audience is. Campbell writes that certain formats are better for particular types of people. Engineers, scientists, and those with a technical background prefer flowcharts, while they might confuse other people. Readers respond better to formats they’re familiar with. However, unfamiliar formats don’t necessarily mean a bad choice. If the old format is ineffective, it is wise to switch. If using an unfamiliar format, Campbell suggests making time to introduce and explain it to your readers. Sometimes an organization requires a certain format, but if it seems confusing, occasionally organizations will make a parallel document, which is more user-friendly.
Another thing Campbell says to consider when formatting your document is the material. The nature of the information narrows your format options. Safety procedures require absolute clarity, so you want a format that is clear at first glance. In this case, a standard narrative format won’t help the reader much, and a flowchart could work much better. Campbell writes that you should examine the nature of the material closely before you settle on a format.
The final aspect of format consideration is management. Since upper management authorizes the policies and procedures, they must also understand and support the document and its contents. Campbell writes that you must ensure management’s comfort level, which is just as important as that of other readers.
Campbell then goes on to discuss how to decide a page layout for your document. She writes that the page layout gives the reader certain information about the policy or procedures, such as title, number, or effective date. This information is usually found in the header. A full header with all of the information typically appears on the first page, and a shorter version appears on the remaining pages. If the information is substantial, it is sometimes split into a header and footer. In other page layouts, certain parts of the text are standardized and are put immediately preceding the policy or procedure but outside the header. Campbell writes that the amount and types of information you standardize are up to you. The goal is to keep the document simple so the standardized information doesn’t detract attention from the policy or procedure itself. Once you decide what the readers need to know, you decide where and how to place it on the page.
Next, Campbell discusses choosing a format among the options. She writes that once you decide on a page layout, you are ready to choose a format from the main text. The primary options are: narrative, outline, playscript, or flowchart. These options are often used in combination with each other. The secondary options are: question and answer, troubleshooting, matrix table, and list. They are known as secondary because they can’t be inserted into the main document format. Campbell notes that once you choose a primary format, you must use it consistently throughout your document.
Campbell then goes on to discuss the primary formats in-depth. She first discusses narrative, which is the standard sentence-and-paragraph style. Standard narrative format is usually a single column, but two-column formats are also common and are used to break up sold horizontal lines of print. Narrative format is used more for policies than procedures. Campbell notes that narrative is not effective with complex, difficult, or lengthy material.
The next primary format Campbell discusses is the outline, which is a variation of the narrative format. The text is separated into shorter sections and subsections. These sections are labeled with numbers, letters or alphanumeric combinations. Campbell writes that the outline formats can vary widely, and that the format depends on the material you’re working with. She also notes that it is used in both policies and procedures because it is easy to follow.
Next, Campbell writes about the playscript format, which is great for procedures that involve more than one person or department. In the simplest form, a playscript has two columns. The first column tells who’s responsible while the second column describes what’s required. This format can be adapted for more complex procedures. The playscript is clear and provides an instant visual clue to the reader so they know what’s relevant to them. Campbell notes that when you use a playscript for the first time, you should explain it briefly to the readers.
The final primary format Campbell discusses is the flowchart, which is a diagram of process that uses symbols and arrows to indicated flow and action. Flowcharts are more commonly used in procedures than policies. Campbell notes that a danger of flowcharts is that they can quickly become cluttered and hard to read.
Campbell then goes on to discuss using secondary formats. The main purpose of these formats is to deal with other possibilities that may arise and special conditions that may exist. Campbell begins by discussing the question and answer format, which are used in both policies and procedures. They contain questions that a majority of readers might ask and are designed to simulate a personal conversation.
The next secondary format Campbell discusses is troubleshooting, which are used primarily in procedures so users aren’t forced to reread the entire document to get help when there’s trouble. Campbell writes that troubleshooting sections are often presented in chart format so the problem can be solved quickly.
Next, Campbell discusses matrix tables, which connect one variable to a second variable. She writes that matrix tables are a good format when readers need to refer repeatedly to the information periodically over time because they eliminate the need for constant rereading and searching.
Campbell then goes on to discuss lists, which should be used often because the eye loves lists. Campbell writes that lists break up the denseness of the printed page and let the eye skim quickly. An indented group of related items is known as a displayed or vertical list, but there are also other types, such as paragraph, nested and parenthetical. Lists allow you to use shortcuts what would sound odd in a regular sentence. These include leaving out the subject and starting with a verb, leaving out articles, and using partial sentences or only key words. Campbell notes that the main purpose of the list is to shorten, organize and clarify.
Campbell concludes this chapter by writing about combining formats and experimenting with different formats. She notes that you can switch among the formats for clarification, but to be cautious as to not overwhelm the reader. The formats should be experimented with in a search for better ways to communication important information with clarity and speed.
Subscribe to:
Posts (Atom)