How do we let our client know about our solutions?

11.1 GENERAL GUIDELINES FOR TECHNICAL COMMUNICATION

There are some basic elements of effective communication that apply to writing reports, giving oral presentations, and even providing informal updates to your client. Thomas Pearsall summarized these common concepts as the seven principles of technical writing but they clearly apply more generally:

1. Know your purpose.
2. Know your audience.
3. Choose and organize the content around your purpose and your audience.
4. Write precisely and clearly.
5. Design your pages well.
6. Think visually.
7. Write ethically!

While Pearsall devoted more than one-half of his book to these principles, we will summarize them here as a prelude to the rest of this chapter.

Know your purpose. This is the writing analog of understanding objectives and functions for a designed artifact. Just as we want to understand what the designed object must be and must do, we need to understand the goals of a report or presentation. In many cases design documentation seeks to inform the client about the features of a selected design. In other cases the design team may be trying to persuade a client that a design is the best alternative. In still other cases a designer may wish to report how a design operates to users, whether beginners or highly experienced ones. If you don't know what purpose you are trying to serve with your writing or presentation, you may not produce anything or serve any purpose.

Know your audience. We have all sat through lectures where we didn't know what was going on or where the material was so simple that we already knew it. We can often take some action once we realize that the material is not set at an appropriate level. Similarly, when documenting a design, it is essential that a design team structure its materials to its targeted audience. Thus, the team should ask questions like, “What is the technical level of the target audience?” and “What is their interest in the design being presented?” Taking time to understand the target audience will help ensure that its members appreciate your documentation. Sometimes you may prepare multiple documents and briefings on the same project for different audiences. For example, it is quite common for designers to close projects out with both a technical briefing and a management briefing. It is also common for designers to confine calculations or concepts that are of limited interest to a report's primary audience to specific sections of their reports, usually appendices.

Choose and organize the content around your purpose and your audience. Once we are sure of the purpose of the report or presentation and its target audience, it only makes sense to try to select and organize its content so that it will reach its intended target. The key element is to structure the presentation to best reach the audience. In some cases, for example, it is useful to present the entire process by which the design team selected an alternative. Other audiences may only be interested in the outcome.

There are many different ways to organize information, including going from general concepts to specific details (analogous to deduction in logic), going from specific details to general concepts (analogous to induction or inference), and describing devices or systems.

Once an organizational pattern is chosen, no matter which form is used, the design team should translate it into a written outline. This allows the team to develop a unified, coherent document or presentation while avoiding needless repetition.

Write precisely and clearly. This particular guideline sounds like “use common sense,” that is, do something that everyone wants to do but few achieve. There are, however, some specific elements that seem to occur in all good writing and presentations. These include effective use of short paragraphs that have a single common thesis or topic; short, direct sentences that contain a subject and a verb; and active voice and action verbs that allow a reader to understand directly what is being said or done. Opinions or viewpoints should be clearly identified as such. These elements of style should be learned so that they can be correctly applied. Young designers may have practiced these skills more in humanities and social science classes than in technical courses. This is acceptable, and even welcome, so long as the designer remembers that the goals of both technical and nontechnical communications remain the same.

Design your pages well. Whether writing a technical report or organizing supporting materials for a verbal briefing or presentation, effective designers utilize the characteristics of their media wisely. In technical reports, for example, writers judiciously use headings and subheadings, often identified by different fonts and underlining, to support the organizational structure of the report. A long section divided into several subsections helps readers to understand where the long section is going, and it sustains their interest over the journey. Selecting fonts to highlight key elements or to indicate different types of information (such as new, important terms) guides the reader's eye to key elements on the page. Tables should be treated as a single figure and should not be split over a page break. White space on a page helps keep readers alert and avoids a forbidding look in documents.

Similarly, careful planning of presentation support materials such as slides and transparencies can enhance and reinforce important concepts or elements of design choices. Using fonts that are large enough for the entire audience to see is an obvious, but often overlooked, aspect of presentations. Just as white space on a page invites readers to focus on the text without being distracted, simple and direct slides encourage readers to listen to the speaker without being distracted visually. Thus, text on a slide should present succinct concepts that the presenter can amplify and describe in more detail. A slide does not have to show every relevant thought. It is a mistake to fill slides with so many words (or other content) that audiences have to choose between reading the slide and listening to the speaker, because then the presenter's message will almost certainly be diluted or lost.

Think visually. By their very nature, design projects invite visual thinking. Designs often start as sketches, analyses often begin with free-body or circuit diagrams, and plans for realizing a design involve graphics such as objectives trees and work breakdown structures. Just as designers often find that visual approaches are helpful to them, audiences are helped by judicious use of visual representation of information. These can range from the design tools discussed throughout this book, to detailed drawings or assembly drawings, to flow charts and cartoons. Even tables present an opportunity for a design team to concentrate attention on critical facts or data. Given the enormous capabilities of word processing and presentation graphics software, there is no excuse for a team not to use visual aids in its reports and presentations. On the other hand, a team should not allow their graphics' capabilities to seduce them into clouding their slides with artistic backgrounds that make the words illegible. The key to success here, as it is with words, is to know your purpose and your audience, and to use your medium appropriately.

Write ethically! Designers often invest themselves in the design choices they make, in time, effort, and even values. It is, therefore, not surprising that there are temptations to present designs or other technical results in ways that not only show what is favorable, but that also suppress unfavorable data or issues. Ethical designers resist this temptation and present facts fully and accurately. This means that all results or test outcomes, even those that are not favorable, are presented and discussed. Ethical presentations also describe honestly and directly any limitations of a design. Further, it is also important to give full credit to others, such as authors or previous researchers, where it is due. (Remember that this discussion of the seven principles began with an acknowledgment to their originator, Thomas Pearsall, and that each chapter of the book ends with references and citations.)

11.2 ORAL PRESENTATIONS: TELLING A CROWD WHAT'S BEEN DONE

Most design projects call for a number of both formal and informal presentations to clients, users, and technical reviewers. Such presentations may be made before the award of a contract to do the design work, perhaps focusing on the team's ability to understand and do the job in the hope of winning the contract in a competitive procurement. During the project, the team may be called upon to present their understanding of the project (e.g., the client's needs and the artifact's functions), the alternatives under consideration and the team's plan for selecting one, or simply their progress toward completing the project. After a design alternative has been selected by the team, the team is often asked to undertake a design review before a technical audience to assess the design, identify possible problems, and suggest alternate solutions or approaches. At the end of a project, design teams usually report on the overall project to the client and to other stakeholders and interested parties.

Because of the variety of presentations and briefings that a team may be called upon to make, it is impossible to examine each of them in detail. However, there are key elements common to most of them. Foremost among these are the needs to identify the audience, outline the presentation, develop appropriate supporting materials, and practice the presentation.

11.2.1 Knowing the Audience: Who's Listening?

Design briefings and presentations are given to many types of audiences. Consider the new beverage container whose design we began in Chapter 3. Our design work might have to be presented to logistics managers who are concerned with how the containers will be shipped to warehouses around the country. The marketing department, concerned with establishing brand identity with the design, might want to hear about our design alternatives. Similarly, manufacturing managers will want to be briefed about any special production needs. Thus, a team planning a briefing should consider factors such as varying levels of interest, understanding, and technical skill, as well as the available time. We can assume that most attendees at a meeting are interested in at least some aspect of a project, but it is generally true that most are only interested in particular dimensions of that project. A team usually can identify such interests and other dimensions simply by asking the organizer of the meeting.

Once the audience has been identified, a team can tailor its presentation to that audience. As with other deliverables, the presentation must be properly organized and structured: The first step is to articulate a rough outline; the second is to formulate a detailed outline; and the third is to prepare the proper supporting materials, such as visual aids or physical models.

11.2.2 The Presentation Outline

Just as with a report, a presentation must have a clear structure. We achieve this structure by developing a rough outline. This presentation structure and organization, which should be logical and understandable, guides the preparation of supporting dialogue and discussion. And because a design presentation is neither a movie nor a novel, it should not have a “surprise ending.” A sample presentation outline would include the following elements:

• A title slide that identifies the client(s), the project, and the design team or organization responsible for the work being presented. This slide should include company logos.
• A roadmap for the presentation that shows the audience the direction that the presentation will take. This can take the form of an outline, a flowchart, a big picture slide, and so on.
• A problem statement, which includes highlights of the revised problem statement that the team produced after research and consultation with the client.
• Background material on the problem, including relevant prior work and other materials developed through team research. References should be included but may be placed in a slide at the end of the presentation.
• The key objectives of the client and users as reflected in the top level or two of the objectives tree.
• The key constraints that the design must meet.
• Functions that the design must perform, focusing on basic functions, and means for achieving those functions.
• Design alternatives, particularly those that were considered at the evaluation stage, including diagrams and descriptions of each.
• Highlights of the evaluation procedure and outcomes, including key metrics or objectives that bear heavily on the outcome.
• The selected design, explaining why this design was chosen.
• Features of the design, highlighting aspects that make it superior to other alternatives and any novel or unique features.
• Proof-of-concept testing, especially for an audience of technical professionals for whom this is likely to be of great interest.
• A demonstration of the prototype, assuming that a prototype was developed and that it can be shown. Video or still photos may also be appropriate here.
• Conclusion(s), including the identification of any future work that remains to be done, or suggested improvements to the design.

There may not always be enough time to include all of these elements in a talk or presentation, so we may need to exclude some of them. This decision will also depend at least in part on the nature of the audience.

Once the rough outline has been articulated, we should also develop a detailed outline of the presentation. This is important to ensure that everyone on the team understands every point being made, throughout the presentation. A presentation outline also helps us develop corresponding bullets or similar entries in our slides because slide bullets usually correspond to entries in the detailed outline.

Preparing a detailed outline for the presentation may seem like a great deal of work. Team members with public speaking experience may be resistant to such tasks, most likely because they have already internalized a similar method of preparation. However, since presentations represent the entire team, every member of a team should review the structure and details of their presentations, as well as the detailed outline required by such reviews.

11.2.3 Presentations are Visual Events

Just as a team needs to know its audience, it should also try to know the setting in which the presentation will be made. Some rooms will support certain types of visual aids, while others will not. At the earliest stages of the presentation planning, the design team should find out what devices (e.g., overhead projectors, computer connections, projectors, and whiteboards) are available and the general setting of the room in which it will be presenting. This includes its size and capacity, lighting, seating, and other factors. Even if a particular device or setup is said to be available, it is always wise to bring along backups (e.g., files on drives, transparencies, hard copies) to back up a slide presentation.

There are other tips and pointers to keep in mind about visual aids, including:

• Limit the number of slides. A reasonable estimate of the rate of slides at which slides can be covered is 1–2 slides per minute. If too many slides are planned, the presenter(s) will end up rushing through the slides in the hope of finishing. This makes for a far worse talk than a smaller selection wisely used.
• Be sure to introduce yourself and your teammates on the title slide. This is also an appropriate time for a brief overall description of the project and acknowledgment of the client. Inexperienced speakers often have the tendency to flash the title slide and move on, instead of using it as an opportunity to introduce the project and people involved.
• Beware of “clutter.” Slides should be used to highlight key points; they are not a direct substitute for the reasoning of the final report. The speaker should be able to expand upon the points in the slides.
• Make points clearly, directly, and simply. Slides that are too flashy or clever tend to detract from a presentation.
• Use color skillfully. Current computer-based packages support many colors and fonts, but their defaults are often quite appropriate. Also, avoid clashing colors in such professional presentations, and be sure to keep in mind that some color combinations are hard to read for audience members who are colorblind.
• Use animation appropriately. An animated video of the function of your design might be very informative, while text flying in from the edges of the slide may not.
• Do not reproduce completed design tools (e.g., objectives trees, large morph charts) to describe the outcomes of the design process as they will likely be far too small to read. Instead, highlight selected points of the outcomes and refer the audience to a report for more detailed information.
• Consider carefully the size and distance of the audience if images of design drawings are being shown. Many line drawings are hard to display and often harder still to see and interpret in large rooms.

Remember that audiences tend to read visual aids as a speaker is talking, so he does not need to read or quote those slides. The visual aids can be simpler (and more elegant) in their content because they are there to reinforce the speaker, rather than the other way around.

11.2.4 Practice Makes Perfect, Maybe …

Presenters and speechmakers are usually effective because they have extensive experience. They have given many speeches and made many presentations, as a result of which they have identified styles and approaches that work well for them. Design teams cannot conjure up or create such real-world experience, but they can practice a presentation often enough to gain some of the confidence that experience breeds. To be effective, speakers typically need to practice their parts in a presentation alone, then in front of others, including before an audience with at least some people who are not familiar with the topic.

Another important element of effective presentation is to use words and phrases that are natural to the speaker. Each of us normally has an everyday manner of speech with which we are comfortable. While developing a speaking style, however, we have to keep in mind that ultimately we want to speak to an audience in their language, and that we want to maintain a professional tone. Thus, when practicing alone, it is useful for a presenter to try saying the key points in several different ways as a means of identifying and adopting new speech patterns. Then, as we find some new styles that work, we should repeat them often enough to feel some ownership.

Practice sessions, whether solitary or with others, should be timed and done under conditions that come as close as possible to the actual environment. Inexperienced speakers typically have unrealistic views of how long their talk will last, and they also have trouble setting the right pace, going either too fast or too slow. Thus, timing the presentation—even setting a clock in front of the presenter—can be very helpful. If slides (or transparencies or a computer) are to be used in the actual presentation, then slides (or transparencies or a computer) should be used in practice.

The team should decide in advance how to handle questions that may arise. This should be discussed with the client or the sponsor of the presentation before the team has finished practicing. There are several options available for handling questions that are asked during a talk, including deferring them to the end of the talk, answering them as they arise, or limiting questions during the presentation to clarifications of facts while deferring others until later. The nature of the presentation and the audience will determine which of these is most appropriate, but the audience should be told of that choice at the start of the presentation. When responding to questions, it is often useful for a speaker to repeat the question, particularly when there is a large audience present or if the question is unclear. The presenter or the team leader should refer questions to the appropriate team members for answers. If a question is unclear, the team should seek to clarify it before trying to answer it. And as with the presentation itself, the team should practice handling questions that it thinks might arise. It is important to have a strategy for handling questions such that the team is not talking over each other or correcting each other while answering questions.

While practicing its presentation, a team ought to prepare for questions from its audience by:

• generating a list of questions that might arise, and their answers;
• preparing supporting materials for points that are likely to arise (e.g., backup slides that may include computer results, statistical charts, and other data that may be needed to answer anticipated questions); and
• preparing to say “I don't know,” or “We didn't consider that.” This is very important: A team, that is, to be caught pretending to know has undermined its credibility and invited severe embarrassment.

A final note about selecting speakers is in order. Depending on the nature of the presentation and the project, a team may want to have all members speak (for example, to meet a course requirement); it may want to encourage less experienced members to speak in order to gain experience and confidence; or it may want to tap its most skilled and confident members. As with so many of the presentation decisions, choosing a “batting order” will depend on the circumstances surrounding the presentation. This means that, as with all of the other matters we've touched upon, a team should carefully consider and consciously decide its speaking order.

11.2.5 Design Reviews

A design review is a unique type of presentation, quite different from all the others that a design team is likely to do. It is also particularly challenging and useful to the team. As such, a few points about design reviews are worth noting.

A design review is typically a long meeting at which the team presents its design choices in detail to an audience of technical professionals who are there to assess the design, raise questions, and offer suggestions. The review is intended to be a full and frank exploration of the design, and it should expose the implications of solving the design problem at hand or even of creating new ones. A typical design review will consist of abriefing by the team on the nature of the problem being addressed, followed by an extensive presentation of the proposed solution. In the cases of artifacts, the team will often present an organized set of drawings or sketches that allows its audience to understand and question the team's design choices. In some cases, these materials may be provided to the attendees in advance.

A design review is often the best opportunity that the team will have to get the undivided attention of professionals about their design project. It is also worrisome for the design team, because its members may be asked to defend their design and answer pointed questions. A design review thus offers both a challenge and an opportunity to the team, giving it a chance to display its technical knowledge and its skills in constructive conflict. Questions and technical issues should be fully explored in a positive, frank environment. To benefit from the design review, the team should try to resist the natural defensiveness that comes from having its work questioned and challenged. In many cases the team can answer the questions raised, but sometimes they cannot. Depending on the nature of the meeting, the team may call upon the expertise of all of the participants to suggest new ways to frame the problem or even the design itself.

Not surprisingly, such reviews can last several hours, or even a day or two. One important decision for the team is to determine, during the review, when a matter has been adequately covered and move on. This is a real challenge, since there is a natural temptation to move on quickly if the discussion suggests that a design must be changed in ways the team doesn't like. There may be a similar temptation if the team feels that the review participants have not really “heard” the team's point of view. It is important to resist both urges: Time management should not become a cover for hiding from criticism or belaboring points.

A final point about design reviews is the need to remember that conflict in the realm of ideas is generally constructive, while personality-oriented criticism is destructive. Given the heat and light that sometimes arise at design reviews, team leaders and team members (as well as the members of the audience) must continually maintain the review's focus on the design, and not on the designers.

11.3 THE PROJECT REPORT: WRITING FOR THE CLIENT, NOT FOR HISTORY

The usual purpose of a final or project report is to communicate with the client in terms that ensure the client's thoughtful acceptance of a team's design choices. The client's interests demand a clear presentation of the design problem, including analyses of the needs to be met, the alternatives considered, the bases on which decisions were made, and, of course, the decisions that were taken. The results should be summarized in clear, understandable language. Highly detailed or technical materials are often placed in appendices at the end of the report, in order to support clarity. In fact, it is not unusual (and in large public works projects it is the norm) for all of the technical and other supporting materials to be moved to separate volumes. This is especially important when the client and the principal stakeholders are not engineers or technical managers, but perhaps members of the general public.

The process of writing a final report, like so much of design, is best managed and controlled with a structured approach. The design process and report writing are strikingly similar, especially in their early, conceptual stages. As with the design process, structure is not intended to displace initiative or creativity. Rather, we find that structure helps us learn how to create an organized report of our design results. One structured process that a design team might follow would include the following steps:

• determine the purpose and audience of the technical report;
• construct a rough outline of the overall structure of the report;
• review that outline within the team and with the team's managers or, in case of an academic project, with the faculty advisor;
• construct a topic sentence outline (TSO) and review it within the team;
• distribute individual writing assignments and assemble, write, and edit an initial draft;
• solicit reviews of the initial draft from managers and advisors;
• revise and rewrite the initial draft to respond to the reviews; and
• prepare the final version of the report and present it to the client.

We now discuss these steps in greater detail.

11.3.1 The Purpose of and Audience for the Final Report

We have already discussed determining the purpose and audience of the report in general terms. Several points should be noted in the case of a final report. The first is that the report is likely to be read by a much wider audience than simply the client's liaison with whom the team has been interacting. In this respect, the team needs to determine whether or not the liaison's interests and levels of technical knowledge are representative of the audience for the final report. The liaison may be able to guide the team to a better understanding of the expected readers, and may highlight issues of particular concern.

Another important element here is for the team to understand what the report's recipient hopes to do with the information in the final report. If, for example, the intent of the project was to create a large number of conceptual design alternatives, the audience is likely to want to see a full presentation of the design space that was explored. If, on the other hand, the client simply wanted a solution to a particular problem, they are much more likely to want to see how well the selected alternative meets the specified need.

A project report often has several different audiences, in which case the team will have to organize information to satisfy each of these target groups. This may include using technical supplements or appendices, or it may call for a structure that begins with general language and concepts, and then explores these concepts in technical subsections. The team, however, should write clearly and well for each audience, regardless of the organizational principle selected.

11.3.2 The Rough Outline: Structuring the Final Report

It would be foolish to start building a house or an office building without first analyzing the structure being built and organizing a construction process. Yet many people sit down to prepare a technical report and immediately begin writing, without trying to lay out in advance all of the ideas and issues that need to addressed, and without considering how these ideas and issues relate to each other. One result of such unplanned report writing is that the report turns into a project history, or worse, it sounds like a “What I Did Last Summer” essay: First we talked to the client, then we went to the library, then we did research, then we did tests, and so on. While technical reports may not be as complex as high-rise buildings or airplanes, they are nonetheless too complicated to be written as simple narratives or chronologies. Reports must be planned.

The first step in writing a good project report is building a rough outline that lays out the report's overall structure. That is, we identify the major sections into which the report is divided, which typically are:

• abstract;
• executive summary;
• introduction and overview;
• problem statement and problem definition or framing, including relevant prior work or research;
• design alternatives considered;
• evaluation of design alternatives and basis for design selection;
• results of the alternatives analysis and design selection;
• supporting materials, often set out in appendices, including;
• drawings and details;
• fabrication specifications;
• supporting calculations or modeling results; and
• other materials that the client may require.

This outline looks like a table of contents, as it should, because a final report of an engineering or design project must be organized so that a reader can go to any particular section and see it as a clear and coherent standalone document. It is not that we think things should be taken out of context. Rather, it is that we expect each major section of a report to make sense all by itself; that is, it should tell a complete story about some aspect of the design project and its results.

When should we prepare a rough outline? Indeed, when should we write our final report? It is evident that we can't write a final report until we have completed our work and identified and articulated a final design. However, it can be very helpful to develop a general structure for the final report early in project. We can then track and appropriately file or label key documents from the project (e.g., research memoranda, drawings, and objectives trees) according to where and if their contents would appear in the final report. Thinking about the report early on also emphasizes thinking about a project's deliverables, that is, those items that a team is chartered or contracted to deliver to its client during the project. We may find that the final stages or endgame of our project are much less stressful if we had organized our final report early on, simply because there will be fewer last-minute things to identify, create, and edit for insertion into the final report.

11.3.3 The Topic Sentence Outline: Every Entry Represents a Paragraph

A cardinal rule of writing states that every single paragraph of a piece should have a topic sentence that indicates that paragraph's intent or thesis. Once the rough outline of a report has been established, it is usually quite useful to build a corresponding, detailed topic sentence outline (TSO) that identifies the themes or topics that, collectively, make up the report. Thus, if a topic is identified by an entry in the TSO, we can assume that there is a paragraph in which that topic is covered.

The TSO enables us to follow the logic of the argument or story and assess the completeness of each section being drafted, as well as of the report as a whole. Suppose there is only one entry in a TSO for something that we consider important, say, the evaluation of alternatives. One implication of this is that the final report will have only one paragraph devoted to this topic. Since the evaluation of alternatives is a central issue in design, it is quite likely that there should be entries on a number of aspects, including the evaluation metrics and methods, the results of the evaluation, key insights learned from the evaluation, the interpretation of numerical results (especially for closely rated alternatives), and the outcome of the process. Thus, a quick examination of a TSO shows us that a proposed report is not going to address all of the issues that it should.

For the same reason, TSOs help identify appropriate cross-references that should be made between subsections and sections as different aspects of the same idea or issue are addressed in different contexts. The format of a TSO also makes it easier to eliminate needless duplication because it is much easier to spot repeated topics or ideas. In Section 11.4 we will show examples that demonstrate some of these points.

It is hard to write this way, but TSOs provide a number of advantages to a design team. First, a TSO forces the team to agree on the topics to be covered in each section. It quickly becomes clear if a section is too short for the material, or if one of the coauthors (or team members) is “poaching” on another section that was agreed upon in the rough outline. Second, a good TSO makes easier for team members to take over for one another if something comes up to prevent a “designated writer” from actually writing. For example, a team member may suddenly find that the prototype is not working as planned and she needs to do some more work on it. TSOs also make life easier for the team's report editor (see the next section) to begin to develop and use a single voice.

Finally, notwithstanding our definition of the abbreviation TSO, the entries in a TSO do not really have to be grammatically complete sentences. However, they should be complete enough that their content is clear and unambiguous.

11.3.4 The First Draft: Turning Several Voices Into One

One advantage of a rough outline and a topic sentence outline is that their structure allows teams members to write in parallel or simultaneously. However, this advantage comes at a price, most notably that of corralling the efforts of several writers into a single, clear, coherent document. Simply put, the more writers, the greater the need for a single, authoritative editor. Thus, one member of the team should enjoy the rights, privileges, and responsibilities pertaining to being the editor. Further, the team should designate an editor as soon as the planning of the report begins, hopefully at or near the onset of the project.

The editor's role is to ensure that the report flows continuously, is consistent and accurate, and speaks in a single voice. Continuity means that topics and sections follow a logical sequence that reflects the structure of the ideas in the rough outline and the TSO. Consistency means that the report uses common terminology, abbreviations and acronyms, notation, units, similar reasoning styles, and so on, throughout the report and all of its appendices. It also means, for example, that the team's objectives tree, pairwise comparison chart, and evaluation matrix all have same elements; if not, discrepancies should be noted explicitly and explained.

Accuracy requires that calculations, experiments, measurements, or other technical work are done and reported to appropriate professional standards and current best practices. Such standards and practices are often specified in contracts between a design team and its client(s). They typically provide that stated results and conclusions must be supported by the team's prior work. Accuracy, as well as intellectual honesty, also requires that technical reports do not make unsupported claims. There is often a temptation in a project's final moments to add to a final report something that wasn't really done well or completely.

The voice or style of a report reflects the way in which a report “speaks” to the reader, in ways very similar to how people literally speak to each other. It is essential that a technical report speaks with a single voice—and ensuring that single voice is one of the editor's most important duties. This mandate has several facets, the first of which is that the report has to read (or “sound”) as if it was written by one person, even when its sections were written by members of a very large team. The president of the United States sounds like the same, familiar person, even while using several speechwriters. Similarly, a technical report must read in a single voice. Further, that voice should normally be more formal and impersonal than the voice of this book. Technical reports are not personal documents, so they should not sound overly familiar or idiosyncratic. And it is important that the voice of the report be the same, from the opening abstract through the closing conclusions, and to the last appendix.

Clearly, there are serious issues for the team dynamics of the writing process. Team members have to be comfortable surrendering control of pieces they have written, and they have to be willing to let the editor do her job. We will discuss aspects of the team dynamics of report writing in Chapter 15.

11.3.5 The Final, Final Report: Ready for Prime Time

A good review process ensures that a draft final report gets thoughtful reconsideration and meaningful revision. Draft reports benefit from careful readings and reviews by team members, managers, client representatives or liaisons, faculty advisors, as well as by people who have no connection with the project. This means that as we are trying to wrap up our project report, we need to incorporate reviewers' suggestions into a final, high-quality document. There are a few more points to keep in mind.

A final report should be professionally done and polished. This does not mean that it needs glossy covers, fancy type and graphics, and an expensive binding. Instead, it means that the report is clearly organized, easy to read and understand, and that its graphics or figures are also clear and easily interpreted. The report should also be of reproducible quality because it is quite likely to be photocopied and distributed within the client's organization, as well as to other individuals, groups, or agencies.

We should also keep in mind that a report may go to a very diverse audience, not simply to peers. Thus, while the editor needs to ensure that the report speaks with a single voice to an anticipated audience, she should try as much as possible to also ensure that the report can be read and understood by readers who may have different skill levels or backgrounds than either the design team or its client. In addition, an executive summary is one way to address readers who may not have the time or interest to read all of the details of the entire project.

Finally, the final report will be read and used by client(s), who will, one hopes, adopt the team's design. This means that the report, including appendices and supporting materials, is sufficiently detailed and complete to stand alone as the final documentation of the work done.

11.4 FINAL REPORT ELEMENTS FOR THE DANBURY ARM SUPPORT

As required in most design projects, the student teams responsible for the arm support design for the Danbury School reported their results in the form of final reports and oral presentations. In this section we look briefly at some of the intermediate work products associated with their reports to gain further insight into some of the “do's and don'ts” discussed in Section 11.3.

11.4.1 Rough Outlines of Two Project Reports

The two teams we have followed each prepared a rough outline as a first step in laying out the report structure. Tables 11.1 and 11.2 respectively show the rough outlines developed by teams A and B and they are similar, yet different. Team A, for example, dedicated several sections to justifying their final design, while the team B organized around process. Both teams relegated sketches and drawings to appendices, although the second team put building instructions in the report body. This reflects the freedom that teams have to decide on an appropriate structure to convey their design results. This freedom, however, does not excuse them from having a logical ordering that allows the reader to understand the nature of the problem or the benefits of their solution.

TABLE 11.1 Danbury arm support team A's rough outline. The rough outline should show the overall structure of the report in a way that allows team members to divide up work with little or no unintended duplication. The structure should also proceed in a clear and logical manner. Does it for this report?

I. Introduction II. Description of problem definition Problem statement Design objectives and constraints III. Generation of design alternatives Morphological chart Description of design alternatives Description of subcomponents IV. Design selection process Metrics description Metrics application V. Final design Detailed description Prototype details VI. Testing the design VII. Conclusions Strengths and weaknesses of final design Suggestions for more advanced prototype Recommendations to the client VIII. References Appendix: Work breakdown structure Appendix: Pairwise comparison chart

Adapted from Attarian et al. (2007).

TABLE 11.2 Danbury arm support team B's rough outline. As with the outline presented in Table 11.1, this outline also shows the overall structure, and it is clear that the report focuses on reporting detailed testing and evaluation of the chosen design

Introduction I. Problem statement II. Background information on cerebral palsy, motivation for project III. Design plan Work breakdown structure Definition of objectives and constraints, including objectives tree Definition of functions and means, morphological chart IV. Design research Summary of devices currently available Evaluation of these devices for suitability in this project V. Description and evaluation of design alternatives Details and drawings of each alternative Metrics for choosing between designs VI. Final design Detailed description of chosen alternative Description of prototype and how it works VII. Testing the design Description of three test sessions at Danbury Conclusions and refinements of design based on testing VIII. Design evaluation Consideration of constraints How well design meets objectives Functional analysis Details on proposed design changes based on testing and evaluation IX. Works cited Appendix: Work breakdown structure Appendix: Research on dashpots

Adapted from Best et al. (2007).

Looking at the structure of these final reports, we also see just how much of each could have been written during the course of the project. Both teams used the formal design tools discussed in Chapters 3–8 to document their decision processes. Thus, the teams could—and should—have tracked and organized their work products in order to facilitate the writing of their final reports.

Finally, neither outline will adequately translate directly into a report. There are issues that could be considered in more than one section, and others not covered at all. Unless a team follows the outline with a TSO or some other detailed plan, the first draft of its final report will need an unnecessarily high degree of editing.

11.4.2 A TSO for the Danbury Arm Support

Table 11.3 shows an excerpt from the topic sentence outline prepared by team B. Notice that while each entry is not in itself a complete sentence, the specific point of that entry is easy to see. At this level of detail, it is relatively easy to identify points that are either redundant or inadequately covered.

The TSO enables the team to see not only what will be covered within each section, but also within each paragraph of the section. It also permits team members to take issue with or make suggestions about a section before writing and “wordsmithing” efforts are extended. For example, team B's definitions of metrics are not clear and could be challenged by a nitpicking reader (such as a professor or a technical manager). It is also clear that the ideas conveyed in some single paragraphs might be better explained were they divided into two paragraphs. It is also not clear why attention was specifically called to the liaison's definitions of constraints: Didn't the constraints (and objectives and revised problem statement) emerge out of the team's questioning of and discussions with the client? Elsewhere in the report the team implies that it alone developed the list of objectives. Perhaps this TSO indicates confusion about how the design process was executed, or at least how its execution is to be reported.

TABLE 11.3 An excerpt from the TSO for one section of team B's final report outline (shown in Table 11.2) for the Danbury arm support project

III. Design plan After clarifying the problem statement, the team began the process of designing the device Paragraph describing the overall approach to the design Work breakdown structure Objectives and constraints Defining functions and means Creating and evaluating design alternative The work breakdown structure consists of the tasks for the design process and their deadlines In order to implement the design, the team needed to define objectives and constraints Paragraph defining objectives Objectives are things one wants the design to achieve Objectives have a hierarchy List of ranked objectives Paragraph on liaison reaction to ranked objectives list Liaisons added an objective and ranked it Paragraph on organization of objectives Objectives sorted into three categories: user-friendly, primary device functions, and features Objectives divided into subobjectives Listing of subobjectives Objectives tree Paragraph on evaluating objectives using metrics Paragraph defining constraints Constraints are limits on the design List of constraints and description Paragraph on liaison input and reaction to constraints Initial constraints Constraints added after reaction from liaisons

Adapted from Best et al. (2007).

We also note that team B has cast their process as a historical narrative, which is very much at odds with our recommended style. For example, the statement “After clarifying the problem statement, the team began the process of designing the device …” is a red flag that the team is documenting the passing of time and events, not the evolution of a design process. Fortunately, because effort was invested in a TSO, it was relatively easy to identify needed changes and to make them.

11.4.3 The Final Outcome: The Danbury Arm Support

The teams we have followed working on the Danbury arm support project did finally finish their work. They produced formal oral presentations, prototypes, and final reports. The two team's reports were as different as were their designs. For instance, the reports were, respectively, 18 and 61 pages long! We have also shown some of their drawings in Figures 9.3 and 9.7, team B's model in Figure 10.1, and team A's prototype in Figure 10.2.

While the two designs have obvious similarities, they also have clear differences. For example, their mounting structures differ, as do their use of damping devices. These differences and similarities are not a surprise to designers or to engineering faculty, and they should not surprise you. As we have also noted previously, design is an open-ended activity, that is, there is no single—or even assured—solution to a design problem. Dealing with the uncertainty implied by the absence of a guaranteed, unique outcome is the reason that design is both challenging and exciting. The only thing that is certain is the satisfaction and excitement experienced by designers, clients, and users when a good design is achieved.

11.5 NOTES

Section 11.1: As noted in the text, the seven principles of technical writing are drawn from Pearsall (2001). In addition to Pearsall, there are a number of excellent books to support technical writing, including Pfeiffer (2001), Stevenson and Whitmore (2002), and the classic Turabian (1996). There is no better reference to effective use of graphics than Tufte (2001), a classic which belongs in the library of every engineer.

Section 11.4: The final results for the Danbury arm support design project from Attarian et al. (2007) and Best et al. (2007).