|
Working Paper
|
models | processes |
In a conversation, Karen Schriver once observed:
Some things [in technical communication] have stayed the same.One continuing sameness is an interest in writing and editing.People have maintained that from the first time I heard the phrase technical communication.
What has changed is that many people in the field [now] realize that what we do is much larger than writing and editing and that the fields that can help us think about what we're doing are really diverse: cognitive psychology, graphic design, typography, human factors, comprehension, management and planning.I think that more people today have to be a jack of all trades even if they're working in large organizations where there's lots of support.
As the work of professional technical communicators has broadened in scope, so has the challenge of integrating this broader range of concerns into everyday practice.Within the academic world, the response has usually been separate courses. Many undergraduate and master's programs in technical communication sport courses in usability testing, visual communication, project management, and technical writing and editing.
Within the professional world, however, technical communicators and people in related fields who produce technical content have addressed this challenge by integrating the different issues into the single process for developing technical communication products (such as the LUCID process developed by COGNETICS (www.cognetics.com/lucid/), and processes described by Hackos, 1994 and Barnum & Carliner, 1993).
This concept of process significantly differs from the process-oriented approach to teaching composition that became popular in the early 1980s. The earlier concept of process emerged from research into the way that people compose documents, such as the research performed by Linda Flower (1989). "Process" as these researchers explored it, is a description of the way that people who are not professional communicators prepare functional documents (a term that Patricia Wright uses to define documents with a practical goal). In contrast, "process" to professional communicators is a prescription of a series of activities for publishing communication products that were commissioned as works-for-hire.
This chapter explores the impact of a process-oriented approach on curriculum design and classroom instruction. Because the process prescribed for the professional practice of technical communication for the web is significantly more intricate than the process used by non-professionals to develop functional documents for internal use, this chapter starts with a detailed background discussion on the role of process in developing technical communication products, how the process has been influenced by other disciplines and adapted for the design and development of content for the web.Then, it explores specific issues involved in bringing a process-oriented approach to the classroom. Last, it suggests implications of this process-oriented approach on the design of curricula for graduate and undergraduate major programs.
One of the first formalized processes for designing and developing content was proposed by the American Institutes for Research (AIR), developed in the early 1940s for the US military, which faced the challenge of efficiently developing training on new military technology. The military wanted to minimize the time needed to design, develop, and deliver training so it could implement the technology as quickly as possible. In response, the AIR proposed the first model of Instructional Systems Design (ISD). It attacked the design and development problem from a number of vantages.To make most effective use of development time and minimize re-work, it prescribed a series of steps to ensure that the right questions were asked at the right time. Throughout the process, it integrated the latest in learning theory(Deutch, 1992). Although adapted by corporations for their unique needs (such as IBM's Systems Approach to Education), elaborated upon, and updated (Gustafson, 1991), and occasionally attacked (Gordon & Zemke, 2000), the Instructional Systems Design model remains the core approach to developing content for training courses, even for the web (Horton, 2000, Driscoll & Alexander, 2000, and Hall, 1997). Figure 1 shows one popular adaptation of the Instructional Systems Design model.
|
|
Needs
Analysis |
|
|
|
ê |
|
|
|
Instructional
Analysis |
|
|
|
ê |
|
|
|
Subordinate
Skills Analysis |
|
|
|
ê |
|
|
|
Instructional
Objectives |
|
|
|
ê |
|
|
|
Criterion-Referenced
Tests |
|
|
|
ê |
|
|
|
Instructional
Strategy |
|
|
|
ê |
|
|
|
Instructional
Development |
|
|
|
ê |
|
|
|
Formative
Evaluation |
|
|
|
ê |
|
|
|
Revision |
|
|
|
ê |
|
|
|
Summative
Evaluation |
|
Figure 1:
Instructional Systems Design Model (Dick & Carey, 1990)
This systematic process to design and development is not unique to the development of training courses. A similar approach is used to develop software (Pfleeger & McGowan, 1997), hardware products, public relations and marketing communications materials (Saffir & Turrant, 1994), and even social service programs.
Faced with the daunting task of publishing 50,000-plus page libraries for large mainframe computer systems, and ensuring that all of those pages would be available on the same day, many large corporate technical publications departments responded with their own processes in the 1960s and 1970s. For example, one large minicomputer manufacturer developed and documented a 13-checkpoint process in the late 1970s.
|
Checkpoints |
Activities |
|
1 through 4 |
Planners used these checkpoints for information planning: identifying the topics to be covered in a given communication product, estimating the number of pages and illustrations, and estimating the development schedule and budget. |
|
4-12 |
Writers and editors used these checkpoints to develop and edit drafts: Odd numbered checkpoints indicated when drafts were due Even numbered checkpoints indicated when reviews should be completed. |
|
13 |
Drafts sent to the Production Department, where another editorial assistants followed a rigid 13-week cycle for producing documents: copyediting, final typesetting (this process was developed before the age of desktop publishing), production, transmittal to the publisher, preparation of plates, printing, and distribution to the warehouse. |
This process was designed for 6- to 12-month development cycles; that is, developing communication products according to this process took 6 to 12 months. The process was also designed for producing "documentation;" that is, communication products whose primary purpose was documenting the functions and features of the system, rather than explaining how to perform tasks with the products. Most users were highly technical and would receive extensive training; the documentation extended that experience. Finally, this process is an activity-focused process. That is, it focuses on the tasks performed by the technical communicator during the phase, rather than on the end product of that work. These activity-focused processes bear a strong resemblance to the processes described by the composition research performed at the time.
Fundamental shifts in business, and product and communication technologies outdated activity-focused processes like this one. A faster pace of development led to shorter product development cycles, meaning that communication products needed to be developed in 3 to 6 months, not 6 to 12.Similarly, the advent of desktop publishing significantly reduced production times. A shift from products for the technical elite to products for the average consumer transformed technical communication products from documentation of functions and features to instructional guides that replaced training and, as much as feasible, technical support (Redish, 1995).Price pressures in the market led to cost-cutting that reduced or eliminated editorial and production staffs, so technical communicators not only wrote their communication products, but also illustrated, edited, and produced it, too. The same cost pressures led the clarion for more accurate cost estimates (Hackos, 1994) and demonstrations of return on the investment in documentation (Mead, 1998). The focus on customers that resulted from the Total Quality Movement of the early 1990s expanded the roles of marketing organizations, and customers in product development (Fredrickson, 1990).Increased exposure to liability and, in certain industries, regulation, led to a similarly increased involvement of corporate attorneys and, in some cases, government regulators.
Technology changes that provide publishing flexibility also require a process-oriented approach. New publishing technologies permit single-sourcing of content. Single-source content is content that is saved in a single source file on the computer, but can be published in a variety of formats, including eXtensible Markup Language (XML), HTML (web format), Portable Data Format (PDF), word processor, and desktop publisher.This allows organizations to provide users with content in their preferred format, but requires extensive up-front coordination, only feasible through a well-defined process (Tsai, 2001, Kostur, 1999). Related to single-sourcing are content objects; that is, content that can be mixed and matched (much like clothing separates) (Aldrich, 2001). The coordination required to identify the objects, and design them for easy tailoring and reorganizing, also requires extensive up-front coordination that is only feasible through a well-defined process. And related to content objects is the concept of mass-customizing information. That is, by tracking, recording, and interpreting a user's behavior with a website, specific content objects can be presented to the user that address the user's anticipated needs. One current example of this is the list of recommended books and CDs that Amazon.com presents to users who have made purchases at its site.
In short, a vastly changed business and technological environment meant that activity-focused processes increasingly used by publications departments insufficiently addressed the issues they faced when developing communication products.A new type of process had to emerge.
Hackos raised the issue of the development process in her 1994 book on project management for technical communication. Like many in the pre-Internet software development environment, she drew parallels to the software development process. The processes for developing technical communication products in software development organizations worked in lock-step with those for developing software, and many used similar terminology, such as Alpha Draft (first) and Beta Draft (second) to match terms used in the software development process. Her process focused on the management of the development of the software and is a top-down process: that is, nearly all estimating is done at the beginning of the process.
Foshay noted that top-down estimates were usually 20 percent off of the actual budgets and schedules. He proposed instead, a phased approach that was more common in the advertising and non-profit industries, where design is funded and performed and includes estimates for more costly development efforts. He found that planned and actual schedules and budgets for phased projects only varied by 3 percent (1997).
Similarly, pre-web development processes tend to focus on management of the development effort, with minimal direction given to the design effort.
Finally, although a process-orientation to software development is recommended by many experts in the field, many organizations do not follow it.In fact, the Software Engineering Institute at Carnegie Mellon University found that processes fall into one of five categories. The first two categories, in which the process is laissez-faire at best, are the most common (Pfleeger & McGowan, 1997).
Because the technology lets users write one minute and publish the next, certainly many web development efforts are laissez faire, and provides strong pressure to organizations to stay so. However, most professional web-development efforts are process-oriented. Part of this is the influence of early authors, such as Louis Rosenfeld and Peter Morville, whose 1998 Information Architecture extolled the virtue of process. Part of this has to do with the nature of early web-development efforts.Many corporate websites were developed by outside agencies. Many agencies find that following a process and communicating that process to clients helps them better meet clients' needs and better set their expectations.As Rick Robinson, chief experience officer at Sapient notes:
I am not at all of the school of thinking that says
that the wonder and the spark of an intuitive solution doesn’t matter in this
world, or that all design is going to become rational. The best of things always
have a huge streak of play in them, and there are always gaps. What project
planning, research design, and design planning do, is set up situations so that
those problems that need a more intuitive approach are much more clear; they
allow people to apply personal experience, intuition and personal points of view
to the right kinds of problems. In many ways, I think the discipline that gets
brought to these more complex programs can open up a lot of opportunity for
people for those things to have a most profound impact (2000).
Many of the first well-publicized web development efforts were focused on e-commerce, but the principles clearly influence technical communicators.Key features of the process that technical communicators have adopted include:
In short, rather than thinking of project management, usability, writing, visual communication, editing, and collaborative work as isolated topics, these processes integrate them, state when in the development of a website that technical communicators need to address these issues, and often suggest how.
Like the numerous variations of the Instructional Systems Design process that have emerged since the American Institutes for Research first proposed it in the 1940s, so many variations of the process for developing content for the web have emerged since they were first proposed in the 1990s. Some processes are adapted for publishing e-commerce content, some for content that is more of an application than the communication of information, and some for games and entertainment.
The following describes another adaptation of the process: this one for designing, developing, and producing technical content. The process has four groups of phases: (1) assessment, (2) design, (3) development, and (4) implementation and maintenance.
The assessment phases are the first ones in the process for developing technical content for the web.In them, technical communicators identify the needs underlying the request to produce a communication product, and set the goals that a successful communication product must achieve.
The assessment phases include:
|
1. Define the Problem |
This phase initiates the design and development process and ends with a formal definition of the problem. This phase is performed by an information designer (also called an information architect, the person who defines and addresses the communication problem (Carliner, 2001)), who identifies: · The sponsor’s business goal; that is, how the communication product should affect the financial situation of the organization funding it (Summers & Summers, 2001). The communication product can generate revenue, reduce expenses, or help an organization comply with regulations (Robinson & Robinson, 1989). · The performance gap; that is descriptions of ideal scenarios of use and, if available, the current scenario of use. These scenarios focus on the end results of users' efforts. (Rossett) · The means of achieving ideal performance: that is, the tasks users should perform with the information. Or put in other words, how will uses apply the information in their own contexts? In some instances, when the tasks involve physical actions, the list of tasks is clear. But in other instances, when the tasks are intellectual ones, such as choosing the right model of computer to meet a customer’s needs, or pertaining to attitudes, such as taking a favorable view of a corporate reorganization, identifying the tasks presents more of a challenge. Identifying the tasks users should perform also involves distinguishing between main tasks¾ or the tasks users need to perform to accomplish their work¾ and supporting tasks¾ or tasks users need to perform to accomplish the main tasks. To effectively identify the tasks, information designers must develop sufficient proficiency with the technical subject. · The users and the influences on them; that is, to whom is the information directed and what would cause these people to accept or reject the information. At the least, information designers need to compile demographics on the users. But at the most, they should develop profiles of the users that attach a mental image to these otherwise faceless demographics (Cooper). · Project constraints. These include drop-dead deadlines, not-to-exceed budgets, technology platforms that must be addressed, existing editorial and web development standards to which the communication team must adhere, and other dependencies for the project. · The "unwrittens;" that is, the information that a sponsor is not likely to directly report, but could profoundly affect success with the project. By identifying aspects of the corporate culture, the information designer can identify past behaviors that might influence performance on the current project, as well as assess the influence of sponsors in the organization, the likelihood that technical information will change during the course of the project, and the behaviors needed to succeed in the organization. Activities in this phase draw heavily from three sources of theory.One is audience theory, a sub-field of usability and rhetoric. A second is task analysis and representing expertise, subfields of usability,instructional design, and artificial intelligence. The last is client management, a subfield of business management. |
|
2. Set the Goals |
During this phase, technical communicators set the goals for a project. At this time, information designers: 1. Define the objectives, a goal statement that uses precise language to express these goals in observable and measurable terms. As Summers & Summers note, communicators "can't really convince [them]selves or [their] clients that the site (re)design has been a success if [they] didn't begin the process with some goal in mind" (8). Communicators prepare two types of objectives: o Business objectives underlying the project, such as generating revenue or reducing expenses o Content objectives. That is, the content that users need to master for clients to achieve their business objectives. When you write objectives, you do so using a particular format that indicates the objective in observable and measurable terms. 2. Develop a plan for evaluating whether the objectives have been met. Yes, they do so before any design work has begun. Drafting the assessment tools now provides technical communicators with an image of how the "end state" should look and helps them structure information and design its presentation so that the communication product is most likely to "pass" the evaluation (Mager, 1997). The evaluation instruments drafted at this time address: o The satisfaction of users o Their ability to achieve the content objectives o The ability of the communication product to achieve the business objectives o The satisfaction of clients (with the ultimate goal of receiving another contract from the client or a referral) (Carliner, 1997) Before proceeding to the next phase, technical communicators present a Report of the Needs Analysis and Goals to the sponsor for approval. The activities in this phase draw heavily from the field of instructional technology, and the evaluation techniques used in training, usability, and finance. |
After receiving the sponsor’s approval on the Report of the Needs Analysis and Goals, technical communicators can design a communication product that addresses those needs and achieves those goals. During the design phases, information designers work with others on the project team to do so, and ultimately prepare a blueprint for the content. Each phase is intended to address the design in an increasingly detailed way. The design phases include:
|
3. Choose the Form of the Communication Product |
During this phase, information designers determine the format (genre) of the communication product and the medium used to deliver that content to users. Specifically, they: · Choose a format (genre) for communication product, such as help, how-to article, reference, wizard, or similar type of product. In addition to identifying the type of product, technical communicators should also identify all of the expectations that users bring to that particular type of communication product, to make sure that those expectations are addressed in the design. For example, users of help expect step-by-step instructions and the communication product must provide them, or explain to users why they're not being provided. · Validate the use of the web as a communication medium. The use of the web was probably dictated as a project constraint, but at this point, an information designer would verify that choice is a good one for sponsors and users. The activities in this phase draw heavily from generic analysis, a subfield of rhetoric, and media selection, a subfield of mass communications, rhetoric, and instructional technology (among others that explore this topic). |
|
4. Structure the Content and Plan Its Presentation |
During this phase, information designers work with usability experts, graphic designers, and technical staff, to prepare and test a sample section to give sponsors a tangible preview of the final product with some assurance that users will accept it, and prepare storyboards or wireframes of each additional screen that specify the presentation of the rest of the content. In doing so, information designers explore appropriate presentation strategies, alternate screen layouts and designs, and address wayfinding issues. Information designers also address issues of re-usability of content, and design for single-sourcing. Information designers address issues of branding (Bogaards, 2000) and the emotional response to the site, too, as they design the more concrete elements. Finally, working in conjunction with the technology staff, information designers set the technical requirements for the site. These requirements include the authoring guidelines (that is, the software used to create screen layouts, text, graphics, database calls, and similar actions), and viewing guidelines (that is, establish the software and hardware that users needs to view the content). This phase produces two products: a blueprint for the website and a prototype of a finalized version of the sample section (after it has been tested with users and approved by sponsors.) The activities in this phase draw on an eclectic body of knowledge, including (but not limited to) · Psychology, including cognitive psychology and motivation theory · Document (screen) design, including wayfinding and layout issues · Principles of user-centered design, a subfield of usability that identifies best practices for designing communication products that result from the experiences of previous usability studies · Principles of performance-centered design, a subfield of instructional technology, that specifies best practices in design to ensure the intended results and, like user-centered design, is based on results of earlier studies · Brand management, a subfield of both advertising and marketing · Software, especially design of database management systems, artificial intelligence programs, content management systems, and similar types of software. · Graphic design · The emerging disciplines of interaction and experience design, which are claimed by usability and graphic design as subfields of their disciplines. |
|
5. Establish Editorial and Project Guidelines |
During this phase, information designers work with information (or content) developers, editors, and project managers to develop the guidelines by which the project will operate and against which the drafts of the communication product will be assessed for quality. These guidelines include: · Editorial and authoring guidelines that codify the conventions specified in the blueprint. Some of the guidelines are documented in style guides, others in templates. · Project plan, which includes the schedule and budget for developing the communication product according to the specifications in the blueprint; and delineated roles and responsibilities for team members. The activities in this phase draw principles of grammar (a subfield of linguistics), style (a subfield of composition and writing), and project management (a discipline in its own right). |
As the name suggests, during these phases, the communication product specified during the design phases is developed. An information developer (also called a content developer or technical writer) prepares the content according to the plans; any change in plans must be approved by the information designer and the sponsor before the information developer can implement it. This approval process is not meant to stifle creativity; it is meant to control unnecessary changes and to assist in managing the sponsor's expectations.
The development phases include:
|
6. Draft the Communication Product |
During this phase, one or more information developers draft the communication product described in the blueprint. Information developers use the following in this effort: · Verbal communication, effectively using language to address the knowledge and motivation of the users, and the unique characteristics of online communication · Visualization, using graphics and animation to explain concepts and present quantitative data, and icons to symbolically represent ideas · Screen design, quickly leading users to specific content, and using visual devices to help users retain the content · Interaction design, conducting a dialogue with users through on-screen prompts and replies Information developers typically use a variety of software products to assist in the production of text and graphics during this phase. The activities in this phase draw on the fields of composition and style, rhetoric, visual rhetoric, graphic design, interaction design, and data visualization. |
|
7. Receive Feedback on the Draft |
During this phase, information developers seek feedback from others on thedraft, and respond to that feedback. Specifically, information developers arrange for these types of reviews:
The activities in this phase draw on editorial theory, user-centered design andusability testing (both subfields of usability), and interpersonal communication (a subfield of psychology also widely addressed in most communication disciplines). |
|
8. Revise the Communication Product |
During this phase, information developers respond to feedback from the reviews, make additional changes, and maintain close communication with clients. Specifically, they: · Incorporate technical and editorial changes · Prepare access aids, such as indexes and tables of contents, which would be unsuitable to prepare at earlier phases in the process when the communication product might drastically change between drafts Although this process only lists one revision, some technical communication products might require two rounds of review and revision. |
The last three phases of the web development process involve making the draft product suitable for publishing online, making it available to users, and providing ongoing support for the communication product. The phases include:
|
9. Produce the Communication Product |
Information developers begin this phase with a draft, and end it with a communication product suitable for publishing. Specifically, this phase involves:
In some organizations, information developers play a vital role in this process.In others, production specialists and the technical staff handle final production. The activities in this phase primarily draw on technical skills, including, at the least, the ability to use web development and graphics software and, at the most, the ability to perform simple programming in a popular language (at the time this chapter was written, these languages included Java, Javascript, and PHP), and use advanced graphics tools such as Flash and database programs such as Oracle and Access. |
|
10. Distribute the Communication Product |
During this phase, the communication product reaches its intended users. Some of the tasks are administrative, such as verifying that the content was posted. Some are marketing-oriented, such as announcing the availability of the new content and adding links to the new pages to existing parts of the website. This activities in this phase primarily draw on principles of marketing communications and motivation theory. |
|
11. Maintain the Communication Product |
During this phase, information designers and developers follow the actual use of the communication product by users and how that use affects the business performance of the sponsor. Specifically, this phase involves:
The activities in this phase draw on evaluation methodologies, especially those from training, marketing communications, and finance, and on project management. |
The Sidebar, A Sample of Web Development and Technical Communication Processes from Industry, provides a list of processes that are followed by organizations specializing in web development. Although each organization offers its own interpretation of the process, they all have these general characteristics:
· Define the design and development effort as a series of steps, which are performed in an observable and replicable way
· Intended to make sure that staff asks the right questions at the right time
· Start by defining the problem, then proposing a design, then developing the website, and last producing and maintaining the website
Note, too, that this process for designing and developing content for the web easily adapts to the design and development of all technical communication products.
Realistically, though, this process prescribes ideal practice; it does not describe the way people actually design and develop content for the web. In fact, if web development bears any resemblance to other types of development efforts, only some of the activities will be universally performed on all projects (Wedman & Tessmer, 1993). In some organizations, too, development is likely so chaotic that formal definitions of activities will not work (Hackos, 1994).
Still, our job in academe is preparing students for ideal practice, and developing the intellectual acumen to assess how to adapt ideal practice for the situations they face.
Methods for incorporating the process-oriented approach into specific courses in a technical communication vary, depending on the course. In this section, I offer specific andragogical suggestions. (Note that I prefer the term andragogy -- the education of adults (Knowles, 1980) -- to pedagogy -- the education of children -- because even traditional college students are legally adults.)
First, when newcomers to the field are presented with the full technical development process, it overwhelms them. The upfront analysis seems daunting, the accountability issues inherent in the development of evaluation instruments brings in its own form of "text anxiety," the complexity of publishing technology is admittedly off-putting to someone who is familiar with it, and the discussions of business issues and sponsors often play at odds with people who expect that writing for a living precludes such considerations. Addressing this concern requires a phased introduction to the process. Rather than introduce the entire process in an introductory technical communication course, students are better off becoming familiar with a simple process of planning first, then implementing, and the complexities of using traditional word processing tools for more complex desktop publishing tasks. An intermediate course could introduce students to additional complexity, such as additional complexity in planning, and professional desktop publishing tools. Advanced and graduate courses could introduce the process in its full complexity, and focus on methodologies for some of the up-front analysis, goal-setting, and design activities.
For example, one tool that can be used in courses is a worksheet for planning a communication product. Although previous writing instruction encourages students to plan in advance, most are not in the habit of doing so. Preparing websites as works-for-hire requires a good deal of planning.
One tool that can be used to introduce students to the process of planning, and deepen their understanding of it, is a Planning Form. By asking students to answer questions about the proposed communication product and by requiring that students submit the form with each assignment, the form guides students through the issues in planning a technical communication product (for any medium) and develops the habit of doing so.
Different forms, corresponding to the deepening complexities of the courses, can be used.For an introductory course, a form that is adapted from Pfeiffer's Technical Writing: A Practical Approach, works well. Figure 2 shows a sample of the adapted form.
Planning Form
____________________________________________________________________ ____________________________________________________________________
§ Its role in decision making process (circle one): Decision maker Decision influencer Decision receiver § Its tolerance for information (circle one) Nibbler Grazer Hearty appetite
__________________________________________________________________ __________________________________________________________________ __________________________________________________________________ __________________________________________________________________ · What response or action do you want from readers to take after reading this information? __________________________________________________________________ __________________________________________________________________ § Therefore: § How much information should you provide the audience (circle one) A lot Some Very little § What information would be most useful to the reader? __________________________________________________________________ __________________________________________________________________ § What information does the audience need that will be difficult for them to receive? How do you intend to handle the problem? __________________________________________________________________ __________________________________________________________________ |
Figure 2:
Example of a Basic Planning Form
An intermediate class provides students with a more in-depth experience in planning a communication product. The course might introduce concepts such as audience analysis, task analysis, setting objectives, assessment, and choice of genres. Figure 3 adapts a format called a concept sheet, which has been used by public relations and marketing communications firms. An instructor would remove those parts of the form that the course does not address.
General OverviewWrite a one-paragraph overview of the request for a communication product, using this format: I have been asked to write
a (type of communication product, fill in the name, such as a user's
guide, online help, or tutorial) about (fill in the topic
name, such as the name of the software or hardware product, or the general
subject area) for (fill in the name of the intended users).
When the users have read this communication product, they should be able
to (fill in the blank with words describing what people should be
able to do, such as use the product, install software, or the like). 1. Needs Analysis§ Business need: States why the sponsor wants to invest resources in developing this communication product. That is, if users can perform the tasks described in the product, how will that benefit the sponsor? § Tasks: First present a paragraph that describes the one "bottom line" task that users should be able to perform (such as install a product) and a summary of the other skills and knowledge they need. Next list: · Five to seven main tasks that users should be able to perform after using this communication product. · For each main task, 5 to 7 supporting tasks--that is, tasks users must be able to perform to successfully complete a main task. (For example, to complete the main task of starting a system, users must be able to complete the supporting tasks of using the power button and entering a password.) · User groups: Describe the intended users of the proposed communication product. Provide: · Demographics: job titles, experience, previous knowledge, and motivation for using the information (must use it, should use it, or nice-to-know) · Character sketches of 2 or 3 typical users in that category
· Schedule (such as a firm completion date that must be met) · Budget (such as a "not to exceed" cost) · Quality (identifies quality standards (such as editorial guidelines) and other characteristics that the proposed communication product must conform to) 2. Goals· Objectives: Make sure that these are stated in observable and measurable terms. · Business objective: Explains, in observable and measurable terms, how the technical communication product will contribute to revenue, contain expenses, or comply with regulations. · Content objectives: Same as the tasks (in a full information plan, you would provide some additional measurement information).
3. Form of the Communication ProductForm: Given that you have been instructed to write a certain type of communication product such as a user's guide or reference, explicitly name the expectations that users bring for that form. Specifically state:
4. Describe the Function
These ideas are often best presented in storyboards or thumbnails. 5. Quality Guidelines
|
Figure 3:
Example of a Concept Sheet
Notice that the Planning Form uses some of the approaches recommended by user-centered design and performance-centered design (Gery 1995). These include:
· A variation on use cases called bottom-line tasks
· Use of archetypes (called character sketches) (Cooper, 1999)
· Flowcharts of content (also called information maps because they show a map of the information--not to be confused with the Information MappingÒ system)
· Storyboards or wireframes (an idea proposed many years ago by Weiss for printed documentation, but not incorporated into standard practice until content moved to the web)
In advanced classes, the planning form becomes more elaborate, walking learners through the experience of developing evaluation instruments (such as user scenarios and satisfaction surveys) and setting project guidelines.
The strength of the planning form is that it provides structure and discipline to an analysis and design process that often lacks these qualities. This strength is also a weakness. Some students only complete the planning form as a perfunctory exercise after completing a project. This has been especially true with the basic planning form in the introductory technical communication course. In intermediate and advanced courses, students can be required to submit plans before they can begin development work. Unfamiliar with planning or not sold on its value, some resist these assignments as unnecessary or unrealistic. Some students do not see the value until several years later; some will request additional copies of the form or ask for a copy of the latest version after they assume an active role for planning in the workplace. Guest speakers who are information architects can have a powerful influence over students.
As past STC President Donna Sakson advised students attending the second STC Student Conference, one of the great myths underlying our field is that we work for the user.Rather, we work for the sponsors who fund our projects (1996). According to Robinson & Robinson (1989), a sponsor is an executive who can authorize payment for services or, if dissatisfied, stop payment. Sometimes these sponsors are internal to the organization, such as software development and information systems executives. Sometimes, these sponsors are external to the organization, such as a paying client.Robinson & Robinson observe that executive sponsors usually have minimal daily contact with a project. They delegate that responsibility to the subject matter experts and other reviewers with whom technical communicators work.
A process-oriented approach offers a sponsor-focused approach.The initial analysis and goal setting is intended to unearth the sponsor's true needs, and set expectations for the rest of the project. The design phases are intended to further set expectations, by describing the concept for the communication product as concretely as possible before actual development work begins. Reviews during the development process provide sponsors with a means of assuring that their needs and expectations have been met.
The user is not an overlooked entity in this process; ultimately, sponsors only achieve their business objectives for a communication product if users can achieve the content objectives. For example, Amazon.com can only generate revenue (much less a profit) if users can easily find and purchase products of interest. But the user is also not the sole focus of this process.
In fact, the end user with whom technical communicators have a special affinity often is not the customer of the sponsor, either. For many technical products in the business-to-business market, an executive makes the purchasing decision.End users are mere recipients, often having little or no say in the selection.
Introducing sponsors into the process has several implications on a course curriculum.Some are practical: a course includes practical lessons on managing expectations. Courses should also introduce students to the realistic dilemma when sponsors' and users' needs conflict with one another. In many instances, observation of usability tests helps sponsors develop an empathy for users that surveys and other market research does not.
An ideal course in which to introduce sponsors into the process is an intermediate course in technical communication. In introductory courses, most students still adjust to ultimately writing for end users and following a formal design and development process. Introducing sponsors to the mix adds an unnecessary level of complexity. Advanced courses and internships offer students an opportunity to refine their understanding of client management (the term that people in the field of business management use for working with sponsors).Certainly the issue of sponsors should be addressed in a project management course. But addressing the topic within a content development course shows students how the issues directly apply to their work.
One of the challenges of teaching a process-oriented approach is helping students choose an appropriate genre to communicate technical information. In addition to a new communication medium, online communication has given birth to several new genres. Among them are:
· Advertisements: promotions of various aspects of a product or service. Often appears inside the front or back covers of a publication, or on the screens displayed by an application when users start or install it.
· Coaches and advisors: online tools that assist users with cognitive (intellectual) tasks.
· Cue cards: instructions that tell users how to perform a task and that are displayed by the system one step at a time and that might visually resemble a cue card.
· Demo (also called guided tour): a trial version of a product that includes a scaled-down version of its features and functions and that provides users with a "tour" of the product. The tour may be "narrated" or may be self-running. Usually, demos provide users with an opportunity to try certain aspects of a product.
· Gaming-simulations: learning experiences that replicates the central characteristics of complex situations (that’s the simulation) and that let users experience the consequences of decisions made in that situation (the gaming aspect).
· Help: a special type of user’s guide for software that is available to users online as they use software applications.
