DTC Textbook

Design Thinking and Communication
Principles and Practice

2013 EDITION
Charles Yarnoff John Anderson Stacy Benjamin Mark Bourgeois Kathleen Carmichael Jeanne Herrick Penny Hirsch Barbara Shwom Deborah Wood
Copyright 2003-2013 Northwestern University
Table of Contents
Introduction
List of Figures .............................................................................................. xiii List of Tables..................................................................................................xv List of Examples ...........................................................................................xvi Acknowledgments.........................................................................................xxi
Chapter 1: Introduction............................................................ 3
1.1 Why teach design and communication together?.......................................4 1.1.1 Design and design-thinking: complex processes to solve complex problems ....................................................................................................4 1.1.2 Conceptual design vs. detailed design..............................................7 1.1.3 Communication: a central design activity ........................................7 1.2 DTC course goals......................................................................................9 1.2.1 Design goals .....................................................................................9 1.2.2 Teamwork and project management goals .....................................10 1.2.3 Communication goals .....................................................................10 1.3 A case study: Real clients, real projects, real audiences ..........................11 1.3.1 Understanding the background: what the client wants...................11 1.3.2 Becoming an expert and identifying the problem ..........................11 1.3.3 Generating alternatives: What ideas might lead to solutions?........13 1.3.4 Proposing a solution .......................................................................14 1.4 References ................................................................................................16
Design Process
Chapter 2: Defining and Researching the Problem............. 19
2.1 Developing a research plan ......................................................................20 2.1.1 Generate a list of questions.............................................................21 2.1.2 Group related questions into categories..........................................22 2.1.3 Identify likely sources to answer the questions ..............................23 2.1.4 Assign research questions to team members ..................................24 2.2 Conducting the initial client interview.....................................................24 2.2.1 Make an appointment .....................................................................24
iii
2.2.2 Assign roles.....................................................................................24 2.2.3 Gather information about the project..............................................25 2.2.4 Write the interview guide ...............................................................25 2.2.5 Write a summary of findings from the client interview..................27 2.3 Using print and electronic sources for research .......................................27 2.3.1 Using Google Scholar..................................................................28 2.3.2 Using effective search strategies.....................................................29 2.3.3 Evaluating sources for credibility ...................................................30 2.3.4 Keeping records of print and electronic research ...........................31 2.4 Analyzing competitive and model products.............................................31 2.4.1 Analyzing competitive products .....................................................32 2.4.2 Analyzing model products ..............................................................34 2.5 Defining user needs ..................................................................................34 2.5.1 Interviewing users about their needs ..............................................34 2.5.2 Observing users...............................................................................39 2.5.3 Creating user profiles and scenarios ...............................................42 2.6 Interviewing experts .................................................................................44 2.6.1 Guidelines for interviewing experts................................................44 2.7 Iterating your research and writing it up ..................................................47 2.8 References ................................................................................................48
Chapter 3: Writing the Project Definition ............................. 49

3.1 Mission statement.....................................................................................51 3.1.1 Guidelines for writing a mission statement ....................................51 3.2 Project Deliverables .................................................................................52 3.3 Constraints................................................................................................52 3.4 Users and stakeholders .............................................................................54 3.5 Requirements............................................................................................54 3.5.1 Identifying client requirements.......................................................55 3.5.2 Identifying the requirements of primary and secondary users........55 3.5.3 Identifying community requirements..............................................56 3.5.4 Organizing requirements into categories ........................................56 3.6 Specifications ...........................................................................................57 3.7 Format for the project definition ..............................................................58 3.8 Development of the project definition......................................................59
iv
3.9 References ................................................................................................60
Chapter 4: Generating Alternatives ...................................... 61

4.1 Brainstorming...........................................................................................62 4.1.1 Ground rules for brainstorming sessions ........................................63 4.1.2 Facilitator guidelines ......................................................................63 4.1.3 Example of a brainstormed list of ideas .........................................64 4.1.4 Clustering the brainstormed ideas ..................................................66 4.2 Generating alternative design concepts....................................................68 4.3 Creating mockups for user testing............................................................70 4.3.1 Guidelines for creating mockups....................................................71 4.4 References ................................................................................................72
Chapter 5: User and Performance Testing........................... 73

5.1 User testing...............................................................................................74 5.1.1 Guidelines for user testing..............................................................74 5.1.2 Organizing user test results.............................................................76 5.2 Performance testing..................................................................................77 5.3 Iterating the testing process......................................................................79 5.4 References ................................................................................................80
Chapter 6: Reporting on User and Performance Testing ... 81

6.1 The testing record: Its forms and functions..............................................82 6.1.1 Purpose of the testing record ..........................................................82 6.1.2 Ethics and the testing record...........................................................83 6.2 Elements of the formal record..................................................................84 6.2.1 Purpose ...........................................................................................84 6.2.2 Methodology...................................................................................84 6.2.3 Results ............................................................................................85 6.2.4 Analysis, conclusions, and limitations ...........................................85 6.3 References ................................................................................................86
Chapter 7: Deciding on a Design Concept........................... 87

7.1 Using test results ......................................................................................88 7.2 Using design requirements and specifications .........................................88 7.3 Creating decision matrices .......................................................................89 7.4 Talking to the client .................................................................................91
7.5 Interviewing experts and testing more mockups......................................91 7.6 References ................................................................................................92
Chapter 8: Failure Modes and Effects Analysis .................. 93

8.1 Why do an FMEA?...................................................................................93 8.2 Creating an FMEA ...................................................................................95 8.3 Using the results .......................................................................................96
Chapter 9: Conducting Design Reviews .............................. 99

9.1 Preparing the review...............................................................................100 9.2 Presenting the review .............................................................................101 9.3 Organizing feedback from the review ....................................................102 9.4 Offering useful feedback as a reviewer..................................................104 9.5 References ..............................................................................................105
Chapter 10: Concluding Conceptual Design: Moving Toward Detailed Design.................................... 107
10.1 Bill of materials ....................................................................................108 10.2 Considerations in detailed design.........................................................109 10.3 References ............................................................................................110
Chapter 11: Ethics and Design............................................ 111

11.1 Ethics in design ....................................................................................112 11.2 Nature and scope of design consequences ...........................................113 11.3 Good design and ethical design............................................................115 11.4 Ethical decision making .......................................................................116 11.4.1 Cost-benefit analysis...................................................................117 11.4.2 Risk assessment ..........................................................................117 11.4.3 Organizational contexts ..............................................................118 11.4.4 Regulatory compliance ...............................................................119 11.5 Conclusion............................................................................................121
Teamwork and Project Management

Chapter 12: Creating a High Performance Team............... 125
12.1 Team Development ..............................................................................126 12.2 Team Success .......................................................................................127 12.3 Team Charters ......................................................................................129
vi
12.4 References ............................................................................................132
Chapter 13: Developing Leadership and Managing Conflict ........................................................... 133

13.1 Developing a leadership structure........................................................133 13.1.1 Guidelines for exercising effective leadership ...........................134 13.2 Managing team conflicts ......................................................................135 13.2.1 Guidelines for managing conflict ...............................................136 13.3 References ............................................................................................139
Chapter 14: Conducting Meetings ...................................... 141

14.1 Setting an agenda .................................................................................142 14.2 Conducting the meeting .......................................................................145 14.2.1 General guidelines for participation in team meetings...............147 14.3 Keeping meeting minutes.....................................................................147 14.4 Conducting meetings with instructors..................................................149 14.5 References ............................................................................................150
Chapter 15: Keeping a Project Folder ................................ 151

15.1 Purpose.................................................................................................151 15.2 Content and organization .....................................................................152
Chapter 16: Writing as a Team ............................................ 155

16.1 Guidelines for writing as a team ..........................................................155
Chapter 17: Project Scheduling .......................................... 161

17.1 Responsibility Allocation Matrix (RAM chart) ...................................162 17.2 Gantt chart............................................................................................165 17.2.1 Team guidelines for creating Gantt charts..................................168 17.3 References ............................................................................................169
Communication
Chapter 18: Written and Oral Communication in Design . 173
18.1 Similarities between design process and writing process ....................174 18.2 Designing your communication deliverables.......................................176 18.2.1 Audience.....................................................................................177 18.2.2 Purpose .......................................................................................177
vii
18.2.3 Content........................................................................................178 18.2.4 Tone ............................................................................................178 18.3 Writing to explain decisions and conclusions ......................................180 18.4 Conclusion............................................................................................184 18.5 References ............................................................................................185
Chapter 19: Client Communication..................................... 187

19.1 When to communicate with clients ......................................................188 19.2 What modes of communication to use .................................................188 19.2.1 Telephone....................................................................................189 19.2.2 Email...........................................................................................190 19.2.3 Meetings......................................................................................191 19.3 How much to communicate..................................................................191 19.4 How to benefit from client communication .........................................192
Chapter 20: Email and Other E-communication ................ 195

20.1 Guidelines for email .............................................................................196 20.1.1 When to use email.......................................................................196 20.1.2 How to make sure your email gets read......................................196 20.1.3 How to make sure your message is understood..........................196 20.1.4 How to make sure the reader acts on your message ...................198 20.1.5 How to keep your team and instructors informed.......................199 20.2 Guidelines for sending attachments .....................................................199 20.3 Guidelines for sending faxes ................................................................200 20.4 References ............................................................................................201
Chapter 21: Visual CommunicationDocument Design, Figures, and Tables ........................................................ 203
21.1 Document design (page layout) for written deliverables .....................204 21.1.1 Line spacing and paragraphing ...................................................204 21.1.2 Margins .......................................................................................204 21.1.3 Headings .....................................................................................204 21.1.4 Lists.............................................................................................206 21.1.5 Page numbers..............................................................................208 21.1.6 Headers and footers ....................................................................208 21.1.7 Fonts............................................................................................208 21.2 Figures ..................................................................................................208
viii
21.2.1 Guidelines: How to present figures ............................................209 21.2.2 Examples: Effective use of figures.............................................210 21.3 Tables ...................................................................................................214 21.3.1 Guidelines: When to use tables ..................................................214 21.3.2 Guidelines: How to present tables ..............................................216 21.4 References ............................................................................................217
Chapter 22: Instructions ...................................................... 219

22.1 Planning................................................................................................219 22.1.1 Purpose .......................................................................................220 22.1.2 Audience.....................................................................................220 22.1.3 Tone ............................................................................................220 22.2 Organizing............................................................................................221 22.2.1 Title.............................................................................................221 22.2.2 Introduction ................................................................................222 22.2.3 Materials and equipment ............................................................222 22.2.4 Theory of operation ....................................................................223 22.2.5 Directions....................................................................................223 22.2.6 Troubleshooting..........................................................................224 22.3 Testing and revising .............................................................................224
Chapter 23: Progress Reports............................................. 227

23.1 Planning the report ...............................................................................228 23.2 Formatting and organizing the report...................................................229 23.2.1 Overall format.............................................................................229 23.2.2 Key parts of a progress report and their purposes ......................230 23.2.3 Using appendices in a progress report........................................233 23.3 Editing progress reports for clarity and conciseness............................233 23.3.1 Pitfall #1: Insufficient details to support your decisions ............234 23.3.2 Pitfall #2: Using a story format to explain your research...........234 23.4 References ............................................................................................235
Chapter 24: Final Reports.................................................... 237

24.1 Planning a final report..........................................................................238 24.2 Structure and content of a final report..................................................238 24.2.1 Cover and binding ......................................................................239
ix
24.2.2 Title page ....................................................................................239 24.2.3 Front matter.................................................................................239 24.2.4 Executive summary.....................................................................241 24.2.5 Body (text of the report) .............................................................242 24.3 Writing style for a final report..............................................................247 24.4 References ............................................................................................248
Chapter 25: Revising for Clarity, Conciseness, and Correctness ..................................................................... 249
25.1 Revising paragraphs for clarity and coherence ....................................250 25.1.1 Topic sentences...........................................................................250 25.1.2 Flow of ideas within paragraphs.................................................253 25.2 Revising sentences for clarity...............................................................256 25.3 Revising sentences for conciseness......................................................258 25.3.1 Choose active over passive verbs ...............................................259 25.3.2 Eliminate redundant or unnecessary words ................................261 25.4 Editing for correctness..........................................................................262
Chapter 26: Documenting Sourcesand Avoiding Plagiarism ........................................................................ 265

26.1 When to document and why.................................................................265 26.2 Guidelines for documenting sources ....................................................266 26.2.1 Reference lists.............................................................................267 26.2.2 In-text citations ...........................................................................268 26.2.3 Paraphrasing................................................................................270
Chapter 27: Oral Design Presentations.............................. 273

27.1 Preparing the presentation ....................................................................274 27.1.1 Analyzing purpose and audience ................................................274 27.1.2 Organizing the presentation ........................................................274 27.1.3 Making the presentation persuasive............................................279 27.1.4 Preparing effective slides............................................................282 27.2 Delivering the presentation ..................................................................289 27.2.1 Effective delivery........................................................................289 27.2.2 Using the prototype to communicate your design ......................290 27.2.3 Managing presentation technology.............................................291 27.2.4 Presenting in a professional way ................................................291
27.2.5 Rehearsing the presentation........................................................292 27.3 References ............................................................................................293
Chapter 28: Poster Presentations....................................... 295

28.1 Designing the poster.............................................................................296 28.1.1 Layout.........................................................................................296 28.1.2 Graphics......................................................................................297 28.1.3 Text.............................................................................................298 28.1.4 Font size and style ......................................................................299 28.1.5 Color ...........................................................................................300 28.2 Preparing the poster presentation .........................................................300 28.2.1 Planning the presentation............................................................300 28.2.2 Practicing the presentation..........................................................301 28.3 Examples ..............................................................................................303 28.4 References ............................................................................................307
Chapter 29: Writing Essays about Design ......................... 309

29.1 Analytical essays (DTC I)....................................................................310 29.1.1 Choosing a topic .........................................................................311 29.1.2 Deciding on an audience.............................................................311 29.1.3 Developing a thesis and organization.........................................312 29.1.4 Supporting your thesis ................................................................314 29.2 Persuasive essays (DTC II) ..................................................................315 29.2.1 Choosing a topic, thesis, and audience .......................................315 29.2.2 Supporting your thesis ................................................................316 29.3 Format and visual desigN of essays .....................................................319 29.4 References ............................................................................................321 Appendix A: Client Interview Summary ....................................... 323 Appendix B: Background research summary ............................. 327 Appendix C: User Observation Plan ............................................ 331 Appendix D: User Observation Summary ................................... 335 Appendix E: Expert Interview Guide ............................................ 341 Appendix F: Expert Interview Summary ...................................... 343 Appendix G: Project definition (Three Versions) ........................ 347 Appendix H: User Testing Guide .................................................. 355
xi
Appendix I: Performance Testing Report.................................... 359 Appendix J: User Testing Report................................................. 363 Appendix K: Two Sample Team Charters ................................... 369 Appendix L: Sample Table of Contents....................................... 375 Appendix M: Sample Executive Summary .................................. 377 Appendix N: Sample Introductions to Final Reports ................. 379 Appendix O: Discussion of Design Limitations in Final Reports............................................................................ 383 Appendix P: Progress Report ...................................................... 385 Appendix Q: APA Documentation formatting advice..................................................................... 389 Appendix R: MLA Documentation formatting advice..................................................................... 393 Appendix S: Terms used in Design Thinking and Communication ................................................................ 395 Index ............................................................................................... 411
xii
List of Figures
Figure 1.1: Recursive design process...............................................................6 Figure 1.2: Initial view of clients desk .........................................................12 Figure 1.3: Alternative one for filing system project stackable sloped tray................................................................................13 Figure 1.4: Alternative two for filing system project lazy susan.................................................................................................13 Figure 1.5: New alternative one for filing system project the filer.....................................................................................................14 Figure 1.6: New alternative two for filing system project the big one ...............................................................................................14 Figure 1.7: Final drawing for the tri-level organizer......................................15 Figure 2.1: Search results...............................................................................28 Figure 2.2: Find it @ NU shows where to find the article .............................29 Figure 2.3: Search results limited to 2001 or later .........................................29 Figure 3.1: Understanding user requirements ................................................55 Figure 18.1: The communication square......................................................176 Figure 27.1: Summarize the design problem ...............................................276 Figure 27.2: State the mission .....................................................................277 Figure 27.3: User needs................................................................................277 Figure 27.4: Present an overview of the design ...........................................278 Figure 27.5: Highlight features and their benefits .......................................278 Figure 27.6: Support design features with evidence ....................................279 Figure 27.7: Use expert authority to support claims ....................................280 Figure 27.8: Use test results to support the design.......................................280 Figure 27.9: Use reasoning to support the design ........................................281 Figure 27.10: Use headlines to signal the presentations organization ....................................................................283 Figure 27.11: Use graphics to highlight the design problem .......................287 Figure 27.12: Use graphics to highlight design features..............................287 Figure 27.13: Use graphics to emphasize benefits.......................................288 Figure 27.14: Use graphics to show design structure ..................................288 Figure 28.1: Annotated Poster: Seatback at a Universal Angle. Chen, Shiao, Srinivasan and Lee (2003)................................................304 Figure 28.2: Poster: Wheelchair Stabilization Rings. Guevarra, Matsuda, Tang, and Tsuruta (2004) ......................................305 Figure 28.3: Poster: The Egg Chopper. Chen, Fatakia, and Kuma (2004) ...........................................................306
xiii
xiv
List of Tables
Table 1.1: Comparing design and writing........................................................8 Table 8.1: Baby monitor FMEA ....................................................................94 Table 11.1: Examples of ethical considerations in each lifecycle stage ......115 Table 18.1: Comparing the design and communication process..................175 Table 18.2: Types of writing in DTC...........................................................175 Table 25.1: Transition words and phrases....................................................254
xv
List of Examples
Example 2.1: List of research questions.........................................................21 Example 2.2: Categorized list of questions ....................................................22 Example 2.3: List of potential sources ...........................................................23 Example 2.4: Sample interview guide............................................................25 Example 2.5: Search terms for researching prosthetics causing pressure sores..............................................................................30 Example 2.6: Analysis of two competitive products......................................33 Example 2.7: Table summarizing user preferences........................................38 Example 2.8: Template for table to organize user comments ........................38 Example 2.9: Task breakdown .......................................................................40 Example 2.10: Portion of an observation results table...................................42 Example 2.11: User profiles...........................................................................42 Example 2.12: Scenario..................................................................................43 Example 3.1: Mission statement for rain harvesting project..........................52 Example 3.2: Constraint for the rain harvesting project ................................53 Example 3.3: Requirements for rain harvesting project.................................56 Example 3.4: Specifications, with metrics, for rain harvesting project .........58 Example 3.5: General structure of a project definition ..................................59 Example 4.1: Brainstormed list ......................................................................65 Example 4.2: Clustering the ideas generated in a brainstorm ........................66 Example 4.3: Key requirements and best brainstormed ideas........................69 Example 4.4: Alternatives matrix for beverage container project..................70 Example 4.5: Two alternatives matrices for intravenous pump alarm project.........................................................70 Example 5.1: Summary of qualitative user test results ..................................76 Example 5.2: Performance test procedure and table for recording results ........................................................................78 Example 7.1: Decision matrix for choosing between two alternatives ........................................................................................89 Example 7.2: Weighted decision matrix for choosing between two alternatives ........................................................................................90 Example 7.3: Decision matrix for choosing among three alternatives...........91 Example 9.1: Summary of design review results .........................................103 Example 9.2: Decisions made after design review.......................................104 Example 10.1: Bill of materials....................................................................108 Example 12.1: Vague and Ineffective Team Charter ...................................130
xvi
Example 14.1: Agenda for team meeting to discuss mockups.....................143 Example 14.2: Agenda for team meeting with instructors...........................143 Example 14.3: Agenda for meeting with client ...........................................144 Example 14.4: Team meeting minutes.........................................................148 Example 16.1: Use a RAM chart to allocate final report responsibilities....156 Example 16.2: Use meeting minutes to allocate final report responsibilities ....................................................................158 Example 16.3: Write a set of style guidelines before drafting.....................159 Example 17.1: RAM Chart with ineffective task division...........................163 Example 17.2: Revised RAM chart with effective task division .................164 Example 17.3: Generic Gantt chart..............................................................167 Example 17.4: DTC winter quarter Gantt chart ...........................................168 Example 18.1: Ineffective tone in an email .................................................179 Example 18.2: Effective tone in an email ....................................................179 Example 18.3: Ineffective tone in a report (overuse of we) .....................179 Example 18.4: Effective tone in a report .....................................................180 Example 18.5: Unclear presentation of data to support a decision ..............181 Example 18.6: Clear presentation of data to support a decision ..................182 Example 18.7: Unclear presentation of data to support a conclusion ..........183 Example 18.8: Clear presentation of data to support a conclusion ..............184 Example 18.9: Using the communication square to plan a client meeting ..184 Example 19.1: Email summary of phone conversation ...............................189 Example 21.1: Wrong and right ways to create a grammatically parallel list .....................................................................206 Example 21.2: Ineffective uncategorized list...............................................207 Example 21.3: Effective categorized list .....................................................207 Example 21.4: Effective use of dimensioned drawing.................................210 Example 21.5: Effective use of photos ........................................................211 Example 21.6: Badly designed graph...........................................................212 Example 21.7: Better graph design ..............................................................213 Example 21.8: Graph is misleading due to distorted scaling .......................213 Example 21.9: Graph presents data without distortion ................................214 Example 21.10: Decision matrix for church space redesign........................215 Example 21.11: Sample decision matrix for church stage project...............215 Example 21.12: Features/benefits of electronic kiosk interface design.......216 Example 23.1: Typical memo heading.........................................................229 Example 23.2: Make specific statements in the introduction ......................230 Example 23.3: Organize the discussion of your progress around decisions and findings ...............................................................231
xvii
Example 23.4: Support decisions with research and test results..................231 Example 23.5: Explain next steps in detail, emphasizing your objectives.......................................................................................232 Example 23.6: Include sufficient detail to support decisions.......................234 Example 23.7: Avoid a story-telling format in progress reports..................234 Example 24.1: Supporting the design approach with authoritative research.....................................................................243 Example 24.2: Supporting design features with performance test results .................................................................244 Example 24.3: Supporting design features with user and performance test results...................................................244 Example 24.4: Effective summary of design features in relation to requirements (1) ...............................................................245 Example 25.1: Rough draft of a paragraph with no topic sentence .............250 Example 25.2: Revised paragraph with a topic sentence .............................251 Example 25.3: Rough draft of a paragraph with a vague topic sentence ..............................................................................251 Example 25.4: revised paragraph with a specific topic sentence ...........................................................................251 Example 25.5: Rough draft that requires editing of the topic sentence and the body of the paragraph..................................252 Example 25.6: Revision with consistent topic sentence and body of the paragraph..............................................252 Example 25.7: Rough draft of a long paragraph with more than one main point ......................................................................252 Example 25.8: Each paragraph has its own main point and topic sentence................................................................253 Example 25.9: Rough draft of a paragraph that lacks a logical flow of ideas...................................................................254 Example 25.10: Revised paragraph with a clear flow of ideas ....................255 Example 25.11: Rough draft of a paragraph with unclear sentence flow.............................................................................255 Example 25.12: Revision with clear transitions...........................................255 Example 25.13: Rough draft of a vague paragraph......................................256 Example 25.14: Eliminating vague modifiers..............................................256 Example 25.15: Eliminating vague verbs.....................................................257 Example 25.16: Eliminating vague pronouns ..............................................257 Example 25.17: Eliminating vague references to methodology...................257 Example 25.18: Vague references to results ................................................257 Example 25.19: Adding clear quantities ......................................................258 Example 25.20: Revised paragraph using precise
xviii
wording and details................................................................................258 Example 25.21: Rough draft of a wordy paragraph.....................................258 Example 25.22: Revised paragraph that is concise and clear ......................259 Example 25.23: Avoiding it is and there is...........................................260 Example 25.24: Eliminating passive or weak verbs ....................................260 Example 25.25: Eliminating redundant modifiers .......................................261 Example 25.26: Eliminating words from a series ........................................261 Example 25.27: Omitting repeated words....................................................262 Example 25.28: Eliminating long phrases ...................................................262 Example 26.1: References list in MLA format ............................................268 Example 26.2: Using MLA style in citations...............................................269 Example 26.3: Original passage from a journal article................................270 Example 26.4: Correctly done paraphrase of the passage (MLA format) ...270 Example 27.1: Capture listeners interest in the introduction......................275 Example 27.2: Turn vague statements into precise ones .............................281 Example 27.3: Wordy mission statement.....................................................285 Example 27.4: Concise mission statement...................................................285 Example 27.5: Wordy list of user needs ......................................................285 Example 27.6: Concise list of user needs.....................................................285 Example 27.7: Slide with non-parallel list...................................................285 Example 27.8: Revised slide with parallel list .............................................286 Example 28.1: Poster text that is wordy and hard to read............................298 Example 28.2: Revised poster text that is concise and easy to read ........................................................................298 Example 29.1: Effective thesis statements for an analytical essay ..............312 Example 29.2: Outline for analytical essay on Logitech Cordless MX Duo...................................................................312 Example 29.3: Introduction to an analytical essay comparing two products ........................................................................313 Example 29.4: Introduction of analytical essay examining how a design developed.........................................................................313 Example 29.5: Introduction of analytical essay examining why window covering designs fail ........................................................314 Example 29.6: A Paragraph that persuasively supports its claim ................315 Example 29.7: Introduction of persuasive essay arguing that a system is flawed and needs redesign .....................................................316 Example 29.8: Introduction of persuasive essay defending the bottled water industry from charges of ethical irresponsibility ......................................317 Example 29.9: Introduction of persuasive essay on importance of DTC project....................................................................318
xix
Example 29.10: Introduction of persuasive essay arguing that a design is ineffective ........................................................318
xx
ACKNOWLEDGMENTS
The authors of the textbook would like to acknowledge the contributions of several colleagues who have had a significant influence over the past sixteen years on Design Thinking and Communication (DTC) and the development of this book. Key principles of user-centered design that inform DTC and this book came from thoughtful input provided by two of the world's leading design firms: Herbst Lazar Bell, Inc., and IDEO Product Development. Particular thanks for their contributions in this area go to Walter Herbst, a founder of Herbst Lazar Bell, and to Stacy Benjamin, John Lake, and Amy Schwartz, who have all worked for IDEO. Edward Colgate, David Kelso, and Gregory Olson, professors of engineering at Northwestern University, contributed substantially to course materials that we used as the basis for the current textbook. Clive Dym of Harvey Mudd College taught with us when the course was in its pilot stage, and also helped us develop our model of teaching user-centered design. Walter Herbst, the director of Northwestern's Master of Product Development Program, provided many of the book's glossary entries. Don Norman of Northwestern University and the Nielsen Norman Group also contributed to the glossary. Michelle Greenberg of Northwesterns Writing Program contributed important material to the discussion of written communication. Matthew Glucksberg of Northwesterns Department of Biomedical Engineering offered valuable advice on user observation. Phillip Jacob, project coordinator for DTC, made key contributions to the chapter on client communication. David Gatchell, Director of the MaDE degree program in Segal, contributed a team charter example. Adam Goodman, Director of Northwesterns Center for Leadership, contributed valuable material to the chapter on creating a high performance team. In preparing the book, we were assisted by several colleagues who reviewed sections of the text, including Bruce Ankenman, Jeanine Casler, Leslie Fischer, Ann McKenna, and David Sabo. The cover and several graphics were designed by Craig Stehle, who also helped plan the layout of the book. We are grateful for everyones assistance and support.
xxi
xxii
PART ONE
INTRODUCTION
Chapter 1: Introduction
CHAPTER 1: INTRODUCTION
Chapter outline
Why teach design and communication together? Design and design-thinking: complex processes to solve complex problems Conceptual design vs. detailed design Communication: a central design activity Design Teamwork and project management Communication Understanding the background: what the client wants Becoming an expert and identifying the problem Generating alternatives Proposing a solution
DTC course goals
A case study: real clients, real projects, real audiences
Key guidelines for the design and communication process

Follow a disciplined process to solve design problems: Research the problem by talking to the client, observing users, and getting information from experts Define the problem in terms of a clear mission statement Generate alternatives for solving the problem Build and test those alternatives with potential users Decide on a design direction and present it to peers and experts for review Refine the design, build it, and test it Deliver the final design to the client in the form of a prototype, final report, and oral presentation
Repeat steps in this process as necessary Make good communication an integral part of the design process
Throughout the process, employ good teamwork practices and effective project management to ensure a high quality final product
The idea of designof making something that has not existed beforeis central to engineering.
Henry Petroski, To Engineer is Human (1985, p. xi)
This textbook for Design Thinking and Communication ( DTC) will introduce you to what most people consider the heart of engineering: complex problem solving that leads to new products and solutions. The text has been written just for youMcCormick freshmen in the introductory course in design and communication. DTC teaches you design while you actually do design. From the beginning, you'll be working on real projectsinvolving real people who need your products and audiences who are not simply your instructors. The textbook will introduce you to the design and communication process youll need for doing that work well. The best way to use the textbook is to read the required sections listed in the syllabus, and then to review the specific sections that are relevant to your projects when you need them.
1.1 WHY TEACH DESIGN AND COMMUNICATION TOGETHER?

1.1.1 Design and design-thinking: complex processes to solve complex problems
Societies are often known by their achievements in design, such as their pyramids, roads, or computers. It is the designer or engineer who synthesizes these new forms, who develops the ideas, goals, and requirements for the production of bridges, automobiles, and electric guitars. Henry Petroski, professor of Civil Engineering at Duke University and author of Invention by Design: How Engineers Get from Thought to Thing (1996), says that design and development distinguish engineering from science. Scientists primarily want to understand the world as it is, whereas engineers wrestle with ways to erect great monuments, or design defenses against enemies, or move people and goods across rough terrain (p. 2). Engineering, Petroski explains, is the art of rearranging the materials and forces of nature (p. 1). Petroskis formulation suggests that design thinking in engineering is as much an art involving creativity as it is a rational process requiring a deep understanding of science and technology. Moreover, since engineers design products and systems intended to be used by people, design thinking must be human-centered and engineers must put themselves in the place of and empathize emotionally with those who will use their designs. Engineers need to understand the problem from the users point of view.
Because design is a creative process that varies from person to person, there is no one right way to do design. Nonetheless, most descriptions of design process include interrelated steps like the following, the steps we use in DTC and in this textbook: Gathering information in order to understand the problem Defining the problem by identifying users and their needs Generating design alternatives Making mockups (sketches or simple models) of alternatives Testing the alternatives Deciding on a design direction Building more mockups Presenting a design for peer review Revising the design and building more mockups for testing Presenting supervisors and clients with deliverables (a final report, a poster or oral presentation, and a prototype)
Each step includes sub-steps or techniques and tools that you will use to develop your designs. Like the main steps, these arent always done in the same order. Thats because the design process is essentially iterative rather than sequential. Design engineers dont just start at the beginning of a list of steps and then march through each step until they reach the final design stage. Rather, as Figure 1.1 illustrates, they continually revisit the various stages as they gain additional knowledge. The list above provides a hint of this in the iteration of steps that involve building mockups, testing, and revising the design.
Define Problem
Draft a mission statement
Research
Interview clients, users, experts Analyze competitive and model products Observe users Research print and electronic sources Create user profiles and scenarios Document needs and initial specs
Generate Alternatives
Brainstorm ideas Cluster ideas Generate design concepts
Mock-up and Test Alternatives

Conduct user testing Conduct performance testing
Refine the design

Revise mission statement Narrow focus
Decide on Design Direction

Develop decison matrix Talk to clients and experts Hold design review
Final Deliverables
Prototype Final design documentation Written deliverables Oral deliverables
Figure 1.1: Recursive design process
In your spring quarter projects, for example, your client may tell you that she would like to develop a new type of automobile seat belt that can be fastened easily by people with arthritis. You will do research: interview seat belt experts, analyze competitive and model products, and observe potential users. Based on this information, you will mock up some alternative designs that you think will accomplish your clients and users needs. However, once you test these mockups on users, you may find that users actually want something quite different from what the client first described to you and from what they were originally able to imagine. So you go back to your client with this information, and may end up redefining the problem and designing a radically different product, such as a handheld device that helps people manipulate existing buckles. With this new idea in mind, you go back to users and experts with new mockups. The design process is just as much a loop as it is a line: you continually move forwardcloser to your goalbut not without retracing many of your steps. As Tim Brown (2009), CEO and president of a leading design firm, explains: The reason for iterative, nonlinear nature of the journey is not that design thinkers are disorganized or undisciplined but that design thinking is fundamentally an exploratory process; done right, it will invariably make unexpected discoveries along the way, and it would be foolish not to find out where they lead. Often these discoveries can be integrated into the
ongoing process without disruption. At other times the discoveries will motivate the team to revisit some of its most basic assumptions. While testing a prototype, for instance, consumers may provide us with insights that point to a more interesting, more promising, and potentially more profitable market opening up in front of us. Insights of this sort should inspire us to refine or rethink our assumptions rather than press onward in the adherence to an original plan. (p. 16)
1.1.2
Conceptual design vs. detailed design
Design process can be divided into two large phases: conceptual and detailed. Conceptual design is the systematic process of developing a general solution to a problem but not performing all the calculations and the evaluations of components, materials, and manufacturing processes necessary for implementation of the design. Detailed design, by contrast, is the process of performing necessary calculations and evaluating components, materials, and manufacturing processes in order to see a design through to implementation. Beginning engineering students arent expected to take a project all the way through to detailed design. To do that, you'll need more advanced knowledge of math, physics, and computers, and you will need to acquire expertise in a specific engineering discipline, such as chemical engineering or materials science. DTC stresses conceptual design. Later in your engineering career, you will take your design ideas through implementation. Well before that time, however, you can familiarize yourself with design process and develop ideas for solving problems. That way, by the time you work on a capstone project as a senior or take a job in industry, you will already know how to define problems, generate alternatives, interview clients, write reports, and give presentations. You will also understand something about the ethical issues that are prominent in design and the role that design plays in society.
1.1.3
Communication: a central design activity
It makes sense to study communication while you study design because communication is an integral part of design: the design process requires communication at every step of the way. In their book, The Engineering Design Process (1996), Atila Ertas and Jesse C. Jones state: Engineers in industry often comment on the large amount of their time that is committed to writing and other forms of communication. Most business and industry communications are verbal, in the form of face-to-face discussions, meetings, and telephone conversations. Important communications are transmitted in writing so that the meaning can be precisely
stated and a record can be established for future reference (p. 470). As a design engineer, you'll have to communicate with experts, clients, and team members. Youll be communicating not only when you write reports and give oral presentations, but also when you sketch ideas, build mockups, and provide graphs and equations. Youll need strong interpersonal skills for working successfully in client and team meetings. Youll need to write minutes, memos, emails, and project plans just to organize your work. But the connections between design thinking and communication do not end there. A real design, as opposed to a fuzzy idea, is something you can articulate and explain to others. Therefore, as you become a skilled communicator, you will become a better design engineer. Design and communication even share similar thinking processes. A writer, for example, follows steps that resemble the stages of design:
Table 1.1: Comparing design and writing

Design Gathering information Writing Collecting the information you need to communicate Identifying your main point, audience, and purpose Outlining different ways to organize the information Writing a rough draft Getting feedback from peers and instructors Revising the draft Delivering the final version of the report, proposal, and/or oral presentation
Defining the problem
Generating alternatives
Making mockups Testing the mockups
Building more mockups Presenting the final deliverables
Like the design process, the writing process is iterative; thats why writers call their different drafts revisions (re-vise means to see again). You can write a clearer final report once you ask a reader to review it. You can figure out if a set of instructions is clear by watching people try to follow it. Good communication, then, isnt just a matter of correct grammar and punctuationor of eloquence and style. Rather, its a form of problem solving, like design. This is especially true of long, complicated documents that require
clear organization of complex material along with visual cues, such as headings, to show readers where to find information. Engineering students often worry about writing and presenting; you may feel more comfortable with numbers and sketches than with sentences and paragraphs or with presentation skills. If so, then DTC should put you at ease; this course will show you that good problem solvers have the logical ability to be good communicators, too. In both design and communication, youll use your analytical skills to succeed.
1.2
DTC COURSE GOALS
Over the years, there have been DTC students who have approached the course as if there were nothing new to learn; they say that design and communication are simply common sense, that all a designer needs is intelligence and ingenuity. But that is not true. If it were true, then there would not be so much bad design in the world. If it were true, then the course would not have the support of top engineering and design firms who say that DTC teaches what students need to learn. If it were true, then employers would not value the abilities of our top design students so highly. And finally, if it were true, then we would not hear back from graduates who say what they learned in DTC was immediately applicable in their jobsand they are grateful to have learned it. The fact is that design and communication, while not overly difficult, are also not intuitive. There is a lot to learn in DTC. Not only will the course give you an opportunity to apply what you are learning in Engineering Analysis (for some projects), but it will also teach you skills and processes that lead to valued results. The three lists below detail the learning goals of DTC in its three major areas: design, teamwork (including project management), and communication. All of the topics are discussed in this textbook. Look over these lists at the beginning of the course to get an idea of where you will be going in DTC. Then at the end of each quarter, review them. You may be surprised at how far you have come.
1.2.1
Design goals
In DTC, you will learn how to: define engineering problems clearly and precisely with the clients and users needs in mind gather information about design problems and possible solutions from a variety of sources: clients, users, experts, print sources, online sources, etc.
generate alternative solutions to design problems build and test mockups that embody your alternative solutions improve designs based on information solicited from clients, users, and your fellow designers analyze designs to understand the risks and benefits they present to users and society embody your final design concepts in a prototype and detailed drawings
1.2.2
Teamwork and project management goals
In DTC, you will learn how to: manage the team formation process work successfully as a team by establishing team goals and standards, allocating responsibilities fairly, benefiting from team members' strengths, and using effective interpersonal communication monitor team performance and provide feedback to teammates manage team conflicts use project management tools, such as RAM charts and Gantt charts, to track responsibilities and develop a project timeline hand off the results of your project to your client or to a future design team
1.2.3
Communication goals
In DTC, you will learn how to: use writing and speaking to help develop and communicate design concepts use the writing processgathering information, planning, drafting, and revisingto produce clear, concise, and persuasive documents write documents commonly used in engineering such as final reports, progress reports, technical posters, instructions, emails and PowerPoint slides write to both technical and non-technical audiences use sketching throughout the design process to communicate ideas make effective oral presentations, using PowerPoint, to communicate a design create effective posters and present them clearly and persuasively in poster display sessions document and archive all work done on a project
10
collaborate with others to produce documents and presentations conduct well-organized, efficient, and productive meetings
Throughout the course, you will consider all three areasdesign, teamwork, and communicationin relationship to a design engineer's ethical obligation to make safety, integrity, and social responsibility a fundamental part of his or her work.
1.3 A CASE STUDY: REAL CLIENTS, REAL PROJECTS, REAL AUDIENCES

The case of the Filing System design team (Andrew Cibor, Tiffany Leung, Ivan Santana, and Chad Wastell) illustrates how the design process you will learn in DTC leads to a successful design. As you'll see, team communication, as well as communication with the client, is integral to the design process, and one key to its success.
1.3.1
Understanding the background: what the client wants
The idea for this project began when Ms. Ann Stuart, Program Coordinator for Industrial Engineering and Management Science in Northwestern Universitys McCormick School of Engineering, came to DTC with the request that students design something that would help her to organize the large number of papers, folders, brochures, and pamphlets she kept on her desk. She was well aware that office supply companies sell numerous filing cabinets, trays, and other equipment for this purpose. However, she believed that she would be better served by a revolving under-the-desk file cabinet tailored to her specific needs. She was not looking for a product that she could market but rather one that she could use to help her work more efficiently.
1.3.2
Becoming an expert and identifying the problem
Ms. Stuarts description of the problem was helpful to the Filing System team, but they wanted to understand the problem better before agreeing that her description was correct and that her proposed ideaa revolving file cabinet to be stored under her deskwould be the best solution. They needed to see for themselves exactly how Ms. Stuart organized the material on her desk and what was ineffective about her methods. Therefore, they made an appointment to meet in her office to learn about the problem firsthand. To prepare for this meeting, they wrote a detailed script of all the questions they wanted to ask. At the meeting, they not only asked her about her current methods of organizing her desk, her problems with those methods, and her under-the-desk
11
solution, but they took photographs that they could analyze later (see Figure 1.2). The team also arranged to have a member return later in the week to spend an hour observing her as she went about her daily routine. This observation session proved invaluable in providing the team with an understanding of the problem. Of particular importance was their observation that Ms. Stuart was visually oriented: she had to be able to see the needed materials on her desk clearly. If a file folder was hidden by something else, she tended to forget about it. This observation suggested that an under-the-desk solution would not be appropriate because everything in that file cabinet would be hidden from view.
Figure 1.2: Initial view of clients desk
To further understand Ms. Stuarts problem, the team interviewed and observed other Northwestern program coordinators who were successful in organizing their desk space. The students learned that these peoples success lay as much in organizational habits they had developed over the years as in their specific desk equipment. For a short time, then, the team thought that their problem was to change Ms. Stuarts habits by writing a set of instructions for organizing her desk space. However, further observations and interviews with Ms. Stuart persuaded them that her habits were so ingrained that this was an unrealistic goal. So they defined their problem as designing a physical structure that would: significantly improve Ms. Stuarts organization of her supplies, loose papers, and folders/projects be easily used while she remained in her chair fit her specifications in both size and appearance
The team detailed the problem and user requirements in a written document called a project definition.
12
1.3.3
Generating alternatives: What ideas might lead to solutions?
Once the team had defined the problem, they could begin to develop alternatives for solving it. They brainstormed a large number of design ideas ranging from labeled trays, sliding shelves, and color-coding to wild ideas like a scrolling marquee of reminders. They also looked online at office supply company websites for ideas. Using all of these ideas, as well as the list of key design requirements they had compiled, the team generated three alternatives, which they quickly mocked up using foamcore. The teams sketches of two of those alternatives (which they called stackable sloped tray and lazy susan) are presented below in Figures 1.3 and 1.4:
Figure 1.3: Alternative one for filing system project stackable sloped tray
Figure 1.4: Alternative two for filing system project lazy susan
These alternatives were not intended to be final designs, but rather to be used to solicit additional information about possible features for the design. For example, which orientation of her papers would Ms. Stuart find easier to work with: horizontal (in the sloped tray) or vertical (in the lazy susan)? The students asked Ms. Stuart to use each mockup for a day, after giving her instructions on how they thought it might be used. In each case, they returned the next day and interviewed herusing an interview script they had written for this purposeon what she did and did not like about each mockup. With her responses in mind, they developed two new alternatives that had features of the previous mockups but were in general quite different. Onenow called the filerincorporated the lazy susan idea but used a different con-
13
figuration of dividers. The other mockupnow called the big oneused slanting shelves but no longer in stacked trays (because Ms. Stuart found it difficult to find papers in the lower trays). See Figures 1.5 and 1.6:
Figure 1.5: New alternative one for filing system project the filer
Figure 1.6: New alternative two for filing system project the big one
These new mockups were subjected to constructive criticism by instructors and fellow students in a formal design review.
1.3.4
Proposing a solution
Based on the feedback they received in the design review, the team decided to recommend both design concepts to Ms. Stuart. They fine-tuned both designs,
14
drew up dimensioned drawings (see Figure 1.7 for a dimensioned drawing for one design, now called the tri-level organizer), and presented their solution to Ms. Stuart in an oral presentation and written final report. They also gave her the more complete of their two mockupsthe Rotational Filerwhich she was delighted with and eager to use. As you can see, the Filing System Design Team followed the design process described earlier in this introductory chapter, but performed many of the steps simultaneously or recursively. Communication was a key part of the process throughout: they communicated with each other, their client, their instructors, and others on a regular basis, and they used all forms of communication written, spoken, graphical, numerical, and interpersonal.
Figure 1.7: Final drawing for the tri-level organizer
15
1.4 REFERENCES
Brown, T. (2009). Change by design. New York: HarperCollins. Cibor, A., Leung, T., Santana, I. & Wastell, C. (2002). Filing system proposal. Engineering Design and Communication, Northwestern University. Ertas, A. and Jones, J. (1996). The engineering design process, 2nd ed. New York: John Wiley and Sons. Petroski, H. (1985). To engineer is human: the role of failure in successful design. New York: Vintage Books. Petroski, H. (1996). Invention by design: how engineers get from thought to thing. Cambridge, MA: Harvard University Press.
16
PART TWO
DESIGN PROCESS
CHAPTERS 2 DEFINING AND RESEARCHING THE PROBLEM 3 WRITING THE PROJECT DEFINITION 4 GENERATING ALTERNATIVES 5 USER AND PERFORMANCE TESTING 6 REPORTING ON USER AND PERFORMANCE TESTING 7 DECIDING ON A DESIGN CONCEPT 8 FAILURE MODES AND EFFECTS ANALYSIS (FMEA) 9 CONDUCTING DESIGN REVIEWS 10 CONCLUDING CONCEPTUAL DESIGN: MOVING TOWARD DETAILED DESIGN 11 ETHICS AND DESIGN
17
18
Chapter 2: Defining and Researching the Problem
CHAPTER 2: DEFINING AND RESEARCHING THE PROBLEM
Chapter outline
Developing a research plan Conducting the initial client interview Using print and electronic sources for research Analyzing competitive and model products Defining user needs Interviewing experts Iterating your research and writing it up
Key guidelines for defining and researching the design problem

Brainstorm questions you need to answer in order to understand the design problem Answer those questions using the following methods: Interview the client Research print and online sources Use Google Scholar and NU library databases Evaluate sources for credibility: author's credentials, absence of bias, support with valid research and citations, etc.
Analyze competitive and model products Observe and interview users Interview experts
Write well-organized research summaries for inclusion in project folder and reports
Even though your client has probably already defined the problem youll be working on, you should take time to do research and come up with your own definition. There are two reasons for this: (1) The client may not have defined the problem correctly, and (2) Studying the problem gives you a better grasp of the project.
19
To understand the importance of correctly defining the problem, consider the project described in Chapter 1. What the client defined as the problem was actually a solution: an under-the-desk revolving file cabinet to help her organize her papers. After observing that she was visually oriented, however, the design team concluded that she would do better with a system that would allow her to see her papers at a glance. In other words, they defined the problem in solution-independent terms. To appreciate the value of extensively researching the problem, consider a second scenario. A design team was charged with preventing a child with Down Syndrome from repeatedly chewing on her fingers, a behavior that was resulting in recurring infections. Although the mother had presented the problem clearly, team members felt they needed to make themselves experts to solve the problem in the best way. So they observed the child, talked to the childs physical therapist, and read studies on the behavior and development of Down Syndrome children. Early in a design project, you can use the following methods to research a problem and develop expertise: interview the client gather background information using both print and online sources analyze competitive and model products define user needs by interviewing and observing users, and by developing user profiles and scenarios interview experts iterate your research process
2.1 DEVELOPING A RESEARCH PLAN

You need to plan your research carefully to understand all relevant aspects of the problem and gather information efficiently. The best way to develop a useful research plan is to spend a team meeting doing the following: 1. Generate a list of questions you need to answer to become experts on the design problem. 2. Group related questions into categories. 3. Identify likely sources to answer the questions. 4. Assign each team member questions to research. Each of these steps is discussed below.
20
2.1.1 Generate a list of questions

Begin your research by formulating questions you need answered in order to understand the design problem thoroughly. To avoid overlooking any aspect, generate every possible question you can think of. You can weed out overlapping questions later. Here is an example of questions generated by a team designing a device to enable people with severe arthritis to crochet with one hand:
Example 2.1: List of research questions What is the extent of the arthritis? Is only one hand affected? Does the disease affect other areas of the body? Toward what age groups is the device targeted? Are there other users and stakeholders, besides the arthritic person, that we need to consider? What aspects of crocheting do the client, users, and other user groups want the device to improve? How is crocheting normally done? How often and for what length of time do users want to crochet? How easy will it be for a person to adapt to such a device or learn to use it? Who, if anybody, will teach the person to use it? What kinds of materials could we use and which are safe? What devices already exist for arthritic individuals? What are the pros and cons of these devices? What would be the ideal size of the device? How durable does it have to be? Should it have any specific safety features? How large a space or area do people need to crochet? If they don't use a commercial adaptive device, how do users currently address the problem? Does what they're doing work? In what settings will the device be used? Where could the device be placed when not in use? What safety concerns do the user and others (relatives, physicians, physical therapists, etc.) have? Why?
21
What social and emotional factors do we need to consider? What might limit the usability of the device for the user? How easy must the device be to use? How intuitive must using the device be? How much learning/practice is required to use the device? What's the best material to use for the crochet hook? What are the preferred dimensions of crochet hooks used for a similar purpose? What other products exist for people with the use of only one hand? Would the user typically use different sizes of crochet hooks? Can users coordinate both hands? How much should the hook cost? Will it be mass-produced or custom-made? What kinds of arthritis cause the loss of use of one hand? How does the arthritis cause this condition?
2.1.2 Group related questions into categories

That long list of questions is useful but difficult to work with, so the team grouped related questions into the following categories:
Example 2.2: Categorized list of questions Causes and extent of the disability What is the extent of the arthritis? Is only one hand affected? Does the disease affect other areas of the body? What social and emotional factors do we need to consider? Can users coordinate both hands? What kinds of arthritis cause the loss of use of one hand? How does the arthritis cause this condition? User groups Toward what age groups is the device targeted? Are there other users and stakeholders, besides the arthritic person, that we need to consider? Competitive and model products What devices already exist for arthritic individuals? What are the pros and cons of these devices? If they dont use a commercial adaptive device, how do users currently address the problem? Does what theyre doing work?
22
Whats the best material to use for a crochet hook? What are the preferred dimensions of crochet hooks used for a similar purpose? What other products exist for people with the use of only one hand? Safety What kinds of materials are safe to use? What safety concerns do the user and others (relatives, physicians, physical therapists, etc.) have? Why? Ease of use How is crocheting normally done? What aspects of crocheting would the client, users, and other user groups want the device to improve? How easy would it be for a person to adapt to such a device or to learn to use it? Who, if anybody, will teach the person to use it? What might limit the usability of the device for the user? How easy must the device be to use? How intuitive must using the device be? How much learning/practice is required to use the device? Conditions of use How often and for what length of time would they want to crochet? What would be the ideal size of the device? How durable does it have to be? How large a space or area do people need to crochet? In what settings will the device be used? Where could the device be placed when not in use? Would the user typically use different sizes of crochet hooks? Client constraints How much should it cost? Will it be mass-produced or custom-made?
2.1.3 Identify likely sources to answer the questions

You will need to consult a variety of sources to answer these questions. The sources that the crochet team decided to consult appear in parentheses after each category of research questions below. For some sources, the team was intentionally vague until members obtained specific names and titles.
Example 2.3: List of potential sources Causes and extent of the disability (client, physical therapists, medical textbooks) User groups (client)
23
Competitive and model products (client; physical therapists; users; salespeople at craft shops; websites of manufacturers, retailers, the U.S. Patent Office, and crocheters). Safety (salespeople at craft shops, physical therapists, users, physicians, materials science professors) Ease of use (users, client, crocheters, physical therapists) Conditions of use (users, crocheters) Client constraints (client)
2.1.4 Assign research questions to team members

You may assign questions based on categories or sources. For instance, if an entire category of questions can be answered by consulting medical textbooks and databases, you might assign that category to a single team member. In other cases, you may need to consult a single source to answer questions in several categories. Your client, for instance, can usually answer a wide range of questions, so you might assign one or two team members to write interview guides containing questions from multiple categories. The next section of this chapter explains how to write interview guides that you can use to gather information from clients, users, and experts. Finally, you should document team members research assignments in a Responsibility Allocation Matrix (RAM) chart, which is discussed in Chapter 17.
2.2 CONDUCTING THE INITIAL CLIENT INTERVIEW

The initial client interview serves to help you begin to define the design problem and learn about user needs and other requirements. To gain as much as possible from this interview and to establish a good working relationship with your client, you should prepare carefully and follow the guidelines below.
2.2.1 Make an appointment

Before you call the client, list times that one or more members can be present. Be flexible: Your client is probably very busy, so you will need to accommodate yourselves to his/her schedule. Tell your client that the interview will take about an hour. You may finish early, but thats better than not scheduling enough time.
2.2.2 Assign roles

If more than one team member will attend the interview, decide who will ask the questions and who will take notes. Even if you tape record the interview,
24
you should still have a note-taker in case theres a mechanical problem with the recorder. Also, be sure to get the clients permission to tape record.
2.2.3 Gather information about the project

Gather information that will allow you to ask relevant and useful questions. You can do this in several ways: Based on information you receive beforehand (for instance, a clients written description of the project), brainstorm a list of needs for various user groups. If the client is affiliated with a company or other organization, research it on the Internet or through other sources. Research competitive products. If you know that previous DTC teams have worked on the project, review their reports. Your instructors can help you gain access to those reports.
2.2.4 Write the interview guide

An interview guide will help you thoroughly understand what the client wants the design to achieve, who the users and other stakeholders are, what they need, and what constraints affect your design. Although your questions will depend on the nature of your project, the Sample Interview Guide below gives you some helpful generic questions that you should adapt to meet the needs of your project. After the interview, a team member should draft a concise, well-organized summary for team review and records. In spring quarter, you will send this summary to your client after your instructors review it. Your team should then meet to decide your next steps on the project, based on the information gathered at the interview.
Example 2.4: Sample interview guide (Note: You will need to adapt these generic questions to suit your specific client and project.) Begin your guide by introducing your team and briefly explaining what you will provide for your client: (1) a written report and final oral presentation that explain your design concept, research, and recommended next steps, and (2) a prototype that shows key functions of your design but is not necessarily a fully functional product. 1. Questions about the client (these are particularly important when your client represents a business or other organization):
25
What does your organization do? Who is served by your organization? What is your position in the organization? What is the problem that you would like us to solve? Why is this a problem? Have you or others taken steps to solve this problem? If so, what were the results, and were they positive or negative? If the problem involves improving an existing product or system: What do you like about the current product/system and why? What dont you like about it and why? Who will be the end users of this design? (NOTE: Encourage your client to give you specific demographics: age range, gender, level of experience, geographic area, etc.) Can you give us the names of users and their contact information so we can interview them later in the project? What other individuals or groups will interact with or have an interest in this design? For example, does someone have to clean, manufacture, or sell it? What requirements do you have for the design? Why are they important to you? Are there any specific features you think the design should have? Why are those features important to you? Are there any constraints on the design that we must take into account? Are there designs currently on the market that we should look at? (NOTE: If you have already researched similar designs, you might want to show the client pictures of them to solicit likes and dislikes.) Have previous designers worked on this problem for you? What designs did they develop? What were the strengths and weaknesses of those designs? May we have access to the designers final prototypes? Can you suggest experts or other people we should talk to regarding the project? Can you suggest relevant books, articles, and websites? How often would you like to receive email progress updates?
2. Questions about the problem:
3. Questions about users and other stakeholders:
4. Questions about requirements, features, constraints, and other designs:
5. Questions about research:
6. Questions about the follow-up: 7. Wrapping up the interview: End on a positive note by thanking the client and expressing enthusiasm about the project.
26
2.2.5 Write a summary of findings from the client interview

After the interview, you should summarize what you learned from the interview in a brief, well-organized report. This report serves four functions: 1. It provides team members who could not attend the interview with crucial information they need in order to participate actively on the project. 2. It provides your instructors with an understanding of the project so that they can better advise you on your research and design process. 3. It offers you an opportunity to share the summary with your client to verify that you understand the problem correctly and did not misinterpret any information from the meeting. 4. It serves as a permanent record of your research and should be included in your project folder. In writing the report, you will need to organize your findings so that readers can easily find the key information they are looking for. Despite having a well-organized list of interview questions, you may find that your client at times threw out information helter-skelter. That means that you cant just type up your notes in the order in which you wrote them down. Instead, youll need to organize them into logical categories. These categories will probably not be the same as the categories you used to organize your questions in the interview script. For an example of one teams summary of their first client meeting, see Appendix A.
2.3 USING PRINT AND ELECTRONIC SOURCES FOR RESEARCH

All DTC projects require you to do researchnot only direct meetings with clients and users, but also research in print and electronic sources. Print sources include textbooks, handbooks, specialized encyclopedias, scientific journals, trade magazines, newspapers, catalogues, pamphlets, and government publications. There are two reasons to consult print sources: (1) Often, the information you need is available only in print. (2) Print sources often provide greater detail than do websites and interviews. Print sources are especially useful for getting background and technical information. For example, if you want background information about a medical condition, its better to use a textbook or an authoritative encyclopedia than a source like Wikipedia or How Stuff Works, which are fine for personal reference but aren't considered authoritative sources for a formal report. Your engineering instructor can refer you to the standard textbooks relevant to your project.
27
Electronic sources include websites, networked databases, and electronic magazines, newspapers, and journals. Northwestern subscribes to a huge number of electronic resources that can be accessed through the NU library website: http://www.library.northwestern.edu/. For information on scientific topics in general, use Web of Science. For articles related to the biomedical field in particular, use PubMed. There are numerous other databases to which your instructors and NU librarians can refer you.
2.3.1 Using Google Scholar

Google Scholar, which is different from Google, is a particularly useful way to find electronic sources that have the kind of credible research material you need for DTC projects. This search engine allows you to find specialized journals that contain more detailed, technical information than you are likely to get from general websites on Google. In addition, the journal articles are generally refereed, meaning that before being published they go through a rigorous process of review by recognized experts. You can also use Google Scholar to find patent information on designs that address the same problem as yours. Here's how to search for information using Google Scholar: 1. After going to Google to find Scholar, type in your search terms. Figure 2.1 below shows a portion of the first page of results from a search for prosthetic devices pressure ulcers.
Figure 2.1: Search results
2. If the full text of the article is unavailable, click on Find it @ NU. This enables you to look for the full text in one of the databases subscribed to by the Northwestern University library. Figure 2.2 below shows that the full text of the article is available on four databases. You can click on any of them to read the article.
28
Figure 2.2: Find it @ NU shows where to find the article
NOTE: Because its often desirable to have the most recent available information on a topic, you can specify that you only want to see articles after a specific year. In Figure 2.3 below, the dropdown menu in the green bar has been set to find articles since 2001.
Figure 2.3: Search results limited to 2001 or later
2.3.2 Using effective search strategies

To find sources that contain the information you need, employ two strategies: (1) use specific and varied search terms, and (2) search the references listed at the end of books and articles. 1. Use specific and varied search terms. A team working on a method for preventing the development of pressure sores at the attachment point of a prosthetic, used several sets of specific search terms to research the sub-
29
ject. In some cases, they grouped terms within quotation marks to narrow the search further.
Example 2.5: Search terms for researching prosthetics causing pressure sores prosthetics cause pressure sores prosthetic devices pressure ulcers prosthetic pressure stump prosthetic skin deterioration prosthetic skin breakdown prosthetic pressure sores prevention prosthesis interior pressure
Each set of search terms yielded new sources. 2. Search the references listed at the end of books and articles. If the books and articles you find are well grounded in research, each will have a Reference page that can point you to useful sources. Often, you can link directly from the Reference listing to electronic versions of the sources. When that's not possible, use Google Scholar to find them.
2.3.3 Evaluating sources for credibility

No matter what kind of source you use, you must evaluate it for credibility. To do that, consider the following questions: What is the authors background and expertise in the subject area? Often, that information is listed at the beginning or end of the source. If it is not, do a web search for the author. For a website, what is the expertise and purpose of the sponsoring organization? A team designing a device to help prevent hamstring injuries was wise in researching the physiology of such injuries on the site of the American Academy of Orthopaedic Surgeons (AAOS) rather than on a site operated by a company that sells athletic training videos. What is the publication date (and, for a website, when was the site last updated)? Make sure information is not outdated. Did the article appear in a refereed journal (one in which all articles must be judged by experts before being accepted for publication)? Generally, the journals available in the Northwestern University library are refereed. Is the information supported by sound research and source documentation? Does the source have an obvious bias that makes its objectivity and reliability suspect? A team working on a wheelchair ramp was investigating the pros and cons of portable and permanent ramps. Because
30
they were concerned about the possibility of bias, they decided not to use information about permanent ramps from a website for a company that manufactured portable ones.
2.3.4 Keeping records of print and electronic research

You will need to record the results of your print and electronic research in several ways: in the body of reports and presentations, to support your findings and decisions (see Chapter 26 for a discussion of principles of source documentation) in the References pages of reports (see Appendices O and P for examples of formatting) in appendices of reports in your online project folder
For an example of one teams summary of their background research, see Appendix B.
2.4 ANALYZING COMPETITIVE AND MODEL PRODUCTS

Much of what you will be searching for as you begin your research are existing products that fulfill the same or similar functions as needed in your design. Analyzing existing products allows you to identify strengths and weaknesses of previous solutions to your design problem and helps you understand why and how well these products work. A competitive product is one that is geared to your users and their intended application, regardless of the technology it employs. For example, several teams recently designed a utensil that would enable stroke survivors with the use of only one hand to cut food when they dine in restaurants. Using the Internet, the teams found pictures of and specifications for several existing productsa wide-bladed knife, a t-handle rocker, a saw-shaped knife, and othersintended for the same user group and purpose. The most valuable competitive product is usually the one that your design is intended to replace. This may include a previous DTC project. A model product is one that performs functions similar to the product you are designing but is intended for different users and applications. For example, the teams who worked on the food-cutting utensil analyzed manual rotary fabric cutters used by quilters and pruning shears used by gardeners to gather ideas about cutting for their design. You also can study model products for
31
subsystems of your design. For example, if you are designing a coffee pot that shuts off automatically, you may want to analyze the auto-shutoff system in electric irons and alarm clocks to determine if these technologies apply to your product.
2.4.1 Analyzing competitive products

Begin by analyzing the product you've been asked to redesign or others that address the same user needs. To start your analysis: Obtain the product and/or detailed pictures. Here are some examples: Several teams were designing an improved device to hold wheelchairs steady while players batted during wheelchair softball games. The teams examined the current device to see how it worked, what it was made of, and how it was constructed. They also took photos from several angles and made a dimensioned drawing for further analysis. The teams working on the food-cutting utensil were not able to obtain the actual competitive products, but they found detailed photos and specifications on the websites of various retailers and manufacturers as well as dimensioned drawings from the U.S. Patent Office website. A team redesigning a crowded office space photographed the office from several angles, measured the dimensions of each cubicle and furnishing, and made a detailed, dimensioned drawing of the office.
Analyze the key features to find out why they were used and how well they function. Here are examples of this analysis from the three projects listed above: The wheelchair softball teams learned several things from their examination of the existing device: 1) It consisted of plywood and two-by-fours that had been nailed together. From this, the team deduced that the device needed to be inexpensive and easy for the players to build. 2) The dimensions were such that the wheelchair could be stabilized but not held completely still. From this, the team inferred that batters probably wanted some degree of chair movement while they swung. 3) The device was ducttaped at a few points, indicating that it had broken during use. As a result of this observation, the team decided that durability should be an important requirement. Of course, the team verified these and many other inferences and decisions with their client and users, but the key point is that they might not have even thought to ask about these things had they not analyzed the product first. The office redesign team was very glad they took photos and made dimensioned drawings of the office, because later in the
32
project they could refer to them when deciding on the dimensions of their own design alternatives. The food-cutting utensil team learned a great deal about the advantages and disadvantages of competitive products by analyzing the photos and specifications they found on websites. The following example provides the teams analysis of two competitive products; it comes from a short report summarizing the results of their research:
Example 2.6: Analysis of two competitive products The Rocker is designed to be used in a rocking motion to cut the food rather than the dragging method used by most knives. Certain models of the Rocker are collapsible, making it easy to transport to restaurants and other dining locations. It simply folds into its ergonomic handle, as in a penknife, to make it easy and safe to carry. A key disadvantage of this design is that it requires a large amount of upper leverage to be effective, which is hard for older people to achieve, especially while sitting down in a dining setting. The Saw is designed so that the handle of the knife is perpendicular to the blade for maximum leverage and ease in cutting. Like a saw cutting a piece of wood, this model uses the dragging motion to cut the piece of food. It is designed to transfer the cutting power from the arm to the center of the blade with minimal effort. The grip is large, comfortable, and fits naturally in the hand. Though this design may seem effective, it has two major flaws. First, it needs a strong stabilization device to keep the food from sliding along with the knife. And it requires a long blade to be effective, which is inconvenient for someone who wants to travel with the utensil.
The teams analysis of competitive products helped them to focus on key problems they would have to solve, such as: How would they stabilize the food if their design used a conventional sawing motion? What kind of device would minimize the upper arm strength needed to cut food? What are the most comfortable kinds of grips for various cutting devices? How would they make the device portable? In addition, the analysis gave them ideas for designing the subsystems of their product, such as a penknife design to retract the blade. Because you will use the results of your competitive products analysis to make design decisions, you must take care to be accurate. The team redesigning the crowded office space paid dearly for inaccuracy when members learned fairly late in the design process that they had mismeasured the size of the desks. As a result, the cubicles they had designed would be too small to accommodate the desks, so they had to go back to the drawing board and lost valuable time.
33
2.4.2 Analyzing model products

Look for model products that use technologies to perform functions similar to those of your product. Analyze these model products by asking how? A team designing a bicycle headlight that would quickly attach to and detach from handlebars of any diameter got ideas by analyzing vise-grip pliers, bungee cords, test tube clamps and other products. The team asked, How do these devices perform an attaching or clamping function? Are any of these methods useful for our design? This type of analysis will help you develop specifications for your design and give you ideas for technologies and materials you can use. You can also analyze model products later in the design process. One team working on the food-cutting utensil decided to focus on a scissors-like design. The teams members wanted to make the scissors grips comfortable to hold, so they went to a store that sold a variety of scissors, held the scissors themselves, and analyzed the features that added to or detracted from comfort. They even bought the most comfortable pair of scissors and used the grips to build a mockup to test with stroke patients.
2.5 DEFINING USER NEEDS

The success of a design depends on its ability to meet user needs. An innovative design will address unmet needs, and meet more needs or meet needs better than existing designs do. Therefore, identifying users and understanding their needs are crucial elements of the design process. If you have followed the process outlined thus far for interviewing the client, using print and online resources to do research, and analyzing competitive and model products, you already will have learned a good deal about users and their needs. This section of the textbook focuses on how to benefit from user interviews, user observations, and user profiles and scenarios.
2.5.1 Interviewing users about their needs

Keep in mind that an interview is more than a conversation. It is scripted dialog that has been carefully written to ensure completeness and consistency in user interviews, and to allow you to compare your findings and synthesize your information. You will get the most useful, in-depth responses by interviewing users in person, or, if thats not possible, by phone. One-on-one interviews provide the opportunity for users to delve into the why behind their answers. Although having users fill out surveys is less time-consuming, the results tend to be spotty and superficial because people arent as eager to reply to emails or take the time to write out their answers when you arent there to encourage their responses. A team that redesigned a crowded office space tried to save time
34
by dropping off surveys for the employees to fill out on their own. The team received only a few responses, and those contained unhelpful comments such as, Its hard to move around in here, which the team already knew. As a result, team members ended up doing one-on-one interviews that yielded detailed explanations of problems and possible solutions. Often, you will combine your interview with a user observation, which is explained in the following section. 1. Find users to interview. These include end-users as well as those who will manufacture, maintain, service, or sell the product. To find users to interview: Ask your client to put you in touch with users of current versions of the product. Ask your instructors how to get in touch with users. Ask family members and friends who fit your user profile if theyre willing to be interviewed. Get an early start in scheduling interviews: Some contacts can meet with you on short notice, but others require a lead-time of one to two weeks. State who referred you. People are more willing to meet with you when someone they know and respect has referred them. When saying who referred you, use proper titles (e.g., Mr., Ms., Professor, Dean). Motivate people to say yes. People are more willing to help when they understand the importance of their participation. Therefore, identify yourself as an NU engineering student and explain the nature of your project and the purpose of the interview. Ask for a response by a certain time. People tend to work better when given a deadline, so politely indicate the date by which you need to conduct the interview. Know when to follow up. When making initial contactwhether by phone, voice mail or email state that you will follow up in a few days. Use professional language. When contacting a potential interviewee by phone, be businesslike rather than too familiar or conversational. If you're communicating by email, double-check your grammar and spelling. When addressing individuals other than students or peers, use proper titles (e.g., Mr., Ms., Professor, Dean). If you're unsure of a persons title, do a little research or ask the individual how he or she prefers to be addressed. A brief, introductory explanation of your project and the purpose of the interview. You might say something like, We are working on a
2. Make an appointment. To improve your chances of securing an interview:
3. Write an interview guide, Your guide should include the following:
35
new design for a child car seat and would like to learn about your experiences with the car seat you own, or We want to find out your thoughts about a product we are designing: a deck that would fit over a bathtub to create more usable space in a bathroom. Demographic questions. Ask for information relevant to your users and project. For instance, a team designing an improved child car seat asked parents how many children they had and how many car seats they had owned in order to establish the parents level of experience with the product. Questions about existing products. Begin with easy questions such as, What features do you like about your current child car seat? Why do you like those features? What features do you dislike? Why do you dislike them? Then move on to questions that require more thought, such as those about aspects of the product you want to improve on: How do you get your child from the car seat to the stroller? How difficult or easy is that transition? Questions about opportunities and requirements for your design. Again, begin with easy-to-answer questions: What advantages would you find in a car seat that converts to a stroller? What concerns would you have about such a product? Then move on to more probing, difficult questions: What do you think is the most convenient way to unfold the seat into a stroller? Make sure to ask questions that your users are capable of answering, rather than those that require expertise.
NOTE: When appropriate, ask questions that users can respond to using numerical ratings or rankings so you can more easily compare and tabulate responses. To determine the most and least important requirements for their design, the convertible car seat team might ask users to rank requirements in numerical order:
Rank the following requirements for a convertible car-seat/ stroller in order of importance to you, with a ranking of 5 being the most important and a 1 being the least important: ___Safety ___Cost ___Appearance ___Ease of Use ___Size/Weight
Alternatively, team members might decide that because some requirements are of equal importance, they should ask users to rate each requirement:
Rate each of the following requirements on a scale of 1 to 6, with 6 being extremely important and 1 being unimportant:
36
Safety Cost Appearance East of Use Size/Weight
1 1 1 1 1
2 2 2 2 2
3 3 3 3 3
4 4 4 4 4
5 5 5 5 5
6 6 6 6 6
Make sure that your questions are worded in an unambiguous way. For instance, dont ask, On a scale of 1 to 5, with 5 being best, how do you rate your current stroller? because you will have no way of knowing what criteria your interviewee is using for the rating. Instead, ask, On a scale of 1 to 5, with 5 being best, how do you rate your current stroller in its ease of folding and unfolding? Similarly, when you ask questions that may have varying interpretations, be sure to follow up with clarifying questions. For instance, it may be useful to ask a broad question like, How versatile is your current stroller? because your interviewee may interpret the question in an unexpected way that yields valuable information for you. You may have meant that to be a question about the range of height and weight in children that the stroller can accommodate, while your interviewee interpreted the question to be about the varying weather and other conditions in which the stroller can be used, something you didnt think to ask but are now glad to have learned. Just be sure to include a clarifying question like, What range of height and weight in children has your stroller been able to accommodate? 4. Decide on a method of recording answers to questions. Options include writing them in a notebook (or below the questions in the interview guide) and tape-recording them. If you do the latter, also take notes in case your recorder malfunctions. Also be sure you obtain interviewees permission to tape-record their answers. 5. Arrive on time or early for the interview! 6. Follow the guide during the interview, but be prepared to capture unexpected information. Designate someone on your team to ask questions and another to take notes in order to make this easier. 7. Follow up with a thank you. Expressing appreciation at the end of an interview is generally sufficient, but following up with a phone call or email is good professional practice and may prompt your interviewee to provide additional feedback. 8. Organize the information youve obtained. Because you will probably interview several users, you will need to sort responses into categories and tabulate the results. Consider this example. A team was designing the front passenger seat of an automobile to make it fold down so the seat back could be used to organize belongings and hold items for school and recreation. They asked car-owners what components they would like in such a product and then organized the results in this table (Shiao, Chen, Lee, & Srinivasan, 2003):
37
Example 2.7: Table summarizing user preferences

Component Kleenex holder CD pouch Lap desk Trash receptacle Insulated food pouches with cold packs Pouch for ice scraper One large pouch Cell phone mount Several small pouches Expandable file / accordion folder Hooks Removable mirror Dry erase board Notepad / Post-it notes Pencil pouch Clipboard # of people who want it 22 20 19 19 17 13 11 11 8 7 7 6 6 5 5 1
Another team designing a patio chair for people with back problems might have devised the following template to organize comments from users about their likes and dislikes regarding existing chairs:
Example 2.8: Template for table to organize user comments
Likes User A Dislikes
: Getting in chair
: Sitting : Getting out : Other
User B
: Getting in chair
: Sitting : Getting out : Other
Some information from user interviews may not lend itself to tabular organization. In that case, summarize the information in a series of brief, well-organized paragraphs and lists.
38
9. Write a memo to your team and instructors summarizing the interview results. Use main categories to group the findings most relevant to your project. Also include tables or graphs used to summarize data succinctly.
2.5.2 Observing users

Observation is another key method for understanding users and their needs. ToBecause you are designing for real people with real needs, you must seek those people out and observe them where they encounter the problem you are attempting to solve. As Tim Brown (2009), CEO and president of design firm IDEO, comments, [A]lmost every project we undertake involves an intensive period of observation. We watch what people do (and do not do) and listen to what they say (and do not say) (p. 43). For instance, to design a better patio chair for people with back problems, watch those people getting in and out of patio chairs currently on the market: Where do they place their hands and how do they position their body as they lower themselves into the chair? Do they show signs of difficulty in performing these actions? Once they're seated, how do they move themselves into a comfortable position? How do they position their hands and body when getting out of the chair? Do they seem to have trouble doing so? By carefully observing your subjects body language and facial expressions, you can discover things they themselves are unaware of. Youll probably observe users early on using competitive products, and later interacting with the mockups you have built. For instance, although the patio chair team would not want to risk having a person with a back problem try to sit in their mockup of the chair, they could learn a great deal by watching a user grip mockups of the armrests in preparation for sitting down. Prepare yourself mentally for the environment in which you will observe, whether it be a hospital, office, home, etc. This may be your first experience doing this kind of thing, and that may lead you to take a passive approach. However, you will be much better served to go in with a confident, professional attitude. In the long run, that approach is much more likely to put users at ease and make them willing to serve as subjects. Finally, be sure to record user observations carefully. Bring the tools you need with youcamera, tape measure, graph paper, etc. Also, dont trust your memory; record the information as the observation is proceeding, and take time immediately after you leave to discuss the observations with your teammates, making further notes as you do. To get the most out of your user observations: 1. Decide what kinds of observations will help you in your project. In other words, dont observe for the sake of observing. Ideally, observations should be done with the actual products and in the actual settings in which they are normally used.
39
2. Schedule observation time when necessary. Some projects dont require a specific time, such as anonymously observing people in line at Burger King. Other observations, including those that you want to videotape, require advance planning to make sure your users are available. 3. Prepare for the observation by writing a task breakdown or task analysis. Amy Schwartz (Human Factors Director at IDEO Product Design) describes this as a list of steps required to perform the task or process you will observe. This list helps you to be a more attentive observer. The following example provides a task breakdown for the patio chair project.
Example 2.9: Task breakdown The user: a. approaches chair b. positions body in preparation for sitting c. extends arm(s) to grasp chair arm(s) d. lowers body e. readjusts hands on the chair arms f. swivels body g. raises legs to rest on the bottom portion of chair h. moves body back i. finds comfortable position
4. Write a user observation plan. This should include: Times at which each observation began and ended. The duration of the session can reveal a lot about the quality of the results. A brief introduction of yourselves, the project, and the purpose of the observation. In explaining the purpose, tell users you are watching what they do to learn how to improve the design (unless you are observing anonymously) and that they are not being tested, the product is. Explain that if they can't do or find something, chances are the design is at fault. This will put them at ease so they perform the task more naturally. Questions to get relevant demographic information. Avoid unnecessary or overly personal questions. For instance, theres no need to ask about gender when you can learn that simply through observation, and you may want to avoid questions about age when you are dealing with older users. Tasks you would like users to perform. Questions about those tasks and other issues relevant to the project. Measurements and other quantitative information you wish to record (and tools you will use to make those measurements) Tools you will use to record what happens at the observation: a. Paper and pencil for simple actions involving one user at a time.
40
b. Video recorder to capture and review subtle details. c. Digital camera for use in visual documentation and preparing a report, poster, or proposal. d. Tape recorder to supplement handwritten notes and capture users comments. e. Sketchpad or graph paper for making drawings. f. Tape measure for recording accurate dimensions.
Note: Use photo and video recording only if your team has obtained the users consent first. Take care that the users do not feel pressured to consent. Photos or videos taken to record information should have identifying tags that say who took the photo, describe the action or object represented in the photo, and include appropriate references to human subjects (i.e. references that accord with the users requests). Even if users have allowed you to make a photo or video record, this does NOT necessarily mean that they wish to be identified in the photo or video record. Be sure to find out if participants want you to use their names or wish to preserve their anonymity. In certain cases, you may need to use Photoshop or video editing programs to block out a users identifying features. For an example of a teams observation plan, see Appendix C. 5. After completing your observations, summarize the results. Provide an overview of key aspects of the session. Your teams record of user observations or testing should include basic elements to help your reader understand the conditions under which you conducted this research. It is especially important to provide readers with a detailed context for user testing, because the results of those tests will likely provide the basis for your team's decision to pursue one design strategy over another. Basic elements of the overview include the following: Date, location, and key persons in attendance Conditions of observations. For instance, were you at practice for an athletic event? In a clinical setting? At the user's home? Recognize that the context imposes certain limitations on what you can learn from that set of data (e.g., conditions in a clinic are likely to be significantly different from conditions in a users home). Explain those limitations in your summary. User groups and sub-groups. Take note of differences among users and their habits or responses to your design ideas. Sometimes unique characteristics of a certain user may dictate his or her response to a design and point up issues that your team may not have anticipated. For example, athletes who use wheelchairs may include both users with paraplegia and users who have had limbs amputated. These users will likely have varying levels of
41
abdominal and back strength or control of those muscles, and may thus interact with designs quite differently. Create a table of observations, opportunities, and follow-up. In the first column, note key observations; if they are complex, use a separate sheet of paper for each step in the process. In the second column, list the design opportunities suggested by the observations. In the third column, list the directions the team would take to follow up on those opportunities. Below is a portion of the observations table compiled by the patio chair team:
Example 2.10: Portion of an observation results table
Observations User grips chair arms tightly Opportunities Prevent users from cutting or chafing their hands Make it easier to grab the middle of the chair arms Have the chair back provide support as the user pulls forward Follow-up Put padding on chair arms
User initially pulls self forward by grasping the middle of the chair arms User displays discomfort when pulling self forward and away from the chair back
Include pegs or other kinds of grips at the middle of the chair arms Include a spring at the base of the chair back to allow it to move forward with the user
Organize measurements and other quantitative data in a table or other easy-to-read format. Provide captions and credits for photos. Be sure that user anonymity is preserved by editing and cropping photos as necessary. Captions can point out significant details as appropriate.
For an example of a teams summary of findings from the user observation, see Appendix D.
2.5.3 Creating user profiles and scenarios

To develop a good design, you need to ask yourself, What are these users like and how will they use this design? You can learn a lot about users even when you arent observing them if you can imagine what its like to be in their situation. A powerful way to answer these questions is to engage in a special kind of role-play: that is, by generating user profiles and scenarios. A user profile is an imaginary but detailed portrait of a typical user for your design. Its like a snapshot that will help you think of your user as a real person and an individual. Here are two profiles for a curbside mailbox designed to be theftproof, vandal-proof, and crash-proof.
42
Example 2.11: User profiles
Claire is 69 and has lived in her home in the country for more than 40 years. She likes to do everything for herself, but lately shes been having problems with mobility. For the last few months, shes been walking with a cane and doesnt get out much. Instead, she does more mail-order shopping. Every morning she walks down to the mailbox at the front of her property to leave letters for the mail carrier, and walks back in the afternoon to pick up her mail, which usually includes catalogues and packages. Claire is becoming increasingly nervous about leaving her mail at the mailbox because of some recent mail thefts in the neighborhood. Mickey is 7, and one of his daily chores is to retrieve the mail from the curbside mailbox. Because his mother has told him he cant go into the street, he has a hard time reaching into the front of the mailbox to get the mail. These user profiles provide a more detailed picture of your users than words like old people and children. If a user profile is like a snapshot, then a scenario is like a short video clip. It imagines these users using the design. Here is a scenario created for the curbside mailbox:
Example 2.12: Scenario
When Kim arrived at work at Dr. Bradys office Monday morning, she needed to retrieve the mail that had been delivered on Saturday. The office is on Route 73, a busy road. At 9 a.m., commuters whiz by at 65 miles an hour. Kim walks down to the mailbox at the curbside and waits 45 seconds for a break in the traffic before stepping into the street to get the mail from the box. She unhooks the mailbox door and digs out six medical supply catalogues, 15 bills, and five advertising circulars. By the time she gathers all this, traffic whizzes by again. Oops! Kim drops an envelope, and its soon run over by a Ford Bronco. She scrambles out of the way of the traffic, but neglects to refasten the mailbox door, and the flap protrudes into the street. Kim begins to lean over to relatch it when a Chrysler minivan zooms by, trying to make the light at the corner. He clips the mailbox flap, tearing it off its hinges. Jeez, Kim says, we have to fix this thing again. Its the third time this year. Why concoct such an elaborate story? Because it lets you visualize a potentially real situation and the challenges that go along with it. You can practically see Kim, nerves on edge, cursing the traffic and the mailbox, trying to keep hold of her catalogues, retrieve her fallen bill, and get the mailbox
43
latched before its ripped from its hinges. What would make her job easier and safer? How can she avoid the traffic problem? Envisioning the problems of Kim, Claire, and Mickey helps you develop requirements and specifications for your design (see Chapter 3).
2.6 INTERVIEWING EXPERTS

Experts can give you the information you need for your project and teach you about technologies that may be critical to your design. They can also tell you what users want, who your competitors are, what shortcomings plague existing products, what regulations are imposed by governmental agencies, and many other facts that influence your overall design. Like client and user interviews, an expert interview uses scripted questions that flow logically from one topic to another. Although you may not follow your guide word-for-word, it will serve as your overall map for the interview.
2.6.1 Guidelines for interviewing experts

As you might suspect, several of these guidelines are the same as those used in the interview guidelines described earlier in this chapter.
Before the interview

1. Define your objectives. Early in your project, experts can provide background information and a better understanding of current designs. For example, an DTC team designing a product to melt ice blockages in drain pipes met with a plumber early in the process to get a sense of how common this problem is and how plumbers solve it. Later in the process, experts might offer information about alternative technologies or help in analyzing a new design. Because an interview shouldnt last more than an hour, limit your objectives to what can be covered in that block of time. 2. Identify experts by using these resources: Your client. In addition to technical expertise, he or she may be able to put you in touch with other experts in the field. Your instructors. They can provide you with background information and technical expertise. Other NU professors. For technical questions, theres probably a professor at Northwestern who has the answer. Family and friends. DTC students frequently find that parents, relatives, and family friends have the answers to their questions. Salespeople and product consultants. People who sell products similar to the one you're designing can provide a wealth of information as well as help you select materials and components for your prototype.
44
3. Make an appointment. To improve your chances of securing an interview, review the guidelines for making appointments earlier in this chapter. 4. Gather information and create sketches. If the objective of the interview is to generate requirements and specifications, or to identify problems with current designs, you will ask better questions and get more useful responses by analyzing a few current designs. Later, when youre trying to solve a difficult technical problem, make drawings or mockups of your current design. 5. Generate a list of questions for the interview. You will want to ask different kinds of questions depending on the objectives of your interview. a. At the start of your project, you need to find out about previous design solutions. Some generic questions for background interviewing are: Who are the users and stakeholders of the product? If we change X aspect of the product, what are the consequences? What modifications of the product have been tried before? Why are there problems with the product?
b. Another objective for interviewing an expert is to define the design requirements by asking about competitive products, so make a point of bringing a competitive product (or a sketch of it). Some generic questions for interviewing about products, devices, systems, or spaces are: What is the rationale for feature A? What are the problems with this feature? How does feature A work? What are the advantages of design X over Y and vice versa? What are the strengths of this design? What are the weaknesses of this design? What is the best-designed component you've seen?
c. Later in the project, you will have specific questions about the feasibility of your design concept and about materials and components for your prototype. Generic questions for interviewing about the features of your design concept and prototype are the following: Are there problems with feature A? What are some solutions to these problems or alternative features to consider? What materials and components should we consider for feature A? What are the pros and cons of each material and component? How can we test feature A? What are we missing in this design concept?
45
At the interview
1. Arrive on time. 2. Introduce yourself, your project, and its purpose. Even if you mentioned these things in your initial email or telephone conversation, its good to do so again. 3. Speak clearly and be sure the expert understands your question. 4. Listen carefully. If you dont understand an answer, dont be afraid to ask for clarification; you may have to ask Why? more than once to get the information you need. 5. Record the answers. Options include writing them in a notebook (or below the questions in the interview guide) and tape-recording them. If you do the latter, also take notes in case your recorder malfunctions. Also be sure you obtain interviewees permission in advance to tape-record their answers. 6. Keep returning to the guide. If the answers start to wander, bring the conversation back to its purpose. 7. Be flexible. If an answer triggers a question not in the guide, go ahead and ask it. 8. Dont argue. Experts may make incorrect statements or state opinions as facts. Dont call them on these; instead, probe more deeply to understand why they hold their opinion. Putting them on the defensive may make them less willing to share their knowledge with you. 9. Follow up with a thank you. Expressing appreciation at the end of an interview is generally sufficient, but following up with a phone call or email is good professional practice and may prompt your interviewee to provide additional feedback For an example of a teams guide for interviewing an expert, see Appendix E.
After the interview

1. Organize the information. Despite having a well-organized interview guide, you may find that the expert at times threw out information helterskelter, and you'll have to sort it into categories. 2. Determine which information is relevant to your project and use it appropriately. A team designing a device to prevent paint from freezing learned from an electrical engineering professor that even for paints listed as not flammable there is a fire risk in inserting an electrical heating device into the can. Despite that information, the team developed one alternative that included a battery-operated heating element inserted in the can of paint. The experts information should have led them to rule out this alternative. 3. Determine what additional information you now need and how to get it. The expert might not have been able to answer all your questions, may
46
have suggested new ones, or may have been able to give only part of an answer. 4. Write a memo summarizing the interview results for your teammates and instructors. The summary should include the main categories of information you got (#1 above), the most relevant information (#2 above), and the new questions you now have to answer (#3 above). For an example of a teams summary of findings from their expert interview, see Appendix F.
2.7 ITERATING YOUR RESEARCH AND WRITING IT UP

In this chapter, we have emphasized doing research to make yourself an expert in the early stages of the project. However, as discussed in Chapter 1, design is an iterative, recursive process. Therefore, you will find that you need to do research at later stages of the project, too. One team found this out while designing a paper-shredding device for developmentally disabled youths enrolled in a vocational training program. After the team decided on their design concept and its components, they still needed to interview a materials science professor to find out about plastics, research the McMaster-Carr catalogue to find out about the specifications of various electronic components, and interview an electrical engineering professor to learn about circuitry. At each new stage in the interview process, they needed to return to the techniques outlined in this chapter, and then to re-evaluate their research summaries and project definition in light of their new research findings. Even though they may have written excellent summaries of their research earlier, they needed to revise those summaries as they went along. Design is a continuous process of analysis and synthesis. Early in your research, you analyze what you learn about the clients wishes, the users needs, important background information, and previously tried solutions. You decide what is most relevant to your design problem and then summarize it for yourself. But, as you accumulate more information from additional sources, you have to synthesize that information in your notes. Sometimes this synthesis takes the form of a short report, such as a memo to your instructors. Sometimes its a table comparing information about other solutions on the market. As you continue to gather information, you need to continue to highlight important information, eliminate irrelevant information, and apply what you learn to your design problem. Consider how your team will act on this new information, and why your client should care about it. A team designing a highchair footrest for children with Down Syndrome and cerebral palsy did extensive research online about those two medical conditions. They learned that many children with cerebral palsy exhibit spastic movements in their legs that can be quite intense. Therefore, the team made sure that their footrest
47
would be able to withstand the force of these repeated impacts. As they learned more about their users needs, they continued to refine the requirements for their design. A key point of thinking in designwhether youre doing the design itself or writing up your research resultsis to synthesize your researched information. Bring together information from sources in a way that makes sense to your teammates and to others who will be reading your reports. Organize your research so that it supports the decisions that lead to your design and backs up your claims about your designs effectiveness The amount of research and the kind of research you do are crucial to good design, but so are the ways in which you think about that research and write it up for others to understand what youve done.
2.8 REFERENCES
Brown, T. (2009). Change by design. New York: HarperCollins. Cornew, D., Cory, C., Laning, E. & Park, Tim. (2008). The BEST Approach to Leg Press Feet Stabilization. Engineering Design and Communication, Northwestern University. Shiao, C., Chen, S., Lee, C. & Srinivasan, S. (2003). Progress report #4. Engineering Design and Communication, Northwestern University. Hoffman, J., Kessler, J., Schickli, E. & Smith, A. (2005). Pediatrician interview guide. Engineering Design and Communication, Northwestern University.
48
Chapter 3: Writing the Project Definition
CHAPTER 3: WRITING THE PROJECT DEFINITION
Chapter outline
Mission statement Project deliverables Constraints Users and stakeholders Requirements Specifications Format for the project definition Development of the project definition
Key Guidelines for Writing the Project Definition

Write a solution-independent mission statement that includes measurable goals State the deliverables that will be given to the client at the end of the project Identify constraints imposed by the client and regulatory agencies Identify requirements through client interviews, user observation, and other research Define requirements in terms of precise, quantitative specifications Revise the project definition periodically to reflect what you learn through research and testing
As you conduct the research outlined in Chapter 2, you will get a clearer idea of the problem your design must solve. In DTC, you keep track of the formulation of the problem through a document called a project definition, which is composed of five parts: Mission statement: a concise, solution-independent statement of the problem to be solved. Project deliverables: a description of what will be given to the client at the end of the quarter, for example a works-like prototype or alternatively a proof-of-concept scale model.
49
Constraints: limitations imposed on the design by the client, regulators, or other stakeholders (in some cases, these design constraints will not apply to the project deliverable). Users and stakeholders: those who will use, produce, market, install, maintain, or in other ways interact with the product; also, those in the larger community who will be affected by the product. Requirements and specifications: the needs that the users and stakeholders want the design to fulfill, and the measurable values associated with those needs. Engineers translate requirements into specifications as part of the design process.
A project definition goes by a variety of names in the engineering workplace. User requirements, functional requirements and constraints, engineering specification, and the spec are just a few of these terms. Whatever it is called, the project definition is a living document that parallels the creation of the design itself. Although common sense may suggest otherwise, you dont write the document first and then create the design. Instead, the document evolves along with your research and testing. The initial version typically has a first-draft mission statement, a general description of the final deliverable, perhaps a few client constraints, and some broad user requirements, such as easy to install. As you learn more about users, your project definition will become more detailed, specific, and focused. For example, an early version of a project definition documenting the design of an innovative desk organization system might include the specification, must reduce desk clutter. Later versions might specify that the system must keep at least 50% of total desk space free of documents not currently in use. As you add detail, your project definition will grow, even as you eliminate requirements and specifications that prove irrelevant or unnecessary or too costly. The bottom line is that your final project definition will contain all the requirements of your design and the metrics for measuring its success. A project definitions main function is to describe the purpose of the design, how it will work, and how a user will interact with it so that the team, the client, and the supervisors can evaluate the design. You may be wondering if it wouldnt be easier and more efficient to just observe how well the design works. The reality is that members of the design team need a project definition to help them evaluate as they are designing. If they are unable to express what the design must do to meet the requirements of users, clients, and other stakeholders, they wont be able to tell if their design will succeed. The project definition also typically outlives the design team, allowing others to make the customary revisions and improvements. When you first create your project definition, it will be solution-independent. That is, it will describe what the solution must do, but it will not actually describe the solution. This stage is necessary because it allows your team to stay open to various solutions and explains to those who get involved later in the project the reasoning behind your selection of features. In later versions,
50
as you zero in on a solution, the project definition will include the specifics of that solution, as discussed at the end of this chapter. In Appendix G you will find an example of how a DTC project definition evolved over the course of the project. The team was designing a method of storing rainwater in a village in Kenya. The following sections describe each part of the project definition in more detail.
3.1 MISSION STATEMENT

A good mission statement not only succinctly summarizes the problem to be solved, but also provides direction and tells others what you are trying to accomplish. Following are guidelines for writing a good mission statement.
3.1.1 Guidelines for writing a mission statement

1. Phrase your mission statement in a solution-independent way to help you ascertain the problem. For example, a client who needed something to organize her work asked a DTC team to design an under-the-desk, rotating filing system. After they observed her at her desk, team members realized the client needed a system that would allow her to keep work in view, not under her desk. They developed this mission statement:
To design a physical structure (or structures) that significantly improves our clients organization of her supplies, loose papers, and folders/projects and that she can easily use while seated at her desk.
Although this statement contains focusing assumptions about the design (it will be a physical structure rather than a set of instructions or techniques for changing her work habits), it doesnt go into detail about the features of the solution. Had the team designed an under-the-desk system, it would have proven unsatisfactory to the client since it would not support her observed work style. 2. Emphasize measurable objectives that allow you to determine whether you have accomplished your goal. The versions below illustrate how a mission statement was revised to emphasize measurable results:
Original mission statement: Design a soda vending machine with a user-friendly, off-the-ground dispensing bin.
Apart from the fact that it includes a solution (off-the-ground), the statement makes it difficult to measure the success of the design because the term user-friendly is subjective and difficult to quantify. A better mission statement would be:
51
Improved mission statement: Design a soda vending machine with a dispensing bin that can be reached with minimal bending.
Now the team can observe and measure the amount of bending users need to do and whether it is a comfortable solution. The team working on the rain harvesting project crafted the following mission statement in conjunction with their client, a representative of a non-profit organization dedicated to helping Kenyans improve their quality of life:
Example 3.1: Mission statement for rain harvesting project Design a physical structure for homes in Ribe, Kenya, that can collect and store enough clear but unsanitized water from rainfall during the rainy season to satisfy daily household needs for the rest of the year.
The team asked the client about the possibility of developing a centralized, rather than home-by-home, solution. However, because of the difficulties of distributing water from a centralized location, he requested that the team integrate the design with individual homes. In addition, to make the project more feasible for the team to complete, he told them not to consider the issue of water purification in their design. Instead, that would be dealt with in later phases of the project.
3.2 PROJECT DELIVERABLES

Having a clear idea of what you need to hand off to the client at the end of the quarter allows you to plan more effectively for that goal. Different types of projects will need different types of deliverables based on what is feasible in the context of DTC. For example, a team designing a means for someone to chop vegetables with one hand can create a working prototype that reflects both the intended appearance and function of their design. But a team designing a lift system to help people with spinal cord injuries to get in and out of a pool may not be able to build a working prototype. Instead, they can deliver a conceptual design and a model that demonstrates the intended function, but is not capable of being used in a pool with users. When delivering a fully functional prototype isnt possible, proof of design function can be supported with partial mock-ups demonstrating key subsystems, performance test results, along with analysis and calculations. In all cases, thorough graphic illustrations of the design should be part of the project deliverables.
3.3 CONSTRAINTS
Almost all projects are subject to constraints, usually imposed by the client and related to scope, cost, and regulatory approval. Constraints cannot be changed and therefore limit the design space you explore. For example the
52
client may specify that the design must be manufactured using existing equipment in the factory, or that each unit must cost less than 30 cents to make. Constraints may also be imposed by industry standards and regulatory agencies (for instance, Americans with Disabilities Act guidelines). If a client imposes constraints, review them carefully to understand why the client thinks they are essential. If no clear rationale is stated, talk to your client about eliminating the constraint. For instance, a client initially said he wanted a beach umbrella that would hold its ground in windy conditions. The design team asked him if the final design had to be an umbrella (as opposed to a canopy or tent). In other words, they wanted to know if umbrella was a constraint on the design. The client said that it wasnt, so the team had free rein to consider other possibilities. Things could have gone the other way, however, with the client saying it had to be an umbrella, perhaps because he manufactured beach umbrellas and wanted to use existing factory equipment. After discussing possible constraints with the client, the rain harvesting team ultimately had just one:
Example 3.2: Constraint for the rain harvesting project Constraint Enough water must be collected to support the needs of each family in a cluster of homes (about 100 L/day)
The client imposed this constraint because he believed that this way of determining water needs would be most equitable for the village. Some students confuse constraints with user requirements. Here are two ways to distinguish constraints from requirements: 1. A constraint can be satisfied in only one way, whereas, generally, a requirement may be satisfied in a number of ways. For instance, if you are designing a method for securing a wheelchair in a motor vehicle so that someone can sit in it safely when the vehicle is in operation, safety would be a requirement because there are potentially many ways that you could make the device safe. However, a constraint would be if your design must conform to the WC19 industry standard mandating four specific, labeled securement points on the wheelchair. 2. A constraint is generally dictated by the client or a regulatory agency, whereas a requirement generally addresses a user need. For instance, if you are designing a small computing device, the requirement might be that it have a display that can be used in a wide range of lighting conditions because your research has shown that users want that. A constraint might be that your client wants the device to use the same battery as is used in other computers manufactured by the company (Creative Industries Research Institute).
53
3.4 USERS AND STAKEHOLDERS

Composed of all those who are affected by a products success or failure, users and stakeholders fall into the following categories: Primary users: end users, the client, and anyone else who makes important decisions about buying, using, or maintaining the product. Primary users can be subdivided into demographic groups. For example, a team charged with designing a highchair footrest to help children with Down Syndrome and cerebral palsy sit up straight while eating divided their primary users into three groups: children with Down Syndrome and cerebral palsy who have trouble sitting up straight while eating (end users of the product) the parents of these children, who will purchase, install, and adjust the footrest for their child childcare workers at daycare centers, who will need to adjust the footrest for different-size children with different physical conditions
The rain harvesting team identified one primary user group besides the client: people in Ribe, Kenya, who will live in homes with and help to build the structure. Secondary users: those employed in the client's various departments (manufacturing operation, service, marketing, etc.). Secondary users also include those will interact with the product at some point: installers, repair people, salespeople, and others. In the case of the rain harvesting project, the secondary users were other people living in Ribe. Other stakeholders: Regulatory agencies, community organizations, and others who are somehow affected by the design and have an interest in its functioning. The rain harvesting team identified these stakeholders: funding agencies who will help pay for the project and the Kenyan government.
3.5 REQUIREMENTS
As a designer, one of your major tasks is to uncover the requirements of your users and stakeholders: the needs the design should fulfill for them. Its important to keep in mind that users and stakeholders are not always aware of or able to articulate requirements. For example, users testing cell phones may not have known they needed a built-in address book until they were in a situation where they needed a phone number quickly. To see how teams uncover user and stakeholder requirements, review the process used by the rain harvesting team. Members conducted research, following the methods outlined in Chapter 2 and illustrated in Figure 3.1 Understanding user requirements below.
54
Interviewing and observing
Research in print and online sources
USER REQUIREMENTS
Analyzing competitive and model products
Developing user profiles and scenarios
Figure 3.1: Understanding user requirements
3.5.1 Identifying client requirements

Face-to-face meetings provide a good opportunity to identify client requirements (although some clients may give you written specifications). Asking clients the reason for each requirement will help you understand their thinking. The rain harvesting team uncovered the following requirements in their initial client interview: Store enough water to last through the dry season Have a method to dispense water to users Have a way to convey rainwater from rooftop to storage unit Resist deterioration from exposure to climate in Ribe Allow for later modifications, such as sanitizing of water and harvesting of solar energy
3.5.2 Identifying the requirements of primary and secondary users

You can identify the requirements of primary and secondary users through observation; interviews; analysis of competitive products; online and print sources; and user profiles and scenarios. Because their primary users live in Kenya, the rain harvesting team was unable to conduct user observations and interviews. However, they were able to do other kinds of research that enabled them to understand user needs: methods of rain harvesting used in other areas
55
of the world, the amount of water needed by people in African countries for various uses, types of homes in Ribe, typical family size in Ribe, technical abilities of residents, climatic conditions in the area, etc. Through this research, they were able to add to their list of requirements: prevent physical contaminants from entering the water so that residents are willing to use it be adaptable to types of roofs in Ribe prevent water from being lost or contaminated during repairs to the storage unit
3.5.3 Identifying community requirements

Most engineering designs affect the broader community in some way. For instance, automobiles produce pollutants and require massive regular road maintenance. There are literally hundreds of public and private organizations that set standards and regulations. Some of the better-known ones are the Food and Drug Administration (FDA), the Federal Communications Commission (FCC), the Federal Aviation Administration (FAA), the American National Standards Institute (ANSI), the Consumer Product Safety Commission (CPSC) and various professional societies such as IEEE, ASME, and ASCE. Virtually every engineering design has to meet a set of standards or regulations. The rain harvesting team researched other projects undertaken by the community of Ribe to determine the level of cooperation and technical expertise they could expect within the community. They also researched applicable standards for rainwater harvesting reported on by the Global Development Research Center. As a result, they added these requirements: be constructed as much as possible from local materials to save money be simple enough for local workers to construct and maintain
3.5.4 Organizing requirements into categories

As you pursue your research, your requirements list will grow longer. To make it easier to work with, you should place the requirements into appropriate categories. Here are two of the categories developed by the rain harvesting team:
Example 3.3: Requirements for rain harvesting project Water storage Store enough water to last through the dry season Limit loss of water due to evaporation
56
Safety Prevent physical contaminants from entering the stored water Keep water clean enough to be made safe for consumption through boiling
3.6 SPECIFICATIONS
Once engineers identify user and stakeholder requirements, they must turn them into precise, measurable terms to evaluate whether their design satisfies those requirements. For instance, a team designed a traffic flow plan for parents dropping off and picking up their children in a grade school parking lot. The team couldnt merely specify that parents need to be able to drop their children off quickly and efficiently. They needed to apply quickly and efficiently to a specific number of cars, a time period, and specific circumstances. After observing the parking lot for several mornings, the team determined the following specifications for the morning drop-off period: 75 cars need to park to drop off children between 7:55 and 8:15 a.m. 50 non-parking cars need a fast way (less than two minutes each) to drop off children between 7:55 and 8:15 a.m. it must be safe for 50 cars to move through the parking lot between 8:10 and 8:15 a.m. 294 children need to be delivered to the main building between 7:55 and 8:15 a.m. 35 preschoolers need to be dropped off between 8:25 and 8:35 a.m.
These specificationswhich were verified by the clientmade it possible for the team to measure the viability of alternative design solutions, revise their proposed designs to meet user requirements, and test the success of their final design. In presenting their final design to the client, the team could demonstrate how their traffic flow pattern could accommodate 75 parked cars and 50 non-parking cars in the 20-minute drop-off period. Metrics are used even for requirements that are difficult to quantify. For the highchair footrest project, the team determined from user interviews that the footrest must be easy to clean because of the food that children would drop on it and grind in with their feet. Easy to clean sounds self-evident and sufficient, but it does need to be specified with metrics: How much time will parents and daycare providers be willing to spend cleaning the footrest? How deep must a groove be before it becomes difficult to clean? How narrow a space at a joint will make it difficult to clean out debris? No matter the design, engineers need metrics to precisely evaluate the viability and success of their concepts.
57
In their original project definition, the rain harvesting team lacked the information to develop specifications with metrics. As they did more research, they were able to add these metrics or put placeholders (in the form of XX) for metrics. Here's how their specification evolved for the amount of water that must be stored in a tank:
Example 3.4: Specifications, with metrics, for rain harvesting project Version 1: Must store XXX liters of water Version 2: Must store 4000 liters of water Version 3: Must store 50,000 liters of water
The specification changed from version 2 to 3 to reflect the teams decision to design a storage tank that would accommodate a cluster of households rather than a single one. The team made this important decision in consultation both with their client and professors. This change illustrates how the specifications become more solution-dependent as the project moves toward completion. Specifications must be derived from research, not guesswork. To define the amount of water a tank needed to hold, the rain harvesting team researched the amount of rainfall in that area of Kenya over a ten-year period, the daily water needs of residents of rural Kenya, and the average family size in Ribe. One final note about specifications: most requirements must be linked to metrics to evaluate the success of a design. Some requirements, however, are simply binarythe design either meets them or doesnt. The parking lot traffic flow team stipulated that the existing entrance and exit of the parking lot be used in their design. This needs no further specification. Subjective requirements, such as aesthetically pleasing, also tend not to be linked to numerical metrics. Instead, the specifications for aesthetically pleasing, might be the emotional qualities you want the design to convey to users. For instance, suppose you are designing a new video game controller for people with severely limited use of their hands. Through user interviews and testing, you learn that the aesthetic qualities these users want in the design are captured by the words sleek, powerful, and dynamic. Those terms would become your specifications, and you would test your prototype with users to ensure that it conveyed those qualities to them.
3.7 FORMAT FOR THE PROJECT DEFINITION

As you enter upper level design classes and various workplace settings, you will find a variety of formats used to document a design. The format we use in DTC has two beneficial characteristics: (1) The project definition is easy to update as the design evolves. (2) The table format helps designers see the relationship between requirements and specifications. The example below shows
58
the general structure of a project definition. Appendix G shows how the rain harvesting team used this structure.
Example 3.5: General structure of a project definition Project name: Client: Team members: Date: Version: Mission statement: Project deliverables: Constraints: Users and stakeholders:
Requirements
Specifications
3.8 DEVELOPMENT OF THE PROJECT DEFINITION

You will produce several versions of the project definition, each more complete and detailed than the previous one. The first version, written early in the project, may have a sketchy mission statement, constraints learned from the client, and a few potential requirements picked up from initial reading. As you do further research and testing, the project definition will change in many ways, such as: The mission statement will become more well-defined The project deliverables will become more well-defined You may add or delete constraints The list of requirements will expand and become more refined You will put specifications (with metrics) next to requirements
59
Your specifications will become more solution-dependent as you settle on a particular design. For instance, at a certain point the rain harvesting team decided, in consultation with their client and instructors, that the solution would involve installing one water tank for each cluster of four-to-six households. They calculated the storage capacity based on that decision rather than, as they had earlier, on the basis of one tank per household.
See Appendix G for an illustration of the development of the rain harvesting team's project definition. Finally, it is essential that you keep a copy of each version of your project definition in your project folder. These sequential drafts, which provide a paper trail of your thinking, are obligatory if your design turns out to be patentable or if you hand off your design to a new design team or product developers. If a future team wants to understand the rationale for a requirement, for example, they will be able to trace its evolution through your project definition.
3.9 REFERENCES
Creative Industries Research Institute. (n.d.) Requirements and constraints matrix. Retrieved July 25, 2012 from < www.ciri.org.nz/downloads/ Requirements%20and%20Constraints.pdf> Hawley, A., King-Bey, D., Perry, B., Tilley, A. (2010). Project definition: Water harvesting in Ribe. Engineering Design and Communication, Northwestern University.
60
Chapter 4: Generating Alternatives
CHAPTER 4: GENERATING ALTERNATIVES
Chapter outline
Brainstorming Generating alternative design concepts Creating mockups for user testing
Key guidelines for generating alternatives

Generate a large number of possible solutions to the design problem by following the rules of brainstorming: Defer judgment Build on the ideas of others One conversation at a time Stay focused on the topic Encourage wild ideas
Sketch your ideas while you brainstorm Develop several design concepts for testing by making an alternatives matrix Sketch and then build low-tech mockups of your alternative design concepts
Once you have begun to research and define the problem, its time to start generating solutions, an activity that continues in one form or another throughout the design process. Notice that we speak of solutions in the plural. Why bother to generate multiple solutions, when the best one may seem obvious to you? Here are just a few reasons: To stimulate your teams creativity. Its the most important reason for generating alternatives because it allows team members to approach the problem from different directions, build on each others ideas, and then choose the solution that combines the best of those ideas. To make the design process more efficient. Focusing on one design concept is like putting all your eggs in one basket: If, after months of work, your design doesnt pan out, youve wasted a lot of time and effort. By
61
testing, eliminating, adding, revising, and refining several alternatives, you learn early on which ideas work and which dont. To narrow down users preferences and more efficiently assess their needs. Giving users several solutions to test helps you better understand what they need, which elements of your designs best meet those needs, and which features should be eliminated, changed, or added. Ask users general questions about their needs, and theyll tell you what they think they like. Show them several designs and let them compare them, and youll get more helpful, specific answers. To improve the designs ability to achieve multiple objectives. By generating a variety of alternatives that incorporate different functions, you can use the best features of each. For instance, if one alternative is easy to use and another is more durable, you can figure out how to incorporate features of both into the same product. NOTE: Rather than have each team member develop his or her own design and then compete to see whos the winner, its more productive to work together on each alternative, and then take the best elements of each to produce your final design. The next sections take you through the process of creating alternatives by brainstorming, generating multiple design concepts, and making mockups. The following chapter explains how to gain valuable information from those alternatives through user and performance testing.
4.1 BRAINSTORMING
Good engineering design requires creativity in developing solutions to problems. But our own ingrained attitudes can interfere with our ability to think creatively. A voice inside our head may censor ideas by saying, Well, its always been done that way, so that must be the best solution. Or, That idea will sound too weird to my team. Or, Lets just evaluate and reject each possible solution until we figure out the right one. To get beyond these restrictive attitudes, designers use the tried-and-true technique of brainstorming. Developed in the 1930s by advertising executive Alex F. Osborne, brainstorming involves generating a large number of ideas quickly, a process which sets off a chain reaction of creative thinking. Brainstorming is especially useful at the start of the design process, when you want to be open to as many perspectives as possible. In the later stages, brainstorming is effective when you need to generate alternatives or possible modifications of a design, or when you get stuck at any point in the design process.
62
The goal of brainstorming is to generate as many ideas as possible in a limited amount of time. Two other steps usually follow it: clustering brainstormed ideas according to similarities, and then evaluating those clusters.
4.1.1 Ground rules for brainstorming sessions

IDEO, a leading international design firm, recommends that teams follow these rules for brainstorming (copyright IDEO Product Development, used with permission): 1. Defer judgment. This is the hardest rule to follow, in part because were used to making quick judgments. But quick judging tends to block our flow of ideas and dampens the spirit of the session, making other people hesitate to contribute their ideas. 2. Build on the ideas of others. Youll quickly learn that you dont need a whole idea to keep things going. Half an idea will work just fine, because someone else will pick up on what he or she thought you meant and turn it into something else. The secrets of success are being generous with your own ideas and picking up on others half-baked (or even fully baked) ideas. 3. One conversation at a time. It gets exciting when several people cant wait to get their ideas out on the table, but to keep the energy flowing and frustration at a minimum, the facilitator must remind participants to let the first person get his or her idea out before going on to the next person. 4. Stay focused on the topic. The thrill of the chase can often lead far from the design problem at hand. To avoid straying too far afield, convey that seemingly off-topic idea in a way that relates. These unplanned force-fits can be a delightful surprise. 5. Encourage wild ideas. Get radical, improbable, unrealistic, impractical, primitive, and even dangerous in your thinking. Your wild ideas are a great way to spark solutions in fellow brainstormers. 6. Quantity, not quality. Your goal is to generate as many ideas as possible, not just good ideas. See above for inspiration. 7. Draw it. A picture really is worth a thousand words when it comes to helping explain a concept and recording it in detail. Pictures also allow you to see connections between ideas that words may not reveal. Be sure you sketch each idea and number your sketch.
4.1.2 Facilitator guidelines

Brainstorms dont just happen; someone has to lead them. That person is the facilitator, who needs to: 1. Prepare for the brainstorm. Collect objects that are relevant to the problem you are brainstorming about. For example, if you're brainstorming about a soda vending machine, bring several unopened bottles and cans of
63
soda and loose change. Also bring plenty of paper and colored pens or markers, as well as a snack (M&Ms work well). Being well prepared and keeping a high level of energy at the session will increase the success of the brainstorming. 2. Break the ice. Do five minutes or so of game playing, then have everyone sketch something simple but relevant. For a brainstorm on soda vending machines, for example, have everyone spend 30 seconds sketching a Coke bottle, the pull-tab on a soda can, or the front of a vending machine. As the brainstorm proceeds, keep it light and spirited. 3. Write a one-sentence problem statement on the board. If the problem is complex, break the concept into simple parts and brainstorm each one. For example, if your design problem is to create a curbside mailbox that withstands car crashes, vandalism, and attempted thefts, brainstorm each of these objectives separately. 4. Keep participants aware of the rules and focused. To counteract participants difficulty in following the defer judgment rule, maintain a positive attitude and make only positive statements. Try to turn negative comments into positives, and questions into concepts to explore. If someone insists on shooting down ideas, say something like, The next time he says that, just ignore him. 5. Keep encouraging participants to sketch their ideas. In fact, insist on it by saying, Draw that for me, or just Draw it! 6. Make sure all ideas are recognized. Make sure only one person talks at a time and that anyone with an idea gets to voice it. If two people express an idea at the same time, ask one to stop talking and let the other continue; then come back to the first. 7. Record the ideas. The recorder must also serve as the interpreter, quickly choosing the right words to capture each idea. Each idea should be accompanied by a sketch. Assign a number to each idea and make sure that number also appears on the sketch. 8. Keep the ideas flowing. When talk starts to slow down, repeat or rephrase the problem statement, or try building on an idea thats already been suggested. Encourage participants to think about related products or other technologies that could be used. Have a few sub-topics or variations on the main problem statement ready to present if needed.
4.1.3 Example of a brainstormed list of ideas

Below is a list of over 75 ideas brainstormed by a DTC team (Donahue, Galfi & Sileika, 2006) designing a device to enable users with spinal cord injuries who have limited use of their hands and wrists to drink directly from beverage containers. Notice how the students viewed the problem from various angles: attaching the device to the hand or arm, attaching it to the container, and placing the container back on the table. In addition, they paid attention to aesthetic considerations and came up with some far-out ideas.
64
Example 4.1: Brainstormed list 1. magnet chain 2. adjustable straps 3. handled clamp 4. motorized string 5. bite switch 6. Theraband 7. fingertip magnets 8. brace attachment 9. snap bracelet with buttons 10. rollerblade clip or straps 11. magnetized glove 12. magnetized mitten 13. strap around palm 14. hand bracket 15. glove 16. glove with inset 17. high friction materials rubber, sticky hand 18. disk on palm 19. pouch 20. glove with elastic band 21. stretchy material 22. convex attachment 23. clamps with roller blade clip 24. clamps on palm 25. electrical actuator 26. turn off electricity to disengage 27. vacuum 28. blood pressure cuff 29. release lever 30. rubber band 31. adjustable backpack strap 32. Super Glue 33. duct tape 34. spatula with back ridge 35. track on forearm 36. platform next to table 37. suction cups 38. clear plastic 39. lightweighttitanium 40. keep close to hand 41. use back of hand 42. hidden inside sleeve 43. use the wrist brace 44. use less metal 45. skin colored 46. personalize (logos, tie dye, write on) 47. screw mechanism 48. electric bite switch 49. switch/joystick combination 50. capo 51. 5-point harness; 2-point harness 52. seatbelt 53. camera battery pack 54. spring on floppy drive 55. big surface to activate spring 56. wire guide 57. elastic harness 58. mechanical roller blade clip 59. seatbelt button 60. two clamps, one stationary 61. funnel attachment 62. clamp 63. multiprong clamp 64. ring clamp 65. Kelly clamp (forceps) 66. roller blade clamp 67. bumper 68. wire wrap 69. ratcheting clamp 70. scoop 71. squeeze clamp
65
72. beanbag grip 73. pneumatic grip 74. Velcro 75. memory metal 76. memory foam
77. cell phone holder 78. magnetic clamp 79. fingertip magnet 80. twisty tie 81. lariat
4.1.4 Clustering the brainstormed ideas

Because its difficult to work with a long list of ideas, the next step is to cluster them so you can see connections. Theres no one right way to cluster ideas, but some common ways are to group them according to user requirements, cost, and functionality, to name a few. As you cluster and recluster, you will discover a wealth of ways to solve design problems. After their brainstorming session, the beverage container team clustered their ideas in this way:
Example 4.2: Clustering the ideas generated in a brainstorm
Attaching to user adjustable straps brace attachment snap bracelet with buttons strap around palm glove glove with inset track on forearm velcro twisty tie Attaching to container handled clamp motorized string magnetized glove magnetized mitten Theraband disk on palm rollerblade clip or straps ring clamp hand bracket pouch glove with elastic band convex attachment rubber band
66
seatbelt funnel attachment wire wrap beanbag grip pneumatic grip memory metal memory foam cell phone holder lariat Securing container magnet chain fingertip magnets high-friction materialsrubber, sticky hand stretchy material elastic harness clamps with roller blade clip clamps on palm electrical actuator vacuum blood pressure cuff adjustable backpack strap Super Glue duct tape suction cups screw mechanism two clamps, one stationary multiprong clamp kelly clamp (forceps) ratcheting clamp squeeze clamp magnetic clamp Putting down container spatula with back ridge platform next to table bumper scoop Releasing container bite switch turn off electricity to disengage release lever electric bite switch switch/joystick combination capo 5-point harness; 2-point harness camera battery pack spring on floppy drive wire guide big surface to activate spring
67
mechanical rollerblade clip seatbelt button Using discreetly clear plastic lightweighttitanium keep close to hand use back of hand hidden inside sleeve use wrist brace use less metal skin colored personalize (logos, tie dye, write on)
As with brainstorming in general, the purpose of clustering is to choose categories that will help you generate design concepts.
4.2 GENERATING ALTERNATIVE DESIGN CONCEPTS

Now you are ready to convert the most promising ideas from the categorized brainstorm list into alternative design concepts that you can test on users and/ or in a laboratory or other controlled environment. At this point you should be developing at least three design alternatives that are significantly different enough to give you good information in testing. Some teams develop alternatives by having each team member come up with an idea. This unsystematic approach, however, simply pits ideas against each other and doesnt allow members to build on each others ideas. To develop alternative design concepts: 1. Decide on which criteria you will use to choose which brainstormed ideas to keep and to eliminate. Generally, these criteria focus on cost and feasibility. That is, youll eliminate those ideas that are probably too expensive to meet the clients constraints and are technologically beyond your capabilities. Discuss each idea in the clustered brainstorm list, eliminating those that do not meet your established criteria. 2. Choose the best remaining ideas. There are a number of ways to do this: Discuss each idea until the team reaches consensus on whether to keep or eliminate it. Or, have each team member vote for a designated number of ideas in each cluster; the ideas that receive the most votes are chosen. Or, have each team member rank each idea in a cluster on a numerical scale; the ones with the highest totals are chosen. 3. Group the best ideas under the functional requirements they fulfill. You may have identified functional requirements when you created categories for clustering your brainstorm ideas, or you may have to develop new cat-
68
egories. The beverage container team decided on four functional requirements that were sufficiently complex and critical to serve as the focus of the initial round of testing. Here is their list of requirements and best brainstormed ideas:
Example 4.3: Key requirements and best brainstormed ideas
Attaching to user Brace attachment Glove Strap around palm Attaching to container Pouch Roller blade clip Ring clamp Securing container Elastic harness Rubber support Stretchy material Ratcheting clamp Releasing container Wire guide Release lever Springs Elastic band
4. Make an alternatives matrix. To decide how the different ideas can be combined to create alternatives, make a matrix: one axis has the major design functional requirements, and the other has the alternatives. (See Example 4.4 below.) The cells in the matrix contain ideas you listed in step #3. Below is the matrix created by the beverage container team. To generate the alternatives matrix, the team asked themselves the following questions: How might the brainstormed ideas fit together logically? In the matrix below, for instance, alternative #2, the glove, is low-tech, relying on fabric and elastic. In contrast, alternative #1, the ratchet, is a more mechanical design, relying on clamps and braces. The team also thought about the key questions they wanted the alternatives to answer. They decided that the key questions were these: Will users be able to operate a highly mechanical device, or will they prefer something simpler? What kind of device will feel most comfortable to users? What kind of device will most securely grip and release the container? They mixed and matched the ideas into alternatives that would best allow them to answer those questions. Next the team asked, Which brainstormed ideas for features do we want to test now and which might be put on hold? Finally, they did not use all of the ideas listed in step #3, but instead kept them as possibilities for later testing.
69
Example 4.4: Alternatives matrix for beverage container project Attaching to user Alt 1: Ratchet Alt 2: Glove Alt 3: Harness Brace attachment Glove Strap around palm Attaching to container Ring clamp Pouch Roller blade clip Securing container Ratcheting clamp Stretchy material Elastic harness Releasing container Release lever Elastic band Wire guide
Sometimes, brainstormed ideas will not fit neatly into one set of alternatives. In that case, create two or more sets of alternatives. A team designing an alarm system to warn of malfunctions in an intravenous pump (Dickerson, Lee, O'Connell & Powers-Maher, 2007), generated two sets of alternatives, one with visual signals and one with audio:
Example 4.5: Two alternatives matrices for intravenous pump alarm project
Visual alarm alternatives Location on pump Alternative #1 Alternative #2 Alternative #3 Alternative #4 Half screen Full screen Tubing station Handle Audio alarm alternatives Melody pattern Alternative #1 Alternative #2 C-E-G C-F#-C Instrument Brass Clarinet
4.3 CREATING MOCKUPS FOR USER TESTING

Mockups are two- or three-dimensional objects that embody your concepts in a physical form and that are developed fairly early in the design process to test key functions, thus giving you valuable information to make decisions about your design.
70
4.3.1 Guidelines for creating mockups

1. Sketch your mockup ideas first. Drawing your ideas helps you to clarify exactly what you want each mockup to do and to look like. Sketches will also help to communicate your mockup ideas to your instructors and to people in the shop who may help you refine and construct them. 2. Keep your mockups low-tech. The mockups for your initial design alternatives should be constructed quickly from easily available materials. For example, a team designing a patio chair for people with back ailments created miniature mockups out of foamcore to get users reactions to their concepts. The team designing a traffic flow plan for a local school used an easy-to-learn drawing program called Visio to mock up three alternatives. By using this fast, low-tech approach, you can get your design concepts out to users quickly and learn about their needs and preferences early on without wasting time on fine details that may be eliminated after the first round of user testing. 3. Include enough detail so users can perform (or simulate) the tasks you want to observe. A team designing space for a university department meeting room used foamcore to make a two-foot-square model of the room plus varying sizes of rectangles and squares to represent tables, chairs, shelves, computers, etc. These movable furnishings allowed the team to easily set up the room-model in different ways to represent their alternative designs, and in each case allowed users to rearrange them as they saw fit. The team recorded users comments and photographed each final arrangement so they could analyze user preferences later. 4. Include only the parts of the design that you want to learn about through testing. A team designing a wind-resistant beach umbrella didnt want to put time and effort into creating a separate mockup to test the design of the base, the pole, and the canopy. Instead, they focused on one component at a time in their mockups. They retrofitted different bases onto a standard beach umbrella and asked users to insert and secure each one into the sand. Then they repeated the procedure in mocking up their ideas for the pole and the canopy. When the team wanted to test whether their umbrella designs inverted in the wind, they had to mock up only the various canopies for testing, not the base and poles. Mockups are useful in testing alternatives throughout the design process. Near the end of the project, you will build a prototype that embodies the key functions and aspects of the appearance of your final design.
Note on working with shop professionals

You will find that the professionals who work in the shop are invaluable mentors for helping you develop mockups as well as prototypes. Keep in mind, however, that they are there not to build your mockups but to offer advice and technical assistance as you plan and construct. They are also very busy, conducting shop training sessions and working with many different users of the
71
shop, from DTC teams to graduate students. Therefore, you should observe the following guidelines in working with the shop mentors: Schedule an appointment by email. Since the shop professionals are so busy, offer several possible days and times. Use a respectful tone. When you have ideas for mockups, prepare planning sheets that include detailed sketches, ideas for materials, and questions you will use the mockups to answer. These planning sheets are available in the classrooms and can be downloaded from the DTC Blackboard website. When you want to leave class to work on mockups in the shop, check with your instructors first. Explain exactly what you intend to accomplish. They may ask you to do some planning before you leave class (for instance, make drawings or formulate precise questions). Allow more time than you think you need to work on your mockups and final prototype. It's not uncommon for students to budget two hours for a mockup that ends up taking two days to build. When you need to order an item through the shop, allow sufficient time for the shop professionals to place the order and for the item to be shipped. Talk with your instructors and a shop professional first to make sure that you really need the item and that it will arrive in time. Don't assume that all materials will arrive the next day. Clean up after yourself. This is a matter not only of common courtesy but of safety: the more clutter in the shop the more likely students are to slip up and hurt themselves.
Once you have built mockups, you are ready to learn from them by doing user and performance testing. These activities are discussed in the next chapter.
4.4 REFERENCES
Dickerson, B., Lee, J., OConnell, T. & Powers-Maher, C. (2007). Progress report #2: medical infusion pump alarm. Engineering Design and Communication, Northwestern University. Donahue, K., Galfi, R. & Sileika, T. (2006). Grip&Sip: final design report. Engineering Design and Communication, Northwestern University.
72
Chapter 5: User and Performance Testing
CHAPTER 5: USER AND PERFORMANCE TESTING
Chapter outline
User testing Guidelines for user testing Organizing user test results
Performance testing Iterating the process
Key guidelines for user and performance testing

Write user test guides that include: a brief introduction of yourselves and the project questions to get relevant demographic information tasks for users to perform with the mockups questions about the mockups
Write performance test guides to evaluate your mockups under controlled conditions Write well-organized test result summaries for inclusion in project folder and reports
Different projects call for different methods of testing. User testing improves a design and helps make sure that it meets user needs. By observing users as they attempt to perform designated tasks using your mockups, you can discover the pros and cons of those mockups. But user testing is only one method for learning more about the pros and cons of your design ideas. Drawbacks to direct user testing include the following: User testing demands significant time from the team and the users. It can be difficult to schedule repeated testing sessions in a short time frame. Not all users are qualified or willing to evaluate a design with the necessary rigor. Not all users can easily communicate their responses to a design. If you are designing a device for use in a tank at the Shedd Aquarium, the fish are clearly users, but poor candidates for interviews.
73
In some situations, as in the design of complex systems or large structures, it is prohibitively expensive, inadvisable or impossible to conduct user testing. In those cases, you need to use your ingenuity to develop design tests that match the nature of your design problem.
5.1 USER TESTING

As you test your mockups with, pay close attention to their facial expressions, which often convey more than words can. Also, be objective: If you observe users having trouble with one of your favorite design features, try to figure out why they're having difficulty rather than blame them. If they like a feature, also find out why. Keep in mind that the best designs grow out of user feedback.
5.1.1 Guidelines for user testing

Setting up the sessions
1. Use these resources to help you find appropriate users to observe and interview: Your client Your instructors Family members and friends who fit your user profile Locations where the product would logically be used
2. Make an appointment. This allows you and your users to prepare and schedule time for the session. Avoid showing up unexpectedly unless your project requires ad hoc interviews with people on location. In general, follow the guidelines described in Chapter 2 for setting up user observations and interviews with experts. 3. Plan the session. Ask yourselves: How many people on the team should be at the session? What methods of recording the results will be most useful? Use: a. Paper and pencil for simple actions involving one user at a time. b. Video recorder to capture and review subtle details. c. Digital camera for use in visual documentation and preparing a report, presentation, or poster. d. Tape recorder to supplement handwritten notes and capture users comments. e. Sketchpad or graph paper for making drawings. f. Tape measure for recording accurate dimensions.
74
Note: Use photo and video recording only if your team has obtained the users consent first. Take care that the users do not feel pressured to consent. Photos or videos taken to record information should have identifying tags that say who took the photo, describe the action or object represented in the photo, and include appropriate references to human subjects. Even if users have allowed you to make a photo or video record, this does NOT necessarily mean that they wish to be identified in the photo or video record. Be sure to find out if participants want you to use their names or wish to preserve their anonymity. In certain cases, you may need to use Photoshop or video editing programs to block out a user's identifying features.
Writing the user test guide and conducting the testing

User test guides provide a consistent methodology, ensuring that all members of your team ask the right questions and that all users perform the same tasks and answer the same questions. The guide is composed of the following: Times at which each test session began and ended. The duration of the session can reveal a lot about the quality of the results, so in your follow-up summary you should also note when the session ends. A brief introduction of yourselves, the project, and the purpose of the session. In explaining the purpose, tell users you are watching what they do with your mockups in order to learn how to improve the design, and that they are not being tested, the mockups are. Explain that if they can't do or find something, chances are the mockup is at fault. This will put them at ease so they perform the task more naturally. Questions to get relevant demographic information. Avoid unnecessary or overly personal questions. For instance, theres no need to ask about gender when you can learn that simply through observation, and you may want to avoid questions about age when you are dealing with older users. Tasks for users to perform. The tasks should be appropriate to the materials and capacities of the mockups. For instance, if you are designing a device that enables people with limited use of their hands and arms to drink from beverage containers, then mockups made from foamcore and rubber bands may yield meaningful responses from users about how the device feels but not about how it functions to pick up a container. Encourage users, as they perform the tasks, to vocalize their thoughts as they interact with the mockups. These comments can provide valuable insights into users' perceptions and feelings.
Questions about the mockups. After observing users, ask what they like and dislike about the alternatives and whether they have suggestions. Whenever possible, give users a scale of numerical responses; this will make tabulating the answers easier. Word the questions pre-
75
cisely to ensure that users understand exactly what issues you want them to address. For instance, don't say, Rank the three mockups from best to worst. Instead say, Rank the three mockups from best to worst in terms of comfort. Similarly, don't say, Rate the effectiveness of the first mockup on a scale of 1 to 6, with 6 being the best. Instead say, Rate the ease of use of the first mockup on a scale of 1 to 6, with 6 being extremely easy to use. Youll gain additional valuable information about users needs and preferences by asking users to explain their numerical responses: Why did you rank mockup 2 as the best? What made mockup 3 so hard to use? During this whole process, someone on the team should take careful notes on the users steps, missteps, and comments. One final piece of advice: Resist the temptation to defend your design alternative or explain the rationale behind a feature to your users. Your goal is to gather as much information as possible from users, not to persuade them of a design's merit. For an example of user testing guide, see Appendix H.
5.1.2 Organizing user test results

Chapter 6 explains in detail how to write formal documentation of test procedures and results. Before writing that documentation, however, you should summarize test results informally for yourselves, as the beverage container team (Donahue, Galfi & Sileika, 2006) did in the following table:
Example 5.1: Summary of qualitative user test results
User testing results and follow-up ideas Model Ratchet Observations and User Comments Open handle is a good idea since the user doesn't have to squeeze hand into something. Users don't always wear their brace; cannot assume that the metal piece can be inserted under a brace strap. Containers may slip while in the ratchet. Add an additional Velcro strap near where the apparatus comes to the wrist; use a Dring so that it can be fitted by the user by him/herself. Use Dycem to reduce slippage and provide a better grip. Follow-up design ideas
76
User testing results and follow-up ideas Model Harness Observations and User Comments Holds containers very well but it's too hard for the user to install a container by him/herself. Platform will not fit with all container sizes. Handle is difficult to use because users have to align their hand correctly to get it through the loop. Make the handle open so that users can slip their hands up into it; design the handle such that it automatically tips toward the mouth. Use gloves that have no finger holes. Use firmer material for the pouch. Follow-up design ideas Abandon the use of the scrunchy or use a D-ring so that users can more easily adjust the scrunchy.
Glove
Too difficult for users to put on themselves. Pouches are flimsy and don't hold the drink in an upright position. Effective design for discreetness.
5.2 PERFORMANCE TESTING

In addition to user testing, you may need to test your alternative designs in a laboratory or other controlled environment to discover whether they work at all. For instance, one team was designing a toy rocket-launching kit, using a two-liter soda bottle for the body of the rocket. In designing the launch mechanism, trigger, fins, and nose cone that would attach to the bottle, the team observed and interviewed usersmostly childrento figure out the most promising ideas for these components. Then they mocked those up using foamcore and other easily available materials, attached the mockups to bottles, launched them, and measured their performance. These tests enabled the team to eliminate some ideas and move forward with others. Alternatives and supplements to direct user testing include the following: Laboratory tests designed to simulate real-world conditions including extreme stresses on your design. A team designing a container to keep paint from freezing in cold climates did laboratory testing of their mockups in refrigerators set to different temperatures. Computer modeling. A team designing a method of rapidly evacuating people from skyscrapers used computer modeling to test their design concepts.
77
A DTC team (Syed, Erisken, Kuo, & Tang, 2004) was designing a method to prevent a new, environmentally friendly paint from freezing when transported or stored in cold conditions. One of their mockups consisted of a Styrofoam container with heat packs. Below is the test procedure they developed, along with the form for recording the results:
Example 5.2: Performance test procedure and table for recording results April 24, 2005 Team 3, Section 15 Test Procedures for Heat Pack Mockup 1. Set freezer to 10 degrees Fahrenheit. 2. Leave box in freezer for three days. 3. Open cardboard box after three days. 4. Carefully cut off Styrofoam lid with an X-acto knife. 5. Open paint canisters. 6. Record observations in table under After 3 Days. 7. If paint is frozen, end the test; otherwise continue. 8. Use Instafoam to seal box. 9. Tape lid down. 10. Repackage paint in boxes. 11. Set for one hour for foam to harden. 12. Maintain paint for another two days at 10 degrees Fahrenheit. 13. After two days, check condition of paint as above. 14. Record observations under After 5 Days.
Time After 3 Days
Observations (i.e., degree of ice formation, condition of boxes, how hot heat packs are)
After 5 Days
Chapter 6 explains in detail how to document test procedures and results. Chapter 22 explains how to write specific, well-organized instructions.
78
5.3 ITERATING THE TESTING PROCESS

Although you may have figured out a design direction after your initial round of testing, you still must decide on the components of that design by continuing to generate and test alternatives. For example, the team designing the bottle rocket kit faced a host of questions after their initial tests led them to narrow down the kind of launch pad and fin shape they wanted. So they continued to generate and test alternative ways for the bottle rocket to attach to the launch pad. Similarly, while they kept the basic shape of the fins that their early tests showed to be best, they had to mock up different-sized fins and attach them at several different positions on the bottle rocket. They also needed to conduct these tests with potential users as well as with themselves. These iterative tests, which continued into the final days of the project, helped them make further decisions. In DTC, you learn that good designs are user-centeredthey take into account and accommodate the full range of user needs, characteristics, patterns of behavior, and environments. For that reason, its often a good idea to evaluate your early design ideas through user testing. User feedback can help you eliminate unpromising ideas early in the design process. But user testing is not the only way to learn more about your proposed designs. Performance testing also helps ensure your design's suitability for your target users. Such tests let you learn more about how your design would behave under circumstances that might be difficult or dangerous to simulate in the context of user testing. In addition, the controlled environment of performance testing makes it likely that you will be able to obtain high-quality, quantified information about your designespecially important if you seek to establish safety parameters for its construction or use. Finally, performance testing takes advantage of the team's special skills and knowledge, allowing you to gather information about the design that may not be readily apparent from a user testing session. Consider this example: a team working with Engineers for a Sustainable World (ESW) needs to develop a system for transporting drinking water to cattle that can be used, maintained, and repaired by inhabitants of a rural community in Panama. The team must then provide the inhabitants with an instruction manual for installation, maintenance, and repair of the system. For such a project, both user and performance testing are vital to the success of the solution. Without user feedback, the team will be unable to evaluate which systems are appropriate to the environment or require too much technical knowledge and expensive equipment for the users to maintain easilyor whether the instruction manual tells them what they need to know. Without performance testing, the team will have difficulty determining how the pump and filter system would behave under adverse climate conditions, such as when the local stream is running low and clogged with debris. Without both kinds of informationand iterationthe team is unlikely to develop a successful final prototype.
79
Keep in mind that the complexity of the testing process mirrors the complexity of the design problem. Any team that relies solely on one kind of testing procedure or one set of tests will likely end up with a design that may work in theory, but fail in practice. In the final analysis, user-centered design typically requires both.
5.4 REFERENCES
Donahue, K., Galfi, R. & Sileika, T. (2006). Grip&Sip: final design report. Engineering Design and Communication, Northwestern University. Syed, S., Erisken, S., Kuo, J. & Tang, S. (2004). Second progress report. Engineering Design and Communication. Northwestern University.
80
Chapter 6: Reporting on User and Performance Testing
CHAPTER 6: REPORTING ON USER AND PERFORMANCE TESTING
Chapter outline
The testing record Purpose of the testing record Ethics and the testing record
Elements of the formal record
Key guidelines for user and performance testing

Structure formal summaries of your tests in this way: Purpose: explain the goals of the test Methodology: provide details on the mockups, user test guides, and performance test procedures Results: summarize the results in an objective, well-organized way Analysis, conclusions, and limitations: explain what you learned and decided as a result of the tests, and discuss any limitations of the test methodology and results
As explained in Chapter 5, testing is the hub of the design process. The ideas your team generates through brainstorming, research, and expert consultations must be tested repeatedly to help you understand how your design will behave and be used in a real-world context. Testing is an indispensable way to measure your early ideas against user requirements so that you can eventually translate those requirements into measurable specifications. Design testing may take many different forms. In the first quarter of DTC, you typically assess your design ideas by asking users to interact directly with your mockups. In DTC 2, you often conduct user testing in addition to devising other ways to evaluate the strengths and weaknesses of your early ideas. But whatever your methods, the information you gain from testing plays a vital role in helping your team determine the final design.
81
For this reason, it is essential that readers of your reports and project notebooks understand your testing strategy as fully as possible. What did you hope to learn? What was the rationale behind your test methods? Did testing go well, or did you run into difficulties? Answers to all these questions and more must be provided in writing. This chapter explains the purpose of the testing record, ethical guidelines, and the basic elements of documentation.
6.1 THE TESTING RECORD: ITS FORMS AND FUNCTIONS

What does documentation mean in the context of the design testing process? Broadly speaking, the testing record, or documentation, is the full record (including things like sketches, photos, and video) of your formal efforts to evaluate the capabilities of your design. It comprises both the team's preparation for tests as well as what you learned from them, including results and interpretation. As an engineer, you have a professional obligation to document your work good record-keeping is required, not optional. Every branch of the profession, however, has its own specific standards and practices regarding documentation; you will learn more about them as you progress in your chosen field. This chapter is intended to make you aware of some fundamental principles for good record keeping and clear documentation. The testing record takes two basic forms: notes from testing and formal documentation. In Chapter 5, you studied the first part of the testing recordgood note-taking. If you do a good job of organizing your notes initially, it is much easier to write your formal documentation.
6.1.1 Purpose of the testing record

Formal documentation, in contrast to your testing notes, is the refined record of the full design testing process as it appears in reports, proposals, and professional publications. Formal documentation is written to explain the testing process to a reader who may know little about the design problem, appropriate testing methods, or the full range of possible solutions. For that reader, your formal documentation of the testing process serves as important evidence of the designs (and the teams) credibility, and should foreground information that anticipates and answers concerns of experts. Thus, it is important to provide readers with a clear, logically organized, and economical account of the testing process so that they understand how your results informed the team's decision to select one design solution (or one set of features, functions, materials, or construction methods) over another. Moreover, a well-written account of your tests and findings will tell the reader about much more than just the design itself. Thorough documentation allows an experienced reader to assess both the complexity of the design challenge
82
and the quality of the team's performance, providing answers to questions like the following: Were the tests appropriate and sufficient? Could better tests have been devised? What were key obstacles to testing the design? How skilled was the team at preparing for and conducting its tests? Did the tests get them the information they anticipated? How complete is the testing record? How careful was the teams analysis of test results? Do the results support the team's decisions, or could the data support other choices as well?
Teams should always make sure that the formal testing record accords with their rough notes from testing, since both are part of the official record of the designs development. Among other things, documentation provides legal evidence of the teams due diligence in testing, showing that the team took steps to ensure that the design addressed the design problem adequately and safely. Moreover, should you wish to patent your design, such records will testify to your detailed insider knowledge of the development process that created the design. Finally, in the event of design failure, a full record of testing can help investigators pinpoint where potential failure modes and effects (see Chapter 8) were overlooked or not fully accounted for.
6.1.2 Ethics and the testing record

Testing doesn't always go exactly as planned, regardless of the experience, diligence, or ingenuity of your team. Maybe the user was able to work with you for only a short time. Maybe you tested with one or two users and are pretty sure that a broader range of users might make some unsuspected defects apparent. Or perhaps the testing apparatus broke down. In any case, such difficulties may mean that your team does not get the kind or amount of information you had hoped. Whatever the results from testing, you must record them scrupulously, even if you believe that the findings do not adequately reflect the possibilities inherent in your design. Failure to document problems that crop up in testing, carelessness in acknowledging limitations of your testing methods, suppression of undesirable results, or worse, fabrication of data all constitute serious breaches of recognized ethical standards. The National Society of Professional Engineers Code of Ethics for Engineers (2007) leaves little room for misunderstanding: Engineers shall acknowledge their errors and shall not distort or alter the facts. [They] shall be objective and truthful in professional reports, statements, or testimony. They shall include all relevant and pertinent information in such reports, statements, or testimony, which should bear the date indicating when it was current.
83
There are other good reasons to keep careful records of all testing efforts, especially those that don't go according to plan. Difficult testing sessions can lead to breakthroughs, encouraging you to seek information about the design or users that you hadnt thought to look for. If your test failed, what new information or opportunities did it reveal? If you didnt get the answers you needed, did you find out how to ask better questions? For many reasons, ethical record-keeping and good design go together.
6.2 ELEMENTS OF THE FORMAL RECORD

Your formal documentation of design tests should include the following four elements: Purpose Methodology Results Analysis, conclusions, and limitations
Each element is discussed in greater detail below. Examples of reports on performance testing and user testing appear in Appendices I and J.
6.2.1 Purpose
The first section of the report states the purpose of the test clearly and concisely. Keep in mind that in the course of design testing you may gather information that you had not anticipated. In such cases, you should neither revise your description of the design tests purpose nor ignore the additional data. Instead, make sure your account of the results from testing includes the unexpected findings with a simple notation stating that while the test had not been designed with the express purpose of discovering that information, your team will be taking those findings into account in the final design.
6.2.2 Methodology
The process of writing up your testing methodology serves a dual function. First, it documents the testing plan in sufficient detail so that an educated generalist reader can understand how the design was tested. Second, it can also help your team double check the plan and make sure that the testing procedure will get you the information that you want. A complete record of the testing plan should include the following: A description of the procedure you plan to follow (or followed) in order to collect information. Include specific, quantified information
84
about mockup construction, user questions, mockups, sample preparation, and similar matters. Justifcation for the testing method(s). This is not always required, but in cases where the reader may be unfamiliar with the rationale for the testing methodology, you may wish to include a short explanation of your choice. If you choose, for example, to create a computer model of the design using specialized software for that purpose, you might explain that this method was recommended by experts and is standard industry practice.
6.2.3 Results
The results of design testing should not be confused with the teams analysis and interpretation of those results. Results of design tests themselves should initially be presented objectively, without interpretation. Detailed information on tests (including contextual information) is generally relegated to an appendix. In addition, you should provide a short overview of any changes in the testing methodology or unexpected circumstances, including the reasons for the changes. This should be considered part of the basic contextual information about your tests (date, time, location, duration, etc.) and should appear in a short paragraph at the beginning of the detailed account of test results. Be sure to provide reasons for the changes. Were the users too fatigued to work with you for long? Had you been unaware of the limitations of your testing equipment? This information can both give your reader a better understanding of your user group and help future teams think about how to avoid such obstacles in future tests.
6.2.4 Analysis, conclusions, and limitations

Analysis
The most common mistake that teams make is to provide the reader with data gathered from design tests but little else, assuming that the results speak for themselvesthat the conclusions to be drawn from the data are obvious and incontrovertible. However, as experienced designers and researchers know, this is rarely if ever the case. The team must explain how they interpreted results in order to justify their decisions about the form of the final prototype and recommendations to readers. The analysis of results from testing is distinct from the results, though sometimes your results may seem to speak for themselves. For example, if your design simply did not work as you expected under real-world conditions, it may earn low ratings both in user and performance testing. In other cases, however, findings may result from something that the team had not intended to test. At such times, your analysis will need to provide the
85
reader with a theory that explains the user response. In one case, a team designing a computer lap tray for users with disabilities presented their client and users with four alternatives: three foamcore looks-like models, and one commercially available product that lacked key features required by the users. In spite of the fact that the commercially available product lacked what the team had determined to be key requirements, the client and users expressed strong preferences for that design. After discussing the results of user testing, the team determined that the client's and users favorable responses to the design had been determined less by the designs working features than by its aesthetic qualities. The team decided to develop new mockups that addressed both functional and aesthetic requirements. For performance testing, your analysis should provide the reader with an explanation of what the raw data mean in terms of design requirements and user needs.
Conclusions and limitations

A short summary of the teams conclusions should usually appear in the main body of the final report, leaving detailed discussions of your reasoning for the appendices. This part of the formal testing record is also a good place to mention the limitations of the testing. For example, if, at the end of the project, your team believes it has developed a promising design idea but has not been able to conduct enough tests to determine what materials would be best suited to ensure the user's safety, that should be noted as a limitation. You should then suggest additional testing in your Limitations section.
6.3 REFERENCES
Long, A., Rein, J., Smith, A. & Smith, L. (2006). Glowcrete: A Thin-Layer Approach to the Development of Self-Illuminating Concrete. Engineering Design and Communication, Northwestern University. National Society of Professional Engineers (2007). NSPE Code of Ethics for Engineers. Retrieved July 15, 2007 from <http://www.nspe.org/ethics/ eh1-code.asp>. Shiao, C., Chen, S., Lee, C. & Srinivasan, S. (2003). Progress report #4. Engineering Design and Communication, Northwestern University.
86
Chapter 7: Deciding on a Design Concept
CHAPTER 7: DECIDING ON A DESIGN CONCEPT
Chapter outline
Using test results Using design requirements and specifications Creating decision matrices Talking to the client Interviewing experts and testing more mockups
Key guidelines for deciding on a design concept

After testing alternatives, decide on a design concept by: analyzing test results referring to design requirements and specifications creating decision matrices that compare alternatives according to key criteria talking to your client interviewing experts testing more mockups
Generating and testing alternatives will yield a great deal of information that you can use to decide on a single direction for your final design. Of course, that does not mean that you now know the details of every feature of the design you will propose. You will need to continue generating alternative components for those features, mocking them up, and testing them, but all that will be done within the context of the design concept you finally settle on. How do you decide on the key elements of the design concept that will be the focus of your further work on the project? This chapter discusses several methods for making those decisions.
87
7.1 USING TEST RESULTS

If you have organized the results of your design concept clearly, aspects of your design direction will leap out at you. For instance, a team designing the interface for an electronic kiosk to give shoppers information on restaurants and entertainment (Johnson, Chen, Kidd, Lesperance, & Marvin, 2002) observed users operating three mockups: a touch screen, trackball, and keypad. The average scores (on a scale of 1 to 5, with 5 being the best) were:
Touch screen: Trackball: ATM: 4.36 2.12 2.15
Because their research had already shown that the three methods were comparable in price and durability, the team decided on the obvious favoritethe touch screen. Sometimes, test results do not clearly favor one alternative feature. When the kiosk team presented users with three alternative methods for searching by location, price, and type (of entertainment or food), they got these results:
Location: Price: Type 4.09 4.03 3.55
Users rated searching by location and price nearly the same, with searching by type not far enough behind to be eliminated. In this case, the team decided to incorporate all three search methods into their design concept, because doing so stayed within the clients budget and offered users several search methods. If you have tested your alternatives in a lab or other controlled setting, you can use the results in the same way to make decisions.
7.2 USING DESIGN REQUIREMENTS AND SPECIFICATIONS

Your project definitiondescribed in Chapter 3is another important tool in helping you choose the main features of your design. A team designing a structure that would help their client organize the papers on her desk relied on the project definition to help them decide on their design concept. When no clear favorite emerged after testing their three alternative mockups, the team turned to their project definition, which revealed that the client wanted an individually tailored product because she had tried the products available in commercial catalogues and found them all unsatisfactory in various ways. The team realized that their alternatives were similar to catalogue products, so they combined the best elements of all three alternatives in an original way and presented a design that delighted their client.
88
7.3 CREATING DECISION MATRICES

A decision matrix can help you sort through multiple alternatives and requirements to determine which features of your alternative designs to use. A simple and effective decision matrix lists the relevant design requirements along one axis and the alternative features along another. Each alternative is then scored (using plus and minus signs or some other method) with respect to each requirement. A team redesigning a stage in a church generated two alternativesa ramp and an electric liftto accommodate users with walkers and wheelchairs. Many church members favored a ramp because they worried that a lift would strain the church budget. Other members thought the ramp would take up too much room and that a lift would be easier to use. With these conflicting views in mind, the team drew up the decision matrix illustrated below. The two alternatives are in the top row, and the requirements are in the first column. The team used three requirements to rate the ramp versus the lift: cost, ease of use, and efficient use of space. They gave the alternative two pluses when it satisfied the requirement extremely well, and two minuses when it did so extremely poorly. Otherwise, they used a single plus or minus to rate the alternatives.
Example 7.1: Decision matrix for choosing between two alternatives
Lift Cost Ease of use Use of space Total -+ ++ + Ramp ++ --
KEY ++ = satisfies requirement extremely well + = satisfies requirement adequately - = does not satisfy requirement adequately -- = satisfies requirement extremely poorly
Although most church members favored the ramp, the decision matrix helped the team decide that the lift was a better option because it satisfied more requirements. The decision matrix also could help the team evaluate alternatives against requirements that are not equally important. For example, the team may have decided, based on interviews with church members, that cost was the most important requirement. In that case, they could have created a weighted deci-
89
sion matrix like the one below to help them evaluate the alternatives.
Example 7.2: Weighted decision matrix for choosing between two alternatives
Lift Raw Cost (x2) Ease of use (x1) Use of space (x1) Total -++ Weighted ---++ Raw ++ Ramp Weighted ++++ -
++
++
--
--
++
KEY ++ = satisfies requirement extremely well + = satisfies requirement adequately 0 = neutral - = does not satisfy requirement adequately -- = satisfies requirement extremely poorly
Using this matrix, the team might conclude that if cost is the driving requirement, a ramp is the better choice, even though it is less effective in meeting the other requirements. Then they could double-check their assumptions about priorities with the client. Sometimes, a matrix might not lead you to a single answer, but will help you eliminate alternatives. User testing on the electronic kiosk showed that some users wanted extensive information, such as restaurant menus, which would mean more time and money to build and maintain the database and possibly cause long lines at the kiosk as users pondered their choices. To figure out a solution, the design team created the matrix below to measure three alternatives against three requirements. The alternatives, in the top row, are: full menus; a list of featured dishes and their prices; and the type of restaurant and its location. The first column lists the key requirements: providing useful information, keeping costs low, and ensuring efficient use of the kiosk.
90
Example 7.3: Decision matrix for choosing among three alternatives

Full menu Featured items No menu info
Provide useful info Keep costs low Use kiosk efficiently Total
++
--
---
++
++ ++
--
++
++
KEY ++ = satisfies requirement extremely well + = satisfies requirement adequately - = does not satisfy requirement adequately -- = satisfies requirement extremely poorly
While the matrix enabled the team to decide against full menus, the other two alternatives fared equally well. The next sections offer additional methods for making decisions when matrices dont yield definitive answers.
7.4 TALKING TO THE CLIENT

When you have tough decisions to make about your design, especially those involving costs, its important to seek input from your client, who can tell you what she is willing to spend and what is most important to her. After eliminating complete menus, the kiosk team had to decide, based on inconclusive user testing, whether to list a restaurants featured dishes or just the type of food and the address. The deciding factor was cost. A meeting with the client confirmed that he was willing to spend the money required to enter information on featured dishes into the database.
7.5 INTERVIEWING EXPERTS AND TESTING MORE MOCKUPS

The last two methods for making decisions about your design concept involve interviewing experts and testing more mockups on users or in controlled settings. Interviewing experts: When you dont know enough to measure how well certain features meet all relevant requirements, seek out experts. Even after interviewing church members and the client, the team designing the access to the
91
church stage still couldnt decide if the electric lift was the best choice. They assumed that a lift would be easy to operate and would use space efficiently. They also assumed a ramp would be harder to navigate than a lift and would take up more space. But they needed more than just assumptions, so they sought the advice of experts on handicap accessibility in rehabilitation institutes, college faculties, and companies that make equipment for people with disabilities. Testing more mockups: Lastly, you can go back to users or the lab with new mockups that embody the alternatives you are stuck between. The kiosk team might want to know whether users would be satisfied with a brief list of featured items for each restaurant or how much time people would spend at the kiosk reviewing full menus. To answer these questions, they could quickly mock up pages that included the alternatives: lists of featured menu items, complete menus, and no extra information. Then they could show these to users and give them a taskUsing these pages, decide where to go to dinner tonightand time their interactions with the mockups. Perhaps only at that point could the team feel confident that they knew enough to decide how much information to include in the kiosk database.
7.6 REFERENCES
Johnson, A., Chen, R., Kidd, L., Lesperance, I., Marvin, J. (2002). Progress report #3. Engineering Design and Communication, Northwestern University.
92
Chapter 8: Failure Modes and Effects Analysis
CHAPTER 8: FAILURE MODES AND EFFECTS ANALYSIS
Chapter outline
Why do an FMEA? Creating an FMEA Using the results
Key guidelines for a failure modes and effects analysis

To assess the ways in which your design could potentially fail, construct an FMEA chart that includes the following information for each failure mode: cause effect and its severity detection method possible action to address the failure mode
8.1 WHY DO AN FMEA?

Periodically throughout the life of a project, it is important to assess the risks related to the product being designed. Some risks are project-focused and often have to do with schedules and budgets. These risks can be addressed through careful project planning and monitoring with tools such as Gantt and RAM charts and by creating contingency plans. Other risks have to do with the product themselves. One useful tool for analyzing the product risks is called Failure Modes and Effects Analysis (FMEA). The purpose of an FMEA is to identify every possible way in which the product could fail and to assess the potential effects of that failure on the product and any people interacting with it. Once all of the risks have been identified and understood, designers can determine how to change the product.
93
A table format is used to capture the information gathered during the FMEA. Different companies vary in their approach, but the basic function is the same. The table below shows a sample FMEA for a baby monitor. Baby monitors generally have two components: the baby unit and the parent unit. The baby unit is placed near the child to pick up sound, and possibly video, and transmit this information to the parent unit. The device allows a parent to be in a separate room and still know if the baby is awake, asleep, crying, etc.
Table 8.1: Baby monitor FMEA
Part Failure Score
3 12 6 6 8 2 4 6 6 9
Item
Failure Mode
Failure Cause
Plastic housing
break
mfg defect
component broken
internal elements exposed; may create sharp edges/small pieces internal elements exposed; may create sharp edges/small pieces potential exposure to internal elements may prevent use of device
visual
Frequency**
Failure Effect on Component
Failure Effect on System
Failure Detection Method Severity*
Action
inspect before packaging
break
drops on floor
component broken
visual
design plastic housing to withstand a drop test at 4 feet
come open/ loose Power cord cord housing cracks
missing screws stress at junction to unit child pulls on cord mfg defect
none
visual
include some snap features in addition to screws add strain relief
wires exposed, possibly broken none
unit doesn't work
becomes disconnected Power button non-functional
child may play with cord: choking, strangulation system cannot be used
adult super- 4 vision nothing happens when button is pressed change in sound on parent unit 2
clear warnings in instruction and on base unit test unit before packaging
non-functional
pressed at wrong time
child presses button
none
caregivers cannot hear child
place button in inconspicuous location, have indicator on parent unit for no signal consider hinged door or leash options consider slide or snap in design in addition to childresistant screw more robust design needed
Battery door
missing
door lost
none
batteries accessible by child batteries accessible by child
visual
missing
screws lost
none
visual
alignment tabs break
stress concentration
cant be assembled
batteries accessible by child
visual
94
Microphone
non-functional
mfg defect
non-functional
caregivers cannot hear child
cannot hear child
Part Failure Score

3 6 2 1
Item
Failure Mode
Failure Cause
Frequency**
Failure Effect on Component
Failure Effect on System
Failure Detection Method Severity*
Action
test unit before packaging
damaged
child sticks fingers in openings mfg defect
non-functional
caregivers cannot hear child/ possible injuries to finger caregivers need to test unit to be sure it is working caregivers need to test unit to be sure it is working
cannot hear child/see injured finger LED not lit when power button pressed LED not lit when power button pressed
all openings should be smaller than child's finger
LEDs
non-functional
non-functional
test unit before packaging
non-functional
burned out
non-functional
select LED life to correspond with expected product life
*Severity Values (user/device) 1 = mild annoyance/visual but not functional defect 2 = really irritated/damaged part, still functional 3 = minor injury/part requires replacement 4 = serious injury/ device requires replacement
**Frequency Values 1 = 1 in 10,000 uses 2 = 1 in 1,000 uses 3 = 1 in 100 uses 4 = 1 in 10 uses
8.2 CREATING AN FMEA

To create the FMEA table, follow the steps listed below. (The title of the column in the table appears in parentheses after each step.) 1. List the parts of the product (Item). It is helpful to group these parts in their subassemblies if they exist. 2. List each way the part could fail (Failure Mode). Below are questions to consider to help you think of how a part might fail: What are the potential manufacturing defects? How might the product fail due to normal wear and tear? What are the steps the user is supposed to take when using the product? What mistakes might a user make? How would users with various limited abilities interact with the product? What problems might they encounter? How might the product be misused or abused?
For misuse/abuse modes, it is not necessary to consider every possible contingency. Instead, focus on likely misuses and abuses. A toddler play-
95
ing with the power cord or randomly pressing buttons on the unit are both likely to occur, though clearly these are not intended uses for the product. 3. Explain the cause of each failure (Failure Cause). 4. Describe the effect of the failure on the part itself (Failure Effect on Component). Does the part still function? Is it weakened? Will it need to be replaced? 5. Describe how that failure impacts the overall product (Failure Effect on System). What happens if the user continues to use the product? 6. Describe how that failure is detected (Failure Detection Method). Some failures might be immediately obvious, while others might not be noticed until they in turn cause greater damage. 7. Provide a severity rating for the failure (Severity). It is important to determine the relative values of the ratings in advance to maintain consistency. The severity ratings are at the bottom of the table. 8. Provide a frequency rating (Failure). How frequently do you expect this type of failure to occur? Your instructors can help you determine this rating. The frequency ratings are at the bottom of the table. 9. Determine the Part Failure Score. Multiply the severity rating by the frequency rating. 10. Describe the action to be taken in response to this potential failure (Action).
8.3 USING THE RESULTS

Based on the results of your analysis, determine what actions should be taken to improve your product. Low scoring items, such as something that is not likely to occur and does not cause much damage, may be able to be ignored, in which case the action is none. However, you may still choose to address it if there is an easy fix. Higher-scoring items must be addressed. Depending on the failure, you may be able to design it out. You do not need to describe the particular design changes at the time of the FMEA; that can be a follow-up activity. In the action column, you can list design change. By understanding all of the failures that require design changes, you may be able to combine them to address as many failures as possible with the minimal number of changes. Some items cannot be designed out, such as preventing a user from putting the baby monitor in a bathtub. You may have to resort to clear instructions in the manual and/or the use of labels. This should be a last resort due to limited effectiveness. In the example of the baby monitor, only the components that were designed by the DTC team were included in the FMEA. If this monitor were being
96
manufactured in industry, the entire assembly would be considered, down to the individual screws used to hold it together.
97
98
Chapter 9: Conducting Design Reviews
CHAPTER 9: CONDUCTING DESIGN REVIEWS
Chapter outline
Preparing the review Presenting the review Organizing feedback from the review Offering useful feedback as a reviewer
Key guidelines for conducting design reviews

Devote most of the review to getting oral feedback from reviewers Prepare a questionnaire to get written feedback from reviewers Prepare visual aids: mockups, slides, and handouts Respond non-defensively to reviewer comments Write down the oral feedback during the review After the review, write a summary of oral and written feedback, and use it to make decisions about developing the design
A design review is a scheduled, systematic evaluation of a design by knowledgeable people, particularly fellow designers. These people can also include the client, members of the clients organization, and outside experts. The purpose of the review is to help the design team ensure that the design meets client and user requirements. A typical review begins with the team briefly discussing client and user requirements. The team then presents its design (or design alternatives, if a single design concept has not been decided on). The reviewers role is to evaluate the design critically: ask questions, identify problems, and make suggestions. Design reviews are an important way for a team to get an informed outside perspective and to keep the project on track. In industry, they are often done at several points during a project. Each review helps designers to rethink and refine their concepts.
99
In presenting your design for review, your goal is not to persuade the reviewers that it is wonderful. Instead, your goal is to encourage them to uncover possible problems in the design, to offer suggestions for improvement, and to help ensure that you have followed the design process rigorously with your client and users constantly in mind. Since you have invested so much time and energy in the design, your natural tendency may be to justify what you have done and to deflect criticisms and suggestions. Doing that may make you feel good, but down the road it will hurt you, especially when you go to your client, who will demand that your design have no flaws and that it meet every single requirement. So use the design review as an opportunity to ensure quality control at a point in the process when its not too late to correct mistakes. The following three sections discuss how to prepare and present the review as well as how to organize the feedback you receive. A final section discusses how to offer useful feedback as a reviewer.
9.1 PREPARING THE REVIEW

Design reviews can be formal or informal. Follow these guidelines to plan your design review for DTC: 1. Outline the key points you will make. Design reviews generally last from 20 to 30 minutes; ask your instructors beforehand how long you will have. Its important to plan carefully to ensure that you leave plenty of time for discussion. Make your presentation brief, devoting most of it to describing the design itself. Present background information on the client and users only as needed. For instance, if everyone in the class is working on the same project, there is no reason to spend time going over client background and user requirements. Conversely, when the rest of the class is unfamiliar with the project background, you may have to spend time explaining the clients organization and the problem, using visual aids such as photos and brief video clipsas needed. 2. Prepare visual aids. These may include your latest mockup(s). For features that are hard to see in the mockups, use graphics on handouts, flip charts, and/or PowerPoint slides. However, don't think of your design review as a presentation, for which you would prepare elaborate or extensive PowerPoint slides. Your visual aids just need to help reviewers understand the design problem and the key features in your latest solution(s). 3. Prepare a questionnaire that you want reviewers to answer about your design. Make enough copies for all reviewers. Ask general questions about the strengths and weaknesses of the design as well as specific questions about areas that particularly concern you. 4. Prepare an analysis of failure modes and effects. In spring quarter, you will be required to include a Failure Modes and Effects Analysis (FMEA) as part of your design review (see Chapter 8). One crucial function that design reviews serve is to alert you to the reliability and safety issues
100
raised by your design. Reliability has to do with the likelihood of the design and its subsystems to fail. Since all systems and subsystems fail at some point (the battery dies, the handle snaps, etc.), your job as an engineer is to delay that failure and minimize its impact. Similarly, all designs have safety hazards. Thats why the instructions for your hair dryer and TV set begin with long lists of cautions and warnings. As an engineer, you are obligated to eliminate, guard against, and/or minimize the effect of these hazards. 5. Assign responsibilities: Who will speak and in what order? Who will take notes (you should not rely solely on the notes reviewers put on the handouts since they may be incomplete)?
9.2 PRESENTING THE REVIEW

To get the most from your reviewers, follow these guidelines: Distribute questionnaire. At the start, distribute the sheet with your questions about the design, and ask reviewers to fill it out and return it to you at the end. Emphasize, however, that you are interested in getting suggestions and criticisms of all aspects of the design, so reviewers need not confine their comments to your specific questions. Ask for oral feedback. Encourage reviewers to ask questions, offer suggestions, and make criticisms during and after the presentation of the design. Respond non-defensively. Just as you did in your user testing, in a design review you should respond to questions, criticisms, and suggestions without defending your design or design decisions. Instead, probe for more information. For instance, the appropriate answer to the criticism that your design has a flaw is not, Well, weve tested that, and it works, but Why do you see that as a flaw? and How can we eliminate it? Similarly, the appropriate response to a suggestion is not, We tried that, and it didnt work, but Heres what happened when we tried that feature. Can you suggest a way to improve on what we did? In other words, give your reviewers a chance to help you think of possibilities you may have missed. Record all comments. Listen carefully and write down reviewers' comments and suggestions. At least one team member should be a scribe during the review.
101
9.3 ORGANIZING FEEDBACK FROM THE REVIEW

After the design review is over, you will need to organize and discuss the feedback you received in order to decide how best to apply it to your design. To accomplish that goal, follow these guidelines: Have a team member categorize all feedback. Include those comments you received orally during the review and those written on the review sheets you distributed. Post this categorized list so that its available to other team members and to your instructors. Below is an example of a design review summary written by a team designing an automobile passenger seatback so that it can be used as a workspace and for storage (Shiao, Chen, Lee & Srinivasan, 2003).
102
Example 9.1: Summary of design review results Design review results

Reviewers like Reviewers dislike Features to be added Features to be removed/ modified Mirrorsafety issue Additional comments
ACCESS Can see what you want. Equally accessible for driver and rear seat. Easily accessible from front seat. Allows driver access to all items on seat. COMPONENTS Lots of stuff to use. Kleenex. OTHER
EASE OF USE Dont like having seat down. Too cumbersome to access from driver seat. USABILITY
Cover Better places to put CD case
USABILITY Most useful if driver is alone in vehicle. Make it usable when its upright as well. Prioritize user needs. VERSATILITY
Only useful for drivers. Cannot be used by back seat. Cant be used when there is a front seat passenger. Not accessible while seat is upright. FUNCTIONALITY
Try not to be so specific with the pouchesmore versatility. COMPONENTS Only things I would use would be the Kleenex, pencil holder, and expandable file. People usually unlock the front door first; getting the ice scraper would be a pain.
Good if you are doing a lot of work in car.
Too cluttered. Too much stuff. Hard to see all of the items. Cup holder is too far away. Safety issues.
103
Have a meeting as soon as possible to discuss the feedback. Make decisions about how you will act on the feedback from reviewers. Below is a table written by a team after they made these decisions (Hwang, Jessop, Sze & Vetter, 2005). The teams project involved designing a cart to store gym equipment for a local school.
Example 9.2: Decisions made after design review Implementation of Design Review Advice
Suggestion/criticism Side joints do not seem strong enough. Suggest triangular supports. Round off sharp corners or add rubber padding for safety. Add lip on bottom shelf. Bungee cord seems unsafe; use mesh. Objects on bottom shelf may obstruct stick storage extending through shelf*. Make sure all the games fit in cart, including Team 2s large games.* Cart needs a design and/ or paint.* Use peg dividers instead of wood slats.*
Implementation Add metal L-brackets between side panels and base.
Add rubber strips on corners.
Add lip on one side of cart. Add mesh netting on both sides of cart. Use indentations in a wood block to secure new stick configurationwork in progress. Continue to work with Team 2 on their games.
Add some type of finish: paint, varnish, or oil. Ask Prof. Jacobson which is best. A simpler divider system is neededwork in progress.
*Solution still neededimmediate action item
9.4 OFFERING USEFUL FEEDBACK AS A REVIEWER

When you are a reviewer, your job is to offer constructive feedback and probing questions that will help your fellow designers improve their design. To do that, keep in mind the following guidelines: Say what you like and dislike. You dont have to be an expert, or even familiar with the design problem, to offer criticisms and suggestions. Ask basic questions that get the designers to explain their design: Who, What, Why, How, When, Where? In particular, probe the how and why of the design: Why did you incorporate this feature? How would I perform this particular task if I were using your design? If you can get the designers to explain their design clearly and carefully,
104
they will discover a great deal about its strengths and weaknesses on their own. Be on the lookout for latent defectsdesign flaws that are not obvious and that may surface during the products use. You will be very helpful to the designers if you present scenarios for the products use that may uncover a defect they have not anticipated. The Y2K problem is a classic case of a latent defect that had enormous repercussions. Many software engineers believed that on January 1, 2000, computers around the world would crash because they represented years by using only the last two digits and would therefore misinterpret 00 as 1900. It is estimated that over $300 billion was spent in order to solve the problem. Ask questions about the designs reliability and safety issues. In particular, ask probing questions about the teams FMEA. Add items to it where possible. Fill out the questionnaire passed out by the designers.
9.5 REFERENCES
Hwang, M., Jessop, B., Sze, N. & Vetter, J. (2005). Implementation of design review advice. Engineering Design and Communication, Northwestern University. Shiao, C., Chen, S., Lee, C. & Srinivasan, S. (2003). Progress report #4. Engineering Design and Communication, Northwestern University
105
106
Chapter 10: Concluding Conceptual Design: Moving Toward Detailed Design
CHAPTER 10: CONCLUDING CONCEPTUAL DESIGN: MOVING TOWARD DETAILED DESIGN
Chapter outline
Bill of materials Considerations in detailed design
Key guidelines for concluding conceptual design and moving toward detailed design
To inform your client of how much it costs to build the prototype, construct a Bill of Materials that includes the following information for each item used: description, including material and dimensions quantity source from which it was purchased catalog part number cost per unit total cost
In freshman engineering, you will concentrate on conceptual design. That is, your projects will culminate in the presentation of a design concept that solves the clients problem and addresses user needs. To test that concept and demonstrate it to your client, you will have to move part way into the second major phase: detailed design. In DTC, that phase will consist of producing a prototype that embodies key features of your design. You will need to figure out exactly where certain components will connect, how far apart holes must be drilled, what kinds of fasteners to use, and other such problems. In a few cases, your detailed design might include a fully functional looks like/works like prototype. This most often occurs if you are creating a one offa unique design for a single user, such as a toy for disabled children at Childrens Memorial Hospital or a wheelchair ramp for a specific clients front entrance. In completing a detailed design, you will produce a bill of materials and dimensioned drawings that depict all components of the system.
107
The bill of materials and other considerations that go into detailed design are discussed below.
10.1 BILL OF MATERIALS

The bill of materials (BOM) is a comprehensive listing of every item that goes into a finished product. For each item, the BOM includes the description, quantity, part number, unit cost, and total cost. The BOM tells the client exactly how much the design costs and eases the process of ordering parts if the client decides to manufacture it. Here is the BOM from a project to design swimming goggles for people with spinal cord injuries:
Example 10.1: Bill of materials Item
Dive mask Ratchet
Description
Qty
Source
Sports Authority Shredd Shop
Part #
2173701 N/A
Unit Cost
$29.99 $5.00
Total Cost
$29.99 $5.00
U.S. Divers Admiral Mask 1 Union snowboard binding ratchet & ladder system Corrosion-resistant aluminum (alloy 5052), 1/8" thick, 1" width, 12" length Polypropylene strip, 1/16" thick, 1/2" wide, 12" long Nylon webbing, 3/32" thick, 1" wide, 12" long, black Elastic fabric, 0.055" thick, 1" wide, 12" long, black Light duty plastic buckle for 3/4" wide webbing, sew on, squeeze release Type 316 SS pan head Phillips ma-chine screw 4-40 thread, 1/2" length Type 316 SS machine screw nut 4-40 screw size, 1/4" width, 3/32" height Aluminum pop rivets, 1/4" head, for material thickness 0.126" - 0.187" 1
Aluminum plates
McMaster Carr
9135K111
$8.01
$8.01
Polypropylene rib Nylon fabric
1 1
McMaster Carr McMaster Carr
8742K131 3510T121
$0.15 $0.51
$0.15 $0.51
Elastic fabric
McMaster Carr
88225K68
$0.24
$0.24
Squeeze buckles
McMaster Carr
29705T82
$0.44
$1.32
Machine screws
McMaster Carr
91735A106
$0.12
$0.72
Nuts
McMaster Carr
90257A005
$0.09
$0.54
Rivets
McMaster Carr
97526A215
$0.04
$0.16
Total
$46.64
108
10.2 CONSIDERATIONS IN DETAILED DESIGN

When a client wants to mass-produce the product, detailed design becomes much more complex than in the case of a one offand beyond the scope of DTC. But because detailed design for production is such a crucial aspect of the work you will do as an engineer, you should have a general understanding of what it involves. Here is a partial list of considerations that typically go into detailed design for production: Materials: What will each component of the product be made of? If there are 18 components in your design, then you must specify the material of each one. It isnt enough to say that the material will be plastic, since there are many kinds of plastic. If you go to the website of McMaster-Carr, a large industrial supplier, you will find that they carry 21 different categories of plastic, ranging from ABS to Garolite to Ultem. Within those 21 categories, there are sub-categories, and each one has specific properties, uses, and costs. You need to research materials to specify those that best suit the requirements of your design. Manufacturing processes: How will components be produced? If you are designing a plastic component for production, will it be manufactured by injection molding, blow molding, rotational molding, compression molding, or some other process? Your decision will affect what features you incorporate into the part and its manufacturing costs. Assembly: How will the various components be joined in the final product? In their book, Engineering Design: A Project-Based Introduction (2000), Clive Dym and Patrick Little give this example: [A]ssembling a ballpoint pen might require that the inkholding unit be inserted into the tube that forms the handgrip, and that caps be attached to each end. The assembly process can be done in a number of ways, and the designer needs to consider approaches that will make it possible for the manufacturer to reduce the costs of assembly while maintaining high quality in the finished product. (p. 202) Reliability: What is the probability that each component in the design will fail to function within a given period of time (or number of uses, miles, etc.)? It is a given in engineering that all components fail. Detailed design requires that you consider the causes that contribute to failure (stress, heat, corrosion, etc.), the means of counteracting those causes, and methods of dealing with failure when it does occur (for instance, designing redundancy into the system so that when one component fails, another allows the system to keep functioning until a repair can be performed).
109
Maintenance: How can the product be designed to make maintenance and repair as easy and practical as possible? Dym and Little (2000) explain the role of engineers in this aspect of detailed design: Designing for maintainability requires that the designer take an active role in setting goals for maintenance (such as times to repair), and in determining the specifications for maintenance and repair activities in order to realize these goals. This can take a number of forms, including selecting parts that are easily accessed and repaired, providing redundancy so that systems can be operated while maintenance continues, specifying preventive or predictive maintenance procedures, and indicating the number and type of spare parts that should be held in inventories in order to reduce downtime when systems fail. (p. 214)
These and other considerations are important to good detailed design for production. Clearly, no one engineer can master them all. Thats partly why companies assemble cross-disciplinary teams to work on design projects. The point is, however, that no designer can afford to overlook these considerations in completing a project.
10.3 REFERENCES
Dym, C. & Little, P. (2000). Engineering design: a project-based introduction. New York: John Wiley and Sons. Foley, P., Kanesathasan, A., Schuster, D. & Willer, M. (2008). Tap-tight goggles:tap on, tap off. Engineering Design and Communication, Northwestern University.
110
Chapter 11: Ethics and Design
CHAPTER 11: ETHICS AND DESIGN
Chapter outline
Ethics in design Nature and scope of design consequences Good design and ethical design Ethical decision-making
Key guidelines related to ethics and design

Consider the impact of your design in relation to: development and testing manufacture users society end of life of the design cost-benefit analysis risk assessment organizational context regulatory compliance
Consider ethical decision-making in relation to:
The first thing to recognize about engineering ethics, and professional ethics generally, is that they do not entail a fundamentally new and different basis for ethics than you already have. Professional ethics do not ask you to adopt one set of values at the workplace and another set in your personal or civic life. Logically and ethically, the founding principles of our actions must go deeper than circumstance. This means that your personal and professional ethics are not entirely divorced from one another. Personal and professional ethics ultimately rest on the same foundation of moral commitment, even though above ground they may branch out in different directions and entail different responsibilities as the context varies. If we ignore that common foundation, we would make professional ethics an ethics of convenience or an exercise in mere rule-following. Ideally, professional ethics should be an extension of the ethical values you already hold, carefully
111
and responsibly applied to your professional work in recognition of the duties and consequences particular to it. Without this common foundation, studying professional ethics would not mean anything. But this is not to say that there is no difference between personal and professional ethics. Although the underlying values will have much in common, professional situations entail fiduciary obligations and involve profoundly new and different contexts for your actionscontexts that could entail farreaching ramifications for others. This difference in context means that your actions take on a different significance when they are part of your professional work. This is the reason that professional organizations create and promote their own codes of ethics. For example, the National Society of Professional Engineers, NSPE, publishes a Code of Ethics for Engineers that attempts to lay out, in a general sense, the basic ethical duties an engineer assumes as a professional. What is different about ethics in the professional context? Ethics, at its most basic level, is about taking responsibility for your actions by anticipating their potential consequencesboth intended and unintendedand acting so that those consequences will be positive. As future engineers, your professional work may greatly influence your users, your community, and even society at largeperhaps in non-obvious ways. Personal integrity is essential. But integrity and good intentions are only prerequisites in a professional environment in which you are entrusted with specific responsibilities whose exercise can have complex and far-reaching implications for others. You must also gain skill in understanding, anticipating, and managing these responsibilities.
11.1 ETHICS IN DESIGN

In fact, additional responsibilities are incurred by professionals generally from doctors to lawyers to professors. What primarily distinguishes engineering from all other professions is the subject of this course: design. Design means the development and creation of new products and systems that collectively can substantially affect societyfor better or worse. Thus, ethics in engineering means that youthe designer and your design teamare accountable for helping shape the impact that your design (and the processes that surround it) will have. Only such an approach will allow you to manage those consequences and do what is possible to ensure that they are positive. Of course, engineers do more than just design things. They may be consultants or advisors in a variety of contexts, and there are other aspects of ethics relevant to engineering (professional ethics, conflicts of interest, endorsements, confidentiality, teamwork, etc.). But as this is a course on the primary task of engineersdesigning and building thingswe'll focus primarily on ethics in design. That actually turns out to have fairly broad implications. Ethical engineeringthat is, engineering that hopes to maximize its positive effect on users and on societyrequires addressing complex design questions
112
ranging from the selection of the problem to the choice of a design solution and its manufacture; from the method of testing to the post-market life of the product. This is because these consequences exist not just in the use of the design, but throughout its whole lifecycle, from development through testing, manufacture, sale, deployment, use, disposal, and beyond. Every phase of the design's life carries social implications, and thereby presents ethical risks and opportunities. Thus, engineers must try to anticipate likely consequencesand even unlikely onesat each stage as much as possible. Ethics in design is not about simply having good intentions, any more than design itself is. Just like design, it is about results. The better you account for the potential impacts of your design, the more you can control the effect it will have in the real world. This is a core part of an engineer's competencenot an optional specialty. It is also one of the more difficult skills to master. Of course, there are reasonable limits to this principle. No one can be held personally responsible for everything that follows from every action he or she takes, if for no other reason than we are not omniscient, and cannot predict (or even know after the fact) all of those consequences. But taking responsibility simply means making the effort to anticipate as many potential consequences as we can.
11.2 NATURE AND SCOPE OF DESIGN CONSEQUENCES

Like design itself, ethics involves more than just safety. A design is not automatically a good one merely because it is safe; still, an unsafe design is probably not a good one. Similarly, an unsafe design is probably not an ethical one; but a safe design is not automatically an ethical one, either. Safety is just one necessary aspect to both good and ethical design. An understanding of the full lifecycle of a design, and the many other impacts it can have, is crucial to understanding what else may be involved. Let's consider the main areas in which a typical engineering design may make its impacts. 1. Development. First, a design must be developed and tested. This means selecting a problem to be solvedideally, if the option presents itself, one that will address a basic unmet need for many people rather than, say, just offering another consumer good. Though fewer engineers are fortunate enough to have this opportunity, it is worth noting that this initial decisionwhat need will my design fill?is probably the most important determinant of just how much good the effort can yield. In any case, once an initial design has been arrived at, it must be tested. But this testing can carry inherent risk to the subjects. The source of the subjects can also present ethical concerns, particularly in medical trials. 2. Manufacturing. Second, the engineered product will very likely involve the use of natural resourcesfor example, steel or petroleum-based plas-
113
tics in the finished product or in the parts that go into it. These natural resources are finite, and so should be used wisely. Obtaining these resources also presents economic, environmental and social costs, especially when these resources are found only in politically or economically unstable regions of the world (for example, demand for the mineral Coltan used in cellular radios has helped fuel civil war in the Congo). In addition there is the manufacturing phase itself, which consumes further natural resources in the form of energy and can also significantly influence the health and safety of the workers. 3. User Impact. Here safety is the most apparent factor, but it is not the only one. Users may be positively or negatively impacted in many ways; for example, a design failure may not hurt anyone physically, but could still present personal or financial costs to the user. This area of impact is reflected in the engineering design goals; but only if those goals account for all the ways the product may impact the user will the design goals include the ethical dimension. It is not always easy to tell when this is the case. Also note that some of these effects may only become apparent after a product is released and used on a large scale in different environments. 4. Social Impact. Not all impacts are borne by the users. Many of them make themselves felt much more broadlyeven by all of society. Among the examples here are automotive emissions, which affect everyone, regardless of whether or not they drive. Technologies may also have profound effects on the structure of society, as has, for example, the Internet, or the increasing costs of medical technology. These are often the most difficult effects to predict, control or account for, but they are also among the most consequential in all of engineering. Anything that can be done to ameliorate these negative ramifications can pay major dividends, both ethical and economic. 5. End of Life. Finally, there are the impacts your design may make at the end of its useful life. Just as the consequences of your product began to be felt even before it was made, its impact continues after it is disused. When a product is disposed of, there is a range of potential positive and negative consequences. On the one hand, if the product contains valuable natural resources that can easily be recovered, its disposal presents an opportunity to prevent further natural resource consumption. If on the other hand it contains toxic elements that cannot easily be reprocessed, the end of life of the product can present a worse health and environmental threat than it did during its manufacture or useful life. In addition, these costs are often not borne equally across all economic strata of society, presenting further ethical considerations. For example, certain poorer parts of Asia have become dumping grounds for old electronics containing toxic materials. Note that while it is helpful to consider these various areas of impact individually, in practice all of them are unified in the design process. After all, the nature of the design determines, or at least heavily influences, the materials, manufacturing, safety, and end-of-life issues. Of course, issues in some of these areas may also arise after the design has been completed; at that point the available options for how to respond to the issue will not include design
114
alternatives, and ethical solutions independent of design will be required. Table 11.1 provides an overview of the lifecycle stages of a design along with examples of the accompanying ethical considerations.
Table 11.1: Examples of ethical considerations in each lifecycle stage
Lifecycle stage Design, development and validation Manufacture, assembly, distribution Direct impact on users and customers Social/environmental impact of design in use Social/environmental impact of design at end of life Example ethical considerations Setting design goals, user testing, clinical trials Mining, petroleum and energy inputs, outsourcing, worker safety Safety, reliability, performance, cost Internet, auto emissions Pollution, disposal, recyclability
It may seem that many of these impacts, while important, are too large for any individual engineer, or even any single design, to be able to influence. It would, for example, certainly be difficult for engineers on a medical device team to do anything meaningful about the high costs of healthcare to which their product might contributethough they might be able to do something to hold down costs for their own product. Nevertheless, all engineers should still be thinking about these impacts for a number of reasons. First, it is important for each of us to better appreciate the full context of our work for personal reasons and as informed citizens in a democracy. Second, if everyone on a project had such awareness, the positive changes possible would become greatly magnified, just as they would if everyone in an industry attained such awareness. And third, you may be in a position later in your career, as a team leader, project manager, or even a CEO, where you will be able to exert a more substantial effect. Moreover, many of these impacts will be under your influence for at least your product. While it will always be more difficult to influence the global scale, the differences in your product alonepreventing a failure mode or refining the user testingcould make all the difference in the lives of those who come into contact with it.
11.3 GOOD DESIGN AND ETHICAL DESIGN

Ethical consideration must be integrated into the design process because it is in design that all consequences are best accounted for, and negative ones minimized or eliminated as possible. Can we say, then, that the ethical dimensions are already accounted for in ordinary engineering design? That ethical design just is good design? There is some truth to this. But it is not the whole truth, because not all important ethical considerationsi.e., not all the impacts a
115
design may haveare directly built into normal engineering design goals. Indeed, many of the most important social impacts a design makes may not factor into typical engineering design criteria. For example, vehicle fuel efficiency can be a selling point for the buyer and at some level is likely to be an explicit engineering design goal; but this consideration does not reflect the full social impact of burning fossil fuels, especially when gas is cheap. Likewise, safety has aspects that affect the users and aspects that could affect others. The aspects that affect others, such as pedestrian safety, are not likely to factor directly in customer safety needs, such as crashworthiness. Therefore, without regulations (which now exist), pedestrian safety would not always factor into the explicit design goals. But a more ethical design approach would proactively identify and address these factors, since they are important consequences of the product in the real world. So considering the user's (or client's) needs remains central to the design process. But ethical, responsible design will consider other needs as well. Engineers, like all professionals, have a responsibility that extends beyond our users or customers and encompasses our broader role in society. This is one crucial aspect that distinguishes engineering ethics from ordinary good engineering. It isn't exclusively about your immediate users and customers, becauseas we have just seenthe impacts of engineering touch us all, directly and indirectly, before and after use. Engineering ethics ultimately means expanding the metrics used to evaluate a design, considering aspects that begin with but might go beyond immediate and obvious user needs. Engineering ethics is a matter of scope. This scope, as we saw above, also extends beyond consideration of the product per se, and includes the processes that inevitably accompany itfrom testing to manufacture to disposal. Explicit engineering design goals traditionally focus squarely on the product itself. They may implicate peripheral processesfor example, manufacturabilitybut typically only as they relate to the end result of the product itself (for example, simplifying manufacturing to keep the unit cost low). Engineering ethics, on the other hand, must be concerned with processes for their own sakefor example, whether the testing phase is conducted safely or whether the product can be efficiently recycled. For all these reasons, ethics is not an extraneous layer added on top of engineering design; it is integral to good designand yet it is not reducible to good design alone.
11.4 ETHICAL DECISION MAKING

Thus, in ethical design, thinking through the many potential impacts of your design, and the choices you've made, is essential. But it is only the first step. Once you have identified areas of concern, what should you do about them? There is no simple answer to this question, if only because every design, every problem, and every environment is different. But there are some basic guidelines, scenarios and information that can be helpful.
116
11.4.1 Cost-benefit analysis

One common approach to addressing problematic design consequences is the cost-benefit analysis. This seemingly simple idea involves comparing the costs of fixing the problem with the cost of the impact if nothing is changed (or comparing the costs of various fixes with each other). This theoretically straightforward approach offers an important perspective, but it is actually fraught with complex ethical questions. The foremost among these is that, if the identified impact involves the risk of death or injury, it requires placing a dollar value on human suffering or even on human life. Only then can the costs be compared on a dollar basis. On one level, this valuation may seem abhorrent. But there are many cases where this is necessary, particularly when the scale of the issue is very great. For example, in crafting safety regulations that will govern entire industries, the government agency in charge must use some dollar figure to compare the benefits in saved lives to the cost of the proposed rule. If they did not, we would go broke trying to eliminate every conceivable risk. But this approach requires tremendous care. History is replete with cases where a company cut corners figuring that the cost or risk was cheaper than doing things rightand people paid with their lives. The other major ethical dimension involved in a cost-benefit analysis concerns how the costs are counted. Even when a dollar value is used to count lives saved, those lives must be accounted their full value regardless of whether or not they represent literal costs to the company. If not, a cost-benefit analysis could ignore those harmed so long as they do not represent actual monetary expenses that the company is likely to bear. If those harmed do not figure into the calculations, the result can be to justify deeply unethical decisions based solely on the company's own financial interests. It is worth noting that, historically in those cases, when the company's reasoning became public, the damage to the company's reputation often became an enormous cost, one that had also not factored into the analysis. These impairments to reputation can take years to recover from. Many firms never do.
11.4.2 Risk assessment

Whether or not a cost-benefit analysis is used, the likelihood and prevalence of the impact requires attention. That is, how likely or common is the negative impact to be and for whom? Is it a risk that all users bear or only users in certain circumstances? Is it a risk that can be avoided if users follow directions and use the design properly? If so, how likely are they to do that? And will the users be aware of the risk? Alternatively, the issue may not be a risk for the user, but for someone elseperhaps a factory worker assembling the product or the person who disposes of it. It may also be a risk that is not specific to anyone but is socially distributed, such as groundwater contamination after disposal. It may even be one that presents itself to an entirely different population than your user base, as when electronics containing toxic elements are crudely recycled in poorer parts of the world. In any case, evaluating the magnitude of the risk can be a very thorny technical problem, and attempts to
117
place numbers on it can profoundly influence the decision of what, if anything, to do about it. These technical issues cannot be addressed here, but the ethical duty can be: to be honest and unbiased in the attempt to assess that risk, and recognize to whom it applies. Once a problem has been detected, and its nature and risk level examined, the obvious next question is what to do about itwhether that means changing the design itself, the materials used, the processes to manufacture it, or simply issuing safety guidance to the user. Clearly, whatever is decided on, that alternative presents a new variation of the designwhich then itself must be analyzed. This is the normal, iterative design process, but, as above, with additional metrics in mind. Also note that, as with the regular design process, choosing what to do about a negative impact will involve the creative generation and comparison of many potential alternatives, not just the first solution you think of. There may not even be a clear-cut fix. The goal, as always, is to find the best compromise solution.
11.4.3 Organizational contexts

In the foregoing, it was assumed that you, as the engineer, have direct influence on the design and the choices that go into it. In DTC, although you work within a team and with a client, this is largely the case. In industry or other professional environments, however, the context is very different. You may still be part of a design team, but you will most likely also be part of a larger, complex hierarchical structure. You will report to a manager; and above him or her, there is an executive management team, a corporate board, perhaps even shareholders. In addition, there may be other teams competing for resources, higher-level corporate goals, company policies, market conditions, indeed, innumerable other factors that may influence the conditions of your work. All of these may constrain your ability to make decisions. So, if you are working on a design and have identified an undesirable outcome it is likely to have, the first question that arises is what scope you have to make changes that would help. In many cases, if it is an ordinary design refinement, consulting with your team and manager to arrive at a superior design will suffice. However, some changes may be more fundamental or may involve other aspects of the overall project. In such cases, you may need to raise the issue with those in higher level positions or with those working on the relevant aspect of the project. Companies will often have explicit channels for raising such concerns, but typically it will begin with notifying your team leader or manager, who then assumes the responsibility for seeing that the problem is communicated to those with the authority to do something about it. There may even be cases where the impact is serious or specific enough that those who would actually be impacted (e.g., end users or community members) should be brought into the decision-making process to offer their own input. This is especially true in cases where there is a particular, inevitable and consequential tradeoff to be made.
118
It is conceivable that there may perhaps come a time when you perceive a major ethical problem with the way that things are being done in your organizationwhether that be a dangerous design flaw, a troubling safety record or some other problemthat you are unable to satisfactorily resolve within your organization's official processes. If this should occur, many larger organizations today offer one additional channel: an ethics office. In fact, even Northwestern University operates one (see www.northwestern.edu/ethics). The purpose of an ethics office, among other roles including education and regulatory compliance verification, is to serve as a confidential venue for reporting ethical concerns. If you feel the need to, you should not hesitate to take advantage of this important avenue, particularly if you believe you have exhausted conventional channels and that the problem poses substantial risks. Of course, in extreme cases, it is possible that even the ethics office, assuming it exists, will not be able or willing to do enough to address the problem. In these cases, you may be forced to consider becoming a whistle-blower. The term simply refers to someone who publicly blows the whistle to call attention to problems as a last resort to getting them addressed. The whistle-blow may take the form of contacting the media, the government, or even a lawyer. The intent in each case is to apply pressure from outside the organization to force it to address the problem. While some of the most important cases in recent history have been initiated by conscientious whistle-blowers (including, for example, cigarette dangers), it is also true that whistle-blowing can be personally a very risky thing to do, threatening relationships as well as employment and even resulting in lawsuits. However, if the issue is important enough, potentially affecting many people or threatening serious injury, you may have no ethical choice but to go public. Fortunately, such cases are not common. In addition, federal law today exists to protect and even reward whistle-blowers.
11.4.4 Regulatory compliance

Engineers, and even entire engineering companies, do not operate in a social vacuum. Because of the large impact of engineering and engineered products on society, there are a plethora of laws, regulations and codes that govern its practice and products. Regulations are part of the social compact between industry and society. Society desires the products of industrywhether they be iPods, automobiles or new drugsbut not at any cost. Regulations, abstractly speaking, exist to mediate the quality of and the means by which these products are developed and sold. Complying with these regulations is thus also an ethical, as well as legal, responsibility. We cannot hope to cover all or even many regulations here. But you should be aware that they exist, and of the important role they play, so a rough overview of our regulatory system is in order. The regulatory environment is very different for the different phases of a product lifecycle described above. Different federal agencies, for example, will have jurisdiction over different kinds of activities. Below are a few of the more prominent ones in the U.S., and a basic idea of their purviews.
119
Environmental Protection Agency (EPA). The agency most responsible for preventing the pollution of air, water and land, the EPA has rules which may influence all phases of the product's lifecycle, from mining for raw materials to production waste products to the energy efficiency of the final product itself. Occupational Safety and Health Administration (OSHA). OSHA is responsible for establishing and enforcing safety standards for the workplace, including industrial sites. Their rules may influence manufacturing aspects in order to protect factory workers. Food and Drug Administration (FDA). The FDA is charged with protecting the safety and efficacy of all medical products (drugs and devices) as well as the safety of many foods. If your product is a medical device or a drug, you must have FDA approval to market it in the US. This often requires clinical studies demonstrating both safety and efficacy. The FDA also regulates promotion and marketing claims for the products it has jurisdiction over. It shares its jurisdiction over food products with the United States Department of Agriculture, USDA. Federal Trade Commission (FTC), including their Bureau of Consumer Protection (BCP). The FTC's mission is to promote fair and honest competition across all sectors of industry. To this end they regulate advertising and product claims, among other things. Their rules may influence sales policies and product marketing. For food, drugs and cosmetics, FDA has primary jurisdiction. Consumer Product Safety Commission (CPSC). The CPSC is a small agency, but it has a large job. It is responsible for policing the safety of any product not regulated by FDA or other agencies. For example, it has rules around lead content in children's toys. The CPSC can mandate recalls of products it determines are toxic or otherwise unsafe. Local regulations. There are of course an unlimited variety of local laws. Building codes are one important example. Codes are set by states and municipalities and govern in detail the construction standards of new buildings. There may also be local regulations around many other activities relevant to engineering. This list is just a sampling of some of the more prominent sources of regulation in this country. Other countries will often have comparable agencies. The point is that the engineer, or someone in his or her company, must be fully aware of the relevant regulations. Ignorance of the law is never considered a valid defense and unfortunately some of the regulations can be complex. If you are doing business internationally, you must comply with the local laws everywhere you operate, which adds to the complexity. Many organizations have entire offices, called compliance departments, dedicated to understanding, keeping up with, and ensuring compliance with applicable regulations.
120
But smaller companies lacking such departments are often equally subject to the laws, and must find a way to become aware of and comply with them.
11.5 CONCLUSION
It should be clear by now that ethics in engineering is not any one skill. It is not confined to any one area or stage of engineering. Nor is it a skill that is ever fully mastered. Rather, it is suffused throughout engineering practice, in ways large and small. And it is a skill that you will continue to hone and grow in throughout your career. The main premise of engineering ethics is to always keep in mind the potentially profound impact your work may have and which engineering, collectively, certainly hasboth locally and globally, on your users as well as on society.
121
122
PART THREE
TEAMWORK AND PROJECT MANAGEMENT
CHAPTERS 12 CREATING A HIGH PERFORMANCE TEAM 13 DEVELOPING LEADERSHIP AND MANAGING CONFLICT 14 CONDUCTING MEETINGS 15 KEEPING A PROJECT FOLDER 16 WRITING AS A TEAM 17 PROJECT SCHEDULING
123
124
Chapter 12: Creating a High Performance Team
CHAPTER 12: CREATING A HIGH PERFORMANCE TEAM
Chapter outline
Team development Team success Team charters
Key guidelines for creating a high performance team

Agree and act on a clear, challenging, and significant overall goal for the team Agree on a team charter to guide the team for the duration of the project Discuss team members' individual strengths and abilities, and assign tasks based on those Develop an effective communication system so that all members are fully aware of team tasks and activities
In each of your DTC projects, you will work on a team. Teamwork makes the engineering design process more efficient and productive, and teams are being used more and more frequently in all professions you may enter. The following two factors explain the importance of teamwork. 1. Teams make the engineering design process more efficient and productive: The varied expertise and experience of team members allow the team to approach problems from many perspectives and thereby produce a good variety of possible solutions. A team can divide up work to make the best use of each members knowledge and skills. Because team members work interdependently toward shared goals, they can motivate each other to work at the highest level.
2. Teamwork is valued no matter what profession you enter.
125
Teams have become a fundamental feature of organizations. You will find teams in factories, corporate offices, research laboratories, universities, hospitals, law offices, government agencies, and other places. According to Harvey Robbins and Michael Finley (1995), two authorities on teamwork, The world is teeming with teams: Work teams, project teams, customer support teams, supplier teams, design teams, planning teams, quality teams. Functional teams, and cross-functional teams....Advisory teams and action teams. Teams with a structure and a charter, and teams that come together on an ad-hoc basis, do something, and fade back into the woodwork. Senior-level teams and rank-and-file teams. Leader-led teams and leaderless teams (p.7). Teams have become integral to organizations largely because of the accelerating complexity of the decisions that need to be made. According to researchers Carl Larson and Frank LaFasto (1989): Whatever the problems are that occupy our attention, it is probable that the more significant they are to our collective well being or to the success of our institutions and enterprises, the more complex they are likely to be. Solving these complex problems demands the integration of many divergent points of view and the effective collaboration of many individuals (p. 17). If you have been on a team in soccer, debate, chess, or other activity, you know that successful teams don't just happen; they are built by individuals working together. This chapter offers you a deeper understanding of how teams develop, what makes them succeed, and why they fail. In subsequent chapters, we will explore ways to make a team work.
12.1 TEAM DEVELOPMENT

In The Discipline of Teams (2005), Katzenbach and Smith define a team as a small number of people with complementary skills who are committed to a common purpose, set of performance goals, and approach for which they hold themselves mutually accountable. They contrast a team with a working group, in which overall performance is a function of what the members do as individuals. A team's performance, by contrast, calls for both individual and mutual accountability. This added factor of mutual accountability means that the team's overall performance exceeds the sum of its parts, its individual members. Katzenbach and Smith emphasize that in order for the team to reach its full potential, members must do more than listen, respond constructively, and
126
provide support to one another... [T]hey must share an essential discipline. This discipline involves five characteristics: 1. A meaningful common purpose that the team has helped shape. After interviewing members of more than 75 teams, Larson and LaFasto (1989) concluded that high performance teams have both a clear understanding of the goal to be achieved and a belief that the goal embodies a worthwhile or important result. Your DTC project may offer value to: an organization that is wasting valuable resources, users with important unfulfilled needs, and even the team members themselves in helping them to develop crucial skills that will benefit them in their later education and career. 2. Specific performance goals that flow from the common purpose. For example, your goal in designing a new product may be to cut the amount of time it requires to perform a task by half. 3. A mix of complementary skills. At the start of the project, you should identify the skills that each team member possesses. Who has had experience working with machine tools, doing technical drawings, leading teams, communicating orally and in writing, facilitating meetings, etc.? In addition, since successful teams rarely have all the needed skills at the outset--they develop them as they learn what the challenge requires. 4. A strong commitment to how the work gets done. The team needs to be structured such that each member has a clear role and is held accountable for his or her contribution. In addition, the team must have an effective communication system, keeping all members informed in a timely way. Members also need to give each other prompt and helpful feedback on their performance so each does his or her best work. Finally, all decisions must be based on facts and data, not on preferences, hunches, or untested assumptions. 5. Mutual accountability. Katzenbach and Smith emphasize that trust and commitment cannot be coerced. The process of agreeing upon appropriate goals serves as the crucible in which members forge their accountability to each other--not just the leader. An important method for achieving mutual accountability is through the team charter, discussed in section 12.3 of this chapter.
12.2 TEAM SUCCESS

Students in DTC who apply this discipline typically act in very specific ways. Below is advice from previous DTC teams about how to do so. 1. Individuals should arrive at each meeting prepared to discuss important issues. Effective teams circulate an agenda in advance of each meeting and they expect team members to have ideas about the major topics on the agenda. This especially helps people who prefer
127
to think before they speak as well as those who talk a lot at meetings, since both types of people have the advantage of preparing their ideas beforehand. 2. Use a project plan, build in extra time, and regularly update your plan. When creating project plans, teams often assume that every task will be completed on time and in order. However, students' actual experience is that unplanned events are part of almost every team's project. More effective teams allow extra time at various stages in their plan to accommodate these events, and they regularly update the plan to make sure that they can get everything done while minimizing the last-minute rush of activity toward the end of the project. 3. Have clearly defined tasks and roles for each team member, including facilitation and project planning. As noted elsewhere in the chapter, teams should make sure that they understand each person's strengths and enable people to play to those strengths throughout the project. This requires members to trust each other. Also, more effective teams value contributions beyond those focused on the task at hand, for instance, from members who plan agendas, facilitate meetings, do project planning, and organize events and activities that allow people to get to know each other outside of class. 4. Emphasize in-person communication over electronic communication. When sending an email or text message, senders tend to assume that their teammates read, understood and agreed to the message's content. Unfortunately, the message might be unclear, the recipients might be confused, or they might disagree but decide not to respond. The bottom line is that electronic communication can cause as much confusion as it is intended to resolve. Effective teams solve problems and make most decisions in person and they primarily use electronic communication to circulate agendas and other information. 5. Get to know each other outside of project work. Effective teams take time to learn about each person's motivation for the project and their life outside of class. Explaining your motivation to others allows you to clarify to yourself what you hope to gain from the experience and gives your teammates a much better chance to help you reach those goals. Knowing about each teammate's interests and background is an effective way to build trust and understanding as you work with each other. 6. Demonstrate success through small wins. Effective teams routinely assemble a long list of small successes that, when added together, end with a successful project. Important small wins include: keeping everyone engaged along the way, solving conflict as soon as it emerges, adhering to the team's decision-making protocols, showing up for meetings prepared and on time, meeting deadlines, being honest with each other when small problems happen (rather than letting problems build), and agreeing to expectations for quality and noting when those expectations are met (and not met).
128
7. Solve conflict early and with honest conversations. It's inevitable for teammates to disagree with each other and healthy conflict is actually a sign of good teamwork. In contrast, an absence of conflict often means that people don't care about the work at hand or that they've given up being heard. Working through a hard problem requires that teams make sure that everyone is heard to her or his satisfaction and then making a great decision. It also requires each person to put the needs and success of the team ahead of his or her own ego.
12.3 TEAM CHARTERS

Teams generally prefer to get right to work on the project theyve been given. This is unwise. In hindsight, many teams trace their failures to not having shared expectations and specific ground rules. Research shows that teams should start with the question how will we work together? not what's the right answer to the project? Numerous experts have emphasized the importance of teams developing a charter at the start of a project so that they have a foundation on which to build a high-performance team (Matthieu & Rapp, 2009, p. 90). A team develops the charter collaboratively in order to agree on how they will work together to complete the project successfully. Among other things, the charter expresses the team's agreements on the following questions: Whats our mission? What will success look like? What specific objectives do we need to reach to achieve success? And by when? What resources (people, time, financial, equipment and processes) do we need? What's the context of our work together? Who called us together and what do we know about that persons (or groups) expectations? Who has authority to make what decisions? What decisions can individuals make? What decisions can be made by smaller teams? What decisions do we make together? What decisions do we need to have made by others? What value do we place on conflict? How will we resolve conflict when it occurs? How will we know when we've reached genuine agreement?
To serve their purpose most effectively, team charters must be comprehensive and specific; as Matthieu and Rapp explain: Teams with high-quality charters are more likely to have thoroughly outlined member roles and interaction processes early on, so members can better concentrate on taskwork without pausing to debate issues already addressed in the
129
team charter and can thereby perform better. To the extent that the charter is comprehensive, it should lay the foundation for a wide variety of circumstances that the team may confront. (p. 92) In DTC, your team charter consists of three main sections: 1. Mission: This is identical with the mission statement in your project definition, as discussed in Chapter 3. 2. Performance Goals: These identify the major objectives guiding the process that the team will follow to achieve its mission with a high level of quality. 3. Team Standards: These specify the behaviors and performance expectations that the team will follow in its day-to-day functioning. The following team charter is neither comprehensive nor specific, so it is unlikely to help the team as the project proceeds and demands more of each member's time and effort:
Example 12.1: Vague and Ineffective Team Charter Mission: We will design a system that enables people in wheelchairs to transfer to and from the leg press machine at RIC quickly and comfortably. Performance goal: Our mission is to fulfill the requirements of our project as set forth in the client's description provided to us at the start. Team Standards: Communication Use email to stay in touch. Be open-minded. Meetings Attend all meetings and be on time. Do everything possible to make the meetings productive. In particular, have a meeting agenda and stick to it. Everybody should participate in each meeting. All ideas should be respected. Dealing with disagreements Disagreements should be openly discussed until agreement is reached. Team Dynamics
130
Have fun! Enjoy the process as much as possible. Track Tasks - Roles & Responsibilities Assign tasks evenly and fairly. Make sure to complete your assigned task on time. Intrinsic Motivation Each person should be sure to coordinate their personal goals with those of the entire team.
While the mission statement is clear, the performance goal sets only a minimal standard of achievement, and the team standards lack detail and leave important questions unaddressed, such as: When and how often will the team meet? What happens if someone fails to attend or is consistently late? Will all communication be conducted through email? If so, how often is it expected that team members will check their email and reply? How will the team ensure that tasks are assigned evenly and fairly? What happens if someone cannot or does not complete a task on time? How will the team have fun? Through what means will the team resolve disagreements?
These are only a few of the gaps in this team charter. True, the team could address these gaps as they arise later in the project, but that would waste time and energy when they can least afford to do so. In such cases, experts find that the team is likely to spend undue time grappling with teamwork issues that were not outlined initially and to suffer performance consequences (Matthieu & Rapp, p. 92). Effective team charters can take different forms and emphasize different expectations and behaviors. The key is to schedule, at the start of the project, a meeting whose purpose is for you to discuss and agree on a specific and comprehensive charter that you feel confident will help you to become a high performance team. For examples of two different but effective team charters see Appendix K.
131
12.4 REFERENCES
Katzenbach, J. & Smith, D. (1993). The wisdom of teams: creating the high performance organization. Boston: Harvard Business School Press. Larson, C. & LaFasto, F. (1989). Teamwork: What must go right/what can go wrong. Newbury Park: Sage. Matthieu, J. & Rapp, T. (2009). Laying the foundation for successful team performance strategies: The roles of team charters and performance strategies. Journal of Applied Psychology, 94:1, 90-103. Robbins, H. & Finley, M. (1995). Why teams don't work: what went wrong and how to make it right. Princeton: Peterson's/Pacesetter.
132
Chapter 13: Developing Leadership and Managing Conflict
CHAPTER 13: DEVELOPING LEADERSHIP AND MANAGING CONFLICT
Chapter outline
Developing a leadership structure Managing team conflicts
Key guidelines for developing leadership and managing conflict

Agree on a leadership structure for the team: individual, shared, or rotating Use online team process checks and peer reviews to help identify potential problem areas Address conflicts that hamper team performance; do not let them fester
To get your team to the performing stage described in Chapter 12, you need to develop an effective leadership structure and learn how to confront and manage conflicts productively.
13.1 DEVELOPING A LEADERSHIP STRUCTURE

Whereas in industry, team leaders are assigned by management, in DTC the team must decide which leadership structure works best for them. In general, this structure takes one of three forms: Shared leadership Team members who decide to share leadership tend to be self-motivated and comfortable taking charge of a particular aspect of a project. One member may be responsible for prototyping, another for user and client interactions, and a third for written deliverables.
133
Rotating leadership This model works well when team members have time constraints at different points in the project. Rotating leadership also is a good choice for teams with members who have strong personalities and are reluctant to give leadership over to one person. One DTC team rotated leadership when members recognized that their relationships and quality of work were deteriorating. One member directed activities during the testing phase, another during the design review phase, and a third during the preparations for the final presentation.
Single-person leadership This model works well when one member is good at managing, motivating, and communicating with his or her teammates or when sharing leadership is causing confusion about roles, missed deadlines, and poor communication. As one student commented, I learned that it is necessary to not be afraid to be a leader. If you feel like your team is falling apart, it is essential that you step up and take charge when the rest of the team needs you the most. Another student found that his team faltered without his leadership: I was the one running all the meetings, setting up times, and calling people. One week when I was out of town, my team forgot to meet. While this was very frustrating, it made me realize that I really did hold the leadership role in my group. While this took up a lot more of my time, I also found it was rather rewarding when the team functioned to produce a final product. However, when one person is acting as the leader, its important for him or her to also be a good team member and to avoid being bossy. Good leadership involves following the guidelines below.
When your team hits the storming stage, discuss whether leadershipor lack thereofis causing problems, and then choose a form of leadership that suits members personalities and needs.
13.1.1 Guidelines for exercising effective leadership

As a leader, you should: 1. Assign tasks based on members interests and skills. People work harder and produce better results when their work matches their talents. 2. Trust team members. Some leaders lose trust in members whose work they think isnt up to par and take it upon themselves to redo the work. This can cause resentment and infighting, so its best to learn to trust the members of your team. One team leader with a need for control said he
134
made a conscious effort to resist his desire to take a finished product from a team member, alter it, and turn it in: I often have an impulse to do this, but I know it is irritating for team members and not in the collaborative spirit, so I have tried not to. Another team leader had a similar experience: I dont like when I feel like I am not on top of the situation, and I am a little uncomfortable in trusting others to do a quality job on something. However, I have become much more confident in team members work and have micromanaged less. In both quarters, my increase in trust made the team run more smoothly and be less testy. 3. Work toward consensus. Some leaders try to push their decisions on team members rather than help them reach a consensus. But that can only backfire. As one wise student leader put it, Team goals should be set with as much input from each team member as possible because people are more likely to complete a task if they have influenced the decision-making process that led to the task. 4. Encourage communication. First, email members regularly to tell them what you are doing and what the team needs to do. One team leader states that in his first quarter of DTC he sent out scores of emails to teammates. He notes the problems that resulted in the second quarter when he did not send out emails at important times when they were needed: There were a few times when one team member and I would make a discovery, plan, or decision without properly consulting with or informing the third team member. That third teammate became resentful and felt he had wasted time on his assigned tasks. Second, encourage communication by leading meetings effectively. See the following chapter for a discussion of how to conduct meetings. Third, help the team identify and resolve conflicts. As one team leader learned by hard experience, Throughout the eleven-week quarter, team dynamic problems that are not addressed directly are difficult to resolve and it is difficult to regroup the team.
13.2 MANAGING TEAM CONFLICTS

Team conflict is inevitable, even when members interests and strengths are well-matched. In fact, some conflict within a team can be a positive thing because it shows that team members are considering very different approaches to their design. A successful team performs well not because it has no conflicts, but because it has learned how to manage them. Here are the three main sources of team conflict. (NOTE: These examples are real, but the names have been changed.) 1. Differences of opinion about goals and decisions. One DTC team couldnt agree about the solution to its design project. Joanne, Nelson, and Stacy felt the team should take a conservative approach and modify an existing device because of members lack of time and knowledge about mechanical engineering. Vera felt they owed it to the client and themselves to take
135
a more experimental approach and develop innovative designs. Until they resolved their conflict, they failed to make progress. 2. Differences in personality and working style. Ann, who was extroverted and outspoken, thought Gregs reticent personality would weaken the teams presentations to the instructors and client. Greg felt Ann was focusing too much on the presentations and not enough on the technical aspects of the project. They resolved their conflict by discussing how each person's personality and working style could contribute to the team's success and then dividing up more of their work.. 3. Perceptions that members are not fulfilling their responsibilities. Three members of a DTC team were frustrated with the fourth member, who didnt do the work he had agreed to. They tried talking to him, but nothing helped until the three members met with their instructors and maturely worked out a solution to the problem that enabled them to move forward on the project. Its important not to let one person who doesnt participate derail the project as a whole.
13.2.1 Guidelines for managing conflict

1. When your team is having conflicts over goals and decisions, shift the focus from what team members want to why they want it. As management consultant Maureen O'Brien (1995) states: When we become emotionally invested in getting what we want, we often lose sight of why we want itand the reason we want anything is to satisfy a need. One of the secrets to resolving conflict is to find out what people need. It's very possible to satisfy a persons or a groups needs without necessarily giving them what they claim they want. The above-mentioned team, who were split over whether to take a conservative or innovative approach to their design, resolved their conflict by discussing their needs rather than defending their positions. Joanne, Nelson, and Stacythe conservative membersneeded to feel they wouldnt jeopardize their grades by adopting a risky approach. Vera needed to express her creativity by choosing a more experimental design. To meet the needs of both sides, their instructors suggested a three-part approach: (1) The team would generate conservative and innovative alternatives, which the instructors reassured them would help their grade. (2) Members would analyze the alternatives and choose the one that best fit client and user needs. (3) The team would then produce a design based on the chosen alternative: a prototype if it was conservative and CAD drawings if it was innovative. With the conflict resolved to everyone's satisfaction, the team was able to move ahead creatively and productively. 2. When you have a problem with a team members personality or working style:
136
a. Decide what you can and can't change. He talks non-stop. She's always so late. When will he quit mumbling so I can understand him? I wish she'd quit being so negative. Just because he has computer programming experience, he thinks he knows everything. If you decide the person cant, or wont, change, figure out what you want to accomplish in the long run. For example, if the persons problem is low participation due to reticence, get him or her to participate by having everyone on the team come to the next meeting with one idea for each agenda item, have team members email ideas to each other, or have each member speak on an agenda item at a meeting. Approach the conflict the same way you approach design problems: identify the real problem, generate alternative solutions, and choose those that best address the problem. b. Use members personality and working style to their best advantage. The DTC team mentioned earlier with Anne, the extrovert, and Greg, the serious-minded, came to realize that each was doing necessary work. Greg's drawings would provide evidence for the presentations that Ann was preparing. And Carla, the third member, would coordinate the efforts of the team. c. Decide when and where to discuss the conflict. Your decisions will depend on the nature of the conflict, the personalities involved, and the goal to be accomplished. In some situations, a formal team meeting is the ideal setting. In others, its over coffee or in your instructor's office. d. State explicitly that you want to discuss the problem. Being direct, rather than beating around the bush, helps you to focus the discussion and prepares the person to listen. Remember to be tactful and to listen. e. Precisely describe the irritating behavior and when it occurred. Avoid generalizing and name-calling. Insults will only make your teammate feel defensive, hostile, and less willing to resolve the problem. Instead, try a more objective and less accusatory approach. Begin by stating facts: When I suggested a format for the user survey, you said it would never work. At the last meeting, when I suggested we interview our client again to nail down the problem, you said that was ridiculous because the problem was already clear. And at the same
137
meeting, you laughed when I said we needed to do more research. These examples give each of you something specific to work from and demonstrate that your reactions derive not from imagined slights but from actual incidents. Next, explain how the behavior affects you and the team. In the situation above, you might say, Im to the point where I no longer want to contribute ideas during our meetings because I worry about being embarrassed by having them put down. That means we might lose out on some potentially good ideas. Besides, its going to make everyone uncomfortable if I just sit here saying nothing during meetings. Explaining the behavior's consequences gives everyone a stake in reaching a resolution. Finally, offer a suggestion. In the situation above, you might say, Id like you to hear me out when I have something to say. And if you disagree, then I'd like you to be specific about which part you dont like and why. Sometimes you might not know what to suggest. In that case, propose that you work together to reach a resolution so the problem doesn't stand in the way of the team's progress. 3. When someone tells you he or she has a problem with your behavior: a. Try not to get defensive. Although its hard to hold back or refrain from challenging the facts, keep in mind that being defensive makes it harder to resolve the problem. Instead, ask your teammate what is causing him or her to feel this way toward you. b. Paraphrase what you heard the person say. This helps clarify the problem and puts you in the proper frame of mind to reach a resolution. c. Comment on the suggestion your teammate offers. Can you act on the suggestion? If not, what are some alternatives to resolving the conflict? d. Offer explanatory facts if appropriate; for instance, I've been late because my supervisor at work has asked me to work extra hours, so maybe we should talk about shifting our meetings to a time thats good for all of us. 4. When conflicts arise from the perception that some team members are not doing their fair share of work, try the following. a. Find out through discussion whether you're correct in thinking these members are not doing their fair share. Occasionally the team member is doing the work, but others don't see it that way. In the case of the introvert and extrovert, Greg and Ann saw each other as less hard-working because neither understood the
138
value of the work the other person was doing. They needed to appreciate the contributions both were making to the project. b. When it becomes apparent that one or more team members are not doing their fair share, the rest of the team has two options: (1) discuss a fair way to assign responsibilities; (2) ask your instructors to intervene. In one DTC class, three team members worked hard while one, George, did very little. When he failed to follow through on new tasks he agreed to do, even at the persuasion of his instructors, his team members decided that worrying about him was distracting them from the project. After consulting with their instructors, they divided the work among themselves, started having fun, and developed an outstanding design. If George had behaved this way on a job, he would have been transferred, or even fired. In DTC, those are not options. But because teamwork is required, George received a low grade for failing to cooperate with his team.
13.3 REFERENCES
OBrien, M. (1995). Who's got the ball? (and other nagging questions about team life). San Francisco: Jossey-Bass.
139
140
Chapter 14: Conducting Meetings
CHAPTER 14: CONDUCTING MEETINGS
Chapter outline
Setting an agenda Conducting the meeting Keeping meeting minutes Conducting meetings with instructors
Key guidelines for conducting meetings

Post agendas well before meetings, using this structure: date/time/location objective leader scribe topics/presenters come on time have everyone participate make decisions by consensus, not majority rule date/time/location participants scribe topics, key points, and decisions
Follow these guidelines for effective meetings:
Post minutes after the meeting, using this structure:
Team meetings will play an important role not only in your work in DTC but in your professional career as well. Researchers who surveyed over one hundred engineers with an average of fifteen years of experience found that meetings and informal interpersonal situations are the places where a significant amount of engineering work gets done and provide the context for creating and sustaining productivity in daily practice (Darling, Dannels, 2003, p. 8).
141
In DTC, class periods dont give you enough time to work on your project, so your team should meet at least once a week outside of class to plan tasks, analyze information, write reports, and practice presentations. In addition, your team will have formal meetings with faculty to discuss team progress. Out-of-class team meetings are valuable for the following reasons: Members can talk about their skills, interests, and outside commitments so that work can be distributed in the most realistic and productive way. Meetings are an incentive to complete your work, knowing youll have to report on it at a team meeting. They help you figure out answers to difficult questions such as, What should our objectives be? and What kind of user testing should we do? They help clarify team goals, reach consensus on decisions, and bring to the surface and resolve underlying problems that may be hampering the team's performance. They spark creativity by having you bounce ideas off each other.
The rest of this chapter explains how to get the most out of these meetings.
14.1 SETTING AN AGENDA

Prepare an agenda, with input from team members, to make the best use of your time. Set the agenda by having team members contribute items. The agenda should include: Meeting date, time, and location. Make sure all team members can attend and arrive on time. If you are going to be absent or late, let the meeting leader know. Select a location thats safe and convenient for everyone, or rotate locations. Meeting objective. Be as specific as possible in your meeting objective so you dont get off-track. For instance, Discuss the progress of the project is too vague, but Finalize decisions on mockups and assign roles for building them gives members a clear goal. Key roles. The leader posts the agenda and facilitates discussion; the scribe takes notes during the meeting and posts the minutes to the team afterward; the time keeper makes sure the team stays within its allotted time for each agenda topic. Consider rotating roles from meeting to meeting to give everyone a chance at each job. Discussion topics. This may simply be a list of topics or, for formal meetings with your instructors, more detailed.
142
Below are three different agendas used by a team working on a food-cutting device for stroke survivors. The first agenda was for a meeting held by team members to plan mockups:
Example 14.1: Agenda for team meeting to discuss mockups Team Meeting Agenda Meeting date, time, location: April 22, 2:00-3:00 p.m., Foster-Walker Objective: Plan mockups and user testing Meeting leader: Jessie Scribe: Nirav Topics/presenters Mockup #1/Nirav Mockup #2/Vera Mockup #3/Alicia User testing/Jessie Update RAM and Gantt/Jesse
Below is an agenda for a meeting held with instructors to review progress. The agenda is much more detailed, primarily because faculty will assign an advisory grade based on the teams clarity, conciseness, and professionalism. DTC provides a downloadable agenda form for team/instructor meetings, modeled on the best practices in industry.
Example 14.2: Agenda for team meeting with instructors Meeting date, time, location: May 4, 2:30 to 3 p.m., Ford Objective: Get feedback from instructors on mockups and user test plan Meeting leader: Vera Scribe: Jessie Timekeeper: Nirav
143
Topic Review of action items from previous meeting
Presenter Vera
Time 2 min.
Outcome Instructors know key findings resulting from completion of action items
Process Oral summary with reference to minutes of preceding meeting and to progress report
Preparation Review progress report and minutes of preceding meeting
Mockups for user testing
Nirav, Alicia, and Vera Jessie
10 min.
Instructors provide feedback on mockups
Oral summary with mockups
Review progress report; make sure everyone brings mockups Jessie types email and circulates it among team for review; makes copies of edited version for meeting Jessie types guide and circulates it among team for review; makes copies of edited version for meeting Make sure project notebook is updated and complete in case material is needed to answer questions
Plan for getting users
5 min.
Instructors review and offer suggestions for revising email to client asking for users
Copies of email are distributed
User test guide Jessie
8 min.
Instructors review and offer suggestions for user test guide
Copies of user test guide are distributed
Questions and comments from instructors
Vera
8 min.
Instructors have opportunity to raise issues and concerns
Discussion
Finally, here is an agenda for a team meeting with the client. It was held three weeks before the scheduled final presentation, and its goal was to get the clients feedback on the final design direction that the team had chosen as a result of user testing. It is less detailed than the agenda used for the meeting with instructors because the client does not need to know the planning process used by the team for each topic. However, the time allotted for each topic is included because it is critical that the team adhere to the client's schedule.
Example 14.3: Agenda for meeting with client Meeting date, time, location: May 15, 9:30-10:00 a.m., Ford Design atrium Objective: Get feedback on final design concept from client Meeting leader: Alicia Scribe: Jessie Timekeeper: Vera
144
Topics/time/presenter Review of meeting objective and agenda/1 minute/Alicia Review of mockups tested with users/5 minutes/Nirav Summary of results of user testing/5 minutes/Vera Decision matrix used to arrive at final design concept/5 minutes/ Alicia Review of sketches of final design concept/10 minutes/Jessie Next steps/2 minutes/Nirav Final presentation time and place/2 minutes/Nirav
Although preparing an agenda may seem like a lot of work for a relatively short meeting, it's well worth doing because it helps members accomplish what they set out to do within the time allotted.
14.2 CONDUCTING THE MEETING

Below is a list of responsibilities for members holding major roles in a team meeting.
Leader
Write the agenda and email it to the team 24 to 48 hours before the meeting so participants can adequately prepare. Upload the agenda to the project folder. Make sure the meeting starts and ends on time. Keep the discussion focused on the topic and tactfully steer it back when it drifts. Encourage everyone to participate by having each person say something on the topic at hand. Make sure all agenda items are discussed. If that isnt possible, ask individual members to circulate material on items that will carry over to the next meeting. Help the team reach a consensus. Ask if anyone disagrees with a decision that has emerged from the discussion. If so, ask for further discussion to clarify and resolve the disagreement. Help the team identify what actions need to be taken based on decisions made at the meeting, who will be responsible for those action items, and when they will be completed.
Timekeeper
Let the facilitator know when discussion time is up for an agenda topic. At that point, the leader, with the concurrence of the partici-
145
pants, can decide to continue the discussion, and thus modify the agenda, or table the discussion and continue with the original agenda.
Scribe
Take notes on key discussion points, decisions reached, and actions to be taken (along with who is responsible for those actions and when they should be completed). Review the action items with the team at the end of the meeting. Type up a well-organized version of the meeting minutes and email them to the team within 24 hours so members can offer additions, corrections, or clarifications. Then post the revised minutes to team members and your instructors. After all corrections are made, upload the minutes to the project folder. NOTE: Meeting minutes are discussed in greater detail in the last section of this chapter.
Topic presenter:
Prepare the material specified in the agenda and bring it to the meeting. If something unexpected comes up to prevent you from doing that, notify the rest of the team as soon as possible and try to arrange for someone else to prepare the material. If youve prepared the material but find you cant attend the meeting, make sure to get it to a teammate before the meeting.
146
14.2.1 General guidelines for participation in team meetings

Follow these guidelines to ensure a productive meeting: Have everyone participate. Management consultant Maureen OBrien (1995) urges participants to abide by the ground rule, Everyone must respond out loud. This energizes the team, and it confirms agreement or disagreement, which, in the end, helps to clarify decisions (p. 128). Keeping silent signals to others that you agree or that you're too angry to say anything, neither of which may be the case. If one or more members are consistently quiet during meetings, experiment with ways to get everyone to contribute: for example, go around the circle and take turns giving ideas, or have team members write down their suggestions. Dont interrupt. Even though people sometimes interrupt out of enthusiasm, interrupting is disrespectful and can cause members to become disengaged. If interruptions are a persistent problem at meetings, have the leader or someone else call a time out whenever there's an interruption or come up with another solution that everyone can agree on. If people feel the need to interrupt because one member dominates the discussion, bring that problem up at a meeting. Dont reject ideas out of hand. Such behavior can take many forms: insulting (That's ridiculous), condescending (Thats an interesting idea, but...), dismissive (No, you're wrong), and devastating (the silent treatment). Abruptly dismissing others ideas means that good ideas will be lost and teams will lose valuable perspectives. The best way to respond to an idea with which you disagree is to ask the reasoning behind it. Require consensus, not majority rule, on major decisions. As Harrington-Mackin (1994) points out, When we vote, there is a winner and a loser. In addition to the fact that losers usually like to get even, a team with winners and losers is a divided team with two different goals, doomed for failure (pp. 48-49). Consensus is often difficult to achieve, but is essential for key decisions. For strategies on how to achieve consensus, see the earlier chapter on managing conflict.
14.3 KEEPING MEETING MINUTES

Minutes serve as a record of key ideas discussed, decisions reached, and tasks assigned. In this way, minutes help keep the project on track. Instructors can refer to these minutes (in the project notebook) to make sure everyone on the team is involved in the project. And the team can refer to the minutes when they plan email updates to the client. Meeting minutes shouldnt be a record of everything that is said at the meeting. Instead, they should include the following information:
147
Location, date, and time of meeting. Names of people present and absent. Name of scribe. Topics discussed, plus a brief summary of the major points and decisions made in regard to each. Actions planned, the names of team members assigned to them, and the deadline.
The minutes should be posted shortly after the meeting for review and use by team members. Here are minutes written by the team designing a food-cutting device for stroke victims.
Example 14.4: Team meeting minutes Location, date, and time of meeting: Tech Express, May 12, 2:30 to 3:45 p.m. Attending: Entire team (Jessie, Vera, Alicia, Nirav) Scribe: Jessie Topics, key points, and decisions Review of user testing procedures: Jessie and Nirav followed the user interview script we developed for our three mockups with two users at RIC. They took 33 digital photos during the tests. Features liked by users: Mockup 1: sponge-grip handle; 45-degree-angle handle Mockup 2: spring mechanism Mockup 3: safety lock; rounded edges Mockup 1: shortness of blades Mockup 2: awkward angle of handle Mockup 3: difficulty of getting fingers through holes in handle
Features disliked by users:
Concept for design review: Using a decision matrix, we decided to build one mockup for the design review. It will have a blade length of approximately six inches with rounded tips for safety, and sponge handles at a 45-degree angle. Because the safety lock and spring mechanism will add to the cost and make the device difficult to clean, we will leave those features out. Instead, we will mock up a different kind of screw connection of the blades (yet to be determined) and a carrying case, probably leather for safety. Tasks to prepare for design review (and deadlines): Type RAM chart: Jessie (5/15) Buy mockup supplies: Vera (5/16)
148
Build mockup: Jessie and Vera (5/20) Prepare design review slides and questionnaire: Nirav and Alicia (5/20) Practice design review: everyone (5/21)
Writing and posting minutes usually takes no more than 15 minutes if the scribe has taken good notes at the meeting. The payoff is a valuable reference for the team and the instructors.
14.4 CONDUCTING MEETINGS WITH INSTRUCTORS

In spring quarter, each team will conduct at least two half-hour meetings with their instructors. The purpose of these meetings is to review team decisions, plans, and questions so that your instructors can offer constructive advice for your project work and evaluate your project management and teamwork. The team is responsible for planning and conducting the meeting. As you do that planning, keep in mind the following guidelines: Focus the meeting on key design decisions and plans for the upcoming weeks. Your team will have submitted a progress report to instructors the day before the meeting, so there is no need to rehash its contents. You should focus the meeting on where your design stands now and what your planned next steps are. Structure the meeting so that it will lead to developing action items that move the project forward. Have team member take an active and equal role in the meeting. This means assigning roles beforehand, as described above in the sections on setting the agenda and conducting the meeting. It also means that everyone on the team should know not only what he or she will discuss but also what the others will. If one person dominates the meeting and others are foggy on project details, your instructors are likely to question the effectiveness of your project management and teamwork. Review action items from the previous meeting. A major purpose of the meetings is to develop a list of actions that the team should complete in the upcoming weeks. By the time of the next meeting, make sure that youve completed those action items. Near the start of the meeting, briefly go over each item. If there are good reasons why you have not completed some of themthey are no longer relevant to your project or the people you need to contact are unavailableyou should explain those reasons and your plans regarding the actions. Meet as a team beforehand to develop an agenda. Discuss what you need to cover at the meeting with your instructors, and assign roles and necessary preparation. Someone should post a draft of the agenda
149
for team review and revision. Then post the final version of the agenda to your team and instructors, and bring copies for everyone to the meeting. Bring all support materials to meeting. These include copies of the agenda and progress report, updated Gantt and RAM charts, project notebook, drawings, mockups, and anything else that you plan to discuss or that your instructors may ask to see. Before the meeting, review the Gantt and RAM charts to make sure that your team is on schedule and has completed all the tasks it should have.
14.5 REFERENCES
Darling, A. & Dannels, D. (2003). Practicing engineers talk about the importance of talk: A report on the role of oral communication in the workplace. Communication Education, 52(1), 1-16. Harrington-Mackin, D. (1994). The team building tool kit: tips, tactics, and rules for effective workplace teams. New York: Amacom. OBrien, M. (1995). Who's got the ball? (and other nagging questions about team life). San Francisco: Jossey-Bass.
150
Chapter 15: Keeping a Project Folder
CHAPTER 15: KEEPING A PROJECT FOLDER
Chapter outline
Purpose Content and organization
Key guidelines for keeping a project folder

Upload all project-related material to your teams collection within Google Docs, including: drafts and final versions of all reports, PowerPoint slides, testing guides, project definitions, RAM and Gantt charts, etc. sketches and drawings from brainstorming, alternatives, mockups, and prototypes (scanned versions) email correspondence team documents, such as team standards, agendas, and minutes research results, such as articles, photos, videos, test data, and interview summaries
Upload material as you produce itdon't wait till the end of the project
15.1 PURPOSE
Professional engineers and designers know the importance of keeping complete records of all their projects. The most common tool for doing this is the engineering notebook, which has two purposes. (1) It provides a central location for recording research plans and results, design ideas, data, notes, and sketchesall of which are used by the team and others who continue the project. Because employees sometimes leave one company for another in the middle of a project, the remaining members of the team need to have a permanent repository of everyone's work in order to move forward. In addition, companies looking to improve their existing products depend on these repositories of project-related material to fill in subsequent teams. (2) It serves as a legal record of design activity to preserve patent protection. In industry, this is often a bound notebook that serves as a legal record, and to which pages cannot be added or deleted.
151
In some cases, all records are kept electronically. In DTC, each team maintains an electronic version of a project folder using Google Docs. As the quarter progresses, the team will generate a large collection of documents: interview guides, research plans, research results, report drafts, emails, photos, drawings, and more. Think of the collection in this way: If your team won the lottery midway through the project and decided to go on vacation for the rest of the quarter, another team could use the materials in your collection to retrace all your steps, understand all your thinking, find all your research data, and quickly pick up where you left off. Each document should include the date and the name(s) of the person(s) who created it. Dating each document is a good habit to develop early in your career. Later, when you may engage in research that leads to patents, you will find that dated notes serve to document priority in patent disputes. Including the names of team members who created the respective documents will help your instructors (and, later in your career, supervisors and others) determine who did what during the course of the project. Your instructors will review your documents periodically. Theyll be checking to see that the team has been following the design process, completing all tasks, and recording all results accurately and comprehensively. Theyll also be looking for signs of good teamwork and individual participation, which are evident in the scope of the material, and in the initialing and dating of that material. The project folder counts as part of your team's project management grade. It will also be used to help calculate each student's team and individual participation grades. For this reason, it's important that all team members contribute materials to the folder, and that the team scrupulously document individual contributions.
15.2 CONTENT AND ORGANIZATION

Each team will have its own collection of Google Docs; other Google Apps are also available for the teams to use (Groups, Sites, Calendars, etc.). Specific instructions and help sessions will be available to all DTC sections and teams. Your instructors will give you ideas for how to organize and categorize your project information in Google Docs. Organizing such a large and diverse collection of materials can be a challenge. Include clear and specific titles for all of the items and attached files in your document collection so that they are easy to identify. For instance, instead of Meeting_agenda, use a more descriptive file name like Team_Meeting _October_12_agenda_v1. Below is an alphabetically arranged list of categories that that shows a representative range of types of materials generated during a DTC project.
152
Background research Initial research questions (categorized) Internet and library sources Research results (you may want to create more sub-categories to organize this material so that it is easy to find) Analysis of competitive and model products Expert interview guides, notes, and summary/analysis Brainstorming sketches (scanned) Brainstorming lists (initial list and clustered version) Records of client phone calls Client emails (both to and from the client) Initial client interview guide, notes, and summary/analysis Client meeting agendas, notes, and summary/analysis Questionnaire handed out to class Power Point slides Sketches and other visuals used in the design review Notes from and summary/analysis of design review All drafts of the various sections of the report (including instructor feedback) Final version of the report Alternatives matrices Mockup planning sheets and sketches Pictures, descriptions, and operating procedures of mockups Performance test guides Raw data from and summary/analysis of performance testing All drafts of the poster Notes used for presentation Visuals (besides the poster) used for presentation Handout given to judges
Brainstorming
Client contact
Design review
Final report
Mockups
Performance Testing
Poster presentation
153
Project definitions Initial project description from client Project definition (all versions) Course syllabus RAMs Gantt charts Decision matrices that led to prototype Plans for constructing prototype Drawings and photos of prototype Prototype testing procedure and results Subsequent modifications to the prototype Instructions for using the final prototype Information to build another prototype Bill of materials Isometric and orthographic drawings (scanned) Instructions for building the prototype
Project management
Prototype
Team information & standards Contact information of team members Weekly schedule of team members non-DTC activities (this is helpful for planning outside team meetings) Team standards (all drafts) Signed student/client understanding form Agendas Minutes User observation/interview guide, notes, and summary/analysis User testing guide, notes, and summary/analysis Photographs Drawings & sketches (scanned) Maps, charts, & tables
Team meetings
User contact
Visuals
154
Chapter 16: Writing as a Team
CHAPTER 16: WRITING AS A TEAM
Key guidelines for writing as a team

Use a RAM chart or team meeting minutes to allocate responsibilities for writing sections of a report or presentation Choose at least one person to take charge of assembling and editing the sections of the report Get the sections to the editors early enough so they have time to do the editing Before writing the sections, decide as a team on style guidelines related to font size, headings, paragraphing, and technical terminology
Engineers and scientists in both industry and academia often team up to write. This collaboration allows them to split up their work, pool their strengths and talents, and solve difficult intellectual and business problems. Sometimes one member of the team will write a draft, especially when the document is relatively short, and the others will edit it. At other times, each member will contribute sections or appendices, and hand it over to another member to assemble. Then that member will turn it over to others on the team for editing.
16.1 GUIDELINES FOR WRITING AS A TEAM

Depending on how you approach it, writing as a team can be an efficient and effective way to writeor a burdensome procedure. The following guidelines can help you save time and produce effective documents. 1. Decide as a team on the goals of the document and the best ways to achieve them. Research has shown that team writing is most effective when all members discuss and agree on the goals of the document before they begin writing. A good place to start the discussion is with the four elements of communication explained in Chapter 18: Audience: Who will be reading your writing? What does your audience already know? What do they need to know? What questions will be on their mind? What decisions will your document help them to make?
155
Purpose: What do you want your audience to do or know after reading the document? What does your audience expect the document to help them understand or do? Content: What do you need to say to accomplish that purpose? What is the best way to organize what you will say? Tone: How do you need to sound to accomplish your purpose? Formal or informal? Assertive or questioning?
2. Assign responsibilities and deadlines. Because progress reports, final reports, and PowerPoint presentations consist of several sections and are time-consuming to write, you will need to divide up the work. In general, teams allocate the responsibility not only for writing the individual sections but for assembling and editing those sections into a coherent, consistent whole Here is an example of a team that used a RAM chart to allocate responsibilities:
Example 16.1: Use a RAM chart to allocate final report responsibilities
Due date Yasmin Fiona Dale Edward Person who completed task (and date completed)
First draft of report Title page Table of contents Executive Summary Introduction Users and Requirements Design Concept References Update Appendix Revisions Limitations Conclusion Design Rationale Assembling/editing the draft Revised final report Title Page Table of Contents Executive Summary Introduction Users and Requirements 5-Mar 5-Mar 5-Mar 5-Mar 5-Mar x x x x x 27-Feb 27-Feb 27-Feb 27-Feb 27-Feb 27-Feb 27-Feb 27-Feb 27-Feb 27-Feb 27-Feb 1-Mar x x x x x x x x x x x x x
156
Due date
Yasmin
Fiona
Dale
Edward
Person who completed task (and date completed)
Design Concept References Update Appendix Revisions Limitations Conclusion Design Rationale Assembling/editing the revision Final version of final report Editing the final version Copying and binding the report
5-Mar 5-Mar 5-Mar 5-Mar 5-Mar 5-Mar 7-Mar x x x x x x x
15-Mar 16-Mar
x x
There are a few important things to note about how this chart was created: The team allocated the responsibilities according to the members' individual strengths. For instance, Yasmin and Dale were the strongest writers, so they assumed responsibility for assembling and editing the three versions of the report. Similarly, Edward, who had taken the lead in building the prototype, was very good at drawing, so he took responsibility for the Design Concept section. The tasks remained consistent throughout the process. That is, team members who worked on certain sections for the first draft were also responsible for revising them. However, in some cases a team might decide to make adjustments to the RAM chart based on team members' actual performance. For instance, if Fiona's work on her first draft sections was not up to par for some reason, then the team might decide to reassign her to some other important aspect of the project, such as helping to build the prototype, working on PowerPoint slides, and/or copying and binding the report. The team would then revise the RAM chart accordingly. Due dates are crucial. In order for Yasmin and Dale to assemble and edit the various sections so that the report could be submitted on time, they needed to have the sections two days before the due date. The final columnperson who completed the taskin part indicates whether the designated team member has actually completed the assigned task.
Another way to record team writing responsibilities is in team meeting minutes:
157
Example 16.2: Use meeting minutes to allocate final report responsibilities Team 4 Meeting Minutes Date: May 21, 2010 Time: 7:30 pm Location: Lisa's Cafe Objective: Discuss goals of the report and divide up work for the first draft of the final report (due May 26.) Scribe: Barb Topics, Key Points, Decisions: 1. Final report should have pictures, good headings and sub-headings, and emphasis on bullet lists to present information. Main audience is client and his organization; our goals in writing the report are to communicate our design clearly and to persuade them to use the design as a basis for seeking funding from governmental organizations. Important: We all need to read the Final Report chapter in the textbook. a. Title Page: Barb b. Table of Contents: Barb c. Executive Summary: Barb d. Introduction: Barb e. Users/requirements: Barb f. Design Concept: Emory g. Design Rationale: Emory h. Design Limitations: Vic i. j. k. Conclusions and Recommendations: Vic References: Vic Appendices i. ii. Project Definition: Vic Client Interview Summary: done
iii. Instructions for Building/Cost, Bill of Materials: Tracy iv. Summary of Alternatives: Tracy (intro and conclusions for matrices) 1. Alternative Matrices v. Background Research: done vi. Heat transfer calculations Appendix: Vic 2. Design Freeze: Tracy a. Bring two hard copies of this to class b. Ask whether to include as an Appendix in the Final Report
158
3. Everything should be emailed to Barb before 10 pm on May 25. She'll edit it for consistency and put it all together in one file for the profs. a. Let her know by May 24 if you're running into a problem.
3. Decide on style guidelines before team members begin drafting the individual sections. This will save a lot of editing time later on when you are putting the report together. Style guidelines include: margins, fonts, line spacing, paragraphing, headings, lists, and vocabulary. Here is an example of a team's style guidelines for a final report:
Example 16.3: Write a set of style guidelines before drafting Margins: one inch on all sides Font style for body text: 11-point Times New Roman Headings: Main headings and appendix titles: 12-point, Arial, bold, underlined, centered Second-level headings: 12-point, Arial, bold, left margin Third-level headings: 12-point, Arial, underlined, left margin
Lists: Indent three spaces. Use solid bullets Paragraphs: Single-space. Ragged edges on right margin. No indentation at start of paragraph. Skip a line between paragraphs. Terminology: Use these terms (not the ones in parenthesis): conveyance (not transfer) storage unit (not tank) disinfect (not purify or sanitize)
4. Give and receive criticism of the draft with respect. People are often very sensitive about their writing. For that reason, be tactful in discussing and offering suggestions for one another's writing. Similarly, when you receive feedback on your writing from your teammates, be open-minded to their suggestions. Your goal is to produce a clear, persuasive report.
159
160
Chapter 17: Project Scheduling
CHAPTER 17: PROJECT SCHEDULING
Chapter outline
Responsibility Allocation Matrix (RAM chart) Gantt chart
Key guidelines for project scheduling

Use RAM charts to allocate responsibilities and deadlines for specific tasks to individual team members Create new RAM charts periodically to plan the coming weeks' work Make a Gantt chart to create a timeline for the main phases of the overall project Update the Gantt chart periodically to reflect work completed and any necessary shifts in the timeline
Whenever you're working on a large project, its crucial to share the workload, coordinate your activities, and establish and stick to a schedule. Successful teams use meeting minutes, the course syllabus, and two other important tools to help them stay on top of things: the Responsibility Allocation Matrix, commonly called a RAM chart, and the Gantt chart. The RAM chart details whos in charge of what and when its due; the Gantt chart is a schedule of tasks using a timeline. You may wonder why you need a RAM and Gantt chart in addition to a syllabus. The answer is, they offer something more: A RAM chart gives you a detailed view of tasks (not all of which are specified on the syllabus) and shows who is responsible for performing the task and by what date. A Gantt chart displays at a glance what work needs to be completed, when it should start and finish, and which tasks need to be worked on simultaneously. A Gantt chart is the overall plan for the project, whereas the RAM is the weekly to do list to help you follow through on that plan. Activities on the Gantt chart generally take a week or two (with the exception of milestones, which are single events). The RAM includes the specific tasks embedded in those activities. If you were to try to include that level of fine detail in a Gantt chart, you would spend more time managing the chart than doing the work. A
161
RAM chart is a quicker, more effective means to plan and manage the details on a week-to-week basis and to help the team stay on target with the Gantt chart schedule.
17.1 RESPONSIBILITY ALLOCATION MATRIX (RAM CHART)

The RAM chart is a good project-planning tool because it shows the primary and secondary tasks of each individual on the team. It is also a good recordkeeping tool because it helps instructors, supervisors, and others know who did (or was supposed to do) what. The most useful RAM charts divide complex tasks and major deliverables into subtasks. For instance, testing a mockup might be divided into getting materials for the mockup, building it, writing the user interview guide, testing the mockup, and writing up the results. Some RAM charts include a column for noting who completed a task or when it was completed. This helps the team keep a record of whether people are actually doing their work and doing it on time. A RAM chart takes the form of a grid, with tasks listed on one axis and team members and due dates on the other. If a square is marked with an X, a 1, or an equivalent mark, this means the person assigned to that task has primary responsibility for seeing it is done. A corresponding mark, such as an O or a 2, shows who else is working on that task. A blank square means the corresponding team member is not involved in that task. A well-written RAM chart divides large tasks among team members, rather than giving all members primary responsibility for all or most tasks. Heres a RAM chart that fails: Because the tasks are not subdivided sufficiently, it allocates responsibility to everyone for almost all tasks. And even if everyone is involved in a task, its best to make one person responsible (i.e., the leader for that job).
162
Example 17.1: RAM Chart with ineffective task division RAM chart (5/19 to 5/28)
Task Due date Sinem Sharifah Jeff Sean Person who completed task
Mockups Write Client Meeting Summary # 2 Design Review Proposal Draft Write Progress Report #3 Write Meeting Agenda for Team Meeting # 3
5/19 5/19
X 0
X X
5/24 5/26 5/28
X X 0
X X X
X X 0
X X 0
5/28
163
The following revised RAM chart succeeds because it sufficiently divides tasks and indicates what each team member needs to do and by what date:
Example 17.2: Revised RAM chart with effective task division
RAM chart (5/12 to 5/28)

Task Due date Sinem Sharifah Jeff Sean Person who completed task
Prepare alternatives matrix Schedule appointment with shop professional Prepare mockup planning sheets Order materials for mockups Build mockups Write client meeting summary # 2 Do lab testing of mockups Analyze test results Synthesize information for design review Make design review slides Make design review questionnaires Write first proposal draft Write progress report # 3 Write meeting agenda for team meeting # 3
5/12 5/12 5/14 5/15 5/19 5/19 5/20 5/22 5/22 5/23 5/23 5/26 5/26 5/28
0 X
0 0 X
X 0
0 X X 0
0 X 0
X 0 X
0 X 0 0 X
Key: X=primary responsibility
0=secondary responsibility
Creating the RAM chart should be a team activity so that it draws on everyones knowledge and makes members feel invested in performing the tasks. After your team has figured out the necessary tasks, has assigned them based on members skills and interests, and has chosen realistic due dates, have one member type up the chart, post it to the teams online workspace, and place it in the project notebook. You should prepare a new RAM chart every one to two weeks, closely detailing who will do what in the coming weeks. In addition, your instructors may ask you to write a less detailed RAM chart at the beginning of the project in order to familiarize yourselves with the project deliverables, distribute the workload equitably, and begin surveying the skills and interests of team members in order to allocate tasks effectively. In DTC, you are required to submit a
164
RAM chart with your written deliverables, and to include all charts in your project folder as a way of documenting teamwork.
17.2 GANTT CHART

Named for its inventor, management theorist Henry Gantt, the Gantt chart is the most widely used method of scheduling group work by due dates. Using both a table and bar graph format, the Gantt chart lists key project tasks on the vertical axis, and time frames (by weeks or months) on the horizontal axis. A bar across the columns indicates the time span for each task. These bars also indicate which tasks overlap, are interdependent, or take place simultaneously. Gantt charts are used for internal team planning, as in a progress report to a supervisor or client, and for external reporting, as in a project proposal. Like all project documentation, a Gantt chart undergoes modification as you complete portions of your project and better understand it. Thats why you need to keep updating the chart throughout the project. NOTE: Do not include individual assignments in the Gantt chart, such as essay and graphics assignments. Nor should you include small project-related tasks, such as emailing the client or interviewing experts; those belong in the RAM chart. In general, keep in mind that the Gantt chart represents the big picture view of the project. Here is an explanation of a generic Gantt chart, produced with Microsoft Excel: At the top are the project title, section number, team name (or number), and last update of the chart. Along the left column are the main and subtasks. (In your chart you will give the tasks specific names. For example, you might name the first major task Preliminary research and the subtasks Interview client, Analyze Competitive/model products, and Observe users.) Be sure to use action verbs to identify tasks, and include only those tasks related to the teams design process, not individual assignments (such as the individual essay). Darkly shaded bars indicate completed tasks; unshaded or lightly shaded bars indicate uncompleted tasks. Notice that the bars show which tasks can proceed simultaneously and which need to be completed before another task can begin. The stars indicate project milestones. These are events that need to happen at particular times in order to meet project goals. In DTC, its useful to consider two types of milestones. The first includes deadlines imposed by the course syllabus, such as the due dates for assigned written reports and oral presentations. The second type includes milestones that your team has set in order to stay on target,
165
such as the date when user testing must be completed in order to allow you enough time to choose a final design direction and construct a high-quality prototype.
166
Example 17.3: Generic Gantt chart
Project ABC Team 2 Updated 1/31/06 WEEKS

1 2 3 4 5 6 7 8 9 10 11
Tasks
Task A Subtask A1 Subtask A2 Subtask A3 Subtask A4 Task B Subtask B1 Subtask B2 Subtask B3 Task C Subtask C1 Subtask C2 Subtask C3 Subtask C4 Task D Subtask D1 Subtask D2 Subtask D3 Subtask D4 Task E Subtask E1 Subtask E2 Subtask E3 Task F Subtask F1 Subtask F2 Subtask F3
167
Below is an example of a Gantt chart for a winter quarter DTC project:

Example 17.4: DTC winter quarter Gantt chart
One-handed crocheting project - Gantt Chart Team 2 Section 12 Updated 2/16/05 2 Tasks Preliminary Research Research disability Research existing products Interview crochet experts Interview client Observe users Concept Generation Brainstorm/Cluster Ideas Generate alternatives Build Mockups Concept Testing Performance testing User testing Design Review Prepare review Analyze results Adjust project plans/tasks FINAL DELIVERABLES Prototype Build/Test New Mockups Build Prototype Poster Brainstorm Poster Designs Create Poster Write Oral Presentation Final Report Write Final Report KEY completed tasks uncompleted tasks progress report 3 4 5 Weeks 6 7 8 9 10
17.2.1 Team guidelines for creating Gantt charts

1. Brainstorm all the tasks that need to be done for your project. 2. Group these tasks into categories, differentiating between main and subtasks. 3. List the tasks along your vertical axis. Begin at the top, listing tasks that must be done first. Use a hierarchical column to distinguish between main and subtasks. Omit the least important subtasks if your list gets too long. End the list with your final deliverables.
168
4. Divide your horizontal axis into columns, labeling each by week. 5. Use a horizontal bar to show the estimated beginning and end of each task. 6. Review your Gantt chart weekly to check your progress; revise the chart as you add tasks to your project plan. 7. Include updated Gantt charts in your progress reports and project notebook. 8. There are many YouTube videos that provide instructions on making a Gantt chart. Heres one easy method using Microsoft Excel (Dufee & Chase, 2003): Under Page Setup in the File menu, do the following: Go to Page and select Landscape orientation. Also select Fit to one page. Go to Margins and select Center on page horizontally and vertically. Go to Sheet and make sure that Gridlines is unselected. Use the Border commands to make the bars. Use the Fill command on the Drawing toolbar to fill bars as you complete tasks. Use the Autoshapes command on the Drawing toolbar to make stars indicating project milestones.
Under View, go to Toolbars and click Border and Drawing.
17.3 REFERENCES
Anderson, P. V. (1998). Technical communication: a reader-centered approach. 4th ed. San Diego, CA: Harcourt Brace. Dufee, W. & Chase, T. (2003). Brief tutorial on Gantt charts. Retrieved July 27, 2003, from http://www.me.umn.edu/courses/me4054/assignments/ gantt.html Markel, M. (1998). Technical communication: situations and strategies. 5th ed. New York, St. Martins Press. Woolever, K.R. (1998). Writing for the technical professions. New York: Longman.
169
170
PART FOUR
COMMUNICATION
CHAPTERS 18 WRITTEN AND ORAL COMMUNICATION IN DESIGN 19 CLIENT COMMUNICATION 20 EMAIL AND OTHER E-COMMUNICATION 21 VISUAL COMMUNICATION 22 INSTRUCTIONS 23 PROGRESS REPORTS 24 FINAL REPORTS 25 REVISING FOR CLARITY, CONCISENESS AND CORRECTNESS 26 DOCUMENTING SOURCESAND AVOIDING PLAGIARISM 27 ORAL DESIGN PRESENTATIONS 28 POSTER PRESENTATIONS 29 WRITING ESSAYS ABOUT DESIGN
171
172
Chapter 18: Written and Oral Communication in Design
CHAPTER 18: WRITTEN AND ORAL COMMUNICATION IN DESIGN
Chapter outline
Similarities between design process and writing process Designing your communication deliverables Writing to explain decisions and conclusions Comparing major written and oral deliverables
Key guidelines for written and oral communication in design

To communicate effectively in written documents and oral presentations, keep in mind: the audience you are communicating to your purpose in the communication the content you need to communicate the appropriate tone for the communication
In a 2005 survey, business leaders and engineering professionals ranked communication competence as the second most important attribute for a new engineer (Davis, Beyerlein & Davis). The survey identified as a key element of communication competence the ability to organize and convey thoughts clearly and concisely, both in speaking and writing, with necessary supporting materials to achieve desired understanding and impact. As Atila Ertas and Jesse C. Jones explain The Engineering Design Process (1996), [E]ngineers market their skill through the ability to communicate (p. 470). Without that skill, engineers are shut out of decision-making and, worse, career advancement: Important communications are transmitted in writing so that the meaning can be precisely stated and a record can be established for future reference. Employees that are incapable of preparing clear and understandable written communications tend to be relegated to passive roles in this process.
173
They become information receivers and not information generators and thus gradually find themselves out of the mainstream, out of touch with what is going on, and out of mind when raises and promotions are given (p. 470). Engineers need to be proficient in the following types of communication: Written: reports, proposals, memos, emails, instructions, meeting minutes Oral: meetings, design reviews, final presentations Visual: sketches, drawings, tables, graphs, charts, posters, slides Mathematical: equations, statistical analyses Interpersonal: team meetings, client meetings, user and expert interviews
Engineers often use several kinds of communication at a time: They support oral presentations with written slides, which may contain drawings, tables, and other visual elements. They write reports using mathematical elements such as statistical analysis of test data, which may be illustrated by visual elements such as tables and graphs. They use written agendas to organize team meetings, where they focus on sketches of design ideas. In communicating, engineers use a variety of media: paper, email, electronic files, fax, telephone, video, projectors, etc. Each medium imposes specific requirements on engineers as they shape what they want to communicate. This chapter provides an overview of how to think about communication not only in DTC but in your career as an engineer.
18.1 SIMILARITIES BETWEEN DESIGN PROCESS AND WRITING PROCESS

This textbook contains several chapters on written communication because it is the most commonly used form of communicating among engineers. Writing provides a formal record of your work, allows you to communicate with multiple readers, serves as a reference for those who will continue your work, and permits people to review your ideas at their convenience. Engineers write a lot of short, quick messages to arrange meetings, ask or answer questions, request support from a supervisor, and so on. To be effective, these communiqus need to be clear, complete, well-edited, and respectful. As an engineer, you also will write more complex documents, such as research reports, progress reports, and proposals. Developing these longer
174
pieces mirrors the design process because, in most cases, youre designing a document (Table 18.1):
Table 18.1: Comparing the design and communication process
Designers: Gather information Define the problem Generate alternatives Writers: Gather information Define the audience, purpose, and main point of the document. Explore different ways to organize material and develop a persuasive argument Write rough drafts Get feedback from readers Revise and rewrite
Make mockups Gather user feedback Improve the design and iterate the process (make more mockups, get more feedback)
As you can see, both writing and design are iterative and recursive. For example, after writing a rough draft you may need to gather more information in order to write a clear, persuasive revision, which your peers and supervisors will review before it is delivered in its final form. Writing is particularly important in DTC. Not only does DTC serve to fulfill the McCormick writing requirement; it is also the place where you are introduced to all the functions of writing within the design process. In DTC, you will do a range of writing (Table 18.2):
Table 18.2: Types of writing in DTC Reports Project documentation Presentations Correspondence Essays Progress reports Final project reports Project definition Meeting minutes PowerPoint presentations Posters Emails Analytical Persuasive
You may wonder at some point if all this writing is necessary. In short, it is: The writing you do in DTC is part of good design practice, as evidenced in the table above. Designers routinely document their meetings and designs, write reports, prepare persuasive documents, and send correspondence. DTC essays, although not part of design practice, give you an opportunity to analyze and critique designs that you see and use each dayand thus to reflect on design while you get help and instruction in individual writing.
175
18.2 DESIGNING YOUR COMMUNICATION DELIVERABLES

The sole purpose of business and technical writing is to communicate to get work done. The best way to do this efficiently and effectively is not to think about rules but to think about writing as a problem to solve. To solve any communication problem, you need to keep in mind these four elements: Audience: Who will be reading your writing? What does your audience already know? What do they need to know? What questions will be on their mind? What decisions will your document help them to make? Purpose: What do you want your audience to do or know after reading the document? What does your audience expect the document to help them understand or do? Content: What do you need to say to accomplish that purpose? What is the best way to organize what you will say? Tone: How do you need to sound to accomplish your purpose? Formal or informal? Assertive or questioning? Beginning writers of engineering documents tend to think only about content. They also think theres a template for every writing situation. But experienced writers think about strategy, consciously or unconsciously using a tool like the communication square below to help them plan everything they write (see Figure 18.1).
Figure 18.1: The communication square
In addition, experienced writers think about the genre (type of document) and the communication technology (phone, fax, email, written document, etc.) they will need. Below is a more detailed explanation of the key elements in the communication square.
176
18.2.1 Audience
Researchers have found that the audiences with whom engineers engage are many and complex. Engineers speak to other engineers, to clients, to government agencies and to support staff. Some of those audiences have technical background and others do not (Darling & Dannels, 2003, p. 13). The researchers conclude that because audiences for communication are so diverse, engineers probably need a dozen different ways to state and clarify any individual idea or piece of technical communication. Typically, in DTC you will write documents for the following diverse audiences: Client: emails, interview guides, reports, PowerPoint slides, poster Users: interview guides, observation guides, instructions, emails Instructors: progress reports, final report, emails, design essays Teammates: meeting minutes, emails Classmates: PowerPoint slides, design review questionnaires Experts: emails, interview guides Interested members of the community: posters Future DTC teams: final reports
Sometimes you will need to tailor a document to reach multiple audiences at the same time. For instance, your poster should communicate effectively to your client, who knows a great deal about your project, as well as to a visitor who has never heard about it before. Similarly, although the main audience for your final report is your client and instructors, it also may be read by those less familiar with project details: other people in the clients organization, an outside contractor who will build your design, and future DTC teams working on a continuation of the project.
18.2.2 Purpose
Just as important as defining your audience is focusing on what youre trying to accomplish when you communicate. In DTC you will use your writing to: Inform: Telling readers what you have learned, done, or decided is the major purpose of progress reports to your instructors, email updates to clients, and meeting minutes to teammates. Persuade: The project report written at the end of DTC is intended to persuade your client and instructors that you have followed the design process thoughtfully and that your design solves the problem. You will also write emails to clients to persuade them that you thoroughly understand the problem at hand.
177
Instruct: In user testing guides, you need to explain to users how to perform the tasks associated with your mockups. In your final report you will include an appendix with instructions on constructing your prototype. Request: You may write an email to an expert or potential user to request an interview or more information.
Sometimes documents have multiple purposes. A progress report, for example, might be written primarily to inform your instructors of the research that led to your design concept, but it also may be used to persuade them of your wisdom in choosing that concept. Likewise, your final report is intended not only to persuade clients to accept your design but to inform them of your research. Also, keep in mind what your readers expect from a particular document. For example, your instructors want your progress report to tell them the main things youve learned and decided regarding your project. Therefore, you need to select the data that best illustrate and support these expectations and organize the data so your instructors can easily find the important results. One final point: State the purpose of your document in the first paragraph, or by the end of your introduction, so readers know immediately what to expect from it.
18.2.3 Content
Determining your purpose and audience will help you decide what content to include in your document. For example, if you are writing to ask your instructors to extend your deadline on a progress report, you know your purpose and audience, so you can imagine what your instructors will want to know. They will be convinced to grant your request only if they understand the reason for the extensionsuccinctly statedand the date on which you will submit the report. You can also briefly reassure them that you are otherwise on top of the project. As you plan your content, its also important to ask yourself organizational questions such as: How do I want to structure the document? Do my main headings accurately reflect the categories Ive chosen? How should I start and finish? Which points do I want to emphasize and what details do I need to support them?
18.2.4 Tone
The tone of your document tells readers something important about you and thus can enhance or undercut your purpose. Readers will have a very different reaction to your communication depending on whether they see you as respectful or arrogant, serious or frivolous. The email below, from a student team to a client, illustrates a serious problem with tone:
178
Example 18.1: Ineffective tone in an email hey, sue, we cant make it to the meeting at 2, so well be there at 3 insted. we need the list of user fone numbers from you at that time. see you at 3. Jason.
Jason didnt intend to antagonize his client, although that would be the likely result of this inappropriate email. By using incorrect punctuation and grammar, and making assumptions about his clients willingness to reschedule, he comes across as flippant and demanding. Heres a more appropriate version:
Example 18.2: Effective tone in an email Dear Ms. McRea, I am writing on behalf of DTC Section 14, Team 2 (the adaptive crochet hook) to find out if we could change our 2:00 meeting time on January 31 to 3:00 because we just learned of a required chemistry review session we must attend. If you are unable to meet at 3 p.m., would you be able to discuss the user testing plan over the phone earlier in the day? If that isn't possible, one of our team members would be glad to come to your office later this week. In that case, please send a list of available days and times. I apologize for having to reschedule our meeting. I look forward to hearing from you about arranging an alternative meeting time.
Yours, Jason Firth
Jasons tone is polite, considerate, and positive, and it demonstrates concern for the clients needs. This is the correct level of formality to use in an email to clients or users even if they have invited you to call them by their first name. You can never go wrong by being polite and respectful. Another common problem with tone occurs with the use of we, which can give your document a self-congratulatory tone, as in this introduction to a final report.
Example 18.3: Ineffective tone in a report (overuse of we) We have designed a device that enables stroke survivors with the use of only one hand to crochet. We found that people who had enjoyed crocheting before their stroke wanted to
179
be able to continue their hobby. So we did extensive research to understand the problem and arrive at our solution. We interviewed experts and brainstormed many ideas. We narrowed these down to a few alternatives, which we then mocked up. We took these mockups to users and learned a great deal from our user testing. This enabled us to design and build our final prototype, which we are very proud of.
Since these writers are overusing the personal pronoun we, their client is likely to get the idea that the team is more interested in themselves than in her need for a successful design. Heres a revision that emphasizes the design instead of the team:
Example 18.4: Effective tone in a report Strokes often can cause people to lose the use of one hand, making them unable to enjoy activities and hobbies that had been important to them. Our client, Susan McRea of the Rehabilitation Institute of Chicago, found that patients who had enjoyed crocheting before their stroke wanted to be able to continue their hobby. This report describes our teams solution to this problem. The design is based on extensive research, including interviews with experts, various design alternatives, and user testing of mockups. This research led us to a final prototype that enables users to crochet easily and comfortably
The lesson here is to make sure you use the appropriate tone to support your purpose.
18.3 WRITING TO EXPLAIN DECISIONS AND CONCLUSIONS

Many students mistakenly view the writing done by engineers as merely the recording and delivery of information. They believe that the information speaks for itself. However, as Dorothy Winsor (1996), a researcher on technical communication, explains, As study after study has shown,data seldom or never speak for themselves[D]ata are almost always used rhetorically. They are one of the means by which engineers convince one another that their vision of reality is the correct one (p. 32). In writing your reports, you must present information clearly and convincingly in order to explain conclusions and decisions that you have reached concerning your design. In the following examplea progress report written by a team designing a wheelchair rampthe team is reporting to their instructors on their preliminary research on materials (Conroy, Linsenmeier, Taam & Willson). They have reached a preliminary decision to use aluminum. In the rough draft, they simply list the data, expecting that their instructors will understand how they reached that decision:
180
Example 18.5: Unclear presentation of data to support a decision We considered the following materials for the ramp and have tentatively decided to use aluminum. Wood Cost: 12'=$800 Douglas fir, southern pine, and redwood are commonly used Must be weather-resistant, decay-resistant, stiff, strong, and shrinkresistant Pressure-treated wood has preservative chemicals that prevent decay Must be constructed using nails, screws, bolts, and metal framing connectors Dangers: Joints and connections can rot or degrade due to normal wear and tear. Concrete Strong, water- and fire-resistant Cost: 12'=$2,000 Can be cast into any shape Permanent solution Load capacity = 2,000 lbs. Galvanized steel Cost: 12' = $1,200 Designed for permanent and semi-permanent ramps Load capacity = 1,500 lbs. Exceeds ADA specifications for non-skid surfaces Aluminum Load capacity = 800 lbs, well within ADA guidelines. Alternative to galvanized steel Lightweight, which allows for simple pin connections Cost: 12' = $1,000
Confronted with all this information, the teams instructors found it difficult to figure out why the team had decided on aluminum. Since facts do not speak for themselves, writers need to help readers draw the correct conclusions from the facts. If the writers do this kind of workexplaining the factsthen their writing will be easier to read and also more persuasive. The team revised their presentation by clearly stating the decision, the rationale, and the supporting facts. Some facts are not relevant to their decision, for instance the types of wood that are used for ramps. So the team has focused on the relevant facts and has organized them clearly so the instructors can understand how they relate to the project requirements. The team also moved the complete list of materials and specifications to an appendix.
181
Example 18.6: Clear presentation of data to support a decision The most common materials for ramps are wood, concrete, galvanized steel, and aluminum (see Appendix D). Based on the three major client requirements, we have made a preliminary decision to use aluminum: Portability: The clients most important requirement is that the ramp be portable so that it can be easily removed and stored during the extended periods when it is not needed. Aluminum is the lightest of the four materials and can be fitted with simple pin connections that allow for easy assembly and disassembly. Cost: While wood is cheaper than aluminum ($800 vs. $1,000 per 12'), the total cost for aluminum is well within the client's budget of $5,000 for a 30' ramp. Also, in a wood ramp, the joints and connections can rot or degrade due to normal wear and tear; thus, maintenance costs would increase the overall cost of a wood ramp. Safety: Concrete and galvanized steel have a much higher load capacity than aluminum (2,000 lbs, 1,500 lbs, and 800 lbs., respectively). However, the load capacity of aluminum is well within ADA guidelines. Galvanized steel exceeds ADA specifications for non-skid surfaces, so we will need to research whether a suitable non-skid surface can be added to an aluminum ramp without exceeding the clients budget.
Note that in explaining the decision, the team does not misrepresent or ignore contrary data. For instance, they acknowledge that galvanized steel has an advantage in safety. So in using data to support decisions and conclusions, you have an ethical and professional obligation to present all the relevant information and its relationship to your main point. Another team's project was to design a low-cost solar water heater for use in the Dominican Republic (Millea, Nieman, Suszko & Wroblewski). They performed testing with their final prototype to confirm that it heated water within the required specifications. However, in reporting on those tests in a progress report to instructors, they did not explain how the data supported the conclusion that their design is successful:
182
Example 18.7: Unclear presentation of data to support a conclusion We conducted two tests with our prototype to confirm the effectiveness of our design: Test 1 description: Weather condition: sunny, no clouds Rubber hose: 875 ml Start Time: 9:40 a.m. Start H2O Temp.: 61F Start Ground Temp.: 27C Start Air Temp.: 63F End Time: 11:30 p.m. Total Test Time: 1 hr., 50 min. End Ground Temp.: 29C End Air Temp.: 69F End H2O Temp.: 132F
T: 68F
Test 2 description Weather condition: sunny, no clouds Rubber hose: 875 ml Start Time: 12:30 p.m. Start H2O Temp.: 62C Start Ground Temp.: 26C Start Air Temp.: 64F End Time: 2:30 p.m. Total Test Time: 2 hrs. End Ground Temp.: 32C End Air Temp.: 71F End H2O Temp.: 134F
T: 72F
As in the case of the wheelchair ramp report, the instructors had great difficulty interpreting the data and picking out the key points. In the revised report, the team not only presented the data but also explained how the data confirmed their designs effectiveness. Below is the explanation that they added to the two test descriptions:
183
Example 18.8: Clear presentation of data to support a conclusion We conducted two tests with our prototype to confirm the effectiveness of our design. As the data below indicate, the prototype operated within required specifications, which were to be able to heat water to a temperature of at least 120F within two hours at an air temperature of around 60F. We tested the prototype both in the morning and early afternoon for two hours to determine whether the angle of the sun affected the results; the air temperatures were 63F and 64F, respectively. In both cases, the water temperature increased approximately 70F to just over 130F.
In much of the writing you will do in DTC and, later, as an engineer, you will need to present research results to readers so that they can make use of it, whether to track your progress, offer advice, or make a decision. Not only will they be better served if you explain the data clearly but you will, too, because you will be seen as a good communicator.
18.4 CONCLUSION
Although this chapter has focused on writing, you can apply what youve learned here to other forms of communication. For example, you can use the communication square to plan an important meeting with your client.
Example 18.9: Using the communication square to plan a client meeting
Audience: Client Purpose: Present the results of user testing to the client and explain our final design concept. As a result of the meeting, the client will help us to refine our concept and approve our planned design direction. Content: Summary of mockups and methods employed in user tests; table of key results; drawing of final design concept Tone: Informal but businesslike
Similarly, for a final presentation to be effective, you will need to make the same kind of rhetorical decisions that you make in a final reporthow to provide evidence for your assertions, explain your design decisions, interpret your data, etc. You may wish that there were a simple recipe for writing any document or delivering any presentation. However, just as there are no rules for determining the right answer to a design problem, there are no absolute rules for what to say and how to say it in engineering communication. Communication is socially constructed; that is, effective communication varies depending on your profession, your company, and even your communication technology. Thats why, as in design, there is a process you can follow to compose those documents and presentations effectively, one grounded in the communica-
184
tion square. This process requires you to take the same problem-solving approach to communication as you take to design. Engineering communication, however, does include certain genresprogress reports, formal proposals, etc.that do have typical characteristics and follow specific conventions. These characteristics and conventions provide a valuable framework, but they do not replace the thought you must put into developing a strategy for each communication. Your emails, reports, slides, posters, and so on will only be as effective as the informed consideration you give to audience, purpose, content, and tone.
18.5 REFERENCES
Conroy, J., Linsenmeier J., Taam, A. & Willson, B. (2003). Progress report #1. Engineering Design and Communication, Northwestern University. Darling, A. & Dannels, D. (2003). Practicing engineers talk about the importance of talk: A report on the role of oral communication in the workplace. Communication Education, 52(1), 1-16. Davis, D., Beyerlein, S. & Davis, I. (2005) Development and user of an engineering profile. American Society for Engineering Education Annual Conference & Exposition. Retrieved on July 26, 2012 from < http:// www.eerc.wsu.edu/documents/DevelopmentandUseofanEngineerProfile.pdf>. Ertas, A. & Jones, J. (1996). The engineering design process, 2nd ed. New York: John Wiley and Sons. Millea, J., Nieman, E., Suszko, D. & Wroblewski, N. (2003). Everything under the sun: a simple approach to solar water heating. Engineering Design and Communication, Northwestern University. Winsor, D. (1996). Writing like an engineer: a rhetorical education. Mahwah, NJ: Lawrence Erlbaum Associates.
185
186
Chapter 19: Client Communication
CHAPTER 19: CLIENT COMMUNICATION
Chapter outline
When to communicate with clients What modes of communication to use How much to communicate How to benefit from client communication
Key guidelines for client communication

Telephone your client when you need a quick reply, and send a follow-up email to confirm any appointments or decisions made Email your client when you don't need an immediate reply or when you want to present information that would be hard to convey by phone Schedule face-to-face meetings when you have a large amount of information to convey or need substantial feedback Follow up the meeting with an email summarizing the main points and decisions
Understanding your client for DTC will help you get your project off to a good start, avoid misunderstandings later on, and communicate effectively with him or her throughout. It is important to know that clients voluntarily submit project proposals and come from a variety of backgrounds and perspectives. While many clients are professionals in their own right, they bring with them diverse experiences, motives, and expectations. Some clients are readily available to their teams, while othersbecause they are out of town or have many demands on their timemay be less available. One client may have a fairly well developed design already in mind, whereas another may simply identify a problem without the technical knowledge to provide expert advice. While most projects are presented by individuals, in some cases a client represents an organization or business; therefore, several colleagues have a stake in project progress. One implication of all this variety is that the kind of client you have in your second quarter of DTC may be quite different from the one you had first quarter. Another implication is that you need to understand your client in order to establish a good working relationship with him or her.
187
Because clients come from such different perspectives, one tool used to establish shared understanding at the initial meeting is the Client and Student Understandings form (downloadable from DTC Documents on the Blackboard website). Taking a few minutes to review this document with your client will help all involved to understand each other's roles through the duration of the project. The most obvious reasons to maintain good communication with clients are to obtain information from them, such as user contacts and background material, to keep them apprised of your progress, and to solicit their feedback. On the one hand, if you fail to keep your client posted on your activities, he or she may lose confidence in your abilities, and not devote the time to giving you help when you most need it. On the other hand, if you keep the lines of communication open, your client is likely to feel encouraged and enthusiastic about helping you. And at the end of the project, your client is likely to appreciate the research and thought that went into the final design and to be convinced of its success.
19.1 WHEN TO COMMUNICATE WITH CLIENTS

In the first quarter of DTC, your engineering instructor serves as the intermediary between you and the client. In the second quarter, however, your team is responsible for client communication. How often should you contact your client? More often than you think. Students sometimes mistakenly believe that after conducting their initial interview, they dont need to contact the client until they have decided on their final design. This leaves clients wondering how, or even if, the project is progressing. To prevent this problem, ask your client at your initial interview how often he or she wants to hear from you. Some clients like to receive weekly email updates. Others prefer that you email them at key points in the project, such as when youve developed alternatives, completed user testing, and conducted your design review. Regular written communication with your client between face-to-face meetings (client interview, user testing, and final presentation) should prove effective.
19.2 WHAT MODES OF COMMUNICATION TO USE

Just as you need to be strategic about planning your final deliverables, you also need to be thoughtful and strategic about how to contact your client.
188
Your communication mode (or technology) will vary depending on your purpose.
19.2.1 Telephone
Call your client when you need a quick reply or want to set up a meeting. If a client cant meet with you face-to-face for the initial or subsequent interview, you may have to conduct it by phone. As with all communications, plan your call. For example, if youre trying to set up a client meeting, team members should decide the purpose of the meeting and figure out when everyone can meet before you place the call. If you have to leave a message, give your name, section number, team number, and project; purpose of the call; phone number(s); and best times to reach you. If you dont hear back by the next day, call again or send an email. Your client may have forgotten to follow up or not gotten the message. Instructors dont want to hear that you called once but never heard back. After your phone conversation, send your client a brief email summarizing the main points you discussed (copy your instructors and teammates using the cc line of the email header). The email summary: Ensures that you and the client agree about what was discussed Keeps your teammates and instructors informed Documents what was discussed should questions later arise. For that reason, you should save all emails to and from your client in your project notebook.
Here is an example of an email sent to a client after a phone conversation (Sze, 2005). The subject line was Confirmation of s15 Team 4 User Observation, and the message was copied to instructors and teammates.
Example 19.1: Email summary of phone conversation Dear Mr. Duncan, This email is to confirm the meeting we set up by phone today, which established that Team 4, which is working on games storage, will be at Evanston Township High School at 3 p.m., Monday, May 2, to do user observations. As a reminder, these are some of the tasks we will be working on: taking an inventory of the existing games measuring doorways and size of storage spaces measuring the various game pieces obtaining a list of the students and their disabilities so we can tailor the Storage Cart to their needs
189
We look forward to seeing you then. Nicholas Sze Section 15, Team 4 Games Storage Cart Project
19.2.2 Email
Use email when you don't need an immediate response, when you have had difficulty reaching the client by phone, or when you want to present information that would be hard to convey by phone. Note: Keep emails short so that they can be read with little or no scrolling. If you have a significant amount of information to convey, write it up as an attachment to a short email that briefly summarizes its purpose. Assign one team member to email your client throughout the project so that your client does not get confused by messages coming from different people on the team. When sending email it is customary to allow a few business days for a response; however, your client should establish a mutually agreed upon response time from the outset. Chapter 20 explains how to write effective emails. In addition, you should review Chapter 18 for advice on planning your communications. Here are the key components of an email to your client: Subject line: Subject lines often determine whether someone will open your email. A good subject line should indicate precisely the purpose of your email, and identify your project, section, and team number. Rather than write Meeting, write Meeting requestcrochet hook project. If you find yourself writing several emails in a row to your client, don't keep using the original subject line. If youre confirming a change in meeting time or place, for example, change your original heading, which may have been Meeting request to something like Confirming new meeting time: Tuesday at 2 p.m. cc line: Copy your instructors and fellow team members to keep them in the loop. Salutation: Begin your email with a polite salutation, such as Dear Ms. Cohen or Dear Jonathan. Don't use an overly informal opening, as in Hey, Jon. Introduction: Because your client may be working with several teams in more than one section, the first sentence of the introduction should state your section and team number, and the purpose of your email. For instance, an email written after an initial client interview might begin: I am writing as a representative of DTC Team 2, Section 14, which is working on the adaptive crochet hook. We would like to thank you for speaking with us on January 18. This email summarizes our understanding of the major user groups and requirements of the project. If you would like to clarify anything or add information, please email me.
190
Conclusion: At or near the end, state your next step and what you would like your client to do. A conclusion might be worded like this: Please call or email me (my contact information appears at the end of this message) if this summary of users and requirements is in any way incorrect or incomplete. Your concluding paragraph should be upbeat: We are excited about working on this project because it gives us an opportunity to improve the daily lives of stroke patients.
19.2.3 Meetings
Schedule a meeting when you need substantial feedback from your client. If the meeting is your initial client interview, write an interview script, as discussed in Chapter 2. If you are meeting later in the quarter, prepare a detailed agenda that follows the format and guidelines discussed in Chapter 13. Also prepare visual aidsdrawings, mockups, graphs, and chartsto bring with you. If you are conducting the meeting as a videoconference, fax or email these visual aids to your client beforehand. Another good way to prepare for a client meeting is to anticipate questions your client will have (particularly about the reasoning behind your research methodology and design decisions) and answer these questions in your presentation, or be prepared to answer them if your client asks. Your project folder is an invaluable source of information. Always bring your laptop to client meetings so that you can access the project folder if necessary. Occasionally, because clients live far away, you will need to conduct meetings by Skype, teleconference or videoconference, depending on the technology available to your client. You may use the equipment in Segals conference room. Just speak with your instructors to find out about reserving the room and learning to use the technology. In addition, Northwestern offers students access to software that allows you to conduct videoconferences from your personal computer. To find out about that, go to: <http://www.it.northwestern.edu/desktop-videoconference/about.html>. As with telephone conversations, send your client a brief email after the meeting, summarizing the main points. Copy your teammates and instructors.
19.3 HOW MUCH TO COMMUNICATE

How much you communicate to your client depends in great part on which mode of communication you use and where you are in the design process. Phone calls convey the least amount of information. Emails, which should be kept to a screen or two, allow for slightly more information. Meetings allow you to communicate orally and visually, but be sure you stick to the most important information: your conclusions and decisions, and the key research data and design tools that support those. For example, if you are presenting
191
your design direction after conducting user testing, you would show sketches or mockups of what you tested, a chart summarizing the major results, a decision matrix that enabled you to apply these results, and a sketch of your latest design concept. Further details, such as results from the brainstorming you did before deciding on alternatives, and the way you decided on those alternatives, are probably not of interest to the client. Where you are in the design process also affects what you will want to share with your client. For example, it is not a good idea to show your mockups to the client before you have done some user or performance testing. Your client may not understand that you are using the mockups simply to elicit information about your ideas; he or she may think the mockups are early versions of your final design and therefore may discourage you from pursuing a promising line of investigation. Finally, always bring your project notebook to the meeting to help you answer client questions.
19.4 HOW TO BENEFIT FROM CLIENT COMMUNICATION

When its the clients turn to communicate, take notes during phone calls and meetings, follow through on suggestions, and report back with the results. If you think the clients suggestion is counterproductive, diplomatically explain why you would like to take a different direction. Ask your instructors for guidance if you need to. Sometimes you may have to respond to criticism from your client. One client sent an email chastising a team for failing to tell her they were coming to her workplace to do user observations when she wasnt there. The team had forgotten that all observations must be coordinated with the client and had instead sought permission from someone else at the workplace to do the observations. The team could have sent an angry, defensive email or ignored the client. They wisely decided to send an email apologizing for the miscommunication and promising to make all future arrangements for user interaction through her. They also said they wanted to do the best job possible on the project and asked the client if she would like them to send a weekly update. She responded positively, and for the rest of the project was encouraging and helpful to the team. If you receive a problematic or angry email from a client, resist the temptation to write an angry email in response. Instead, consult with your instructor about the best way to proceed. Maintaining good communication is essential if you are to develop a design that your client finds successful. Moreover, you will discover that the good communication practices you use with your clients in DTC will serve you
192
well in internships and jobs later on. Your employers and supervisors will be looking for those same communication practices from you on the job.
193
194
Chapter 20: Email and Other E-communication
CHAPTER 20: EMAIL AND OTHER E-COMMUNICATION
Chapter outline
Guidelines for email Guidelines for sending attachments Guidelines for sending faxes
Key guidelines for email and other ecommunication

Use your Northwestern account to send email Write a subject line that clearly indicates the purpose of the message Keep individual paragraphs and the overall email as short as possible In the first paragraph, indicate the message's context, purpose, and main point Provide enough details in the body to convey the main point clearly Conclude by stating what you want the reader to do with the information you have provided Use a polite and respectful tone Check and re-check for typos and other errors before you hit send Copy your teammates and instructors Use clear filenames and common file formats for attachments
In DTC, you will be communicating frequently with team members, instructors, clients, and other interested parties. As in the business world, most of this correspondence will be through email. As you probably know, people in business and other professions receive a large number of emails each day. A 2006 study at a technology company found that the average employee received 87 emails a day (Fisher, Brush, Gleave & Smith, 2006). Thus, it is crucial that you craft each email so that the reader pays attention to it, can understand it easily, and acts on it in the way you want. This chapter offers advice for achieving those objectives.
195
20.1 GUIDELINES FOR EMAIL

20.1.1 When to use email
Use email when you dont need an immediate response, when you want to give a person time to consider the message, when you have had difficulty reaching the person by phone, or when you want to present information that would be hard to convey in a phone call (such as test data or an attached graphic).
20.1.2 How to make sure your email gets read

Because of the large number of emails received every day, people often make quick decisions about which theyll open and which they wont. To make sure your DTC email gets read: 1. Send the email from your Northwestern email account, not your personal account, so it looks legitimate. 2. Use a subject line that indicates the messages purpose, such as Meeting requestadaptive knife project. The more vague the subject line, the more likely the reader will pass on to the next email. If you are emailing your client or instructors, include the name of your project, and section and team number. Avoid subject lines like URGENT and IMPORTANT, since these are often used by spammers. 3. Keep your message short, one screen if possible. The longer the message, the more likely the reader will think, This is going to take too long. Ill get back to it later (which often means never). One way to control the length of your email is to make sure it has only one purpose. Thus, dont send an email that is intended both to provide a project update and set up a meeting. Another way to keep the email short is to provide only the essential information and avoid tangents and extraneous details. Finally, edit for conciseness using the techniques discussed in Chapter 25. When you do need to make your document longer, or include graphics or tables, write it as a memo or report that you attach to the email.
20.1.3 How to make sure your message is understood

As with any communication, you need to organize email messages carefully. 1. The first paragraph should indicate the messages context, purpose, and main point. a. In DTC, the context includes the project you are working on. For your client and instructors, who are often working with multiple teams and sections, it also includes the section and team number. For experts and users, context includes the fact that you are a Northwestern Uni-
196
versity engineering student working on a design project to accomplish a specific goal. If you are writing to your client or instructors, you should also indicate your section and team numbers. Finally, if you refer to events that have occurred are or planned, use specific dates for ease of reference. Instead of, Thank you for meeting with us last week, write, Thank you for meeting with us on Tuesday, February 13. b. The purpose is a statement of why you are writing this message to the reader, for instance, to request something (a meeting or some information), to confirm something (an agreed-on meeting time or an understanding of the decisions made at a previous meeting), to provide a project update, etc. c. The main point is the key idea you want the reader to get from the message. For instance, a project status update might include this main point: We have built three mockups and will test them with users during the week of February 10th. The rest of the email would go into more detail on the mockups and testing. 2. The body of the email should present the necessary information in an easy-to-follow format. Keep the paragraphs shortwith only one idea per paragraphand skip a line between paragraphs. For longer emails, use headings and lists to break up the text and to emphasize main points. In addition to organizing the email clearly, you should also provide sufficient detail so that readers understand your points. Here is an example of a statement with insufficient detail. The team is writing to their client to confirm the requirements for a project to design a drinking system that can be attached to a wheelchair used by people with quadriplegia.
Based on our interview with you, we have identified several design requirements ranging from safety to ease of use.
The reader cannot tell whether the team has fully understood the requirements because not all of them are stated and there is no explanation of the two requirements that are stated. Here is a revision that provides enough detail to communicate the teams understanding of the requirements clearly.
Based on our interview with you, we have identified these design requirements: Safe: The device does not harm the user or anyone near the wheelchair. Easy to use: The user can reach and drink from the device without undue strain. Independently used. The user can drink from the device without the aid of others. Washable. The device can be cleaned in a dishwasher. Leakproof. The device does not leak as long as it has been properly assembled prior to use.
197
Inexpensive. The device costs less than $50.
20.1.4 How to make sure the reader acts on your message

1. Conclude by stating what you want the reader to do with the information you have provided. If you are confirming a meeting time, ask to be notified if the time needs to be changed. If you are following up on understandings reached at a previous meeting, ask to be notified if you misunderstood anything or if the reader has further information to provide. If you are trying to set up a meeting, ask the reader to reply by a certain date. 2. Provide the reader with options for action that will also fit your needs. When you present just one option, the reader may feel that youre being overly demanding. In addition, if that option doesnt work for the reader, then you wont achieve your goal in sending the email. So if you are trying to set up a meeting, dont give just one day and time, give several that fit your schedule, and perhaps suggest alternatives such as a conference call. 3. Use a polite and respectful tone. Tone is an element of email that causes great problems. A reader can get so irritated or offended by either an overly casual or overly demanding tone that she or he does not act on the message or acts in a way that you dont want. Therefore, when you are emailing your instructor, your client, or someone you havent met, such as an expert youd like to interview, make the style more formal and polite than in an email to a friend. Here are some tips for conveying an appropriate tone: a. Begin with a polite salutation, such as Dear Ms. Paschen or Dear Professor Jones (rather than Dear Fran or Hey! or Hi, Prof. J. b. Proofread the email carefully. Readers often view typos and misspelling as a sign that you didnt have the professionalism and respect to correct obvious errors. c. Avoid giving brief replies that may sound rude or rushed, rather than merely concise. Adding a phrase such as Thank you for replying so quickly can avoid misunderstandings. 4. End on a positive note. For instance, in the conclusion to an email providing a project update to a client, after writing, Please let us know if you have questions or suggestions for our user testing, you might add, We look forward to sharing our results with you when user testing is complete or The user testing results will help us develop a design that meets your requirements and satisfies users. 5. Avoid writing angry, critical remarks or jokes you wouldnt want others to see if the email is forwarded. This can be a particular problem in emails between team members. 6. Make sure your reader knows whom to contact. Give your name and other identifying information at the end of the message to clarify who is send-
198
ing the message. (The automated from line may show only your email address or NetID.) On mail being sent to addresses outside of Northwestern, put your email address in the signature because it is sometimes difficult to find it in the header. You may also want to include a telephone number in your signature.
20.1.5 How to keep your team and instructors informed

Because email is such an important component of project communication, it is essential that you keep your team and instructors in the loop. When teammates dont know what each other is doing because no one is being copied on emails, the entire team suffers. When instructors find out a week after the fact that your client emailed you that she cant make it to the final presentation or wants you to change your mission statement, then you are denying yourselves the support and advice your instructors might have been able to offer. Therefore, you should copy your instructors and teammates on all projectrelated email. This includes emails to team members, clients, experts, users, etc. When you receive emails from your client, experts, and users, be sure to forward them to your instructors and teammates. Finally, print out email correspondence with client, experts, and users, and include it in your project notebook as part of the permanent record of your work.
20.2 GUIDELINES FOR SENDING ATTACHMENTS

In DTC, as in most workplaces, documents are transmitted and stored electronically to save time, simplify drafting and revising by teams, and ensure that documents are easily accessible to everyone. Sending files electronically, however, requires thought and preparation. Below are guidelines for preparing electronic documents. 1. Give your files meaningful titles, version numbers, and other useful identifying information. A ubiquitous name like report.doc is likely to get lost in the shuffle. Instead, give it a name like:
progress_report_3_v2_s20t2.doc
The name identifies that this file is Progress Report 3, Version 2, posted by Team 2, Section 20. The suffix .doc tells what kind of file it is. Ask your instructors what file-naming conventions they prefer, and discuss them with your teammates. 2. Identify your documents clearly on the inside as well, using headers and footers where appropriate. Readers should be able to determine quickly
199
who the document belongs to, which version it is, which team member wrote it, and so forth. Remember that your instructors may have many different documents on their desk (or on their screen) at once. Marking your document clearly will prevent them (or you) from reading the wrong version of a document. Moreover, if an instructor downloads your file, he or she should know whose file it is once it is opened. 3. Use a file format everyone can read. Before sending a file, make sure your team members and instructors use a program that can read it. Then decide on a standard format for your group. Although Microsoft Word is the most commonly used word processor at Northwestern, check with your team members to be sure they all use it. Incompatible file formats between different versions of Microsoft Office can also cause problems. If someone on your team uses a word processor other than Word, save and send your files in RTF (rich text format), which most word processors can read. When publishing final versions, you can use PDF (portable document format) files, which can be read using Adobes free Acrobat Reader. Software for creating PDF files is available in all public computer labs at Northwestern. 4. When attaching files to email, keep the file size small. There are limits to the size of a file you can attach to an email message. Files that contain graphics and other media can become truly gargantuan.If you need to share large files, you may have to use an alternative to email attachments. 5. Guard against viruses. Use virus protection software and scan all files you receive.
20.3 GUIDELINES FOR SENDING FAXES

Occasionally, you may need to send a fax rather than an email attachment. Prepare a typed cover sheet that includes the following information: To: the name and title of the recipient and his or her organization From: your name, project, section/team, and NU/DTC affiliation Subject: be as specific as you would be in the subject line of an email Date Fax number Your phone number Number of pages (including the cover sheet)
200
20.4 REFERENCES
Fisher, D., Brush, A., Gleave, E., & Smith, M. (2006). Revisiting Whittaker & Sidners Email overload ten years later. Proceedings of the 2006 20th Anniversary Conference on Computer Supported Cooperative Work
201
202
Chapter 21: Visual CommunicationDocument Design, Figures, and Tables
CHAPTER 21: VISUAL COMMUNICATIONDOCUMENT DESIGN, FIGURES, AND TABLES
Chapter outline
Document design for written deliverables Figures Tables
Key guidelines for visual communication

Make the important components of a figure easily visible and clearly defined Give each figure and table a number and descriptive title Refer to each figure and table in the accompanying text Use parallel grammatical structure in lists Break lists with more than seven items into sub-categories Distinguish different levels of headings by varying the typography (e.g., font size, bold, underlining, italics) Single-space a report, and skip a line after each paragraph Number the pages in a report
In the first half of this textbook, you have seen that much of engineering design depends on visual communicationsketching during brainstorms, preparing mockups for user testing, and presenting slides and mockups in design reviews. Visual communication also includes document design and page layout so your reports will be attractive and easy to read, as well as effective use of figures and tables to communicate information clearly, concisely, and professionally. (Additional types of visual communicationposters and PowerPoint slidesare discussed at length in later chapters.)
203
21.1 DOCUMENT DESIGN (PAGE LAYOUT) FOR WRITTEN DELIVERABLES

A documents appearance and organization have an immediate effect on a reader. If it looks professional and makes information easy to find, readers are more likely to read it and to understand and be persuaded of your ideas. For advice about the overall appearance of DTC reports, see Chapter 24. For designing pages that are easy to read, follow the directions below. Each page of a document should look neat and professional, and be easy to read. This section explains how to use line spacing, margins, fonts, page numbers, and headers and footers to achieve those goals.
21.1.1 Line spacing and paragraphing

Use single-spacing and left-justified block margins for most of the documents you write in DTC: memos, reports, even documentation in your project notebook. Skip a line between paragraphs. In long reports, skip two lines between main sections. Use double-spacing for essays. Do not include an extra space between paragraphs; instead, use an indented first line to indicate a new paragraph.
21.1.2 Margins
Margins affect a documents readability because readers need sufficient white space to read easily. Follow these guidelines for margins: 1. Use 1-inch margins in all documents. Place headers and footers less than one inch from the top or bottom of the page, but surround the body text by at least one inch of white space. 2. Unless otherwise instructed, use a ragged right, not right-justified, margin for all body text. 3. For the left margin, use block paragraph form (no indentation) if you single-space. Use indented paragraphs if you double-space. 4. Indent block quotations one additional inch at the left margin. This extra indentation signals the quotation, so omit quotation marks.
21.1.3 Headings
Technical reports tend to organize material with headings, which makes them look different from papers in English composition. In the latter, you present your ideas and supporting information in a continuous flow of sentences and paragraphs because teachers read the material from beginning to end to see
204
how you develop your line of thinking. Engineering audiences, in contrast, tend to skip around to find what they want. In a long report or proposal, you may need several levels of headings to indicate the main sections (1st level headings), subsections (2nd level), sub-subsections (3rd level), and so on. Its unlikely that you will have more than four levels of headings, and if you do, you probably wont number them. Here are guidelines for writing clear, useful headings. 1. Be precise and concise. To do that you can choose among the following options: Use a key word or phrase that identifies the purpose of the section. However, avoid using headings such as Research, which tells readers little. Instead, say Lab Test of Umbrella Mockups. Phrase the heading as a short question the section will answer (for instance, What are the benefits of this design?) If you decide to use question headings, use them consistently throughout the document, or at least throughout that section of the document. Question headings are particularly useful as subheadings within a section of a document. Word the heading as a short statement that the section will explain: Users Prefer Design A.
2. Use parallel structure. Use the same grammatical form for headings at the same level of generality. For example, if you use Procedures for user testing, followed by Results of user testing, your next heading should be Next steps for user testing, and not What will we do next in user testing? 3. Make headings stand out visually. Skip at least one line above a heading. For first-level headings, skip a line below the heading. Use boldface, italics, underlining, or a larger font, but dont overwhelm the text with excessively large headings. Use decreasing levels of emphasis in decreasing levels of headings. For example, you might use a 14-point font in boldface for headings of main sections, 12-point boldface for the second level, and an underline or italics for the third level. Use the same size and typeface for headings at a given level. Place headings on the page so readers can identify their level. For example, you might place main headings at the left margin, secondlevel headings indented a few spaces, and third-level headings on the same line as the body text (in which case, you should underline or italicize the heading).
4. Make sure headings appear on the same page as the body text they introduce.
205
5. Capitalize only the first letter in a heading. In long documents, however, capitalize all letters in main headings, as in a chapter title. For an example of the effective use of headings and sub-headings, see the progress report in Appendix P.
21.1.4 Lists
Most of the material in a report is written in complete sentences and paragraphs because that provides the best way to explain logical relationships and make a persuasive case. However, the strategic use of lists can complement paragraphs, particularly when you want to highlight steps in a process and parts of a whole. Lists may consist of single words, phrases, sentences, and even short paragraphs. To present lists effectively, follow these guidelines: 1. Use numbers to present a sequence or series; otherwise, use bullets. Numbers also allow you to refer back to a point in a list. 2. Use parallel construction to indicate that items in a list are of the same kind. For example, in the list you are reading, each item begins with a command verb: Use, Make, Organize. Use either uppercase or lowercase letters, but be consistent. In the chart below, the list on the left is not grammatically parallel because two items are adjectives, two are nouns, and one is a complete sentence. The list on the right is grammatically parallel because each item is the same part of speech: an adjective or adjectival phrase.
Example 21.1: Wrong and right ways to create a grammatically parallel list
Wrong: not grammatically parallel Right: grammatically parallel
The key requirements are that the design be: easy to use cleanability users can store it under table portability water resistant
The key requirements are that the design be: easy to use easy to clean storable under table portable water resistant
3. Make sure all items are logically, as well as grammatically, parallel. For example, if you were listing equipment needed to build a prototype, your list should include all nouns and the nouns should be pieces of equipment. 4. Organize the list in a logical order. For example, you might list user groups from most to least important; you might list components of a design in the order in which the user will use them.
206
5. For a list of more than seven items, create subcategories so readers can see the logical relationships among the items. A team designing a desk organizer created this list of the items on the clients desk:
Example 21.2: Ineffective uncategorized list loose papers (about 15 sheets) telephone computer monitor CPU tower paper clip holder printer picture frames (3) stack of CDs pen cup mouse pad and mouse catalogues (6) brochures (8) file folders (5) rubber bands phone book speakers answering machine
The list is random and difficult to understand. In their progress report the team should subcategorize the list so they and their instructors can understand what the client needs help organizing:
Example 21.3: Effective categorized list Computer equipment CPU tower monitor printer speakers mouse pad and mouse brochures (8) catalogues (6) loose papers (about 15) file folders (5) pen cup paper clip holder rubber bands
Pamphlets
Work-related papers
Office supplies
Phone supplies
207
telephone answering machine phone book picture frames (3) CDs
Personal items
A word of warning about using lists: Its easy to get carried away and write entire sections of reports and memos in list format. Resist that temptation. Over-listing will make it much harder for readers to follow your line of thinking. Use lists in conjunction with, not instead of, sentences and paragraphs.
21.1.5 Page numbers

Include page numbers in every document, even drafts that you submit. The page number may be placed in either a header or footer. See Chapter 24.2.3 for when to use Roman numerals in a reports front matter.
21.1.6 Headers and footers

Use headers and footers to provide additional information about the document, such as title, date, and version number. These are not required, but if they are used, they should be formatted consistently and not contain so much information that they detract from the body text.
21.1.7 Fonts
In general use no more than two font styles in a document, one for headings and one for body text. Use the same font for all body text. A standard, readable font is 12-point Times or Times New Roman. Avoid using fonts larger than 16 point or smaller than 9 point. Also, avoid changing sizes too often, as this will make your work appear amateurish. Use boldface and italics sparingly and consistently.
21.2 FIGURES
Figures are crucial in technical communication. They help readers understand and visualize information that is often hard to understand from text alone. The word figures covers a wide range of items, including photos, sketches, drawings, graphs, diagrams, flow charts, and maps. As with all communication, keep your audience and purpose in mind as you plan your figures. Consider, for instance, the final report written by a team designing a desk organizer for a client overwhelmed with clutter. The team created highly detailed, dimensioned drawings of their final design, but the
208
client didnt have the knowledge necessary to read them. To accommodate their client, the team used photos in the body of the reportthe part that the client would be most interested inand put the dimensioned drawings in the appendix for the woodworker hired to construct the product. When you consider using a figure, ask yourself the following questions: Audience: Who will be looking at the figure, and will they know how to interpret it? If not, should I include an explanation of how to interpret it or should I use a different figure? Purpose: What point do I want the figure to illustrate? Does the figure illustrate that point clearly, or do I need to use a different one? For instance, if the desk organizer team wanted to illustrate how to use the product, a series of sketches or photos might be better than a single illustration. Labeling: Does the figure stand on its own or does it need explanatory labels (i.e., arrows that connect the components of a design to phrases identifying those components)? Visual clarity: Are the important components easily visible and sharply defined, or is the figure cluttered with too many details and labels? Is the figure large enough?
21.2.1 Guidelines: How to present figures

Here are rules for presenting figures clearly and correctly: 1. Label the figure. Give each figure a number and a title that concisely describe what the label representsfor example, Figure 6: Top View of Desk Organizer. Place the figure number and title below the figure. (Note: This is different from tables, where the number and title are placed above the table.) 2. Indicate the source. When you include a figure from another source, include a source line under the figure number and title that indicates where the figure was originally published. For instance:
Figure 3: Tube desk organizer Source: Crate and Barrel (http://www.crateandbarrel.com/ store/details.asp?category=86&index=0)
3. Refer to your figure in the text. Always refer to figures in the text, explaining their significance and key points. You cant expect readers to focus on the details that impress you about the figure unless you guide their view. The reference should precede the figure and identify it by number (Our proposed design has two sliding trays that allow you to work easily with two documents at the same time. See Figure 4.). The amount of explanation for each figure depends on the figures complexity.
209
4. Position the figure effectively. Place it as close as possible to its reference in the text. Avoid placing the figure and accompanying text on separate pages. 5. Dont clutter figures with too many details and labels. Include only those details and labels that readers need to understand key points.
21.2.2 Examples: Effective use of figures

The examples below illustrate the effective use of drawings, photos, and graphs. 1. Effective use of a dimensioned drawing. The following drawing, from a final report for a redesign of the stage area in a church meeting hall (Balash, Lee, OSullivan & Zhang, 2002), is clearly labeled and includes details only on the ramp entrance to the stage, which is the focus of this section.
Example 21.4: Effective use of dimensioned drawing The new entrance to the meeting room/library is wheelchair accessible. Located inside Fellowship Hall is an ADA-compliant 1-to-12 ratio ramp (Figure 4) that consists of inclines, platforms, railings, and rounded turns to decrease the amount of area and increase the safety. The ramp is positioned so that the landing/stage platform in Figure 4 can double as part of the stage (labeled Stage 2 platform) being developed by the other Northwestern stage design team. Our collaboration in these projects has allowed us to develop this feature, which will incorporate a handicap-accessible stage in the center of the space.
210
Figure 4: Ramp entrance to meeting room / library
2. Effective use of photos. The photos below effectively illustrate a prototype of a clip for attaching a bicycle light (Cameron, Collins, Rauwerdink & Woodward, 2003). The juxtaposed photos and accompanying figure titles show clearly what the team wants the client to see: the clip in open and closed positions.
Example 21.5: Effective use of photos Our prototype demonstrates the mechanics of our design. Figures 5 and 6 show our prototype clip in the open and closed positions.
Figure 5: Prototype in open position
Figure 6: Prototype in closed position
3. Effective use of graphs. Graphs are useful to help your readers visualize data and see relationships. For example, you might use a bar graph to emphasize that users preferred one mockup to two others. Or, if youve
211
surveyed users about their preferences on a designs features, you might use a pie graph to show the percentage of users that favored each feature. Designing good graphs requires that you follow some key guidelines: a. Choose the right type of graph to convey your information. For example, you would not want to use two side-by-side pie charts for comparing information when a reader would understand the comparison more easily if you used a paired bar or column chart. b. In designing graphs, eliminate all extra ink and clutter. For example, avoid 3-D, unnecessary gridlines, and unnecessary lines around graphs, so the data stand out. If you need gridlines, make them gray rather than black. In other words, avoid graphs like Example 21.6 (which may be encouraged by your softwares default views) and instead design graphs to be more like Example 21.7. (Note: your softwares default may encourage bad practices, such as 3-D views, so you may need to change the default.)
Example 21.6: Badly designed graph Users prefer shoe strap
212
Example 21.7: Better graph design Users prefer shoe strap
c. In addition, be sure to design your graph so that it represents the data honestly and accurately. Imagine a team that has tested three mockups to determine which one users can operate in the least amount of time. In the graph below (Example 21.8), it appears that mockup A is significantly better than the other two. However, that is only because the starting point is made to be 54 seconds.
Example 21.8: Graph is misleading due to distorted scaling
72 70 68 66 64 Seconds 62 60 58 56 54 Mockup A Mockup B Mockup C
213
When the scaling begins at 0 seconds (Example 21.9), the differences among the three mockups no longer seem significant:
Example 21.9: Graph presents data without distortion
80 70 60 50 40 30 20 10 0 Mockup A Mockup B Mockup C Seconds
For a good discussion of graphs and charts, refer to Sedlack, Shwom and Keller (2008)see References.
21.3 TABLES
Tables allow readers to see relationships between numbers and concepts at a glance, without having to read painstakingly through a paragraph and visualize these relationships.
21.3.1 Guidelines: When to use tables

Use a table to (1) present categories with several shared characteristics or variables; (2) show the presence or absence of specific characteristics; (3) compare items with a paired logical relationship. Each situation is discussed below. 1. Use a table to present more than two categories or items with several shared characteristics or variables (this type of table is called a matrix). Below is an example of such a table. The team redesigning a space in a church asked church members for their reactions to three mockups (Balash et al., 2002). After compiling the data, the team created a matrix. The first column lists the criterion (the user requirement), the second lists the relative importance, or weight, of that criterion, and the last three
214
columns list the average rating of a particular criterion used to test each mockup. The bottom row gives the weighted score for each mockup. The team used this table in deciding on their final design direction and to justify their decision to their client and instructors.
Example 21.10: Decision matrix for church space redesign
Criterion Weight Library (mockup 2) 8.6 9.7 9.5 8.8 8.7 9.5 9.6 8.5 66.31 Library & meeting (mockup 1) 9.6 9.2 9.4 7.6 9.3 9.6 10 8.3 66.55 Library & meeting & storage (mockup 3) 6.5 7.4 8.6 8.9 6.3 8.6 9 6.8 56.5
Maximize space usage Maximize bookshelf space Minimize clutter Maximize ease of accessibility Maximize comfort level Maximize capacity Maximize safety Maximize mobility Score
1 0.8 0.7 1 1 0.9 1 0.9
KEY The averages for the three mockups are based on a rating system of 1 to 10, with 10 being the best and 1 the worst.
2. Use a table to show the presence or absence of specific characteristics. The church space redesign team created this kind of tablewhich uses Xs, checks, or pluses/minusesto decide whether to make the space accessible by means of an electronic lift or wheelchair ramp (Balash et al., 2002). The two alternatives appear in the top row, and the requirements are in the first column.
Example 21.11: Sample decision matrix for church stage project
Lift Cost Ease of use Use of space Total -+ ++ + ++ -Ramp
KEY ++ = satisfies requirement well + = satisfies requirement adequately - = does not satisfy requirement adequately -- = satisfies requirement poorly
215
3. Use a table to compare three or more items with a paired logical relationship, such as before and after, features and benefits, and users and functions (in other words, a table correlating two or more lists). Below is an example from the conclusion of a final report from the team designing the user interface for an electronic kiosk to help shoppers find restaurant and entertainment information for downtown Evanston (Chen, Johnson, Kidd, Lesperance & Marvin, 2002). The table helped the team emphasize the benefits of every feature in their design.
Example 21.12: Features/benefits of electronic kiosk interface design
Feature Touch screen Benefits Is easy and intuitive to use Has large buttons accessible to a wide variety of people Allows users to quickly go back to earlier stages for quick navigation
Link trails
Color-coded buttons
Make certain categories stand out to users as being different from the other selections Makes selections and comparisons of similar businesses easy
Search by type
Search by location
Allows users to find businesses in a specific district Allows users to find restaurants within their budget
Search by price
Index
Provides basic contact information in an easy to read format
21.3.2 Guidelines: How to present tables

Here are rules for presenting tables clearly and correctly: 1. Label the table. Give each table a number and a title that concisely describes what the table represents (for instance, Table 12: Features/Benefits of Electronic Kiosk Interface Design). Center the number and title above the table. (Note: This differs from figures or illustrations, where the number and title are placed below the figure.) 2. Footnote when necessary. Provide footnotes (at the bottom of the table), using lowercase letters or asterisks, to indicate explanations at the bottom
216
of the table. For example, use a footnote to indicate that N/A in a cell refers to omitted data. 3. Indicate the source. Use a source line to indicate where a table from another source was originally published:
Source: Adirondack Video Astronomy (http://www.astrovid.com/starlight_xpress_ccd_camera_comp.htm)
4. Refer to the table in your text, and explain its significance and key points. The reference should precede the table. Refer to the table by number (As Table 11 indicates, the lift is preferable to the wheelchair ramp to make the redesigned space accessible.). Alternatively, if the table immediately follows its reference, refer to it by position (As the table below indicates). The amount of explanation each table requires depends on its complexity. 5. Position the table effectively. Place the table immediately below its reference in the text. If you refer to a large table repeatedly throughout the text, place the table in an appendix. 6. Include a key when necessary. The key appears just below the table and explains what the values in the body of the table mean. For example, if the table contains the results of user ratings, the key would indicate that the numerical values mean the following: 1=did not like at all, 5=liked very much.
21.4 REFERENCES
Balash, P., Lee, J., OSullivan, T. & Zhang, F. (2002). Final proposal. Engineering Design and Communication, Northwestern University. Cameron, N., Collins, A., Rauwerdink, M. & Woodward, D. (2003). Fast clip bike light proposal. Engineering Design and Communication, Northwestern University. Chen, R., Johnson, A., Kidd, L., Lesperance, I. & Marvin, J. (2002). Evanston kiosk proposal. Engineering Design and Communication, Northwestern University. Sedlack, R., Shwom, B. & Keller, K. (2008). Graphics and visual communication for managers. Mason, OH: Thomson.
217
218
Chapter 22: Instructions
CHAPTER 22: INSTRUCTIONS
Chapter outline
Planning Organizing Testing and revising
Key guidelines for instructions

Write an introduction that explains what the instructions will enable readers to do List the materials and equipment in a logical order Keep each step short and on a separate line To make a long list of steps easier to follow, break them into categories Use pictures to illustrate the steps Warn readers of dangers and hazards in emphatic terms Test a draft of the instructions with a user and then revise accordingly
Depending on your project, you may need to write instructions for users to build, operate, fix, or maintain your design. For example, a toy designed for children with disabilities might include instructions for assembling, cleaning, storing, and safely using the toy. In addition, you may find it useful to write informal instructions for teammates to help them complete different tasks. Its wise to draft instructions early because doing so can help you figure out specifications and uncover problems with a design. In addition, you may need to draft instructions for users who will test design mockups.
22.1 PLANNING
As with all technical writing, keep in mind the purpose, audience, and tone when writing instructions.
219
22.1.1 Purpose
Think of your purpose as defining the task or tasks that users will be able to perform as a result of reading the instructions, and state this purpose in the introduction. For instance, heres the first sentence of a set of instructions: These instructions will lead you through the process of safely and efficiently setting up the wheelchair ramp for Northshore Opera Company performances. When instructions explain more than one major task, the introduction should state the multiple purposes. Heres an example from the instructions written to accompany a design for a footrest attachment to a highchair: In these instructions, you will learn how to attach the footrest safely and securely, adjust it according to the childs height, and detach it for cleaning. Notice how the multiple purposes are described in grammatically parallel phrases (a series of verbs).
22.1.2 Audience
Before you write your instructions, ask yourself: Who is the audience? How experienced are they with this kind of procedure? Are they familiar with the technical terms and equipment referred to in the instructions? What will their attitude be as they begin using the instructions?
Will the audience use the instructions independently or will they first be trained and then use the instructions as a reference? Can the audience use the instructions either spread out on a surface or held in their hand? Will the audience be performing the procedure alone or with the help of someone else? Will the instructions be in the form of a hard copy or an electronic document?
22.1.3 Tone
You will need to use a variety of tones in different parts of the instructions. Use command statements to present the steps: Insert bolt A into hole 3. Use a neutral, straightforward tone to state the purpose of the instructions or of individual steps. Sometimes these statements are written in third-person: At this point, the three rods should form an equilateral triangle. Sometimes, particularly in the introductory sections,
220
instructions address the reader in second person (referring to the reader as you): Depending on the amount of space available, you can store the ramp safely either in an upright or flat position. State warnings using a tone of urgency and explain the reason for the warning. Note: while it is fine to put WARNING or CAUTION in all capital letters, dont use all caps for text in the warning. Doing so will make your text harder to read. Here is an example of an effective warning:
WARNING: Make sure all four bolts are securely tightened. Failure to do so may result in the ramp collapsing and causing serious injury to someone on or near it.
These guidelines for tone apply to most circumstances, but be prepared to alter the tone to fit your audience. For example, a team designing a device for a child with disabilities used a friendlier, more informal tone than is typically found in instructions.
22.2 ORGANIZING
Organizing instructions might seem simple: you might think that all you need to do is give steps in sequential order. Unfortunately, readers are likely to get lost if they must follow a long list of steps or if there are too many actions in one step. Theyll also get lost if they cant visualize the end result of the instructions. Well-organized instructions give the big picture first. Then they group actions into logical units and divide actions into discrete steps. Heres a typical structure for instructions: 1. title 2. introduction 3. materials and equipment 4. theory of operation 5. directions 6. troubleshooting Heres what you might include in these sections to make the instructions easy to use.
22.2.1 Title
Use a title that indicates this is a set of instructions for performing a specific process. Instead of Wheelchair Ramp, write Setup Instructions for Northshore Opera Company Wheelchair Ramp.
221
22.2.2 Introduction
Consider these questions when writing your introduction: What precisely will these instructions show readers how to do? People appreciate knowing the purpose first, as illustrated in the example about the wheelchair ramp: These instructions will lead you through the process of safely and efficiently setting up the wheelchair ramp for Northshore Opera Company performances. What major steps will the instructions cover? The wheelchair ramp instructions might include this statement:
The instructions are divided into the following sections: Connecting the ramp sections Connecting the handrails Adjusting the supports Checking connections and adjustments Disassembling the ramp Storing the ramp
What level of experience and background knowledge do the instructions assume readers have? If your instructions assume specialized knowledge or experience, say so in the introduction. For example, instructions for a device to test the physical mobility of stroke victims might include this statement: These instructions are intended for physicians and physical therapists working with stroke patients. How should readers go about using the instructions? Instructions often suggest that you read through the entire document before proceeding, but people rarely follow this advice. Therefore, additional, more specific, suggestions are often helpful: Two people are necessary to assemble the ramp, or, After completing steps 1 through 8, you may take a break before proceeding. How long does the process take? This is especially important if the procedure is lengthy or involves waiting between major steps for components to dry. What general warnings do you need to include to alert users about safety hazards? You will, of course, include warnings in explaining the steps themselves later, putting the warning ahead of the step to which it refers, but you should also highlight hazards at the start if they must be kept in mind throughout the procedure.
22.2.3 Materials and equipment

Before giving directions, list materials and equipment in the order they will be used or according to type (large equipment, electrical tools, fasteners). Be precise: Dont say a nut, say 1/8-inch square nut. If the items in your materi-
222
als list are not common household items, then you should include a bill of materials (BOM). A description and an example of a BOM are provided in Chapter 10. If the BOM is long, you may include it at the end of your instructions and use just a materials list at the beginning.
22.2.4 Theory of operation

Include a theory of operation section if you think readers will benefit from visualizing the end product and understanding how it should work. Theory of operation is not always necessary, especially in instructions for household and other consumer items. Instructions for highly specialized, technical equipment, however, frequently include a theory of operation section.
22.2.5 Directions
The step-by-step directions are the body of your instructions. 1. Present each step clearly and concisely. a. Use the command style (also known as the imperative verb form, which were using in this section) for each step. If you need to add explanations, do so after the command. b. Number or letter each step to help readers keep track of where they are in the procedure. c. Present one step at a time; dont combine steps in paragraphs, such as the following:
Slide module G into slot 3. Then pivot the module 45 degrees to the right. Lower the stabilizing rod on the module until rod locks into place.
Instead, present instructions like this:

Slide module G into slot 3. Pivot module 45 degrees to the right. Lower the stabilizing rod on the module until rod locks into place.
d. Make steps stand out by skipping a line after each one. 2. Group related steps under main categories. To make a long set of instructions easier to understand, follow these guidelines: a. Break long lists of steps into categories that contain fewer steps. In writing this list of guidelines, for instance, we have grouped eleven steps under four numbered categories. b. Use headings and highlighting (italics, underlining, boldface) to emphasize main categories. Word the category heading (or intro-
223
ductory sentence) so it gives readers the big picture (for instance, Connecting the ramp sections). 3. Use illustrations where needed to clarify directions. When using illustrations: a. Place the illustration next to or right below the step it refers to. Give the illustration a number and title: Figure 2: Checking the Settings. Readers do not like to flip back and forth to the end of a document to see the figures. b. Refer to the illustration in the appropriate step: Check that the settings appear as shown in Figure 2. c. Avoid cluttered illustrations: Label only the parts that readers need to have identified. 4. Address dangers and problems readers may encounter. a. Put boldfaced Warnings, Dangers, and Cautions, and an explanation, in front of the hazard theyre intended to prevent. Use Warning to label a hazard that might harm a person. Use Danger if the harm could be life-threatening. Use Caution if harm may come to the equipment. b. Where applicable, explain how to tell if a tricky step was done correctly. For example, instructions on folding a cardboard six times might end with the statement, The cardboard should look like an inverted pyramid.
22.2.6 Troubleshooting
When necessary, end instructions with a chart that lists common problems and ways to solve them.
22.3 TESTING AND REVISING

Testing is a crucial part of writing instructions. Have users test your instructions and provide feedback to help detect problems in the way theyre written and in the design itself. When testing your instructions: 1. Choose users from your target audience. 2. Observe users and take notes on how they follow the instructions. Do not offer help unless a user is too confused to proceed or is about to make a serious error. 3. Interview users to get feedback after they complete the test. Use the feedback to revise your instructions. Then test the instructions again to make sure you've eliminated the problems and have not created new ones. Revise again as necessary. This rigorous process of testing and revising is
224
necessary to prevent damage and injuries resulting from poorly written instructions.
225
226
Chapter 23: Progress Reports
CHAPTER 23: PROGRESS REPORTS
Chapter outline
Planning the report Formatting and organizing the report Editing for clarity and conciseness
Key guidelines for progress reports

Use a memo heading, indicating the primary authors in the From line Begin with a brief summary of specific key findings, decisions, and next steps; do not write in generalities about the steps you have taken After the introduction, explain your most important findings and decisions Provide support for decisions in the form of specific results from research and testing Explain next steps in specific terms Cite sources in the text and in a References page Arrange appendices in the order in which you refer to them in the body of the report Follow the guidelines discussed in Chapter 21 regarding the use of figures, tables, headings, lists, and page numbers
This chapter explains the progress reports that you will write in the second quarter of DTC. A progress report concisely summarizes the current project status (including key research findings and design decisions), and next steps. It is intended to be read quickly, so the body of the report should be concise and well-organized. Focus on the most significant information. Use short paragraphs, headings, subheadings, and bullet lists to make the report easily readable. Edit sentences for conciseness and clarity (see Chapter 25). A progress report may be either an internal report addressed to the supervisor of an ongoing project (for instance, your DTC instructors) or an external
227
report addressed to the project's sponsor (the person paying for the project, such as a client). In the second quarter of DTC, you will write internal progress reports addressed to your instructors. Although your instructors have been working closely with you on the project, they are also supervising several teams and may not recall all the details of your work. Therefore, it's very helpful for them to read a concisely written report that summarizes exactly where you are in your project. Progress reports are important in DTC because they: help you prepare for your team meetings with instructors allow your instructors to see how your project is shaping up, to troubleshoot problems, and to help you fix these problems give your team the opportunity to synthesize its research and see what else there is to do document your design process as part of the teams project folder
Although one or two team members may be responsible for drafting it, the report represents work done by the entire team. Therefore, all members should contribute to the report, especially the appendices. The primary writer should also circulate a rough draft so that team members can suggest revisions before the due date. In industry, you will find that different companies and managers have different requirements for progress reports. The same is true for the various instructors in DTC. Therefore, you should discuss with your instructors their preferences for the organization, format, and length of the progress reports you submit. Appendix P at the end of the textbook contains an excellent progress report submitted in DTC. Review it with your instructors to get ideas for your own reports.
23.1 PLANNING THE REPORT

To illustrate how to write a progress report, lets look at how one team plans its report by considering each element of the communication square (see Chapter 18). The teams project is to make the entrance to a local church wheelchair-accessible. Content: Progress since our first team meeting and plans for the next three weeks. Our main decision has been to focus on a stairlift design rather than a wheelchair ramp or elevator. The decision was based on the lack of space for a ramp, the results of our user surveys, and the cost-effectiveness of a stairlift. Our main next steps are to research stairlift retailers, contact the Evanston department responsible for building codes, interview a building contractor, and meet with the church property committee with a draft of our stairlift plan.
228
Audience: Our DTC instructors. They have read our first progress report, so they know what the client is looking for in general. However, we cant assume they know much about ramps and stairlifts. Purpose: To inform our instructors of our major decision and persuade them that it is based on sound research and reasoning; to get their help in locating a building contractor to interview; to get their advice about what our final prototype should be, since we wont actually be building a stairlift. Tone: Businesslike and straightforward
23.2 FORMATTING AND ORGANIZING THE REPORT

As mentioned above, you should talk with your instructors about their specific preferences for the format, organization, and length of the report. In this section, we present general guidelines.
23.2.1 Overall format

In DTC, as in many businesses, you will prepare your reports as memos with appendices. That means you should follow the conventions common to memos, with a heading like the one in Example 22.1 below. Single-space the report, skipping a line between paragraphs and sections. Use a memo heading that consists of Date, To, From, and Subject. The From line should indicate the section and team number, the reports primary author, and the names of the other team members.
Example 23.1: Typical memo heading To: Professors Herbst and Herrick From: Section 23 Team 4 - Dhaivat Buch, Tinlee Lin (primary authors), Kelly Luck-asevic, and Garrett Thoelen Date: May 23, 2006 Subject: Progress Report 2 on Diaper Wipe Project
Use headings and subheadings to identify the main categories of information you are presenting. Number the pages.
229
23.2.2 Key parts of a progress report and their purposes

When organizing your report, make sure that you do the following: Begin with an introduction that briefly summarizes the key decisions and findings of the previous few weeks, as well as the next steps to be taken in the upcoming weeks. You will elaborate on each decision, finding, and next step in the body of the report. Also, state the project, purpose of the report, and dates it covers. In stating your decisions and findings, avoid generic statements that apply to all projects. Here's an example of an uninformative, vague sentence in an introduction and a greatly improved version that offers specific information (Buch, Lin, Luckasevic& Thoelen, 2006):
Example 23.2: Make specific statements in the introduction
Vague We conducted user surveys and learned a lot from them. We also made significant decisions that will enable us to develop the design.
Specific Our user surveys showed that the majority of parents would find a dryto-wet baby wipe container useful. We also decided to use a modified ball-valve to release lotion onto dry wipes, and built a proof-of-concept model of this system.
In the body of the report, organize the discussion of your progress around key decisions and findings, not around the steps you have taken so far. Your instructors are well aware of the syllabus, so they know the general steps you have taken. They are most interested in finding out what you have learned and decided through that process. Below are two examples of the headings and sub-headings used to structure the information in the body of a progress report. The first example follows an uninformative chronological structure, while the second uses an informative structure that highlights key findings and decisions:
230
Example 23.3: Organize the discussion of your progress around decisions and findings
Uninformative step-bystep heading structure
Informative decision-based heading structure
1. Progress since last report a. User surveys b. Alternatives c. Design concept d. Design review
1. Progress since last report a. User surveys approved dryto-wet wipe idea b. Design concept development c. Modified ball valve for lotion delivery Bear as visual concept
Design review issues in lotion delivery method
d. Latest drawings
Support decisions with significant findings from research and testing. Organize the report so that readers can easily see the connection between the decisions and the supporting information. If the information comes from outside sourcesbooks, articles, and websitescite them in your References page. If the information comes from interviews and testing, provide names, dates, and places. Raw data from testing should appear in appendices (see below). However, present key data in the body of the report also. Do not simply say, See Appendix F, hoping that readers will take the time to flip to the appendix and search through it to find for the relevant data. Here's an example of an unsupported decision followed by a greatly improved revision that provides supporting data:
Example 23.4: Support decisions with research and test results Decision with no support: We did user testing that confirmed our decision to move forward with the dry-to-wet container design. But it also made apparent that we must make the product visually appealing and useful looking, and the product should not cost much more than a regular container (see Appendix D). Decision supported with data from user testing: On May 7, we surveyed five parents (who currently have children in diapers) at the Sheil Catholic Center on their wipe-purchasing habits and on our dry-to-wet concept. (See Appendices D and E for survey form and results.) We learned that: 3 out of the 5 parents purchase generic brand wipes most often because they are cheapest
231
Only 1 parent purchases Pampers brand wipes regularly 3 out of 5 parents think a dry-to-wet dispenser would be useful Only 1 parent would buy the dry-to-wet dispenser if it was more expensive than regular Pampers dispensers
These results confirmed our decision to move forward with the dry-to-wet container design, but they also made it apparent that the product should not cost more than a brand-name container. Additional feedback also revealed that the product must be visually appealing and useful looking.
State the next steps for the upcoming weeks. Be specific; dont just repeat the generic steps listed in the syllabus. Here's an example of a vague statement about next steps followed by a specific informative version:
Example 23.5: Explain next steps in detail, emphasizing your objectives Vague statement of next steps: After building our protoype and getting further feedback on it, we will write the report and PowerPoint for our final presentation (see Appendices D and E: RAM and Gantt Charts). Specific statement of next steps: These are tasks we need to accomplish before we pre-sent our final design on June 7: Further examine details of valve leak problem Complete proof of concept prototype, including ball-valve Complete visual prototype in yellow foam Hold a second design review to assess our complete prototype Write report and PowerPoint for final presentation
If necessary, discuss any help you need from your instructors. Conclude by summarizing where you are in the project and whether you are on schedule. Your instructors may also ask you to discuss whether you are within the DTC budget of one hundred dollars. This discussion may be supported by an appendix that itemizes your current and planned expenditures Cite sources in a References page. You should list all the books, articles, and websites you researched, as well as interviews you conducted. See Chapter 26 for guidelines on documenting sources. Include supplemental material in one or more appendices. See below for further discussion of this part of the report.
232
23.2.3 Using appendices in a progress report

In a progress report, appendices are used to provide raw data, the project definition, RAM and Gantt charts, and any other backup information. But be selective; dont dump all your research into the appendices. When presenting appendices: Put only one kind of information in each appendix so readers can find information easily. Arrange and label appendices so readers can find information quickly. Arrange appendices in the order in which you refer to them in the text. Label them sequentially: Appendix A, Appendix B, etc. Begin each appendix on a new page and identify each with a title and descriptive heading (for instance, Appendix C: Summary of User Test Results). Make sure you refer to each appendix at least once in the body of the report. Start any appendix that is not self-explanatory with a brief introduction explaining what the information means and how it was derived. For example, the introduction to an appendix that presents a table summarizing the results of user testing should explain the test methodology, any limitations to the data as a result of that methodology, and the meanings of headings and numerical values in the table. Project definitions and RAM and Gantt charts generally do not need introductions.
23.3 EDITING PROGRESS REPORTS FOR CLARITY AND CONCISENESS

To accomplish the goal of communicating your progress to instructors, you need to edit for clarity and conciseness. Guidelines for writing concisely are covered in Chapter 25. Clarity, however, involves much more than writing style. In particular, you need to make clear to your instructors how the conclusions and decisions you've reached derive from your research and testing. Review Chapter 18 for an explanation of this key point. Then work to avoid the two common pitfalls in writing progress reports that are explained below: 1. Providing insufficient details to support your decisions 2. Presenting research results in a story format
233
23.3.1 Pitfall #1: Insufficient details to support your decisions

Your readers need enough specific information to understand what youve learned about the problem and the rationale behind your decisions. Below is a rough draft of a paragraph about environmental and safety considerations in designing mockups (Syed, Erisken, Kuo & Tang, 2004). The project involved designing a system that would prevent a new, environmentally friendly paint from freezing in very low temperatures.
Example 23.6: Include sufficient detail to support decisions Paragraph with insufficient support: The mockups we have designed are straightforward and, to the best of our knowledge, do not harm the environment or create safety problems. Our team has not used any more Styrofoam than what is present in the current design used by the paint company. Paragraph with strong support: We evaluated the three alternatives for possible safety problems. We determined that Mockup #2 was problematic (see Appendix D: Mockups and Appendix E: Failure Analysis) because we had submerged the wiring in the paint. Because this could pose a fire hazard at an industrial plant, the vibrating instrument is now located outside of the paint container. Our other mockups do not harm the environment or create safety problems. The heat packs in Mockup #1 are safe, non-combustible, and environmentally friendly--e.g., they are used in crates transporting live animals. The Styrofoam, though not biodegradable, is still safe. Our team has not used any more Styrofoam than what is present in the current design used by the paint company.
In the process of adding more detail to support their claim that the mockups are safe, the team realized that one of their mockups was hazardous. This is a good example of how the communication process feeds into the design process.
23.3.2 Pitfall #2: Using a story format to explain your research

The story format (sometimes called narrative organization) used in this example is wordy and emphasizes the teams actions rather than the results.
Example 23.7: Avoid a story-telling format in progress reports Wordy use of story-telling format: We conducted a number of mockup tests to determine the best way to hold the attachments in place. We decided that our first mockup would use Velcro to perform this function. We had to find out whether
234
Velcro would be strong enough to work. So we applied the Velcro to the attachments, and then put them on the mockup. Then we had our users try to pull the attachments off. During the test we saw that it was too easy for the users to pull off the attachments. Consequently, we decided not to use this feature. Concise explanation of decision and support: Mockup testing led us to eliminate Velcro as a method of holding the attachments in place. During the tests, users pulled off the Velcro attachments on the first mockup too easily.
A clear, comprehensive progress report communicates what you have been doing and where you are headed, giving your instructors the information they need to provide feedback at different stages of your project.
23.4 REFERENCES
Buch, D., Lin, T., Luckasevic, K. & Thoelen, G. (2006). Progress report 3. Engineering Design and Communication, Northwestern University. Syed, S., Erisken, S., Kuo, J. & Tang, S. (2004). Second progress report, drafts 1 and 2. Engineering Design and Communication, Northwestern University.
235
236
Chapter 24: Final Reports
CHAPTER 24: FINAL REPORTS
Chapter outline
Planning a final report Structure and content of a final report Cover and binding Title page Front matter Table of contents List of figures List of tables
Executive summary Body References Appendices
Writing style for a formal report
Key guidelines for final reports

Follow this structure for the body of the report: executive summaryexplain the problem, requirements, and final design (in no more than a page) introductionsummarize the report's purpose and preview its organization discussion of major users and requirements design conceptuse verbal explanations and dimensioned drawings rationale for the designsupport the design with reference to research and testing design limitationsexplain aspects of the design that need further testing and development conclusionsummarize how the design meets key requirements
Cite sources in the text and in a References page
237
Arrange appendices in the order in which you refer to them in the body of the report Follow the guidelines discussed in Chapter 21 regarding the use of figures, tables, headings, lists, and page numbers
This chapter explains how to write a final report about a design. You will write this kind of report at the end of each quarter of DTC. The goal is to persuade the client (and others in the clients organization) that a proposed design solves the problem in a way that fulfills the major stakeholder needs. It must also include whatever information is necessary for your client to proceed with the project, particularly a discussion of limitations of the design concept and instructions for building and using the prototype.
24.1 PLANNING A FINAL REPORT

To understand how to plan a final report, lets look at how one team considers content in relation to audience, purpose, and tone (see discussion of communication square in Chapter 18). The project was to design a new library for a local elementary school. Audience: Our clientsthe school principal and parents and teachers on the library planning board are knowledgeable about school libraries, so we need to anticipate their questions about, and objections to, our design features. Its also possible the principal will show the report to building contractors, so we need to present drawings with detailed measurements and specifications (especially in the appendices). Purpose: To explain all aspects of our design, how it satisfies all client and user requirements, and its basis in solid research. After reading the report, readers should understand our design and be convinced to move forward with it. Content: Detailed explanation of our design and its rationale, supported by our research. Tone: Businesslike and straightforward. We should avoid engineering jargon. Also, although we are trying to sell our design, we shouldnt make the report sound like a sales pitch; all statements need to be to the point and well supported by facts, research, and testing.
24.2 STRUCTURE AND CONTENT OF A FINAL REPORT

Many companies, organizations, and classes furnish style and report guidelines that writers must follow. In DTC, your final report should include the following elements:
238
1. Cover and binding 2. Title page 3. Front matter: Table of Contents, List of Figures, and List of Tables 4. Executive Summary 5. Body (text of the report, divided into key sections) 6. References 7. Appendices
24.2.1
Cover and binding
To look professional, your report should have a cover and binding (preferably spiral, but Velo is acceptable). Ask your instructors what type of binding they prefer. Any of the copy shops near campus will be able to bind your report.
24.2.2
Title page
The title page should include: 1. Full title of report 2. Names of team members in alphabetical order, and team and section number 3. Date of document (the final presentation date) 4. Name of the organization for which the team works (Northwestern University, Design Thinking and Communication) and the names of your instructors 5. Name of the client and the clients organization 6. Professional-looking, easy-to-read fonts and basic colors. (Avoid fancy fonts and colors.)
24.2.3
Front matter
The front matter of a report refers to those pages that follow the title page and are numbered in italics (see the Note on numbering below). These usually include a Table of Contents, List of Figures, and a List of Tables. Some organizations require an abstract instead of an Executive Summary.
Note on numbering pages

Formal reports typically include two sets of page numbers. Pages in the front matter Table of Contents, List of Figures, List of Tablesare numbered consecutively in lower case Roman numerals. The title page is not numbered, but the Table of Contents usually is ii. All page numbersRoman and Arabicare typically centered at the bottom of the page.
239
Regular page numbering, using Arabic numerals, begins after the front matter, typically starting with the Executive Summary. Pages in appendices continue the numbering sequence from the body of the text.
Table of Contents
In order of appearance, the Table of Contents comes first. It lists the headings and subheadings of the document and the page number on which each begins. Subheadings should be indented. Make sure the headings and subheadings in the body of the document are the same as those in the Table of Contents. The Table of Contents also contains a list of all appendices. List each appendix separately, along with the page number on which it begins. Each appendix should have a letter and title (for instance, Appendix A: Design Specification). To punctuate a Table of Contents, place a series of periods, called leaders, between the heading and the page number. The page number should extend to the right-hand margin. See Appendix L for a sample Table of Contents
List of Figures
If your document contains more than five figures, put a List of Figures after the Table of Contents. Figures include illustrations, sketches, photographs, graphs, charts, and maps. The list should contain the figure number, the figure title, and the page number on which the figure appears. NOTE: Consecutively number the figures throughout the report using Arabic numerals (Figure 1, Figure 2). See Appendix L for a sample List of Figures.
List of Tables
If your document contains more than five tables, put a List of Tables after the List of Figures. If there is no List of Figures, put it after the Table of Contents. The list should include the table number, the table title, and the page number on which the table is found. NOTE: Consecutively number the tables throughout the report using Arabic numerals (Table 1, Table 2). See Appendix L for a sample List of Tables.
240
24.2.4
Executive summary
An executive summary encapsulates in one page the main points of the report so that executives and managers can read it quickly to make administrative and budgeting decisions without reading all of the detail in the body of the report. An executive summary typically contains: 1. A title that labels it an executive summary 2. A brief statement of the problem that led to the project, including reference to the client (one or two sentences) 3. A brief statement of the purpose and scope of the project (one or two sentences). NOTE: If the project was funded by an outside grant, indicate that in this part of the executive summary. 4. A brief description of the methodology used to develop the design: interviews, user testing, performance testing, etc. (one or two sentences). Avoid mentioning steps that are common to all design projects, such as brainstorming, design reviews, and analysis of competitive products. Instead, focus on the steps that distinguish your project from others, such as your specific methods of testing mockups and obtaining information from experts. 5. A summary of the design and its benefits. This is the most important part of the executive summary and should describe the designs major features and benefits. You may briefly describe each feature and concisely state the major benefits of the design. Alternatively, you may describe the major requirements and explain how the key features fulfill each of them. You may present this summary as a table or in short paragraphs. You may also include a photo or drawing of your design. 6. If applicable, a brief statement (one or two sentences) of significant limitations of the design The executive summary should be written after you write the rest of the report so that you know exactly what to include and can even borrow sentences and perhaps a figure from the report. The executive summary appears after the table of contents (or list of figures and list of tables, if they are included), and should be written to stand on its own so it can be read independently of the report. It is NOT an introduction and therefore should not contain statements such as, as the report will explain or see Appendix 4 for more detail. (Similarly, the report should be written so that it can be read independently of the executive summary; the report will need a separate introduction.) Those who read an executive summary may not be experts in your engineering field, so you should write it in clear, relatively non-technical language. Appendix M contains an example of an executive summary.
241
24.2.5
Body (text of the report)
The body of the report presents the design problem and your solution in a way that persuades the client that the design meets all stakeholder needs. The body of the report starts on the page following the executive summary and usually consists of the following parts. Naturally, the report should appropriately reflect the project, so if your project does not lend itself to this structure, talk to your instructors about alternative ways of organizing the report. Introduction that summarizes the problem and the reports purpose Major users and requirements Design concept Design rationale Design limitations Conclusion
Each of these sections is described below.
Introduction
The introduction briefly summarizes the problem and solution, states the purpose of the report, and lists its main sections. If the client is not the only person in the organization who will read the report, then you may need to explain the problem in greater detail. Write the introduction as if it will be the first thing readers read; do not assume they have read the executive summary. See Appendix N for examples of effective introductions.
Users and requirements

This section explains the major users and requirements, and how you determined that meeting the requirements was essential to the success of the design. It isnt necessary to detail each stakeholder group and need because the complete list is contained in your project definition. For that detail, you can refer readers to the appropriate appendix.
Design concept
This is the heart of your report, the section that will be of greatest interest to your readers. That is why you describe your design and explain how it works rather than giving readers a narrative about the design process you followed to get to this point. Below are guidelines for explaining your design clearly. NOTE: Your prototype is not, in most cases, identical to your design; it illustrates key features and functions of the design. In writing this section, therefore, describe your design concept, not just your prototype. Use pictures of the prototype only to illustrate the design.
242
1. Begin with an overview of the design. Explain the designs overall appearance or main function (what is it? A device? A plan? A system?), list its major features, and briefly describe how it works. Use one or more illustrations. End with a brief paragraph listing the sections that will follow. 2. Present design subsystems and features using words, numbers, and pictures. The sections that follow the overview should combine verbal descriptions and illustrations of each feature. When describing features, include weight, dimensions, and other numerical specifications where appropriate to show readers that you have been attentive, as engineers, to the finer details of the design. 3. Organize the subsystems and features logically. The order in which you present them may be from most to least important; in the order in which the user interacts with them; from top to bottom or vice versa; etc.
Design rationale
In this section, you persuade readers that your design is based on sound research and will indeed solve the problem. Again, avoid a chronological discussion of the process you followed. Instead, organize the discussion around the major decisions you made: general approach, key features, materials, etc. Support those decisions using the results from your research and testing. Here is an example from a team working on a project to design a low-cost solar water heater to be built and installed during the construction of homes in the Dominican Republic (Millea, Nieman, Suszko & Wroblewski, 2003). To support its general approach of using thermosiphon heating, the team drew on its email correspondence with an expert on solar energy and research from an authoritative manual on solar heater design:
Example 24.1: Supporting the design approach with authoritative research Thermosiphon heating, upon which our system is based, has been shown to be ideal in meeting the requirements our design must satisfy: simplicity, reliability, and adaptability. In email correspondence with us, John Harrison, senior research analyst for the Florida Solar Energy Center, wrote, [T]hermosiphon heaters would be perfect for that area [Dominican Republic]. Actually, thermosiphons are by far the most common systems outside of the US. A thermosiphon system is simple, reliable, and can be made of materials that are perhaps locally available (2003). In How to Build a Solar Water Heater, D.A. Sinson, a McGill University engineering professor, states, The unit described [thermosiphon] has been designed to incorporate low cost materials generally available, even in relatively remote parts of the world (1965). Those who build the system do not need special training or expertise; it can be built by inexperienced volunteers and can be adapted to the environment where it is needed most.
243
In the following example, the team draws on performance testing results to support its decision to combine black rubber hose with an acrylic-roofed box to heat water quickly:
Example 24.2: Supporting design features with performance test results A major advantage of the device is its efficiency in heating water quickly. Our tests on heating devices showed that on a partly cloudy 60 F day, a simple black rubber hose can heat water from 62 to 116 in two hours (See Appendix F: Test Results, Phase 1). The heating effectiveness of the hose greatly increased when it was placed in the design's acrylicroofed box; water temperature rose from 61 to 132 in two hours. Based on linear models, the system would heat water to just over 150 F when the air temperature is 110 F (See Appendix G: Test Results, Phase 2).
The next example draws on results from both user and performance testing to support the choice of a particular feature. The project was to design an apparatus to allow individuals with limited wrist and hand strength, due to spinal cord injury, to drink directly from a variety of beverage containers.
Example 24.3: Supporting design features with user and performance test results Container Strap: The beverage rests inside of the container strap. A rubber pad and foam insulation covered with Dycem securely hold the beverage container in place after the container strap is tightened with a D-ring. User testing revealed that users were able to operate the D-ring easily (see Appendix E). Dycema non-slip, non-adhesive materialhas been used with great success at the Rehabilitation Institute of Chicago for its clients who have difficulty gripping objects. Performance testing demonstrated that the strap can securely hold up to 20 lbs and has a surface area large enough to hold an Arizona Iced Tea can, which is quite large, securely (see Appendix F).
Design limitations
As stated in Chapter 10, Concluding Conceptual Design, few DTC projects culminate in a fully functional product. More commonly, they offer a prototype and detailed drawings. Teams do not have time to test the functionality of all the features to be sure the design will work as expected. Moreover, the design may not address all the requirements. As responsible engineers, you should, therefore, make clear to your readers what the designs limitations are and how they might be addressed. See Appendix O for an example of how one team discussed the limitations of their design.
244
Conclusion
The body of your report should conclude by summarizing how your design meets the requirements, as in the following example (Millea, et al., 2003).
Example 24.4: Effective summary of design features in relation to requirements (1) To summarize, our design meets the key needs of families who will use the system and volunteers who will install it. The design uses a combination of: a commercial-grade rubber hose capable of transporting water up to 180 F PVC-coated copper piping that transports water at temperatures up to 180 F without significant heat loss a 3/8" acrylic sheet that uses the greenhouse effect to heat water
Families also need a system that is safe. Our anti-scald valve prevents injury from burns. Finally, families need a design thats simple to maintain and fix. Our water heater fills the bill because it uses no pumps, batteries, or electricity. Volunteers want a simple system that does not require rigid building specifications or hard-to-find materials. Unskilled volunteer carpenters can easily construct this system for under $820 in a matter of hours.
References
Your report must include a complete list of references of all the books, articles, websites, and interviews youve used to explain your problem and your rationale. This list appears at the end of the body of the report, but before the appendices. See Chapter 26 for more detail on documenting sources. NOTE: If the project was funded by an outside grant, indicate that above the list of references.
Appendices
Most reports require appendices that support or supplement information in the body of the document. They are useful for the following kinds of information, which some readers will want to examine in detail. For example, if your client wants to build your design, he will refer not only to your instructions but to the Bill of Materials to find vendor names and materials needed. If he wants to have more work done on the design, he may need to see what performance testing you have done and decide whether more testing is needed.
245
Useful appendices: Project definition: This is generally the first appendix. Its major purpose is to show that your design adequately addresses the requirements and specifications. Use it to double-check that your design DOES actually meet all requirements and specifications. Your design and project definition must be complementary. User observation results User testing results Performance testing results Expert interview results Background research (e.g., analysis of competitive products) Bill of Materials Instructions for building and using the prototype
Do NOT use an appendix as a dumping ground for everything you did on the project. You are writing for a real audience, whose time and attention are limited. You are not trying to impress your client or professors with bulk. Therefore, include only the material your readers might find useful in understanding and validating your design process, or in implementing your design. You do not, for example, need to include class work, such as your list of brainstormed ideas. Conversely, be careful not to bury important supporting data and illustrations in the appendix; these belong in the body of the reportbecause most readers wont read the appendices (and the body of the report should make a persuasive argument on its own). When determining where to put information, assume readers will not refer to the appendix the first time they read the document. Inexperienced writers often have no idea how frustrating it can be to readers if reports are poorly organized, incomplete, or incorrectly numbered. Below are some guidelines for structuring and organizing appendices. Put only one kind of information in each appendix so readers can find information easily. Arrange appendices in the order in which you refer to them in the text. Label them sequentially: Appendix A, Appendix B, etc. Begin each appendix on a new page and give it a descriptive heading: Appendix C: Summary of User Test Results. Refer to each appendix at least once in the body of the text. Consecutively number the pages of the appendices, continuing the pagination from the body of the document. List the title and beginning page number of each appendix in the Table of Contents.
246
Begin each appendix with a brief introduction explaining what the information means and how you obtained it. For example, the introduction to an appendix that presents a table summarizing the results of your user testing should explain what the table is, how the test was conducted, and what the headings and numerical values mean. An appendix must stand on its own, meaning readers must be able to understand its purpose and results without referring to the body of the report.
While it is tedious and time-consuming to order and label all of your appendices properly, the effort is worth it. Poorly handled appendices greatly undercut a reports credibility.
24.3 WRITING STYLE FOR A FINAL REPORT

A good design report is written in a professional style so that all of its ideas are clear and unambiguous and the report itself underscores your argument by being attractive and correct in all its detail. Naturally, if you have an inadequate design that fails to meet your design requirements or cant be justified by research and testing, then no amount of good writing and pretty pictures will turn your material into a good report. But the opposite isnt true. If you have a good design that you cant adequately explain or justify, your client wont understand it; and if you submit a report that has interesting content but contains grammatical errors or typos, your client will begin to doubt your reasoning and question your attention to detail. To write a good report, follow the guidelines for page design, visual communication, documentation, and revising for clarity and conciseness in the rest of this book (see especially chapters 6, 21, 22, 25, and 26).
247
24.4 REFERENCES
Cooper, J., Huffman, G., Kolodner, B. & Peng, J. (2007). Screen N Flush. Engineering Design and Communication, Northwestern University. Donahue, K., Galfi, R., Sileika, T. (2006). Grip&Sip: final design report. Engineering Design and Communication, Northwestern University. Long, A., Rein, J., Smith, A. & Smith, L. (2006). Glowcrete: a thin layer approach to the development of self-illuminating concrete. Engineering Design and Communication, Northwestern University. Millea, J., Nieman, E., Suszko, D. & Wroblewski, N. (2003). Everything under the sun: a simple approach to solar water heating. Engineering Design and Communication, Northwestern University. Tsuruta, F., Wong, C. & Wuisan, G. (2004). Pope John XXIII school library design. Engineering Design and Communication, Northwestern University.
248
Chapter 25: Revising for Clarity, Conciseness, and Correctness
CHAPTER 25: REVISING FOR CLARITY, CONCISENESS, AND CORRECTNESS
Chapter outline
Revising paragraphs for clarity and coherence Revising sentences for clarity Revising sentences for conciseness Editing for correctness
Key guidelines for revising for clarity, conciseness, and correctness

Begin each paragraph with a topic sentence that summarizes its main point Break up long paragraphs Include transition words within paragraphs to clarify the flow of ideas Replace vague wording with precise language and specific data Make sentences clear and concise by choosing active over passive verbs Eliminate redundant and unnecessary words
Engineers must at all costs avoid confusion and vagueness in their writing, because unclear writing can lead to costly, even disastrous, mistakes. Ultimately, writing clearly means paying attention to details like paragraphs and sentences. Paragraphs are the main organizational unit for writing, and readers tend to skim paragraphs to find main ideas. As a result, paragraphs need to be well structured so that main ideas appear early, in topic sentences, and all details in the paragraph support the key point. Similarly, sentences need to be well structured so that readers can easily find key points and act correctly on the information presented. In addition, engineers must write concisely, not only because readers are busy and want to get the information quickly, but because wordiness can obscure meaning and, as with vagueness, lead to mistakes. This kind of writing is like detailed design in the design process, getting down to a level of precision and accuracy that may not be present in earlier stages.
249
Revising for clarity and conciseness is a huge topic, so this book cannot offer comprehensive advice in these areas. In this chapter, however, we present important ideas about the professional writing style you should use in documents related to design, and techniques for revising and editing to achieve clarity, conciseness, and correctness.
25.1 REVISING PARAGRAPHS FOR CLARITY AND COHERENCE

Well-written paragraphs allow readers to identify main points easily, understand the reasons behind those points, and assimilate the information. In the following sections, you will learn how to make sure that each paragraph has a strong topic sentence (usually the first sentence in the paragraph) and that sentences clearly relate to one another and to the topic sentence.
25.1.1 Topic sentences

The purpose of the topic sentence is to state the main point. Its the most important part of the paragraph because readers are likely to pay the most attention to it; in fact, they may merely skim the rest of the paragraph. Therefore, you should evaluate the opening sentence of each paragraph by asking: Does it state a single main point? Does it state the main point specifically and concisely? Does it capture the essence of the paragraph? With these questions in mind, you might do one or more of the following to improve the topic sentence: add a topic sentence to the paragraph revise the topic sentence to make it more specific make the topic sentence and body of the paragraph consistent with one another break a long paragraph into shorter paragraphs and add a topic sentence to each
Each type of revision is discussed below. 1. Adding a topic sentence. Sometimes youll come across a paragraph you have written that lacks a topic sentence. You may have become so bogged down in details that you didnt figure out the main point, or you may have been thinking of a topic sentence but neglected to write it down.
Example 25.1: Rough draft of a paragraph with no topic sentence User testing proved to be of less help than we had hoped in making the three design alternatives because there was a statistically insignificant spread among user preferences. After speaking with our client, we decided to focus on alterna-
250
tive onethe three-compartment storagedue to its versatility and ease of use. Our client strongly believes that of all the alternatives, the three-compartment design allows users to adapt the design most easily to their individual storage needs.
The first sentence doesnt state the main point of the paragraphthe decision to focus on alternative oneand so is not a topic sentence. Here is a revision:
Example 25.2: Revised paragraph with a topic sentence We have decided to focus on alternative onethe three-compartment storagefor our final design direction on the basis of client, rather than user, input. User testing proved to be of less help than we had hoped in deciding among the three design alternatives because there was a statistically insignificant spread among user preferences. After speaking with our client, we decided to focus on alternative one due to its versatility and ease of use. Our client strongly believes that of the three alternatives, the three-compartment design allows users to adapt the design most easily to their individual storage needs.
The topic sentence mentions client and user input, and nicely sums up the ideas in the paragraph. 2. Revising the topic sentence for clarity. You might find some paragraphs with vague topic sentences that fail to state the main point in specific enough terms. The topic sentence in the following rough draft suffers from that problem; it says that the team will continue its progress but not precisely how they will do so:
Example 25.3: Rough draft of a paragraph with a vague topic sentence In the next two weeks we will continue our progress. We plan on brainstorming, setting criteria to evaluate our brainstormed ideas, and developing at least three design alternatives. We will then mock up these alternatives in foamcore and test them on users in our target groupchildren between the ages of 5 and 12.
Following is a revised topic sentence that replaces the vague phrase continue our progress by stating specifically what the team intends to do.
Example 25.4: revised paragraph with a specific topic sentence In the next two weeks, we will generate alternatives and build mockups that we can test. We plan on brainstorming, setting criteria to evaluate our brainstormed ideas, and developing at
251
least three design alternatives. We will then mock up these alternatives in foamcore and test them on users in our target groupchildren between the ages of 5 and 12.
3. Revising the topic sentence and the body of the paragraph. Occasionally you will need to revise both the topic sentence and the body of the paragraph to make them consistent with one another. Here is an example of a rough draft in which the topic sentence and the rest of the paragraph are inconsistent:
Example 25.5: Rough draft that requires editing of the topic sentence and the body of the paragraph To keep costs down, we have chosen Velcro straps to secure the compartments. Velcro is easy to use and durable. Our user observations show that children can easily use Velcro straps to secure and open the compartments. In addition, there are a number of types of Velcro designed for the heavy use the compartments will receive.
The topic sentence mentions cost, but the body of the paragraph doesnt. Also, the body of the paragraph mentions usability, but the topic sentence does not. The ideas were connected in the writers mind, but werent expressed in the paragraph. Therefore, both elements of the paragraph need revision:
Example 25.6: Revision with consistent topic sentence and body of the paragraph To keep costs down without sacrificing usability, we have chosen Velcro straps to secure the compartments. Our research revealed that Velcro would cost 75 percent to 90 percent less than our two alternative methods. Furthermore, Velcro is easy to use and durable: Our user observations show that children can easily use Velcro straps to secure and open the compartments. In addition, there are a number of types of Velcro designed for the heavy use the compartments will receive.
4. Breaking up long paragraphs that contain more than one point, and giving each one a topic sentence. Often, long paragraphs need to be broken up because they contain more than one main point. Heres a rough draft of a long paragraph:
Example 25.7: Rough draft of a long paragraph with more than one main point The storage case will be made of a durable, weather-resistant, slightly flexible plastic called thermoplastic elastomer. It is the same material used to make the soles of athletic shoes and is meant to perform well under high-impact conditions. It has also proven to stand up well to rain, snow, and extremely
252
high and low temperatures (see Appendix D). The plastic walls of the case will be 1 inch thick so the contents will not be damaged by impacts to the case. Because the material is flexible, it will not dent as metal will. The dimensions of the case are 12 inches wide, 10 inches high, and 7 inches deep. These dimensions allow the case to fit into the required space and to hold the kinds of objects specified by users. A lock makes the case theft-resistant. We have contacted a manufacturer of the thermoplastic elastomer and learned that the lock mechanism can easily be installed in a case made of this material (see Appendix E).
This topic sentence leads readers to believe that the paragraph is about the benefits of the plastic used for the case. But the body of the paragraph also makes important points about the dimensions and lock. The revision below divides the information into several paragraphs each with its own main point and topic sentence:
Example 25.8: Each paragraph has its own main point and topic sentence The storage case will be made of a durable, weather-resistant, slightly flexible plastic called thermoplastic elastomer. It is the same material used to make the soles of athletic shoes and is meant to perform well under high-impact conditions. It has also proven to stand up well to rain, snow, and extremely high and low temperatures (see Appendix D). Finally, because the material is flexible, it will not dent as metal will. The dimensions of the case will make it user friendly and durable. The cases measurements are 12 inches wide, 10 inches high, and 7 inches deep. These dimensions allow the case to fit into the required space and to hold the kinds of objects specified by users. The plastic walls will be 1 inch thick so the contents will not be damaged by impacts to the case. A lock makes the case theft-resistant. We have contacted a manufacturer of the thermoplastic elastomer and learned that the lock mechanism can easily be installed in a case made of this material (see Appendix E).
The three shorter paragraphs are not only easier to read, and more visually appealing on the page, but they mesh more effectively with the way that people read and notice information: people notice and best remember information that appears at the beginning of something.
25.1.2 Flow of ideas within paragraphs

Technical documents often contain a lot of information in each paragraph, making it easy to lose your reader. The solution to this problem is to relate
253
each sentence to the topic sentence or to the previous sentence. In doing so, you make your writing flow. For example, if you write a topic sentence that says the paragraph is about research results, you should clearly state results or make a point about results in each succeeding sentence. You should also use transitional words and phrases between sentences and paragraphs to highlight the logical connections. Table 25.1 lists some transitional words:
Table 25.1: Transition words and phrases Transition categories

Adding to Showing sequence Contrasting Showing cause and effect Providing examples Showing similarity
Transition words
also, furthermore, in addition, moreover then, next, after, finally, first/second/third, one/two/three however, nevertheless, in contrast, on the other hand therefore, as a result, consequently, thus, for this reason for instance, for example similarly, likewise
As you edit paragraphs for logical flow of ideas, dont just add these transitional words indiscriminately. Instead, think first about how all the sentences in the paragraph relate to each other, and then edit to clarify these relationships. In the rough draft paragraph below, its difficult to determine the relationships among the facts:
Example 25.9: Rough draft of a paragraph that lacks a logical flow of ideas After our research revealed the magnitude of this project, we took steps to determine whether it would still be within our client's budget. We consulted with a manufacturer and two retailers. We learned that the estimated price of materials and construction would range from $6,000 to $8,000. We were advised by our professors to meet with our client as soon as possible to determine where we should go with this project. We were informed that our client would not go forward with our current design approach.
There are two major problems with the flow of ideas in this paragraph. First, the topic sentence states that the team took steps, but some of the later sentences do not indicate the steps that were taken. For example, the team says they were advised by professors to do something, but thats a step that their professors, not they, took. Second, the sentences do not always relate to one another: In the last two sentences, did the professors tell the team that they should meet with the client and that the client would not want to go forward
254
with the current approach? Or, after talking to their professors, did the team go to the client and learn from him that they should not go forward with their approach? Without transitions, the paragraph is unclear and choppy. The following revision corrects these problems:
Example 25.10: Revised paragraph with a clear flow of ideas After our research revealed the magnitude of this project, we took steps to determine whether it would still be within our client's budget. First, we consulted with a manufacturer and two retailers, and learned that the estimated price of materials and construction would range from $6,000 to $8,000. Then we solicited advice from our professors, who recommended that we meet with our client as soon as possible to determine where we should go with this project. Finally, we met with our client, who told us not to go forward with our current design approach.
In the rough draft below, the relationship of the sentences to one another also is unclear. The teams intention in this paragraph was to make a case for their design by citing three advantageous features. But because they didnt state that intention, or use transitional words, their point is unclear.
Example 25.11: Rough draft of a paragraph with unclear sentence flow The swivel-grip design allows for a simple, intuitive clamping motion to attach the light to any support bar. The clamping motion requires very little hand movement, and can be completed quickly. Unlike the existing design, the swivel-grip adjusts easily to whatever diameter the support bar may be. In tests of the prototype, users were able to attach the swivel grip to bars of varying diameters in approximately one second. The shape of the swivel-grip makes its use intuitive. Users were able to attach the prototype without any instruction or prompting from us.
In the following revision, the team clarifies its point by stating the paragraphs purpose and using transitional words:
Example 25.12: Revision with clear transitions The swivel-grip design allows for a simple, intuitive clamping motion to attach the light to any support bar. Three features account for the designs ease of use. First, because the clamping motion requires very little hand movement, it can be completed quickly. Second, unlike the existing design, the swivel-grip adjusts easily to whatever diameter the support bar may be. In tests of the prototype, users were able to attach the swivel grip to bars of varying diameters in approximately one second. Third, the shape of the swivel-grip makes
255
its use intuitive. Users were able to attach the prototype without any instruction or prompting from us.
25.2 REVISING SENTENCES FOR CLARITY

Even if a paragraph is well structured, vague wording or overly long or complicated sentences can confuse readers and make them doubt your credibility. Consider the following rough draft paragraph from a final report intended for a client:
Example 25.13: Rough draft of a vague paragraph The ramp will be reasonably safe. Sheeting with an extremely high coefficient of friction will cover it, making it rather difficult for a wheelchair to slip while ascending or descending the ramp. Although less expensive sheeting with a lower coefficient of friction could have been used, this seemed ideal to address the needs. In addition, our expert interviews appeared to support it strongly. We did tests under very wet conditions and it performed really well.
Not only is this paragraph worded vaguely, but it will make the client question the safety of the design. What does reasonably safe mean? How is it safe? What exactly is the coefficient of friction? What coefficient of friction is recommended for wheelchair ramps? What does rather difficult to slip mean will wheelchairs slip under certain conditions? What is the difference in cost between the two types of sheeting? In the phrase this seemed ideal to address the needs, what is this, why does the sheeting only seem ideal, and whose needs will be addressed? Which experts were consulted? What were their credentials? How were the tests performed and what were the results? The vague wording in the paragraph falls into the following categories. Note that the precise revisions often require more words, but that does not make them wordy. Wordiness refers to writing that is longer than necessary, not to extra words that clarify your meaning. 1. Vague modifiers: reasonably safe, extremely, rather, difficult, ideal, very, really, well. Eliminate vague modifiers or replace them with precise ones:
Example 25.14: Eliminating vague modifiers
Vague The ramp will be reasonably safe. Clear The ramp will keep wheelchairs from slipping in rain or snow.
256
2. Vague verbs: could have, seemed, appeared. Replace vague verbs with precise ones:
Example 25.15: Eliminating vague verbs
Vague Our expert interviews appeared to support it strongly. Clear Our expert interviews supported it strongly.
3. Vague pronouns: this, it. Use specific words to avoid ambiguity:

Example 25.16: Eliminating vague pronouns
Vague Our expert interviews supported it. Clear Our expert interviews confirmed that the sheeting would prevent wheelchairs from slipping on a wet ramp.
4. Vague references to research methodology. State who you interviewed, how you tested, etc.
Example 25.17: Eliminating vague references to methodology
Vague Our expert interviews Precise We interviewed two professors in Northwestern Universitys Department of Materials Sciences (see References page).
We did tests under very wet condi- We covered a mockup of the ramp tions with the sheeting and sprayed it . with a hose for 15 minutes. Then a team member went up and down the ramp in a manual wheelchair.
5. Vague references to research results. As with research methodology, state the results precisely:
Example 25.18: Vague references to results
Vague It performed really well . Precise The team member ascended and descended the ramp three times without the wheelchair slipping at any point.
257
6. Unquantified measurements and values. Quantify information whenever you can to establish credibility:
Example 25.19: Adding clear quantities
Vague less expensive sheeting Precise less expensive sheeting ($2.50 per sq. ft. as opposed to $4.50 per sq. ft.)
Here is a revision that eliminates vague language from the paragraph in Example 25.13:
Example 25.20: Revised paragraph using precise wording and details Covering the ramp in sheeting keeps wheelchairs from slipping in rain or snow. The sheeting we used is a 20 mesh minus crumb rubber with urethane binders (see Appendix F). The sheetings high coefficient of friction (0.8) prevents wheelchairs from slipping while ascending or descending the ramp even in wet conditions. Although we could have used less expensive rubber ($2.50 per sq. ft. as opposed to $4.50 per sq. ft.) with a coefficient of friction of 0.6, we chose to use sheeting that conforms to the ADA recommended coefficient of 0.8. Interviews with two Northwestern University professors in the Department of Materials Science confirmed that this sheeting will ensure the safety of users. In addition, our own tests of the material demonstrated its non-slip qualities. We covered a mockup of the ramp with the sheeting and sprayed it with a hose for 15 minutes. Then a team member went up and down the ramp three times in a manual wheelchair. The wheelchair did not slip at any point.
The precise language and quantified detail in this paragraph make it clear and persuasive.
25.3 REVISING SENTENCES FOR CONCISENESS

Wordiness in engineering reports and memos also obscures meaning and slows down the reader. The following rough draft is wordy because it uses more words than necessary to communicate its information:
Example 25.21: Rough draft of a wordy paragraph A total of four design alternatives have been generated by us, and now that the process of their being tested on users has begun in earnest, important and significant information is
258
being learned by our team about which features the users we are concerned with do favor and do not favor. Another piece of crucial information that has been revealed by the testing is the fact that there is great concern among users about the safety of the storage unit. This is interpreted by us to mean not that the current unit is unsafe for users but that the unit designed by us must be at least as safe and, what would be even more preferable, safer for those users. It is for this reason that we intend and plan to incorporate into the unit a feature that completely prevents the lid from collapsing at all when items are being retrieved by users from the interior of the storage unit.
The unnecessary verbiage forces readers to pore over the sentences to uncover their meaning. Here is an edited version:
Example 25.22: Revised paragraph that is concise and clear We have generated four design alternatives and begun testing them on users. These test have revealed which features users like and dislike. Testing also has revealed that users are concerned about the safety of the storage unit. We believe this means not that the current unit is unsafe, but that our design must be at least as safe if not safer. For this reason, we plan to incorporate a feature that prevents the lid from collapsing when users retrieve items from the storage unit.
The revision illustrates two principles for editing wordy sentences: choose active over passive verbs eliminate redundant and unnecessary words
Each principle is discussed below.
25.3.1 Choose active over passive verbs

Active verbs, as their name implies, state actions: implement, purchase, gather, brainstorm, use, test. In a sentence with an active verb, the subject performs the action stated by the verb: Our team (subject) built (verb) three mockups. In sentences with passive verbs, the subject receives the action stated by the verb: Three mockups were built by our team. A comparison of the two sentences illustrates why passive verbs lead to wordiness:
Three mockups were built by our team. Our team built three mockups.
The sentence with the active verb has five words; the sentence with the passive verb has seven. Sometimes writers in engineering and science avoid active verbs because theyre trying to avoid personal pronouns; they may
259
believe theyve said we or our team too often. However, many things other than people can do an action in a sentence. For example, data can indicate, testing can show, an analysis can demonstrate. Use Grammar Check on your word processing software to find passive verbs and decide whether you can replace them with active verbs that clarify who or what is performing an important action. Similarly, use your software to search for forms of the verb to be (is, are, am, be, was, were, being, been), followed by a past tense verb or forms of to be that appear in stretcher phrases like it is, there are, there were, and there will be. The following examples show how to change these wordy constructions into concise active ones:
Example 25.23: Avoiding it is and there is
Wordy It was apparent to us why users did not like that feature. There is a crucial flaw in the design. Concise and active We realized why users did not like that feature. The design has a crucial flaw.
This chart shows how to replace wordy, passive and weak verbs with concise, active verbs:
Example 25.24: Eliminating passive or weak verbs
Passive A total of four design alternatives have been generated by us. The process of their being tested on users has begun. Significant information is being learned by our team. Another piece of crucial information that has been revealed by the testing is There is concern among users about the safety of the storage unit. This is interpreted by us to mean It is for this reason that we intend When items are being retrieved by users Active We have generated four design alternatives. We have begun testing them on users. Our team is learning significant information. The testing has revealed another crucial piece of information. Users expressed concern about the safety of the storage unit. We interpret this to mean For this reason, we intend When users retrieve items
We dont mean to suggest you should never use passive verbs. In the following circumstances, passive verbs are effective because they help to place the emphasis in the right place or they promote coherence and clarity:
260
To emphasize an action or result rather than who performed it: A force of 100 pounds per square inch was applied to the mockup. To start the sentence with the most important element: The lid is securely attached with four bolts. To connect a sentence to the previous sentence by continuing to focus on the topic youve just mentioned: We used four different brands of paper towels to wipe up the liquid. Since the liquid was absorbed at an equal rate by three of the brands, we assumed that any of these would work for our experiment. in this case its acceptable to use passive voice because youre using it to connect the beginning of a new sentence to the end of the previous sentence.
25.3.2 Eliminate redundant or unnecessary words

Another way to eliminate wordiness is to make yourself aware of the most common wordy constructions and get rid of them. 1. Redundant modifiers. In each of the following cases, the modifier can be cut without changing the meaning of the sentence. Thus, the modifier is unnecessary or redundant.
Example 25.25: Eliminating redundant modifiers
Wordy A total of four design alternatives has begun in earnest completely prevents makes total sense Concise Four design alternatives has begun prevents makes sense
2. A series of two or more words that have the same meaning. If you use two or more nouns, adjectives, verbs, or adverbs in a row, be sure they have significantly different meanings. If they dont, choose the one that best conveys your meaning and omit the others:
Example 25.26: Eliminating words from a series
Wordy important and significant information we intend and plan Concise important information [or significant information] we plan [or intend]
261
3. Repeated words. Instead of looking for a synonym to a repeated word, omit it:
Example 25.27: Omitting repeated words
Wordy do favor and do not favor we plan to incorporate into the unit a feature that prevents the lid from collapsing when users retrieve items from the storage unit Concise do and do not favor we plan to incorporate a feature that prevents the lid from collapsing when users retrieve items from the storage unit
4. Unnecessarily long phrases. These may be harder to spot than other kinds of wordiness:
Example 25.28: Eliminating long phrases
Wordy we have begun the process of testing them on users must be at least as safe and, what would be even more preferable, safer Concise we have begun testing them on users must be at least as safe if not safer
Revising for clarity and conciseness can be difficult because the original versions may not seem wordy to you. You wrote the sentences and know exactly what they are supposed to mean. Using the techniques suggested above can help you identify vague and wordy sentences. You should also have teammates look at your draft and offer editing advice.
25.4 EDITING FOR CORRECTNESS

Revising and editing are two different procedures. Once youre satisfied with your written textand youve revised it for clarity and concisenessyou still need to edit it to give it a professional finish. This means proofreading to find errors in grammar, spelling, and punctuation. It also means checking headings and font styles for consistency, and section and appendix numbers for accuracy. While a spell-checker is immensely helpful for final editing, you cannot rely on it completely because it cannot differentiate between similar words that are spelled correctly but have different meanings. Are you designing an exercise apparatus to strengthen users mussels or muscles? When youve written its, do you really mean it is, or did you mistakenly add an apostrophe when referring to its dimensions? Mistakes like these, while minor in many ways, can undermine your credibility. Readers are likely to think that if you were careless about final editing in your report or your presentation slides, you may have been equally careless in your design calculations. They will be
262
especially frustrated if they try to check one of your references only to find that the information didnt come from the website in your reference list, or if they refer to one of your appendices looking for specific information only to find that your appendices are misnumbered. Proofreading for grammar and punctuation are equally important. In design reports, the most common grammatical problems involve pronouns that lack antecedents and faulty parallelism in lists. As you proofread, make sure that every it or which or this refers to a specific noun that precedes it. Similarly, check items in every list for parallel structure so that the list wont be confusing. See Chapter 21 (section 21.1.3) for a discussion of parallelism in lists. The most common punctuation problem is the comma spliceusing a comma instead of a period, to connect two complete sentences. As you proofread, pay special attention to commas. Make sure that all sentences are complete, but no sentences are overly long. If punctuation is difficult for you, try proofreading out loud. Or read with a pencil in your hand to encourage you to focus on each word. Final editing is a tedious task, but one that represents your whole teams work. For this reason, it should be divided among team members who, ideally, proofread and correct sections of the report that they have not written. Moreover, final editing should be done by someone proficient in English, especially if the team has members for whom English is not their first language. It is not cheating to get help with final editingsuch as using Northwesterns Writing Place or asking your instructors for help. Try to finish your writing in time to get this extra help, and be especially scrupulous about prominent parts of your report, like the title page and executive summary, or work that will be on display, like your poster for the DTC project fair.
263
264
Chapter 26: Documenting Sourcesand Avoiding Plagiarism
CHAPTER 26: DOCUMENTING SOURCESAND AVOIDING PLAGIARISM
Chapter outline
When to documentand why Guidelines Reference lists In-text citations Paraphrasing
Key guidelines for documenting sources and avoiding plagiarism

Include a References page that lists all outside sources Use in-text citations to reference ideas, quotations, facts, statistics, and other information from outside sources For in-text citations, include the author's last name or, if no author is given, the first words for that source as listed in the References page
Use quotation marks to indicate that you are quoting verbatim from a source
Documentationor citing your sourcesis a key part of any writing in academia and much professional writing. This chapter explains why and how to document your writing in DTC. Failure to document your work is a serious violation of academic integrity. You can find yourself in troubleand accused of plagiarism and cheatingeven if your failure to document is unintentional. Thus, read this chapter carefully, and discuss any questions you have about documentation with your professors.
26.1 WHEN TO DOCUMENT AND WHY

In writing related to engineering design, as in all academic writing, you need to credit each source you use in your reports, presentations, and essays,
265
whether your information comes from printed material (books, articles, manufacturers literature), websites, lecture notes, interviews, or other sources. Documenting your sources serves several purposes: Makes your writing more credible Helps readers locate information mentioned in your report Demonstrates that you are ethical Avoids serious academic and legal repercussions of using sources without acknowledging themin other words, of plagiarizing
You may be surprised to learn that people want to know how you are building on other peoples ideas and will even respect you more for knowing the literature, that is, what else has been written in an area, rather than looking as if youve developed every idea by yourself (which would be impossible). You may also not realize that in academia you are responsible for giving credit to others ideas even when you dont quote them directly. When you write, youre actually joining a new community, a conversation that has been going on before you entered it and to which you are now contributing. Documentation identifies that conversation and shows what you are using, questioning, and adding to it. If you borrow too much information from your source material, readers will wonder what youre contributing to a paper or report. Your own voiceyour analysis and your ideasneeds to dominate your writing. Whatever you quote or paraphrase should be used to support your ideas. Document your ideas as you go along; do not wait to add your citations after youve written your entire draft. There are several reasons for this. First, if you dont write down your sources as you do your research, take notes, and write your research summaries, you may omit required information that will be hard to find later (and will lead to a waste of time). Second, if you dont add citations as you draft your documents, you may forget what youve quoted and plagiarize material unintentionally. Finally, to give you the most valuable feedback, your instructors need to see which of your ideas are based on research, what kind of research youre doing, and how youre analyzing what you find. Without accurate documentation, they wont be able to assess your work properly and give you helpful advice.
26.2 GUIDELINES FOR DOCUMENTING SOURCES

Documentation consists of two parts: a reference list and citations within your text. Below are guidelines for both.
266
26.2.1 Reference lists

1. Include a reference list at the end of all documents (reports, research summaries, essays, slide presentations) that use information from outside sources. Information needs to be documented regardless of whether you are quoting specific material or paraphrasing information. The list should include all written, interview, and video sources in developing your document. You even need to document your own work if you are drawing on a paper or report you have written and submitted somewhere before. In a college course, it is common practice for instructors to read your reference list to see if youve based your analyses and arguments on impressive, well-chosen, up-to-date information. In many cases, your reference list is like a snapshot of your research. A reference list does not need to include everything youve read for your project; it should include only what youve used. For example, if you refer to a dictionary or encyclopedia to get some general background information that most people know and that youre not using directly in your report, then you should not cite that information. 2. Use the citation format your instructors prefer. Three commonly used formats come from the MLA (Modern Language Association), APA (American Psychological Association), and the IEEE (Institute of Electrical and Electronics Engineers). Appendices Q and R contain details on APA and MLA formats, but only on the most commonly used kinds of sources in DTC. For additional information, good advice can be found online at NuWrite, Northwestern's new online writing resource for students and faculty, and at the Purdue Online Writing Lab site (OWL) at http://owl.english.purdue.edu/. For information on IEEE format, go to: <http://www.ieee.org/publications_standards/publications/authors/ authors_journals.html>. Note that each format has specific rules for formatting a reference list entry. Whichever format you choose, follow those rules exactly because readers from different fields are used to reading reference lists in a conventional way. Here is an example of a short reference list in MLA format and, below that, explanations of some of the items. Note that MLA format no longer requires you to give the URL for electronic sources; you simply include the word Web in the citation.
267
Example 26.1: References list in MLA format References Cooper, Ian. Pick me for NU student affairs vice president. The Daily Northwestern 12 Feb. 2001. Web. 24 June 2003. Marlok Information. 15 Dec. 2002. IPRT Facilities and Engineering, Institute for Physical Research and Technology. Web. 27 June 2003. Millennium Online Security Management Systems. Kaba Ilco Corporation. Web. 27 June 2003. Yarnoff, Charles. Personal Interview. 20 June 2003.
The first three items are online sources: a newspaper article and two websites. Note the following about the references: The newspaper article and the Marlok Information website include two dates: The first one indicates when the material was published; the second tells when it was downloaded by the author of the paper. Neither of the two websites has an author; in such cases, begin with the title of the page that contains the information you have used. If there is no title, begin with the name of the institution or organization sponsoring the site. URLs are not included for the web sources, just the word Web. The list is alphabetized using the first word in the entry. This is the authors last name, if there is an author. The last item is an interview that the author of the paper conducted with Professor Yarnoff.
26.2.2 In-text citations

Within your text, use parenthetical citations for any material that is quoted or paraphrased, and for any facts you have gotten from a specific source. These short citations show readers that your information comes from somewhere else and that they can find the full reference by going to your reference list. Quotations: You are quoting when you use the exact words of your source. Indicate quoted words by putting them in quotation marks (or, for passages longer than three lines, by indenting). Use quotation marks even when youve quoted only a phrase or word from your source. Cite the source using parentheses at the end of the quoted sentence(s), or at the end of the sentence containing the quoted phrase. It is good practice to integrate quotations into your text by indicating their source in an introductory phrase. It is also good practice to divide long quotations or to paraphrase information that can be easily described in your own words.
268
Paraphrases: You are paraphrasing when you use your own words to summarize ideas or information from your source. Do not use quotation marks when you paraphrase; just cite the source using parentheses at the end of the paraphrase. See the following section of this chapter for a full discussion of paraphrasing. Facts: If you get specific facts from a sourcefor example a statistic or other numbercite that source at the end of the sentence containing the fact. It is particularly important to cite facts that your readers may want to verify. Here is an example of a fact from an DTC paper that needs to be cited: Every year, over four million babies are born in the United States; however, nearly seven of every one thousand die within one year of birth (World Health Organization).
Use the same style for parenthetical citations (MLA, APA, or IEEE) that you use for the reference list. Each style has minor differences. For example, MLA style includes the name of the source in a parenthetical reference and, if applicable, the page number. APA style also includes the date of publication. The following section from an analysis of Northwesterns Marlok key system illustrates key guidelines in using parenthetical citations. (See Example 26.1 for the papers reference list.)
Example 26.2: Using MLA style in citations The Marlok key system has two major advantages: First, it offers excellent security by allowing only authorized people to enter specified buildings and rooms. Each authorized person has a key that has been encoded so it can be read by an infrared optical key reader attached to a door memory unit (Marlok Information). If the key reader at a door doesnt recognize a keys code, it means the key holder hasnt been authorized, and the door will not open. The second advantage of the Marlok system is that the university can easily program it and train people to operate it by searching by user name and other identifiers. In addition, door locations pop up quickly on the computer monitor (Millennium). The Marlok system has two major disadvantages: The first is that the infrared reader sometimes fails to recognize the key code when the key is dirty. Professor Charles Yarnoff reports: My key has failed several times, and only after repeated cleanings was I able to open the door. This was especially inconvenient and embarrassing when I was escorting a visiting professor around campus. The second disadvantage, admittedly a selfish one, is that Marloks are programmed to open doors in the dorm where the student lives, but not other dorms. This disadvantage is expressed by a columnist in The Daily Northwestern, who maintains that students want their Marlok keys to get them into all the dorms on campus so they do not have to wait outside in nasty weather (Cooper).
269
Note the following about these parenthetical citations: They list the last name of the author (or the first word[s] of the title when the source doesnt list an author) so the reader can flip to the References page and quickly find the source. The citation of online sources does not include the URL. None of the citations includes page numbers because the citations are from websites. If the websites had page numbers, they would have to be included in the parenthetical citation. Parenthetical citations are placed at the end of sentences that contain quotes, paraphrased material, or source-specific facts. The quotation from Yarnoff is not followed by a parenthetical citation because his name is used in the body of the sentence that introduces the quotation.
26.2.3 Paraphrasing
As mentioned above, paraphrasing involves using your own words to summarize information or ideas from an outside source. When your paraphrase extends beyond one sentence, you need to ensure that readers understand where it begins and ends, since there are no quotation marks to indicate that. At the start of the paraphrase, include the name of the author or title (e.g., "According to Smith" or "According to a recent article in The New York Times"). Note: If you are using APA format for your documentation, you would also include the year in parentheses, e.g., "According to Smith (2008)". The reader will know that your paraphrase begins with the reference to the source and ends with the in-text citation you will put at the conclusion of the paraphrase. Below you'll see a passage from a journal article followed by the correctly done paraphrase of it in a student paper:
Example 26.3: Original passage from a journal article The path taken by the McDonalds and Kroc illustrates three steps of the knowledge funnel process: Pinpointing a market opportunity (Selecting a particular mystery to be solved -what might the impact of post-war mobility be on American eating habits?). Devising an offering for that market (An initial heuristic or "rule-of-thumb" -- Americans want a quick, convenient, tasty meal). Codifying its operations (Converting heuristic to algorithm -- Kroc systematized McDonalds). Example 26.4: Correctly done paraphrase of the passage (MLA format) Roger Martin, Dean of the management school at the University of Toronto, illustrates the knowledge funnel process via the three-stage development of McDonald's: (1) Determining a "market opportunity" by asking how greater mobility would change the way Americans ate. (2) Pursuing that opportunity
270
by developing an appetizing fast-food product. (3) Developing a systematic method of operation (37).
The reference to Roger Martin indicates the start of the paraphrase, and the parenthetical reference to the page number at the conclusion of the paraphrased passage indicates the end. Note, too, that in addition to giving the author's name at the start, the student has mentioned his credentials to lend credibility to the information. The student has also been careful to use quotation marks wherever she used the exact words from the original source, e.g., knowledge funnel process. This method of documenting paraphrased information may be new to you because in the past you may have been told that you merely need to indicate your source at the end of the paraphrase. However, using the method described here is more accurate because it helps readers distinguish your voice and your original thinking from the voice and ideas you are borrowing from others.
271
272
Chapter 27: Oral Design Presentations
CHAPTER 27: ORAL DESIGN PRESENTATIONS
Chapter outline
Preparing the presentation Analyzing purpose and audience Organizing the presentation Making the presentation persuasive Preparing effective slides Effective delivery Using the prototype to communicate your design Managing presentation technology Presenting in a professional way Rehearsing the presentation
Delivering the presentation
Key guidelines for oral design presentations

Minimize the amount of text on each slide, and make the font big enough for people at the back of the room to see Use easy-to-see graphics (photos, drawings, charts) to complement the text Use your prototype to explain and support the design Cite research and test results to support decisions about design features Face the audience while speaking and project your voice Use precise language in your explanations Answer questions non-defensively and clearlywith supporting data Be professional: dress appropriately; introduce and thank your client; make smooth transitions from speaker to speaker; pay attention even when you're not speaking
Good engineers need to be good speakers. They need to identify and explain problems, propose solutions, persuade others to take a particular action, and give reasons for their decisions. Researchers who surveyed over one hundred
273
engineers with an average of fifteen years of experience found that for the individual interested in career advancement, the ability to give a formal presentation is essential (Darling & Dannels, 2003, p. 13). This chapter explains how to plan an effective presentation, including how to make good PowerPoint slides, and then deliver the presentation persuasively and professionally.
27.1 PREPARING THE PRESENTATION

27.1.1 Analyzing purpose and audience
As in planning any type of communication, you should begin by considering what you want to accomplish (your purpose), who you are communicating with, and what that implies for your content and tone. The primary purpose of your spring quarter final presentation is to explain your design and persuade your client that it is an excellent solution to the problem. In that final presentation, your audience will comprise four different groups: 1. your clientand possibly others from your clients organizationwho wants to know how your design solves the problem 2. your instructors, who will evaluate your presentation for clarity, persuasiveness, and professionalism 3. your classmates, who want to see your final design 4. visitors, such as clients of other groups, who know nothing about your project and would like to hear a clear, interesting presentation To present your design clearly and persuasively to this diverse audience, your team will need to work together to deliver a solid group performance. In DTC you will have 30 minutes for your final presentation, the typical length of many business and professional presentations. In the first partno more than 20 minutesyou will describe your design and its benefits. In the remaining time, you will answer questions from the audience.
27.1.2 Organizing the presentation

Final presentations generally follow this order: (1) introduction, (2) agenda, (3) explanation of problem, (4) overview of solution, (5) features, (6) summary, (7) recommendations, (8) conclusion, and (9) Q & A. Sometimes the problem is explained in the introduction and thus precedes the agenda. If the content of your presentation does not lend itself to this outline, talk to your instructors about alternative ways of organizing it. This same advice applies to all the examples in this chapter. Do not use the sample slides and other examples as templates. Instead, adapt them to your content, audience, and purpose.
274
1. Introduction. People typically use one to three slides for their introduction. While your title slide is on the screen, you will introduce your team, project, and client (and other guests). Plan to thank your client for coming. The title slide should include the date and the names of the project, client, team members, and organization (Northwestern University, Design Thinking and Communication). If you want to use a logo for Northwestern, go to the Northwestern University Relations/Publications website to download an authorized version (see References). Finally, if the project was funded by an outside grant, indicate that at the bottom of the title slide. Instead of following your title slide with your agenda, you may decide to introduce your topic by using a detail that will grab your audiences attention. For instance, a team designing a toy grocery store checkout counter to teach children about nutrition might begin with a slide that presents the startling facts about the rise in childhood obesity. While that slide is showing, they might say something like this:
Example 27.1: Capture listeners interest in the introduction There is a silent epidemic occurring in the United States today. It is childhood obesity. In 1964, 10% of children were obese; in 1994, 20%; today, 26%; and some predict, in short time, obesity will rise to 50% unless some changes are made. One partial solution to this crisis is education. The Dolores Kohl Education Foundation is spearheading a drive to educate 4-8 year old children about nutrition. They have asked us to participate in their program by designing an interactive toy grocery story checkout counter that helps children to learn how to recognize nutritious foods.
To accompany this introduction, they might use a slide that presents these startling facts about the rise in childhood obesity. This slide would precede an agenda slide. 2. Agenda. Following this introductory story, state the purpose of your presentation and the major topics it will cover. If you decide to do this on an agenda slide, avoid clichd, generic items such as problem, design overview, features, summary, and next steps, which are boring and not very informative. Instead, use phrases that are specific to your project. For instance, instead of a bullet point reading Problem on the agenda slide, the bullet might read, Why teach young children about nutrition? Instead of Design overview, the agenda item might read, A child-sized grocery checkout counter to teach nutrition basics. If you list the key points in your presentation, organize the list hierarchically (like an outline) so that the audience can see which are the major sections of your presentation and which are subsections. For example, instead of listing User Testing and Performance Testing as two major,
275
equal sections, you could present Testing Results as a major section and then make User Testing and Performance Testing subheadings. An agenda does not need to be a list. Some of the most effective agendas are diagrams, such as flow charts. PowerPoint is a visual media, so you should consider exploiting its capability to present information visually. 3. Explanation of problem. Explain the problem concisely. The following slide uses a photo and concisely worded text to summarize why athletes need a device to stretch their hamstring muscles unassisted (Chikando, Hamzah, Heng & Kryger, 2004):
Figure 27.1: Summarize the design problem
The specific heading is more effective than a simple label like Problem or Challenge, because it immediately gives the audience important information. The team further explained the problem with slides detailing the mission and requirements. In some cases, you might need only to explain the mission statement because it includes the main requirements. If you have several user groups, you might also include a slide that lists them.
276
Figure 27.2: State the mission
Figure 27.3: User needs
4. Overview of solution. Give your audience the big picture of your solution, but dont describe it in detail at this point. You might show your final prototype, or a slide containing a photo or drawing, and comment on the main features. Heres a slide giving an overview of the hamstring stretcher:
277
Figure 27.4: Present an overview of the design
5. Features. Explain all the features of your design and how they satisfy the major requirements. The following slide uses a photo and bullet points to highlight the benefits of one feature of the hamstring stretcher. (The team also used the prototype itself to demonstrate features.)
Figure 27.5: Highlight features and their benefits
Support your claims of the features benefits with evidence from user testing, reasoning, and the opinions of authoritative sources. The hamstring stretcher team used the following slide to demonstrate that users preferred their shoe strap system to two other systems they had tested. This slide is especially effective because it starts with a heading that conveys important information and it uses a good mix of figure and text.
278
Figure 27.6: Support design features with evidence
6. Summary. Use one or more slides that highlight the relationship between features and benefits to summarize how your design satisfies the major requirements. You also might demonstrate the operation of your prototypes key features. 7. Recommendations. Recommend steps to refine, further test, and implement the design. These steps should parallel those explained in the corresponding section of your final report, but you should avoid overemphasizing what others, such as future teams, need to do (see Chapter 24 on Limitations). Of course, if there are no major steps to recommend, you neednt say anything here. 8. Conclusion. End on a positive note by briefly emphasizing the benefits of the design for users and by thanking your client. 9. Q & A. If no hands go up immediately, wait a minute or two for audience members to formulate questions. If there are no questions, politely thank everyone for listening.
27.1.3 Making the presentation persuasive

To persuade your client that your design solves the problem, you will need to present evidence and reasoning to support your claims As mentioned in #5 above, this evidence may come from the authority of experts, the results of testing, or your own analysis. The following slide illustrates the use of expert authority. A team working on a project for the BridgeClimb Tour of Sydney, Australiawhich sponsors a climb of the Sydney Harbour Bridgehad to solve the problem of noisy climbing equipment that bothered area residents (Hertog, Nelson, Ng & Parikh, 2004). To offer persuasive evidence that the equipment creates a bothersome noise, and to identify the type of noise, the team drew on expert authority a consulting firm in Australia. They summarized this authoritative research in this slide:
279
Figure 27.7: Use expert authority to support claims
The next slide illustrates the use of evidence from testing. The BridgeClimb team built a prototype and tested it in a chamber designed to measure noise emissions. The slide compares the noise emissions with and without their prototype.
Figure 27.8: Use test results to support the design
The following slide illustrates the use of sound reasoning to support a design decision (Tsuruta, Wong & Wuisan, 2004). A team designing a new library for an elementary school wanted to support its decision to use rooms 201 and 202 for the library rather than rooms 202 and 203. They reasoned that using rooms 201 and 202 allows for more efficient planning and use of space due to the rooms symmetry and the location of pillars and doorways.
280
Figure 27.9: Use reasoning to support the design
You can also present evidence orally. For example, to support a claim about your design, you might orally summarize the statements of an expert you interviewed. Here is additional advice about being persuasive: 1. Be precise in your oral statements. Turn vague statements into precise, convincing versions, like the ones below:
S
Example 27.2: Turn vague statements into precise ones

Vague We interviewed experts. Precise We interviewed two professors in Northwestern Universitys Department of Industrial Engineering. We tested the mockup with five wheelchair users, all within our target age range of 21 to 55. The ramp will keep wheelchairs from slipping in rain or snow and will bear loads of up to 800 pounds. We estimate that the materials and building costs for the ramp will not exceed $750, as this slide shows.
We tested the mockup with users.
The ramp will be safe.
The cost will be fairly inexpensive.
2. Use talking headlines instead of topics. Talking headlines take advantage of the prominent headline section of a slide to make a point rather than just announce a topic. These headlines can be complete sentences or simply phrases. Figure 27.6 illustrates a sentence used as a talking head-
281
line, and figure 27.9 uses a phrase that talks as it communicates a whole idea. 3. Avoid sounding defensive when your client, instructors, or classmates appear to challenge an aspect of your design during the question and answer session. If your client asks, Wont that feature pose a safety hazard?, dont say, We looked at that and dont see how that can cause any safety problems. Instead, ask the client what specific safety hazards he sees, and then explain point by point how you have designed the feature to minimize those hazards. If you think the client has a valid point you havent considered, recommend that future designers on the project address the issue. 4. Dont apologize for lack of time on the project: Every engineer feels the pressure of the final deadline and wishes there were more time. Instead, take a positive approach: We have verified the feasibility of audio output in our design by interviewing Professor Unsworth of the electrical engineering department at Carnegie-Mellon. To implement the feature, we recommend the following work.
27.1.4 Preparing effective slides

Most DTC teams use PowerPoint slides because theyre a valuable tool in visual communication. As shown in the examples above, good slides help you explain your design, summarize research results, highlight benefits, and present evidence. They help audiences visualize your message, stay on track, and remember key points. Poor slides, however, distract the audience from your message. Therefore, our key advice is: Don't just write slides and slide presentations. Design them with your audience in mind. Below are guidelines for developing good slide presentations.
Guidelines for organizing slides

1. Number of slides. Avoid using more than one slide per minute unless some of your slides are simply pictures that all support the same point. Your slides should support, and not be the subject of, your oral presentation. 2. Logical organization. Divide your material into logical categories and use headlines for clarity. The following series of six slides illustrates logical organization (Cibor, Leung, Santana & Wastell, 2002). They focus on the second product in a two-product solution to the problem of disorganized desk space. The slides start by saying this is the second of the two products, go on to give the teams rationale for the design, and finally focus on the designs four key features. The headlines in the last four slides include the number of the feature.
282
Figure 27.10: Use headlines to signal the presentations organization
283
Guidelines for making slides visually appealing

1. Design template. Pick a design template (background) that enhances the material you are presenting; avoid using a busy template that will distract readers from your graphics and text. PowerPoint offers an array of templates that convey different moods. You can find additional templates online, and even design your own template. Whichever option you choose, make sure the text stands out clearly from the background. For this reason, avoid slides with color gradations that are likely to interfere with your font color. Also, make sure the background is appropriate for your designdont use a template with a law theme for a product for a nursery school. Finally, dont use a background that is too cute for a business audience. 2. Font style. Choose fonts on your computer that are easy to read, such as Arial and Times New Roman. You can use two different fontsone for headlines and one for body textas long as one is a serif font (like Times) and the other is sans serif (like Arial). 3. Font size. Use a font size that is large enough to be read easily: Headlines should be 28 points or larger. Bullet-point fonts should range from the size of your headline down to 18 points (for third-level bullet points). Use fonts no smaller than 18 points, except for material in the slide footer. Use font sizes consistently in your slides. Be aware that fonts used in the text for figures and tables tend to be too small to read. Either reformat the text or eliminate it.
Guidelines on slide text

1. Keep slide text to a minimum. Use key words or brief phrases to highlight points you plan to explain. Remember that a bullet point shouldnt exceed two lines. Heres how one team restructured its mission statement slide to make it easier to read (Cameron, Collins, Rauwerdink & Woodward, 2003).
284
Example 27.3: Wordy mission statement Mission Statement To design a clip to facilitate the process of attaching a bike light to a bicycle and to design a battery containment system to prevent the battery from falling out Example 27.4: Concise mission statement Mission Design: a better mechanism to attach a light to a bicycle a secure battery compartment for the light
Heres how another team whittled down the verbiage on its list of user needs:
Example 27.5: Wordy list of user needs Design a prominent place for brochures and other informational material to be kept for students to pick up Divide the office from the area that students wait in Create enough places for students to sit Have one window for pick-up and one for drop-off Have an overall pleasant and professional-looking environment Create an environment that is comfortable to work in Example 27.6: Concise list of user needs Provide the user with: Prominent spot for informational material Waiting room divided from office Ample seating Separate windows for pick-up and drop-off Pleasant, comfortable, professional environment
2. Use the same grammatical form for all bullet points. Phrase bullet points in a grammatically parallel style, i.e., sentences, verb phrases, or noun phrases.
Example 27.7: Slide with non-parallel list Requirements Must be durable
285
Safety Ease of use Be easy to maintain Example 27.8: Revised slide with parallel list
Requirements Durable Safe Easy to use Easy to maintain
3. Use effective builds to emphasize key points. On a build slide, the slide starts with the first bullet point, and others appear as you mention them. Avoid fly-insbullet points that fly into the slide from above, below, or the sidesbecause they distract from the content. If you are presenting from a figure, your build might include circles or arrows that highlight key areas of the figure as you discuss them. Or you might begin with an overview picture of the whole design and then follow with a series of slides in which each presents a close-up of a key feature.
286
Guidelines on slide graphics

The following slides show how to use graphics to make key points: 1. Highlight the design problem. The slide below uses graphics and minimal text to show how the cap for a bicycle headlight can easily come off and get lost (Cameron et al, 2003).
Problem
Battery cap is easily lost if light is dropped
Figure 27.11: Use graphics to highlight the design problem
2. Highlight the features of your design. The slide below shows how a safety zone improves the way parents drop off and pick up children from the school parking lot. Note the use of arrows to connect the text to the relevant part of the graphic (Bosak, Davidson, Mitra & Ratz, 2001).
Figure 27.12: Use graphics to highlight design features
287
3. Emphasize the benefits of the features you present. The following slide complements the graphic with bullet points and a heading that emphasize the benefits of the safety zone (Bosak et al., 2001).
Figure 27.13: Use graphics to emphasize benefits
4. Illustrate the structure of the design. The slide below uses clear, simple graphics and minimal text to show the placement of the two products designed to reduce the clients desk clutter (Cibor et al, 2002).
Figure 27.14: Use graphics to show design structure
After preparing a draft of your slides, review them as a team. Make sure each slide coordinates headline, text, and graphics, and that the slide package makes sense to your audience. Slides should have a clear flow and tell a persuasive story. Note on including supplemental slides and using handouts: You may find it useful to make supplemental slides that include graphics you can refer to during the question and answer session. For instance, you may include backup slides with data tables, graphs, photos or drawings of the design, etc. These slides are not meant to be part of your formal presentation but to serve as visual aids during the Q & A. Similarly, if you have material that is too dense
288
to be readable on a slide, such as a table with many testing results, you can use a handout to supplement a slide.
27.2 DELIVERING THE PRESENTATION

A successful presentation involves more than just designing good slides. You also need to speak clearly and professionally and to demonstrate your prototype effectively. Here is advice for doing that.
27.2.1 Effective delivery

A successful presentation requires that you: Speak clearly. Talk to the back of the room. If you imagine yourself talking to people at the back of the room, you will automatically project your voice sufficiently so that even audience members who are hard of hearing or who are coping with background noise from the adjacent room will hear you. Maintain eye contact with your audience. To make sure you dont neglect a section of the audience, deliberately look at individuals who are sitting in various parts of the room as you speak. Don't read aloud from notes. Your audience expects you to be the expert on your design and to be able to speak without written notes. Don't read slides aloud. Instead, look at each slide briefly to refresh your memory, and then turn and talk directly to your audience. You should have more to say than whats written on the slide. The extra information you present will give your presentation depth. Avoid digressions. Stick to the content and organization your team worked hard to develop for the presentation. Stand so that everyone in the audience has an unobstructed view of you and your slides. Dont stand between the projector and the slide (to avoid casting a shadow on the slide). Use precise language. Avoid vague wording like our mockup is not exactly to scale, but its pretty close, and were fairly confident our design will stand up to the wear and tear of everyday use. Instead, say, Our mockup is built to nine-tenths scale, and We are confident our design will stand up to the wear and tear of everyday use. Our written proposal details the rigorous testing we subjected our prototype to establish its durability. Avoid filler expressions like uhm and right. Its okay to be silent for a moment while youre thinking. Repeat each question posed to you and answer it in a straightforward way. Repeating the question ensures that everyone hears it and that
289
youve understood it. If you dont know the answer, be honest and say you will research it.
27.2.2 Using the prototype to communicate your design

Your prototype is not, in most cases, identical with your design; it illustrates key features and functions of the design. Its important, therefore, to avoid confusing your audience on this point. That means that you must be clear about the features of your prototype that do and do not correspond with your final design concept. For instance, if your prototype is made of wood, but you are recommending that the final product be manufactured out of aluminum, you need to say that. Despite this word of caution, however, your prototype is probably your most powerful tool in illustrating the design and persuading the client that you have solved the problem. Therefore, carefully integrate the display and demonstration of your prototype into the presentation using the following guidelines: Decide when to show your prototype in the presentation. Briefly demonstrate your prototype near the start if you believe doing so will dramatically convey your solution and predispose your client to accept it. Later, you can present the prototype in more detail. However, you may decide that your client will more readily understand and accept your solution if you present the problem and research first, followed by slides that show close-ups of features, culminating in your demonstration of the prototype. Display the prototype prominently. Place it on a table in viewing range of the audience. If its small, have one team member hold it up while another explains its features. If its large, place it on the floor, surrounded by the audiences chairs. Make sure you turn up the room lights if you have dimmed them for the slide presentation. Use slides to supplement the demonstration of your prototype. If some features of your prototype are small or hidden, use enlarged slides to show these features. Clearly explain the prototypes functionality. Prototypes in DTC tend to have some fully functional features, some that are partly functional, and some that do not yet function at all. In addition, the prototypes dimensions may differ from those in your recommended design. Therefore, you should explain the level of functionality and the ways in which the prototype differs from your recommended design. Otherwise your client might assume the prototype is the final design, and wonder why it doesnt work the way you say it does.
Using video to demonstrate a prototype: As an alternative to doing a live demonstration, some teams have made a video of the prototype in use and shown that at the presentation. The advantages of making a video are that you
290
can show the prototype being used in its intended location and that you avoid the possibility of embarrassing malfunctions during the presentation. The disadvantage is that your video might not work (see the next section on managing technology). If you plan to use a video, be prepared to discuss the prototype without the video in case something goes wrong.
27.2.3 Managing presentation technology

The technology you use to deliver your presentation should complement your message, not overwhelm it. Be prepared for problems, and prevent them by following these guidelines: To increase the likelihood that your presentation file will be compatible with the classroom computer, (1) use standard fonts that will be available on the classroom computer for presentations. Avoid unusual fonts you may have downloaded to your computer. (2) Avoid cutting and pasting pictures into your presentation. Instead, save picture files to your computer and use the insert function to insert them into your presentation. Use high-contrast colors and fonts for your presentation, and make sure they look good. Pastels or light shades that look good on your monitor are likely to look washed out when projected. Test them at your rehearsal. Test your slide presentation on the equipment you will be using. Anticipate hardware and software problems, and work with local tech support to solve them. If you have problems with computers in the design studio, consult the DTC staff. Test all multimedia in advance. Not all video, audio, animation, and modeling applications that worked on your computer will work on the computer youll be using at the presentation. To avoid this problem, copy large files to the computers local hard disk instead of running them from a CD or networked drive. Test all demonstrations in advance to prevent delays or catastrophes during the presentation. Have backup copies of all files on hand. If you can download files over the network, great. But be prepared for problems: You dont want to have to sprint back to your dorm room because of a network outage or bad disk. Set the room lights at an appropriate level. The audience should be able to see you, the screen, the prototype, and handouts. Practice setting the lights so you can adjust them quickly and unobtrusively during the presentation.
27.2.4 Presenting in a professional way

All members of your team are expected to take a visible, active role in the final presentation and to present themselves professionally. Making a profes-
291
sional group presentation requires more than effective delivery by each individual. Here is some advice for presenting professionally as a team: Dress professionally: a jacket and tie, or a tie and dress shirt for men; a nice outfit for women. All members of a team should be dressed at a similar level of formality. Introduce group members at the start of the presentation and list their names on your title slide. Introduce and thank your client. Assign each team member a role. Each team member should deliver part of the presentation. During the question and answer period, have all team members answer questions to emphasize that the design is a team effort. Decide beforehand who will answers questions on various topics. Make smooth handoffs from person to person during the presentation. For example: That summarizes the problem and requirements. Now Jamal will explain how our design addresses those requirements. Stand and pay attention throughout the presentation, even when youre not speaking. Chatting, slouching, or looking off into space while your teammates are speaking is not professional! Give your client the prototype, a bound color copy of your proposal, and a disk or flash drive with your PowerPoint presentation.
27.2.5 Rehearsing the presentation

Rehearsing as a group makes a tremendous difference in the quality of your final presentation because it helps each person become more confident and relaxed. It also provides an opportunity to make changes to your content, organization, and delivery. As soon as you speak your ideas out loud, you are likely to gain new insights about what to say and even what to emphasize about your design. Moreover, practicing out loud will help you perfect your timing. As you rehearse, ask yourselves the following questions: Content. Is the main message getting through? Are we providing enough or too much detail? Organization. Does the order of points make sense? Are there points that need to be explained sooner? Delivery. Can each person be heard and understood? Is the prototype demonstration effective? Are the slides helpful? Do the visuals connect to what the speaker is saying? How can each person improve his or her part of the presentation?
292
Technology. Are we handling the equipment unobtrusively? Have we resolved all potential hardware or software conflicts? If something goes wrong, do we have a backup plan?
Time yourselves to ensure that the presentation is no more than 30 minutes, with the last 10 devoted to questions and answers. Rehearse at least twice, once in front of your class and instructors, and, if possible, video your practice presentation so that you can review it later.
27.3 REFERENCES
Bosak, G., Davidson, W., Mitra, A. & Ratz, M. (2001). Pope John XXIII team: a final presentation. Engineering Design and Communication, Northwestern University. Cameron, E., Collins, A., Rauwerdink, M. & Woodward, D. (2003). Fast-clip bike light final presentation. Engineering Design and Communication, Northwestern University. Chikando, C., Hamzah, N., Heng, Y. & Kryger, M. (2004). The hamstring stretcher final presentation. Engineering Design and Communication, Northwestern University. Cibor, A., Leung, T., Santana, I. & Wastell, C. (2002). Team filing system final presentation. Engineering Design and Communication, Northwestern University. Darling, A. & Dannels, D. (2003). Practicing engineers talk about the importance of talk: A report on the role of oral communication in the workplace. Communication Education, 52(1), 1-16. Hertog, A., Nelson, P., Ng, W. & Parikh, A. (2004). Noise reduction for BridgeClimb on the Sydney Harbour Bridge. Engineering Design and Communication, Northwestern University. Northwestern Identity System: Download Graphics(2006). University Relations/Publications. Northwestern University. http://www.northwestern.edu/univ-relations/publications/logo/downloads.html Sedlack, R., Shwom, B. & Keller, K. (2008). Graphics and visual communication for managers. Mason, OH: Thomson. Tsuruta, F., Wong, C. & Wuisan, G. (2004). Pope John XXIII library renovation project. Engineering Design and Communication, Northwestern University.
293
294
Chapter 28: Poster Presentations
CHAPTER 28: POSTER PRESENTATIONS
Chapter outline
Designing the poster Layout Graphics Text Font size and style Color Planning the presentation Practicing the presentation
Preparing the poster presentation
Key guidelines for poster presentations

Minimize the amount of text and make it big enough for viewers to read Emphasize graphics (photos and drawings) and make them easy to understand at a glance Arrange text and graphics so viewers can easily see the relationship between the design problem and solution Face viewers while speaking and project your voice Point to the poster or prototype when you want to call attention to important features Answer questions non-defensively and clearlywith supporting data Dress professionally
A Fall/Winter Quarter DTC poster quickly illustrates the essence of your design and its benefits. It contains less text than the posters used at most science fairs or professional science and engineering conferences because it is meant to be viewed in a large room with dozens of visitors circulating rather quickly among the offerings. Your accompanying two-to-five-minute presentation provides further details about the design, so the viewer has little time to read your poster.
295
DTC project fairs can last several hours, during which time you may be asked to give your poster presentation many times. To ensure a successful presentation, make the poster visually compelling and have team members on hand to explain and answer questions about your project. Your poster and poster presentation should work together to convey your main message. You want your audience to think, Thats a great design and these are impressive students! At the end of this chapter, you will find three sample posters. Each takes a different approach to communicating the problem and solution, but they all follow best practices in poster design. If you design a poster for a Spring Quarter project with more technical material, you may use more textand even tables and equationsthan you will find on these examples.
28.1 DESIGNING THE POSTER

Decide as a team the main message of your poster: the problem and your solution. Boil those down to two sentences: one that defines the problem users have, and the other that highlights what you have designedyour designs approach to solving the problem. Now decide what content the poster needs in order to communicate this message. Then consider secondary information. Next sketch the poster on a large sheet of easel paper. Visualize your poster in sections or panels that convey your main message. Use index cards or Post-it notes to sketch the graphics and accompanying text. Move these around the easel paper to determine what works best. You want the poster to have a clear, persuasive organization that conveys your message. Toward that end, organize the various elements so that the solution clearly correlates with the problem, and the key design features with the requirements that they fulfill. If you have done research that goes beyond the typical DTC projectfor instance, specialized lab testing or a large-scale surveylook for a way to highlight that. Now you can begin to work on the specifics of the poster: the layout, graphics, text, fonts, and color.
28.1.1 Layout
Here are tips for the layout of your DTC poster, which will measure 24 inches by 36 inches: Use more graphics than text. Your poster should be about 40 percent graphics, 40 percent white space, and 20 percent text. Put a title banner across the top. Use 96-point type so the title is visible 10 feet away.
296
Arrange information in sections that correspond to the message you want to convey. For example, you might use a two-part format if your organization is problem/solution, and a three-part format if its problem/solution/implementation. Within these sections, organize information into blocks of figures and text. Make the blocks of information easy to follow by following these guidelines: Align the blocks of information so the viewer can easily follow the flow of information. Left-justify the text, but use ragged edges (unjustified text) for the right margins. Make the blocks of information similar in shape and size. Use white space to separate blocks of information and columns. Use numbers or arrows to indicate the sequence of blocks of information.
Use font sizes to indicate the hierarchy of information: bigger fonts for headings and captions, smaller fonts for explanatory text. (See the section below on font sizes and styles.) Leave margins on all four sides of the poster.
NOTE: If your project was funded by an outside grant, indicate that at the bottom of the poster (or make sure that it is part of the template provided to you by DTC).
28.1.2 Graphics
Emphasize graphics, not text, and select photos, drawings, tables, and other graphics that clearly convey your main message. Here are tips for using graphics effectively: Eliminate unimportant information from each graphic. Remove extraneous labels and dimensions from figures, and redo a table to make it less detailed. Dont number figures or include explanatory keys and footnotes (although you should give each figure a caption). If the viewer doesnt get the point of a figure or table in 10 seconds, the graphic has failed in its purpose. Make figures large enough to be viewed six feet away. Make each figure stand out from the text. You may do this with a border or with a background color from a PowerPoint autoshape.
297
28.1.3 Text
Keep the explanatory text to a minimum, but make it clear, emphatic, and informative. One consultant on poster design recommends repeating this mantra when editing the text: There always is too much text. Always too much text (Radel, 1999).
Strategies for writing concisely

Pare down sentences and phrases. Here is a portion of a rough draft of a poster featuring a childrens entertainment module for the backseat of a car. The text is loaded with extra words:
Example 28.1: Poster text that is wordy and hard to read Solution Our solution addresses the problem with the following features: It has a flip-down game table. This allows children to easily access games that entertain them on long car rides. It has a slide-out drawing board. This allows children to occupy themselves by coloring on those long car rides. Its also space saving because it slides under the game table. Finally, it has clearly labeled pouches for storing crayons, game pieces, playing cards, and other items.
Here is the revision:

Example 28.2: Revised poster text that is concise and easy to read Solution: Features and Benefits Flip-down game table Entertaining Easily accessed Entertaining Space-efficient Keep back seat tidy Are easy for kids to use
Slide-out drawing board
Labeled storage pouches
298
Cut unnecessary details. List major features only. Emphasize the problem and the design solution. Include a few significant research results if they support the benefits of your design; you can go into more detail on research when you talk about the project. Omit references to graphics (see Figure 3)
Strategies for making text dynamic

Use headings to make strong, clear statements. Instead of Problem Statement, be specific: Keeping Children Entertained on Long Car Trips. Avoid vague wording such as probably, may, seems, likely, in our opinion. Use active over passive voice. Say, Children dislike long car trips instead of Long car trips are disliked by young children. Emphasize the positive results of your project in the conclusion (the last block of information).
Strategies for making text easy to read

Avoid long lines of text. Avoid abbreviations. Use bulleted lists of sentences and phrases rather than long paragraphs. Make sure the bulleted sentences are clear. The following sentence is not clear or easy to read, despite being bulleted:
We determined that the main problems with storage in current rear seat designs are that there isn't enough storage space and that items tend to fall under the seat.
The revision is much easier to read:

Rear seat storage problems: 1. Storage space is inadequate 2. Items get lost under seat
28.1.4 Font size and style

To make your text easy to read, follow these guidelines: Font size Title: 96 point Captions for graphics: 36 to 48 point Main headings: 36 to 48 point
299
Supporting details: 30 to 36 point Keep the style simple; avoid fancy fonts and effects. Use a sans serif font (one without flourishes at the end of lines) for headings and titles. Use sans serif or serif (one with flourishes at the end of lines) for the rest of the text. Use the same font size and style for headings of the same importance. Dont use all uppercase letters for headings; they are hard to read.
Font style
28.1.5 Color
Keep poster colors subdued and functional so as not to distract from the content. Use a neutral background (white or a subdued color). Use only two or three colors. Avoid garish colors. Make sure text and graphics stand out clearly. Use similar colors to connect images and ideas. For example, use the same background color for text that points out a specific problem and text that explains how to solve it.
28.2 PREPARING THE POSTER PRESENTATION

Your oral poster presentation is not you reading what's on your poster. Its you elaborating on the poster's contents.
28.2.1 Planning the presentation

Review your posters main message, and then decide what you want to say about each block of information in the poster. Ask yourself which blocks of information are self-explanatory and which require an explanation. For the latter, jot down what to say to clarify the information. Different viewers will have different levels of interest in your project, so prepare both a two-minute and a five-minute version of your oral presentation. The five-minute version should expand on the shorter one and be tailored to more knowledgeable and interested viewers, such as the judges. In general, your presentation should cover the following:
300
Introduction in which the first speaker mentions his or her name, as well as those of other team members present. You may also want to catch the viewers' interest with a striking fact or anecdote related to your project. For instance, a team designing an inexpensive water ski for people with limited use of one arm might introduce their project this way: People with disabilities want to be able to return to the activities they enjoyed before they became disabled. Over the last decade, for instance, adaptive water skis have enabled people with limited use of one arm to experience the thrill of being pulled over the water by a boat. However, these skis cost around $1,000, making them prohibitively expensive for some. The Rehabilitation Institute of Chicago (RIC) has asked us to design an inexpensive water ski that addresses this problem. Brief explanation of the problem, including the client organization, the users, and the mission Major requirements Overview of the design and the key features, paying special attention to how they meet the requirements. In the five-minute version, you may also include relevant test results that support the design. Conclusion that sums up how the design addresses the problem
Try to anticipate visitors questions, and write down answers so youre prepared.
28.2.2 Practicing the presentation

Practice the presentation with your team, your classmates, and others. Ask them for constructive criticism, and then practice again. As you practice, concentrate on using body language effectively, guiding viewers through the poster, demonstrating the prototype, responding to questions, and maintaining a professional demeanor.
Using body language

The most important rule to keep in mind is to look at your viewers, not your poster. Facing the audience and maintaining good eye contact not only draws people into your presentation, but also helps them hear you. Youll be in a crowded hall or room, so make sure you speak loudly enough. Never read directly from the poster or note cards: That conveys the impression that you are unfamiliar with your own project. Look away from your audience only when you want to draw their attention to a graphic. Point to the graphic to direct audience attention. Stand to the side of your poster so people can see it easily. Stand up straight to show you're enthusiastic about talking about your project.
301
Guiding viewers through the poster

Use strong transitions as you move from one section of the poster to another. Example: In moving from the problem to the solution, you might say, So the problem is twofold: a lack of sufficient backseat storage space in the car and a tendency for items to fall under the seat during long drives. Our design addresses both those problems.
Using the prototype

If your prototype is especially good at demonstrating the major functions of the design, feature it prominently during your presentation. However, avoid calling attention to functions that do not work well in the prototype. It is perfectly acceptable, by the way, to have one team member demonstrate the prototype as another speaks about it.
Responding to questions
Practice by having your teammates and others ask you questions. If necessary, before answering a question, paraphrase it to make sure you understand and to give yourself a little more time to come up with the answer. Typical questions address aspects of the prototype that obviously need improvement, safety-related issues, and alternative methods of solving the problem (for instance, Did you think about implementing this other kind of feature instead?). Support your answers with information from testing and research. Avoid vague wording like Our prototype is not exactly to scale, but its pretty close, and Were fairly confident our design will stand up to the wear and tear of everyday use. Instead, say, Our mockup is built to nine-tenths scale, and We are confident our design will stand up to the wear and tear of everyday use. Its made from Lexan, the plastic used for those super-tough Nalgene water bottles. Finally, dont interrupt one another. If you feel that a team member is not addressing the question well, let him or her complete the answer before you add your clarification. Interruptions send a message of team disunity to viewers and undermine the overall persuasiveness of the presentation.
Maintaining a professional demeanor

Greet people who come up to the poster, and give them a chance to look it over. As they leave, thank them for talking with you, expressing interest, and offering suggestions. If visitors approach you in the middle of your presentation, greet them and tell them where you are in the presentation: Hello. I'm explaining how our design solves the problem of limited storage space in the backseat of a car.
302
Finally, dress professionally. For men that means a jacket and tie, or nice slacks with a shirt and tie. For women it means a dress, skirt, or nice slacks. All team members should dress with the same degree of formality. Like any oral presentation, poster sessions can be nerve-wracking. The more time you put into planning and practicing, however, the more confident and successful youre likely to be.
28.3 EXAMPLES
On the following pages are three examples of excellent posters. The first is annotated to highlight its outstanding qualities. The other two demonstrate different ways that posters effectively convey a design.
303
Figure 28.1: Annotated Poster: Seatback at a Universal Angle. Chen, Shiao, Srinivasan and Lee (2003)
304
Figure 28.2: Poster: Wheelchair Stabilization Rings. Guevarra, Matsuda, Tang, and Tsuruta (2004)
305
Figure 28.3: Poster: The Egg Chopper. Chen, Fatakia, and Kuma (2004)
306
28.4 REFERENCES
The Cain Project in Engineering and Professional Communication. Guide to designing a poster. Retrieved December 21, 2002 from http://www.owlnet.rice.edu/~cainproj/. Chen, J., Fatakia, F. & Kumar, V. (2004). The egg chopper. Engineering Design and Communication, Northwestern University. Chen, S., Shiao, C., Lee, C. & Srinivasan, S. (2003). Seatback at a universal angle. Engineering Design and Communication, Northwestern University. Guevarra, N., Matsuda, N., Tang, S. & Tsuruta, F. (2004). Wheelchair stabilization rings. Engineering Design and Communication, Northwestern University. Radel, Jeff. Designing effective posters. (July 1999). Retrieved December 20, 2002 from http://www.kumc.edu/SAH/OTEd/jradel/ Poster_Presentations/PstrStart.html. Tosney, Kathryn. How to create a poster that graphically communicates your message. Retrieved December 20, 2002 from http://www.biology.lsa.umich.edu/research/labs/ktosney/file/PostersHome.html
307
308
Chapter 29: Writing Essays about Design
CHAPTER 29: WRITING ESSAYS ABOUT DESIGN
Chapter outline
Analytical essays (DTC I) Persuasive essays (DTC II) Format and visual design in the essay
Key guidelines for writing essays about design

Focus the essay on a clear, concise thesis that states your stand on the topic Organize the essay to develop the thesis logically Support the thesis with evidence from research, testing, analysis, reasoning, and observation Use figures where necessary to illustrate key points Follow the guidelines in these chapters: Chapter 21: Visual Communication Chapter 25: Revising for Clarity, Conciseness, and Correctness Chapter 26: Documenting Sourcesand Avoiding Plagiarism
Much of the writing in DTC is team-based, or collaborative, writing. However, because the course serves to fulfill your writing requirement, it is important that everyone have an opportunity to write on his or her own and to revise that writing based on feedback from instructors and other readers, such as their team members. Individual writing assignments in both quarters of DTC give you that opportunity. You'll be asked to write two drafts of the individual writing assignment and will receive feedback from your instructors and perhaps from others between drafts. Four other chapters of this text provide advice that you will need to use: Chapter 2: Researching and Defining the Problem. Your writing should be based on good research and problem definition. Both assignments will depend upon your understanding what constitutes problems and solutions in human-centered design.
309
Chapter 21: Visual Communication. Your writing should be formatted using the guidelines from this chapter. The chapter also provides advice on using figures and tables. Chapter 25: Revising for Clarity, Conciseness, and Correctness. Your writing should be well-organized with your ideas presented in well-focused paragraphs. Your writing also needs to be edited to eliminate vagueness and wordiness. Chapter 26: Documenting Sourcesand Avoiding Plagiarism. You will need to document all of your sources, most likely in a reference list at the end of your assignment. In addition, you will need to document all quotations, paraphrases, and source-specific facts with intext citations.
The individual writing assignments are determined by the writing instructor for your section of DTC. In most sections, you will be assigned to write an essay on a design-related topic not connected with your team project. In some sections, however, the assignment may involve writing a portion of your final project report or another document related to your project. Since report-writing is discussed elsewhere in this book, this chapter focuses on the content of essay assignments not related to your team project. It ends with a brief discussion of visual communication in essays.
29.1 ANALYTICAL ESSAYS (DTC I)

The DTC first quarter essay generally focuses on analysis. For this assignment, you will write a 3-4 page double-spaced essay, analyzing a product or system from a design point of view. You can choose from a number of different approaches, as long as they have been approved by your section instructors: 1. Identify a product or system that you believe is well designed, based on design criteria that you learn about in DTC. Analyze why the design is effective for its users. 2. Identify a product or system that you believe is poorly designed, based on design criteria that you learn about in DTC. Analyze why the design is ineffective for its users. 3. Compare two competitive products or systems, one that you believe is well designed and one that is poorly designed. Analyze why one is better than the other. 4. Compare two similar products or systems that aim at two different user groups. Analyze why each product is designed well (or poorly) for its intended user group. 5. Analyze the effectiveness of a design of a product or system from a specific point of view: ethical, ecological, safety, aesthetic, cost-benefit, etc.
310
Your communication instructor may suggest other approaches. Remember that analysis focuses on why and how, examining parts of the whole and relationships. A writer can explain how something works, examine the cause of the problem, or break down a problem into sub-problems. Analysis involves the same intellectual process in writing that it does in engineering problem-solving. The most important thing about analytical discussion is that its goal is to help the reader understand. Below are important things to think about as you plan and write the essay.
29.1.1 Choosing a topic

To choose a design to analyze, consider items that you see and use daily things in your home, dorm room, cars, classrooms. You can also consider items in public spaces (for example vending machines) or items for sale in stores. Your essay will be most interesting to you and your readers if you choose a design that you know well and care about because it affects you directly. It will also be more interesting if you narrow the topic so that you can go into depth on it in three or so pages. Here are two methods for narrowing the topic: Focus on a specific model. For instance, instead of writing about several computer keyboards, one student wrote about the Logitech Cordless MX Duo. Focus on one set of related user requirements and exclude all others. For instance, you may decide to discuss only those requirements related to functionality (ease of use, versatility, and performance), eliminating from consideration such requirements as aesthetics and cost.
You can base your analysis simply on your own observations of the items and of people using the items; if you like you can also do some reading about the products, the designers, and the design context.
29.1.2 Deciding on an audience

One important step in planning an essay is to identify who your intended (and ideal) readers are. You might decide to write the essay for DTC students or for an audience of potential users of the product. Your decision about audience will affect every aspect of the essay: how you write the introduction in order to interest your readers, how much background you present about the product, how much technical detail and terminology you use, how you conclude the essay in order to provoke readers to keep thinking about the topic, etc.
311
29.1.3 Developing a thesis and organization

Your essay should present a well-defined main point that you want to demonstrate about the product. Here are examples of clear thesis statements.
Example 29.1: Effective thesis statements for an analytical essay Thesis 1: The Logitech Cordless MX Duo successfully meets the users physical, cognitive, and emotional needs (Beithon, 2004). Thesis 2: Blender 3-D graphics software is exceptionally well suited for hobbyists and students working on small personal projects, while Maya is well designed for professionals working on large projects. (Matsuda, 2004)
In both cases, the thesis statements go beyond vague statements like the product is a great design by specifying what makes it great or who its great for. You should strive for the same precision in a thesis that criticizes the product. The essays organization should derive from the thesis. For instance, heres the outline (excluding the introduction and conclusion) of the essay whose thesis was, The Logitech Cordless MX Duo successfully meets the users physical, cognitive, and emotional needs:
Example 29.2: Outline for analytical essay on Logitech Cordless MX Duo 1. Methods of meeting physical needs a b a b c a Wireless technology Ergonomic form of keyboard and mouse Key positioning Labeling of F-keys Positioning of advanced buttons Color and shape of keyboard
2. Methods of meeting cognitive needs
3. Methods of meeting emotional needs
Each lettered item in the outline above was developed in a separate paragraph in the essay. In addition, each paragraph began with a clear topic sentence stating the main thesis-related point of the paragraph. Below are the introductions of two analytical essays written by DTC students. Each takes a different analytical approach. The following introduction comes from a comparative essay examining how two different types of computer portsFirewire and USBdeveloped as different solutions to the same problem:
312
Example 29.3: Introduction to an analytical essay comparing two products Anyone using computers for the past 10 years knows that the computer industry has gone through many changes. Processor speeds have increased by more than tenfold, high-end graphics cards are a necessity, and PC towers have halved in size. Although these more apparent changes are noticed, the more subtle changes are often overlooked. One such change is the shift from parallel ports to Universal Serial Bus (USB) and FireWire ports as means to connect external devices. Parallel ports lacked fast transfer rates, had high cabling cost, and limited the number of peripherals per computer to the number of ports available. Both USB and FireWire designers were interested in designing a product that would raise transfer rates between computer and peripherals, decrease implementation and cable costs, and increase the number of devices supported on a single bus. The goal of these designers was to create a single system that would replace various ports on a computer with a universal port. Although the designers had the same goals in mind, they tackled the problem slightly differently, visualizing two similar yet distinct solutions. (Van Norden, 2005)
The essay then is organized to discuss the limitations of parallel ports, what designers were trying to accomplish in designing new ports, who developed FireWire and how FireWire meets these goals, who developed USB technology and how that meets the goals, and finally the pros and cons of each approach. The next introduction comes from an analytical essay that takes an historical approach. It analyzes how the design of golf balls evolved to make the golf balls fly faster and straighter.
Example 29.4: Introduction of analytical essay examining how a design developed The top ten long-ball hitters on the PGA tours today have an average drive of 300.6 yards, with Tiger Woods leading the pack averaging 303.3 yards. The top ten most accurate players hit the greens in regulation (two under par) 77.2% of the time, with Sergio Garcia leading the pack with an outstanding percentage of 81.9% (Garcia). Compare this to Arnold Palmer, The King of Golf who at the peak of his career averaged 272.3 yards and hit 72% of greens in regulation (Pros)). One must wonder why golfers skills are increasing at such an exponential rate. However, when you look at the equipment theyre using now, compared to previous technology, the answer is clear: the new golf ball design. The history of the technology of golf balls is over five hundred years of innovations and shows a story of mans ingenuity to create a device that will fly straight and far. (Grafton, 2005)
313
The essay is then organized to trace the history of design innovations in golf ballsand how those innovations affected the game of golf. The following paragraph introduces an analytical essay that examines the reasons that various types of window coverings fail to work effectively:
Example 29.5: Introduction of analytical essay examining why window covering designs fail Do you ever get tired of broken window shades, or of cumbersome window curtains? What about the color fading on the cloth on your furniture because the sun hits it through the windows? Isnt it annoying when the sunlight coming through the space in the curtains prevents you from seeing the TV? These are just some of the problems with common window coverings on the market: they are either dangerous, dirty, easily broken, or just let in too much light. Studies have shown that there is a significant risk of infants choking from the cords of blinds or roller shades (Window). These roller shades often break due to a malfunction in the roller mechanism. Horizontal blinds also become dirty quickly and are difficult to clean. Vertical blinds, although they do not become dirty as quickly, do have a habit of breaking easily. Drapes, another window option, fall into the dirty category and often dont prevent all sunlight from entering a room. There is often that small sliver of light coming in from between the drapes that you can never get rid of. Often the drapes that are heavy and cumbersome enough to block out all light are difficult to remove and clean. (Kreie, 2005)
The essay is then organized by analyzing the problems of the most common window coverings.
29.1.4 Supporting your thesis

Even though this essay is primarily analytical, you still need to provide persuasive support for your thesis. To make the essay persuasive, include evidence and anticipate objections. Evidence can come from a variety of sources: magazine articles, product reviews, personal experience, surveys of other users experiences, illustrative pictures, explanations of the mechanics. Evidence that comes from articles, websites, interviews, etc. should be cited in parenthetical citations and a references page. It also needs to be carefully evaluated. One student added little credibility to his essay about the superiority of Birkenstock sandals by relying entirely on claims and descriptions from the Birkenstock website. Review the end of Chapter 2.3.3 for a discussion of evaluating sources for credibility. Below is an example of a paragraph that uses a combination of product specifications and personal experience as effective evidence to support a point about the convenient size of the Sony Cyber-Shot DSC-P8 digital camera
314
Example 29.6: A Paragraph that persuasively supports its claim Size does matter: that is one thing that makes the P8 superior to the other Cyber-Shot models. Weighing 206 grams and measuring 4.25 X 2.0 X 1.4 inches, which is slightly longer than a business card, the P8 is one of the tiniest 3.2megapixel digicams on the market (The Imaging Resource). It fits perfectly into my purse, backpack and even my shirtpocket. Its compact size also enables it to fit nicely into ones hand (see Figure 1). The elongated shape provides space for me to extend two fingers comfortably across the front and top of the camera without blocking the lens or the control panel. (Heng, 2004)
Figure 1: The P8 fits comfortably in ones hand Source: Digital Camera Resource Page < http://www.dcresource.com>
29.2 PERSUASIVE ESSAYS (DTC II)

The DTC second quarter essay generally focuses on persuasion and logical argumentation. Your instructor will give you a specific assignment; assignments may differ from section to section. You may, for instance, be asked to take a stand on an ethical issue, persuade readers of the importance of your spring quarter project, or propose an improvement to a design. Below are important things to think about as you plan and write the essay.
29.2.1 Choosing a topic, thesis, and audience

For this essay, choose a topic about which you can make a strong caseand then choose the claim you want to make and the best audience to whom you will address your claim. For example, if you want to write an essay defending the ethics of companies that produce bottled water, your audience might be environmentally aware readers who take a dim view of these companies. If you want to propose a new system for arranging the food lines at your dining hall, the best audience might be the manager of the dining hall. If you want to
315
write an essay arguing that one brand of competition swim suit is more effective than another, the audience might be competitive swimmers. Whatever topic and audience you choose, your approach must be persuasive: your goal is make a claim (thesis); to support that claim with evidence, reasoning and/or authority; and to answer counterarguments.
29.2.2 Supporting your thesis

To support your thesis, include evidence from your reading, personal experience, observations, surveys, interviews, or analysis. At the beginning of the writing process, you may believe your claim is supportable but may not yet have any evidence. To develop that evidence, you may have to do substantive research. This is part of the writing processand one good reason to begin writing early. Note that some types of essays do not readily lend themselves to the use of empirical evidence to support claims. For instance, if you are developing a thesis in response to a hypothetical scenario about an ethical dilemma faced by an engineering student, you will not be able to draw on statistics and research studies for support. However, you can draw on the principles stated in professional codes of engineering ethics and the views expressed by ethicists to back up your claims. Similarly, if your essay is recommending a change in a design, you probably will not be able to support your claim with empirical evidence. After all, the change hasnt yet been adopted and tested. However, you can support your claim with strong reasoning that convinces readers the improved design is likely to work. In addition, you may draw on principles of design discussed by experts in the field, such as Professor Don Norman in his book The Design of Everyday Things. As you draft your essay, it is also important to anticipate and address your readers objections. You can either provide counter-evidence that negates their objections. Or you can concede their point, but argue that it is outweighed by other factors. Below are the introductions of persuasive essays written by DTC students. As you read them, pay attention to their claims and imagine the kinds of evidence they would need to support the claim. Also imagine what kinds of objections readers would have. The following is the introduction of an essay designed to persuade airport administrators that the United Airlines check-in system at OHare Airport should be changed.
Example 29.7: Introduction of persuasive essay arguing that a system is flawed and needs redesign I fly on United Airlines out of OHare International Airport at least twice in an academic quarter. I no longer fall into the
316
false sense of security one might get from seeing that the check-in line looks relatively short. Although this line often appears to be a fraction of the length of the security line, I know that once I get to check-in I should put down my luggage and get out my book because that line is going nowhere fast. The problem is that the current check-in process creates significant confusion through a combination of poorly organized lines, the new computerized check-in system and a general lack of explanation about how the process works. These problems slow things down tremendously. Based on my observations made on Sunday, April 17th from 11am -12pm., and Friday, April 22nd from 5am -- 6am, and during prior visits, I believe that this process could be redesigned in a way that would make it much easier and faster by implementing several relatively easy and inexpensive changes. (Pakula, 2005)
The essay supports its claim by providing evidence that the current system is inefficient and causes problems. To gather this evidence, the author observed United Airlines passengers waiting in check-in lines at OHare. She also interviewed passengers to get a clearer idea of what steps in the check-in process caused problems. The essay also proposed several changes to the current system, with reasoning to explain why those changes will solve the problems. The author anticipated that readers might object that the changes would be too expensive. As a result, she provided evidence that most of the benefit would be gained just by changing signage at OHare, a very inexpensive improvement. The following introduction defends the bottled water industry from charges that it is ethically irresponsible:
Example 29.8: Introduction of persuasive essay defending the bottled water industry from charges of ethical irresponsibility In the past 10-15 years there has been an explosion in the market for bottled water. It is estimated that by 2011, the global market for unflavored, bottled water will be approximately 4 billion gallons per year, or $86 billion annually.1 Obviously, a market this large draws the attention of many companies looking to make a profit. There is no reason why these companies should not be allowed to profit from a legitimate consumer demand. Unfortunately, the topic isnt that straightforward. There are many arguments against legitimate companies selling bottled water. There is the idea that bottled water companies (BWC's) are creating massive amounts of waste in the form of plastic bottles that take up landfill space. There is the argument that bottled water uses inordinate amounts of energy in transport from its bottling point to its distribution point. There is the argument that tap water is just as good as bottled water in a developed country like the United States. And most recently, as detailed in the book Blue Gold by Maude Barlow, there is the argument that water is a human right, and should not be sold in a capitalist market, but rather distributed evenly by the governments of the world.2 Through this essay, I will show that while BWC's are completely ethical in their current business practices,
317
there is a potential for environmental improvement in their business model. (Richardson, 2009)
The essay develops the thesis by refuting, point-by-point, the arguments leveled against the bottled water industry. Support for the thesis comes from statistics on the tiny percentage of plastic bottles in landfills, references to the regulations and requirements imposed on the bottled water industry, and research on the recyclability of plastic bottles. The following paragraph introduces an essay written to persuade engineering design students that an DTC projectdesigning a pediatric scaleis addressing an important problem.
Example 29.9: Introduction of persuasive essay on importance of DTC project Upon initial examination, the task of designing a pediatric scale may seem unnecessary. After all, decent pediatric scales already exist. However, current scales are not errorproof enough to ensure the healthy development of children. In pediatrics, accurate measurements are necessary because they profoundly influence a doctors ability to determine the appropriate dose of medicine, track normal growth during crucial developmental phases, and detect medical conditions that require immediate attention. In this respect, a pediatric scale that minimizes potential for error could improve the health of children everywhere. (Hoffman, 2005)
The essay then goes on to support its claim with (1) evidence that current scales are not sufficiently accurate, based on interviews with physicians, and (2) evidence that inaccurate weight measurements can lead to health problems for infants based on research from the World Health Organization. The author anticipated that readers might think that it should be easy to get accurate weights for infants; after all its no problem getting accurate weights for adults. To counter this preconception, the author provided a persuasive scenario to help readers visualize the problems that doctors and nurses have in getting infants to stay still on scales. The paragraph below introduces an essay arguing that fans in laptop computers are ineffective and lead to both comfort and health problems. The essay goes on to propose a new user-friendly fan. The audience is McCormick students.
Example 29.10: Introduction of persuasive essay arguing that a design is ineffective Its Tuesday night and the engineers are at it again: furiously punching away Matlab code on their laptops, in a desperate attempt to finish their EA homework. As the sweat drips down their faces, the students rush through the online text, trying to learn the analytical solution to an oscillating differential equa-
318
tion. The sweat is not solely a product of stress; the students laptops are also working overtime, and, as a result, are literally heating up. Laptops have fans designed to keep the CPU at a safe operating temperature; however, this operating temperature is well above the optimal comfort zone for the human users. As a result of the extra heat, not only do the engineers develop an unfortunate habit of snapping at passing Weinberg students, but they also develop sweaty hands and, potentially, fertility problems for the males. If only those laptops had been equipped with user-friendly fans, those poor tech students might actually enjoy working on their programming. (Lee, 2005)
To support the claim the laptop temperatures are beyond the optimal comfort zone for human users, the author researched computer specifications for fans, measured temperatures from several computers, and researched the medical literature to identify the negative effects of prolonged high temperatures. All this information was cited in parenthetical citations and a references page. To support his proposal for a user-friendly fan, the author drew a sketch to illustrate that the fan could feasibly be moved to a safer location and then used both a sketch and reasoning to show how a different pattern of heat dispersal would lower the external temperature of the computer. The author anticipated that readers might argue that laptop designers had already thought about these things and had placed the fans in their current locations out of necessity. To counter these objections, the author pointed to a specific brand of computer that had redesigned components to make possible a change in fans. As stated earlier, your choice of audience will influence every aspect of the essay. If, for instance, the student addressing the problems with laptop fans had been writing to a computer manufacturer, the introduction would have had to be very different. She could not have assumed the reader knew about Matlab and EA, she would have adopted a more businesslike tone, and she would have ended with a thesis addressing the readers needs and interests: Your company has an opportunity to gain an edge in a highly competitive market by developing an innovative system to cool laptops.
29.3 FORMAT AND VISUAL DESIGN OF ESSAYS

In your past writing experience, you may have structured essays primarily as a series of paragraphs, paying no particular attention to the visual elements of communication: systems of headings and subheadings, figures, tables, bullet lists. These elements are increasingly important as you write in engineering, science, and the social sciences. In your essays for DTC, pay as much attention to visual design as you do in your DTC reports. Chapter 21 provides advice for effectively using headings, figures, tables, and lists. Your essays should take advantage of all this advice.
319
As you draft your essay, be sure to do the following: Include a title that captures your key idea. (See examples in the References for this chapter.) Consider whether headings and subheadings will help your reader better see your organization. If so, use them. Include figures (photos, sketches, diagrams, data graphics) when they will be useful to help readers visualize the problems or designs you are discussing. Include tables when they help you present information concisely. Use bullets (or numbered lists) when you want readers to see listed items at a glance.
In addition, refer to Chapter 21 for guidelines about line spacing, margins, fonts, page numbers, and headers and footers. Note that the one major formatting difference between DTC essays and reports is that essays are doublespaced, while reports are not.
320
29.4 REFERENCES
Beithon, P. (2004). User-oriented design in computer input devices: Logitech Cordless MX Duo. Engineering Design and Communication, Northwestern University. Grafton, K. (2005). History of golf ball design. Engineering Design and Communication, Northwestern University Heng, Y. C. (2004). Sony DSC-P8a pursuit of perfection. Engineering Design and Communication, Northwestern University Hoffman, J. (2005). The importance of the pediatric scale project. Engineering Design and Communication, Northwestern University Kreie, M. (2005). New window coverings: controlling the light. Engineering Design and Communication, Northwestern University Lee, C. (2005). Blowing off the heat. Engineering Design and Communication, Northwestern University Matsuda, N. (2004). Blender and Maya: different products for different users. Engineering Design and Communication, Northwestern University Pakula, M. (2005). Plan to cost effectively reorganize the United check-in process at OHare International Airport. Engineering Design and Communication, Northwestern University Richardson, K. (2009). The ethics of bottled water: Are companies that sell bottled water doing something wrong? Engineering Design and Communication, Northwestern University Van Norden, E. (2005). Universal serial bus versus FireWire technology. Engineering Design and Communication, Northwestern University
321
322
Appendix A: Client Interview Summary
APPENDIX A: CLIENT INTERVIEW SUMMARY*
This appendix summarizes the results of our initial interview with our client, Evan McDowell, the fitness specialist at RIC's Center for Health and Fitness. The interview occurred Tuesday, January 22nd, 2008 at 7:00 p.m., in the Ford Building. Daniel Cornew and Tim Park were present. The purpose of the meeting was to learn more about the problems that RIC was having with their current leg press.
Begin by stating what information the appendix contains and how it was gathered.
Problems
Our client emphasized four problems that users experience using the leg press: It is hard for people in wheelchairs to transfer from the seat of their wheelchair to the seat of the leg press. There are handles on the sides of the leg press that get in the way of the transfer because they are above the seat of the leg press.
Use headings and organize them in order of importance.
The users feet tend to slide off of the footplate of the leg press. This is a problem because then there is nothing holding users to the seat, so they can fall off the leg press. The seat is hard to adjust back and forth. On the leg press, you can move the seat back and forth for people of different leg lengths. The weights for the leg press machine can be dangerous to adjust, because the weights can pinch fingers.
Requirements
Our client identified these requirements for the design. He did not indicate Include explanatory lead-ins to any order of importance in the requirements. Ease of use
lists where necessary.
* Cornew, D., Cory, C., Laning, E., Park, Tim. (2008). The BEST Approach to Leg Press Feet Stabilization. Engineering Design and Communication, Northwestern University. The team's project was to design a method for enabling people in wheelchairs to exercise comfortably and securely in a leg press machine. People with paraplegia exercise on the machine to build up their leg muscles.
323
It must be easier for wheelchair users to get into the seat of the leg press. Ideally, the new leg press design would be able to be used by both wheelchair users and non-wheelchair users, but it is more important that the leg press is usable for wheelchair users. The design must be a permanent fix to the problem and should be able to stay a part of the leg press machine. The seat of the leg press should be wider to provide more comfort and stability for the users. The design must be safe for all users (wheelchair and non-wheelchair) to use the leg press. The general area and shape of the leg press must stay the same so that other users in the gym who may have loss of sight do not trip over the leg press or in any other way hurt themselves due to the leg press. The leg press must still be able to safely accommodate at least 250 pounds. The design must allow the users to transfer to the leg press machine independently and then use it. It must cost less than $6,500 overall. The design should be creative and innovative.
Universality
Permanence
Comfort
Safety
Independence
Cost Creativity
Users
Users of the facility include people with MS, stroke survivors, people with varying degrees of paralysis, people with loss of sight, and amputees. Users are typically between the ages of 18 and 65 and have a maximum weight of 250 lbs. There are 2,000 registered participants in the facility. About 290 new users join the facility every year.
Equipment
The leg press is from the Life Fitness Pro-Series.
324
Other equipment in the facility includes Ergometers, treadmills, Stair Steppers, one elliptical machine, Nusteps, Biosteps, bikes, Cyclecentric Biodex, MotoMeds, leg press.
The interview provided crucial information for understanding problem, users, Conclude with a and client requirements. It raised two questions that we will answer when we summary of the findings and next do our user observation at RIC:
steps.
What are the exact dimensions of the leg press?
325
326
Appendix B: Background research summary
APPENDIX B: BACKGROUND RESEARCH SUMMARY*
At the beginning of the project, we did background research on terms and concepts mentioned by our client--a physical therapist at RIC--in his written description of the project. The project involves designing a method for enabling people in wheelchairs to transfer comfortably into and out of a leg press machine. People with paraplegia due to spinal cord injuries often exercise on the machine to build their leg muscles. Our background research helped us begin to understand several aspects of this problem so that we were better prepared for our client interview. In particular, we researched: (1) basic information about the physiology of spinal cord injury; (2) the causes of difficulty in transferring from a wheelchair; (3) current products for aiding in wheelchair transfer; and (4) the leg press machine used at RIC. Physiology of spinal cord injury
Begin by explaining the topics and purpose of your research.
of the body controlled by the sections of the spinal cord below the injured section are also impaired. However, if the vertebra damage is only partial, then some functions may still have limited functionality (What Is a Spinal Cord Include in-text Injury). In our case, according to the project description, there are some users who have limited mobility of their legs and hands because of this condition. Limited mobility usually means that the user is not able to grasp things tightly, but they can move and grab things to varying extents. Users can move their legs slightly and to varying degrees, including up and down, but they cannot walk. Figure 1 shows which areas of the body are affected when the spinal cord is injured in a specific area.
Use headings that correspond to the Damage done to a section of the spinal cord will cause some functions to research topics cease for the part of the body that the particular section controls. All the parts listed in the appendix intro.
source citations for all information.
* Cornew, D., Cory, C., Laning, E., Park, Tim. (2008). The BEST Approach to Leg Press Feet Stabilization. Engineering Design and Communication, Northwestern University. The teams project was to design a method for enabling people in wheelchairs to exercise comfortably and securely in a leg press machine. People with paraplegia exercise on the machine to build up their leg muscles.
327
Use figures to illustrate your research findings.
Label each figure with a number, descriptive title, and source.
Figure 1: Spinal Cord and Areas Affected by Injuries Source: "What Is a Spinal Cord Injury?" <http://www.apparelyzed.com/ spinal_cord_injury.html>
Causes of difficulty in wheelchair transfer People with paraplegia due to spinal cord injury typically experience a great deal of pain in their upper limbs, especially shoulders, elbows, wrists, and hands. This pain occurs because they have to rely so much on their upper limbs to perform their daily activities. In a recent study, 65% of the subjects said that this pain made it difficult for them to transfer to and from a wheelchair (Koontz, et al., 2011). Koontz et al. point out that during transfer, people typically encounter pain in the elbows and shoulders. Forces on the hand and elbow go right to the elbow, dramatically increasing the stress there. In addition, increase of moments at the shoulder tends to place stress on shoulder muscles. Current products to assist in wheelchair transfer There are three commonly used products to assist people in transferring between a wheelchair and another surface such as a seat, bed, or toilet. They are a transfer board, handle, and thigh lifter.
328
Transfer board
Use sub-headings to highlight key The transfer board is the most commonly used assistive device. It is generally points.
flat and rigid, and is made of wood or plastic (see Figure 2). According to Fairview Medical, it allows users to move between surfaces without using [their] legs. It allows for several small movements instead of one big motion. It also requires less upper body strength than other types of transfers." Users can also learn to use it independently (Transferring).
Figure 2: Transfer board Source: Source: Fairview < http://www.fairview.org/healthlibrary/Article/40382>
Handle Handles provide a movable handhold that can be adapted to many situations. They are easy to position to help users lift themselves from one position to the next. In Figure 3, the handle is positioned at the top of a car window frame.
Figure 3: Handle assist device Source: Allegro Medical <http://www.allegromedical.com/daily-living-aids-c519/carcaddie-helping-hand-p529623.html>
Thigh lifter The thigh lifter allows the user to easily lift and move their legs by adjusting one loop around the thigh and one loop around the wrist (see Figure 4). This gives the user enough leverage to lift their legs without undue strain on their
329
back. The double loop design also allows someone with little fine motor control to lift his or her legs.
Figure 4: Thigh Lifter. Source: Southwest Medical <http://www.southwestmedical.com/search/thigh+lifter>
Leg press used at RIC In his project description, our client stated that a Sled 45-Degree Leg Press is used at RIC. This leg press has a sliding seat that can be adjusted and is at a 45-degree angle to the ground (Sled 45-Degree Leg Press). The user lowers the seat by bending the knees until they are almost completely bent, and then extending the knees to push the seat back up to the starting position (Sled 45Degree Leg Press). The proper way to use this machine is to keep a straight spine, pressing up against the back of the seat. The knees should never be locked as this could put strain on the joints instead of the muscles. The knees should also always be kept in line with the toes. The leg press should be used in a fluid motion without stopping, slow enough to ensure the user is in control and not the weights (Rogers). References
Include an alphabetically arranged listing of your sources.
Car Caddie Helping Hand. AllegroMedical.com. 2008. Allegro Medical Supplies, Inc. Web. 17 January 2008. Koontz, Alicia, et al. Upper limb kinetic analysis of three sitting pivot wheelchair transfer techniques. Clinical Biomechanics 26: 9 (Nov. 2011): 923929. Google Scholar. Web. 16 January 2008. Rogers, Cathy. What are Leg Presses? WiseGeek. Web. 16 January 2008. Sled 45-Degree Leg Press. ExRx. Web. 17 January 2008 Thigh lifter. Southwest Medial. Web. Transferring Using a Transfer Board. Fairview. Web. 17 January 2008. What is a Spinal Cord Injury? Apparelyzed. Web.16 January 2008.
330
Appendix C: User Observation Plan
APPENDIX C: USER OBSERVATION PLAN*
We plan to conduct a user observation at the Rehabilitation Institute of Chicago on January 30. Our main goals are to: Understand how a person in a wheelchair uses the transfer method and the leg press, noting the parts of the process that do and don't pose problems Find out the user's requirements and suggestions for improving the process Collect measurements that will be helpful in the design process
Start time: Introduction

Hello, I'm Emily Laning and these are my teammates Daniel Cornew, Christie Cory, and Tim Park. We are students in Northwestern University's Engineering Design and Communication program. We're working on a project to design a more efficient, comfortable, and safe way for people who use wheelchairs to transfer to and use a leg press machine. We were wondering if we could ask you a few questions and then observe you as you transfer to the leg press machine and use the machine. Also, do we have your permission to use voice, video, and photo recording? We are trying to find out what works about the current design and what could be improved, as well as what you like and dislike and what you would like to see in the future. We will watch to see what problems you may encounter because that will help us determine how to address those problems in our design. Before we start, do you have any questions for us?
While the team did not read this intro aloud at the interview, writing it out made them feel confident about what they would say.
* Cornew, D., Cory, C., Laning, E., Park, Tim. (2008). The BEST Approach to Leg Press Feet Stabilization. Engineering Design and Communication, Northwestern University. The teams project was to design a method for enabling people in wheelchairs to exercise comfortably and securely in a leg press machine. People with paraplegia exercise on the machine to build up their leg muscles.
331
Background information
We would like to know a little more about you so that we can evaluate our results correctly. We would like to know a little more about you so that we can evaluate our results correctly. How often do you use the leg press machine? For how long have you been using it?
(To note visually: age, gender, type of wheelchair)

See Chap. 2.5.2 about how and why to create a task breakdown
Task observation
Task breakdown (this is what we imagine the process to be) Approaching leg press Preparing to transfer-positioning of body Placing hands to begin the transfer Lifting/transferring body Adjusting body position, including seat Adjusting weights Lifting legs onto leg press, adjusting Extending legs/using machine Taking legs off leg press Preparing for transfer back to wheelchair Transferring back into wheelchair
Things to note as user makes the transfer and uses the leg press Placement of user's hands, feet, and body in relation to the machine (including angles) Facial expressions Amount of effort seemingly exerted Times they try and fail (e.g., can't change weights, feet slip, can't transfer, etc.) Ease or difficulty of performing tasks Length of time to perform each part of the process
Follow-up questions
What did you like/dislike about transfer? Why?
332
What did you like/dislike about the leg press seat? Why? What did you like/dislike about adjusting the weights? Why? What did you like/dislike about your feet placement? Why? What parts did you find most/least difficult? What are the most important requirements for a design to improve the transfer process and your use of the leg press? Are there other needs we should also consider? Do you have any ideas or suggestions (especially in terms of features)? Do you have anything to add?
Measurements and other documentation

Dimensions of wheelchair Dimensions of machine (include width, height, seat measurements, distance from weight adjust-ments) Comfortable angle of user's legs and back Distance between and around machines Photos of process
Note the start and end time because you will need to include that in your observation summary appendix.
End time: Things to bring:

Paper and pencil Digital camera Tape recorder Graph paper Tape measure
333
334
Appendix D: User Observation Summary
APPENDIX D: USER OBSERVATION SUMMARY*
Emily Laning observed a user of the leg press machine at the Rehabilitation Institute of Chicago (RIC) on Wednesday, January 30, 2008. The following is the information gained from the observation. Emily also spoke with client Evan McDowell to get information about the leg press machine.
Information about the leg press machine
Organize results in order of imporA key constraint on our project is that our design must be compatible with the tance; in this case current leg press ma-chine. Here is information about the leg press at RIC. information about a key project constraint is given Operation of the leg press first.
Lever on left side of the seat adjusts the seat (moves forward and backwards) Weights located on right side of the machine when a user is sitting on the seat; a push pin adjusts the weights Bands from old tires operate in an "x" to strap the feet onto the foot plate
Benefits of this leg press model (explained to us by our client) Smaller weights can be put on top Big back rest
Information about/observation of the user

Characteristics of the user Male Age: 40s
* Cornew, D., Cory, C., Laning, E., Park, Tim. (2008). The BEST Approach to Leg Press Feet Stabilization. Engineering Design and Communication, Northwestern University. The team's project was to design a method for enabling people in wheelchairs to exercise comfortably and securely in a leg press machine. People with paraplegia exercise on the machine to build up their leg muscles.
335
Process of transferring to the machine

Use a numbered list to indicate steps in a sequence.
1. Lifts legs up over the bar between the seat and the bar supporting the plate 2. Grabs wheelchair and side of the seat and hoists body onto seat (bar is in the way) 3. Lifts one leg onto the above-mentioned bar 4. Lifts legs onto the plate 5. Snaps bands around feet (takes a while to adjust) Characteristics of the wheelchair No bar in front May have armrests (usually removable) Lightweightthe chair moves a little even with the brakes on
Time using the leg press machine Used for about a year; progressed from 20 pounds to 120 pounds Uses about 4 times a week; 30 to 45 minutes at a time
Priorities of user (in order of importance) Comfort and ease of use Speed Safety Overall: helps recovery
Information about conditions of observations

Clinical setting In Weight Room of RIC
Relaxed setting Normal setting for use of the leg press
Information from Observation

The team adapted the chart in Chap. 2.5.2 to include a "user suggestions" column.
Table 1 lists the observations as well as the opportunities these created for our design. It also lists the follow-up to these opportunities and suggestions the user had regarding the problems.
336
Table 1: User observation: opportunities, follow-up, and suggestions

Observations Opportunities Follow-up Use one of many products to facilitate transfers Put wheelchair on rough material or set into a contraption Remove the handles or make them retractable User suggestions Something on the machine to grab onto; adjust seat height
User can have difficulty Provide method to transferring to the speed transition machine quickly Users wheelchair moves during transfer despite brakes User can have difficulty transferring over handles next to leg press seat Find a way to keep the wheelchair steady Make the handles in a way so they wont get in the way of the transfer
User can have difficulty Find a way to make making adjustments (to adjustments simple seat, etc.) User can have difficulty Provide easier method lifting feet and legs up for getting feet onto to the plate plate Straps used to hold feet are not sturdy
Automatic adjustments or easier to reach
Plate adjusts (back and forth) rather than the seat
Make a device to facili- Rotate the plate up and tate lifting the legs down; bigger surface to place feet initially Universal boot
Have more sturdy mate- Add universal boots on rial or have something plate or have someway to stick foot on plate tightly hold the feet
User can have difficulty Prevent users from fall- Make the seat bigger or staying in the seat ing out of the chair make with rougher material Weights used are in too great of increments (currently 20 pound increments) Find better weights for more choices Remove the weights Smaller increments and add smaller weights with smaller increments
Leg press measurements

Foot Plate Width: 24 inches Height: 15 inches Distance from top of plate to ground: 39 inches Bars on back of plate Height: 2 inches Depth: 3 inches
Distance from frame of machine: 8 inches Length: 8 inches Height: 12.5 inches
Bar between foot plate and frame of machine
337
Base/Frame of Machine Length: 47 inches Width: 18 inches Smallest height: 12.5 inches Largest height: 18 inches Sliders on machine (on which the base for the seat runs): 1 inch Depth: 12.5 inches Width: 17 inches Back Rest Height: 30 inches Smallest width (at top): 9.75 inches Largest Width (at bottom): 16.5 inches
Seat
Distance from ground at average setting: 23 inches (maximum 26 inches) 16 inches square Smallest distance to actual seat: 5.5 inches Largest distance to actual seat: 7.5 inches Height from base of seat: 11 inches Distance width-wise from seat: 3 inches Distance from seat: 3.5 inches Amount of handle to grip: 7.75 inches Complete length of handle: 12 inches Distance from handle to weights: 9 inches Width (whole apparatus): 24 inches Width (weights): 15 inches Height: 57 inches Distance to seat: 11.5 inches Pin: Length: 7 inches Maximum width: 2 inches
Base the seat rests on
Lever to Adjust Seat
Handle on seat
Weights
Figure 35 shows some of these dimensions.
338
Figure 1: Sketches of leg press from user observation
339
340
Appendix E: Expert Interview Guide
APPENDIX E: EXPERT INTERVIEW GUIDE*
We will interview Dr. David Hruska, a pediatrician at The Child and Adolescent Center at Evanston Hospital, to gain information about the use of and problems with infant scales that we have not been able to gain through Internet research. In particular, we want to understand how scales are used in the day-to-day routine of a pediatrician's practice. 1. Introduction: Im _______________ (name of interviewer) and this is ____________________ (name of scribe). As we mentioned in our initial email, we are freshman engineering students taking a course called Engineering Design and Communication. Our design project is to improve on existing options for weighing children between the ages of 6 months and 2 years. According to our client, they are too big and active to lie in the pan of an infant scale but not old enough to sit or stand still on an adult scale. Thank you very much for agreeing to meet with us today. Your input will greatly help us refine our understanding of the problem and explore solutions 2. What is the nature of your practice? a. How long have you practiced? 3. What procedure do you use in your office or department to weigh older babies and toddlers (6 months to 2 years)? a. Who weighs them? b. To what accuracy? c. How often is each child weighed? d. How many times per day is the scale used? 4. What model scale do you use? a. If you were responsible for its purchase, when did you buy it, and why did you choose that type or particular model? b. What age or weight ranges do you use it for? c. Do you know its approximate price?
This explanation of purpose is intended for the instructors, who may suggest revisions to the guide.
While the team did not read this intro aloud, writing it out made them feel confident about what they would say.
Group related questions together.
* Hoffman, J., Kessler, J., Schickli, E. & Smith, A. (2005). Pediatrician interview guide. Engineering Design and Communication, Northwestern University. The teams project was to design an improved scale for doctors to weigh infants.
341
Appendix E: Expert Interview Guide
d. Is there anything that you particularly like or dislike about the scale compared to others youve used? e. Why are old-fashioned scales with balancing beams still used? f. Have you ever had a scale fail or break? What went wrong? 5. How difficult is it to weigh small children on existing scales (in terms of time, stress, or other factors)? 6. Any features you would like to see in a new scale design? 7. If a better product were available (faster to use, keeps child from thrashing too much), would you buy it? Why? a. What would be the maximum amount you would be willing to spend? b. Any constraints on the scales size or weight? Why? c. What other factors would influence your decision? 8. Would an attachment to an existing scale be preferable to a new scale? Why? 9. Is there anything else it would be helpful for us to know as we proceed with our design? Thanks very much for contributing your valuable time!
342
Appendix F: Expert Interview Summary
APPENDIX F: EXPERT INTERVIEW SUMMARY*
This appendix summarizes information gained from Dr. David Hruska, a Begin with the purpediatrician at The Child and Adolescent Center at Evanston Hospital pose of the interDate of interview: April 14, 2005 Time of interview: 1-1:30 pm. Pediatrician: Dr. David Hruska Location of interview: Child and Adolescent Center at Evanston Hospital Individuals Present: AO Smith and Jess Hoffman (also, two members of the other team working on the project) Purpose of interview: to get doctors opinion on current pediatric scales; to ask him how they could be improved. I. Suggested features of a new scale a. Heated: Cold, metal scales can be frightening to an unclothed child. A heated scale may make the child more cooperative. b. Waterproof: Many children urinate on the scale because of anxiety or nervousness. For this reason, a waterproof scale is essential. No padding, fabrics, etc. c. Easy to clean: for the same reason as above. d. Extended length: Fussy toddlers and those with spinal cord injuries need a longer laying-down scale. We got this feedback from several other doctors as well. It seems to be important. e. Digital readout: easy for doctor to view. f. Simultaneous readout in metric and English units: eliminates the need to do conversions, which may be inaccurate.
Organize information in logically defined categories that emphasize key points. view and basic information about who, when, and where.
Use underlined sub-headings to call attention to key points.
g. Versatility: A machine that could also measure height and length.
* Hoffman, J., Kessler, J., Schickli, E. & Smith, A. (2005). Pediatrician interview guide. Engineering Design and Communication, Northwestern University. The teams project was to design an improved scale for doctors to weigh infants.
343
h. Minimization of clutter: Eliminate need for crinkly paper. II. Requirements and specifications for current scales a. Accuracy and consistency i. Accurate to at least 1/10 of an oz.When administering medicine, a small difference can make a huge difference in the concentration of medicine administered. Scales can be zeroed currently. Keep it this way.
ii. For height/length: should be accurate to cm or inch. b. Age range of children i. Up to 3 years old. ii. Sometimes older for fussy kids or kids with spinal cord injuries. c. Use of old fashioned scales i. They arent used on kids of this age ii. They are extremely accurate iii. They are easy and reliable in terms of calibration iv. No batteries or electrical cord v. Drawback: takes longer. vi. Easy to tell when its off (because it isnt level). III. Procedures for weighing a. Children must always be unclothed when weighed at this age. b. Nurses or technicians do the weighing. c. Parents put the kids on the scale to help keep baby calm and because mothers are protective. Squirming is a problem, but nurse feels this cant be eliminated unless children are restrained, which would make mothers, nurses, and everyone involved uncomfortable. Also, not necessary for such a short procedure. d. Results of weighing are put into a computer system that compares growth with the norm. e. Schedules for weighing i. In some cases (babies in the Intensive Care Unit or children with Failure to Thrive) it is necessary to be weighed daily. Should be same time everyday (usually at night). Children are live-ins at hospital in these cases and same scale must be used everyday to monitor fluid intake and output. Newborn babies gain about 1 oz. a day.
ii. Healthy children go to the pediatricians office on the following schedule during their first two years: 4 days, 2 weeks, 1 month, 2 months, 4 months, 6 months, 9 months, 1 year, 15 months, 18 months, 2 years.
344
IV. Problems to resolve a. Nurses and technicians "mis-write" numbers (i.e., 0.1 instead of 0.01) way too fre-quently. Is there a way to eliminate this? b. Kids start becoming afraid of scales at about 6 months because they associate them with shots. Not sure there is much we can do to change that except eliminate physi-cally uncomfortable aspects. V. Current scales i. Evanston Hospital uses Olympic Smart Scale (lay-down) and SECA (stand-up).
ii. Scales were donated. Evanston Hospital is happy to take donations!
345
346
Appendix G: Project definition (Three Versions)
APPENDIX G: PROJECT DEFINITION (THREE VERSIONS)
The following three versions of a project definition illustrate how a team developed and clarified their understanding of the problem throughout the course of a project that involved designing a method of collecting rainwater for use by the residents of a village in Kenya. As you read through the three versions, notice how the mission statement evolved, requirements became clearer, and specifications were converted from unknown quantities to precise numerical metrics. The team was able to make these changes as a result of their thorough research, which included frequent consultation with the client, research into climatic conditions in the area, and calculations based on hydrological formulas.
347
Project Definition (Version One)

Project name: Rainwater harvesting structure to help the community of Ribe, Kenya Client: David Torkelson, Project Kenya Charity, Inc. Team members: Abby Hawley, Daiaunne King-Bey, Bruce Perry, Alex Tilley Date: April 14, 2010 Version: One Mission Statement: To create a home system that sanitarily collects rainwater and stores enough for household use during the dry season and water shortages, with potential to be adapted to collect solar power in the future. Project Deliverables: A conceptual design of the rainwater system and a model to demonstrate how it works. Constraints Must be built at minimum cost possible Enough water should be collected to aid a large portion of the village
The team will consult with instructors and client to make the Project Deliverables more precise and detailed.
Although the team has tried to identify constraints, they are as yet too vague. See their revision in the final version.
Users/Stakeholders People in Ribe, Kenya who will live in homes with the system (the main users) Other people living in Ribe (who will benefit from increased water supply) Project Kenya Charity, Inc. (the charity organizing construction of the system) Government of Kenya or other charities (potential sources of funding for the project)
The team uses XXX as a placeholder for the precise specifications that they will determine through research.
Requirements Water Storage Safety Water must be disinfected in some way to make it safe for human consumption Have a watertight tank in the structure Have a method to dispense water to the home and other villagers
Specifications
Store XXX liters of drinking water Be XX meters above ground
Be clear and without any visible contaminants Have an acceptable level of microorganisms
348
Requirements Structure The foundation of the building must be able to support the load caused by the water storage tank. Made from locally available materials
Specifications
Be able to support the weight of XXX liters of water, i.e., XXX kilograms
Water Collection Collect water that can be used by the community Use a rooftop collection system Be able to move water from collector to storage tank Be able to collect XXX liters of water Rooftop collection has a total cross sectional area of XXX m2 Connection pipe to storage has a cross sectional area of XXX m2
Maintenance/Durability Not deteriorate from exposure to the elements in Ribe's climate Be simple enough to repair so that someone with little training could fix it in the event of a malfunction, or simple enough that it is unlikely to break Be able to withstand temperature extremes of XX and XXX degrees Celsius
Other considerations Allow for modification to include solar panels or another way of harvesting solar energy Have a surface area of XXX m2 that could be converted into a solar energy collection array
349
Project Definition (Version Two)

Project name: Rainwater harvesting structure to help the community of Ribe, Kenya Client: David Torkelson, Project Kenya Charity, Inc. Team members: Abby Hawley, Daiaunne King-Bey, Bruce Perry, Alex Tilley Date: May 17, 2010 Version: Two Mission Statement: To design a physical structure for homes in Ribe, Kenya, that can collect and store enough water from rainfall during the rainy season to satisfy daily household needs for the rest of the year. Project Deliverables: A conceptual design of the rainwater harvesting system, including the components and materials needed. Sketches and a model to illustrate the design. Constraints Must be built according to a strict cost benefit analysis in order to require the minimum amount of funding from charitable organizations Enough water should be collected to aid a large portion of the village (a few hundred people)
The client suggested that the team eliminate solar power collection from their mission and focus on water collection.
As a result of research, the team adds requirements and includes numbers for their specifications.
Users/Stakeholders People in Ribe, Kenya who will live in homes with the device (the main users) Other people living in Ribe (who will benefit from increased water supply) Project Kenya Charity, Inc. (the charity organizing construction of the system) Other Non-Governmental Organizations and the Government of Kenya (potential sources of funding for the project)
Requirements Water Storage Have a watertight tank in the structure Have a method to dispense water to the home and other villagers Limit loss due to evaporation
Specifications
Store 4,000 liters of drinking water Maximum amount lost to evaporation: XX Liters/day
350
Requirements Safety Prevent physical contaminants from entering the collected water Keep water clean enough to be made safe for consumption through boiling Allow for future addition of a way to sanitize the water
Specifications
Water is clear and without any visible contaminants
Structure The foundation of the building must be able to support the load caused by the water storage tank. Made from locally available materials Be able to support the weight of 4000 liters of water, e.g. 4000 kilograms Be constructed of cinder blocks, bricks, and/or wood
Water Collection Collect water that can be used by the community Use a rooftop water collection method Be able to collect 250,000 liters of water among all storage facilities Rooftop collection has a total cross sectional area of at least 262 m2
Water Transfer Move water from collector to storage tank Be able to dispense water at a rate of XX liters/minute
Maintenance/Durability Not deteriorate from exposure to the elements in Ribe's climate Be simple enough to repair so that someone with little training could fix it in the event of a malfunction, or simple enough that it is unlikely to break Be able to withstand temperature extremes of XX and XXX degrees Celsius
Flexibility of Design Allow for modification to include solar panels or another way of harvesting solar energy Have a surface area of XXX m2 that could be converted into a solar energy collection array
351
Project Definition (Final Version)

Project name: Rainwater harvesting structure to help the community of Ribe, Kenya Client: David Torkelson, Project Kenya Charity, Inc. Team members: Abby Hawley, Daiaunne King-Bey, Bruce Perry, Alex Tilley Date: June 10, 2010 Version: Final Mission Statement To design a physical structure for homes in Ribe, Kenya, that can collect and store enough clear but unsanitized water from rainfall during the rainy season to satisfy daily household needs for the rest of the year.
The team explains Project Deliverables in detail.
Project Deliverables a description of the rainwater harvesting design which includes the overall intent of the design a description of the key components with rationale as to why they were chosen, and the materials and dimensions necessary to build the design computer renderings and a scaled model to illustrate the design.
As a result of client feedback, the team eliminated cost as a constraint and specified the water collection metric more precisely. Specifications now include precise numbers that define the solution, e.g., exact cross sectional area of gutters.
Constraints Enough water must be collected to support the needs of each family in a cluster of homes (about 100 L/day)
Users/Stakeholders People in Ribe, Kenya who will live in homes with the device (the main users) Other people living in Ribe (who will benefit from increased water supply) Project Kenya Charity, Inc. (the charity organizing construction of the system) Other Non-Governmental Organizations and the Government of Kenya (potential sources of funding for the project)
352
Requirements Water Storage Safety Prevent physical contaminants from entering the stored water Keep water clean enough to be made safe for consumption through boiling Store enough water to last through the dry season Limit loss of water due to evaporation
Specifications
Store 50,000 liters of drinking water Amount lost to evaporation fluctuates slightly year round, ~10 L/day.
Water must appear clear to the users and be free of any visible contaminants
Structure The foundation must be able to support the load caused by the water that has been collected. Made from locally available materials Be able to support the weight of 50,000 liters of water, i.e., 50,000 kilograms Be constructed of cinder blocks, bricks, and/or wood
Water Collection Collect water that can be used by the families in the cluster of households with the storage apparatus
Be able to collect 50,000 liters of water among all collection structures in a cluster of 4 to 6 households. Therefore, based on the weather conditions in Ribe, must have a cross sectional area of 40 m2
Water Transfer Be able to move water from collector to storage tank Be able to dispense water to user in a reasonable amount of time Vertical pipe has a diameter of at least 5.5 cm Sloped pipes have a diameter of at least 10.9 cm Gutters have a cross sectional area of at least 144 cm2 Dispensing pipe has a diameter of ~ 2 cm (or include a pump)
353
Requirements Maintenance/Durability Not deteriorate from exposure to the elements in Ribe's climate Be simple enough to repair so that someone with little training could fix it in the event of a malfunction, or simple enough that it is unlikely to break Be segmented so some operability is retained during repairs
Specifications
Be able to withstand temperature extremes of 9 and 39C Be able to withstand wind speeds up to 92 km/h Storage tank is divided into two sections Design life of tank: 50 years
Flexibility of Design Allow for modification to include solar panels or another way of harvesting solar energy Allow for a sanitization procedure for the water Have a large surface area that could be converted into a solar energy collection array Divide storage into two separate tanks
354
Appendix H: User Testing Guide
APPENDIX H: USER TESTING GUIDE*
The following user testing guide comes from a team designing a module that would fit into an automobile passenger seatback and be used to store and easily access items such as snacks, a lap desk, etc. They devised two task scenarios for testing using three full-sized foamcore mockups. Below is a picture of one mockup. A breakfast storage pouch is on the left, and a lap desk is on the right.
* Shiao, C., Chen, S., Lee, C. & Srinivasan, S. (2003). Progress report #4. Engineering Design and Communi-cation, Northwestern University.
355
This initial explanation is not intended for users but for the instructors, who may suggest changes to the goals and methodology for the test session.
User testing guide

We will use the following testing guide with users as they perform tasks with three foamcore mockups. The mockups differ according to the angle of orientation: 45 tilt; 30 tilt; and flat. The tasks involve: (1) placing and removing breakfast items in a designated part of each mockup; and (2) removing the lap desk from each mockup. Our goals are to learn: (1) whether a tilted or horizontal orientation would best facilitate removing food from the insulated pouch in the mockup, and (2) how easy or difficult it is to remove the lap desk from the three mockups. We plan to test the mockups with at least four users. Start time:
Provide users with an overview of the purpose of the test session.
Introduction (for users): Our project is to design a functional seatback, that is, one that will help drivers perform useful desired tasks in the car, such as storing and having access to food. We will have you perform a set of tasks, and then ask you a few questions about each completed task. The mockups you will be using are not intended to simulate the final product in terms of materials, appearance, etc. But your interaction with them will provide us with valuable information so that we can move forward with our design. Please feel free to ask questions and comment at any time. Task one (breakfast storage)
Word each task clearly and concisely.
(Note to team: Steps a and b below are to be performed with each of the three mockups.) a. Place the banana, yogurt, and juice box in the pouch on the left side of the mockup. On a scale of 1-10 (with 1 being hardest and 10 easiest), how easy or hard is it to place your breakfast in the pouch using this mockup? On a scale of 1-10 (with 1 being hardest and 10 easiest) how easy or hard is it to remove your breakfast from the pouch using this mockup?
Ask users for numerical ratings so that you can easily quantify the test results.
b. Now remove the banana, yogurt, and juice box.
c. Do you have any suggestions for improving this design? d. Overall questions about the three mockups What do you like about each mockup? What do you dislike about each mockup? Which mockup would you prefer to use to store your breakfast? Why?
356
Second scenario (lap desk removal) (Note to team: Step a below is to be performed with each of the three mockups.) a. Remove the lap desk on the right side of the mockup. End time: On a scale of 1-10 (with 1 being hardest and 10 easiest), how easy or hard is it to remove the lap desk in this mockup? Do you have any suggestions for improving this mockup? What do you like about each mockup? What do you dislike about each mockup? Which mockup would you prefer to have on your seat? Why?
Include the start and end times because you will need to include the duration of each test in your user test summary appendix.
b. Overall questions about the three mockups:
357
358
Appendix I: Performance Testing Report
APPENDIX I: PERFORMANCE TESTING REPORT*
Purpose
Use the report
Of the various possible ways to make phosphorescent concrete, the addition structure of a thin phosphorescent concrete layer on top of pure concrete appeared to be explained in the most promising. The materials phosphorescent layer in our performance Chapter 6. testing consisted of a powder containing doped strontium aluminate additives. Our objective was to determine the adhesive properties of varying ratios of phosphorescent powder to water in the thin phosphorescent concrete layers.
Methodology
Through the use of a compression test, adhesion properties of the thin layers were observed. A spherical indenter was used to apply the load to each sample. After the load was applied to the samples, the indent was observed using a macro lens camera. We then compared the indents of these samples to those of the pure cement samples created under identical testing conditions. All photographs of such tests are shown in Appendix N. In addition, a three-point bend test was used to test for adhesion. The amount of distortion and cracking was measured and used to help evaluate the adheReference other sive properties of the samples. See Appendix O for how the layer adhesions appendices with were evaluated. relevant information as needed.
Results
Figure 1 displays the control sample of pure cement, containing the ideal amount of water. There are no cracks around the crater and no flaking around the edges. Similar properties were seen in samples containing a 5:1 glow powder ratio entirely through. This indicates that any cracking or flaking was not due to the phosphorescent material failing, but due to poor adhesion.
* Long, A., Rein, J., Smith, A. & Smith, L. (2006). Glowcrete: A Thin-Layer Approach to the Development of Self-Illuminating Concrete. Engineering Design and Communication, Northwestern University. The project was to determine the feasibility of producing a phosphorescent concrete material that would provide added safety in parking garages, runways, etc.
359
Use tables, graphs, and photos to convey test results
Figure 1: Compression test of control samples. pure cement (left) and 5:1 glow powder ratio throughout, 2.1:1 water ratio (right) Table 1 shows the results of the measurements of distortion and cracking to evaluate the adhesive properties of the samples.
Table 1: Strength of layer adhesion Phosphorescent powder ratio* 5.00:1 5.00:1 5.00:1 5.00:1 2.50:1 2.50:1 2.50:1 2.50:1 1.70:1 1.70:1 1.70:1 1.70:1 1.30:1 1.30:1 1.30:1 1.30:1 Water ratio 2.40:1 2.10:1 1.90:1 1.70:1 2.40:1 2.10:1 1.90:1 1.70:1 2.40:1 2.10:1 1.90:1 1.70:1 2.40:1 2.10:1 1.90:1 1.70:1 Layer adhesion Weak Strong Strong Strong Strong Strong Strong Strong Strong Strong Weak Weak Strong Weak Weak Very Weak
*All ratios are by mass of cement to mass of phosphorescent powder or mass of water.
360
Conclusions and Limitations

From the data obtained from the testing, the following can be concluded: Insufficient and surplus water can cause the layer adhesion to be weak Compression test with a spherical indenter is a good method for testing adhesion. The three-point bend test is not a usable method for testing the adhesion of a thin layer, because it does not provide any noticeable change in cross section of the material (even if the compression test indicates that adhesion is poor). Optimal amount of water for adhesion decreases with the increase of glow powder content.
The last conclusion warrants further study. The results are interesting but cannot be explained at present. More samples should be made in the future to replicate these tests. Experts should also be consulted in order to help explain the cause of these results.
361
362
Appendix J: User Testing Report
APPENDIX J: USER TESTING REPORT*
Purpose
Use the structure
The purpose of our first round of user testing was to determine how the mod- explained in Chapule for the passenger seatback should be oriented. To use our design, drivers ter 6 to organize will need to fold down the passenger seat and be able to easily see and reach the report. desired items. In this round we wanted to learn two things: (1) whether a tilted or horizontal orientation would best facilitate removing food from an insulated pouch, and (2) how easy it is to remove the lap desk for writing.
Test methodology
Two team members conducted four user test sessions with our mockups during the week of February 13. The mockups were constructed of foamcore. The mockups differ according to the angle of orientation: 45 tilt; 30 tilt; and flat. Below are photos of the mockup used in user testing. Figure 1 shows the overall mockup. Figure 2 shows the middle panel containing the large pouch in the 45 orientation. Figure 3 shows the large pouch in the opened position.
* Shiao, C., Chen, S., Lee, C. & Srinivasan, S. (2003). Progress report #4. Engineering Design and Communication, Northwestern University. The team was designing a module that would fit into an automobile passenger seatback and be used to store and easily access items such as snacks, a lap desk, etc.
363
Figure 1: Overall mockup
Include clear, labeled photos or drawings of your mockups.
Figure 2:Middle panel (45 angle)
364
Figure 3: Pouch opened
The tests were conducted in a team member's parked car. The user sat in the driver's seat, and the mockup was placed on the folded-down passenger seat. Three of the sessions were conducted with individual users, while one was conducted with two users at the same time. The one-user sessions lasted between 20 and 25 minutes, while the two-user session lasted 40 minutes. During the tests, one team member sat in the back seat and one stood outside the driver's door so users could be observed from different angles. The users were read the tasks and given no other prompting during the tests. The tests concluded with users being asked to rate the mockups in terms of ease of use. Results
Where possible, present results The following table summarizes the user testing results. In the ratings, 1 is using tables or hardest to use, 10 is easiest. graphs.
365
TASK 1: Breakfast storage Flat Joe 7
MOCKUPS
Completely tilted 8
Half tilted 8
Comments both are easy to use, but tilted is easier
Scott Karen
6 5
8 6
8 6 prefers structured pouch prefers latch instead of zipper prefers that the pouch open from bottom: easier to grab onto
Thanen
Chris
TOTAL TASK 2: Removing lap desk
31
38
38
MOCKUPS
Flat Joe 8
Completely tilted 6
Half tilted 6
Comments flat is easier because hand does not get cramped
Scott Karen
6 6
5 7
5 7 doesnt think she would use lap desk: too bumpy depends on which side handle is on
Thanen
Chris TOTAL
7 33
5 29
5 29
366
Analysis, conclusions, and limitations The results for the two tasks were quite different: Pouch: In removing food from the pouch, users generally preferred a tilted to a flat position. Four users rated tilted as preferable to flat, and one rated them the same. There was, however, no difference in the scores given for 45 vs. 30 tilt. Lapdesk: In removing the lap desk, users generally preferred the flat orientation to the tilted. However, this preference was not consistent: Karen preferred the tilted orientation and Thanen had no preference. There was no difference between ratings for 45 vs. 30 tilt.
The results suggest a design consisting of a tilted pouch and flat lap desk. Also, since there was no difference in ratings for 45 vs. 30 tilt in either task, Based on the the choice between them will be based on other criteria: safety, durability, and analysis and limiease of construction. tations, identify
decisions and next
One limitation to our testing methodology was that in the two-user session, steps. Thanen was able to watch Scott as he performed the tasks. We noted similarities in their responses to task one but not to task two. In future testing, each session should be restricted to just one user. In addition, because the results for the lap desk are inconclusive, testing with additional users is needed.
367
368
Appendix K: Two Sample Team Charters
APPENDIX K: TWO SAMPLE TEAM CHARTERS
Effective team charters can take different forms and emphasize different expectations and behaviors. This appendix contains two different, but effective charters. The marginal annotations emphasize general principles to use in formulating your teams own charter.
Sample Team Charter #1

Our mission is to earn an "A" grade for all team deliverables and to build a product that makes us proud. Communication Reply to emails within 24 hours (48 hours during weekend). Focus on team communication by replying all to emails. Be open to criticism and honest opinions (respectfully!). Write email updates to the client on a bi-weekly basis beginning week 3.
Specify communication modes and frequency.
Meetings Attendance Attendance is very important for each meeting. If you are unable to attend, you must send an email to your team with at least 24-hour notice. After one absence, the member's absence will be brought up at the next meeting.
Include steps to be taken when expectations are not met.
Protocol Set and adhere to a regular meeting day, time, and place throughout the project. No outside conversations through cell phone or computer, stay attentive during meeting. Efficient meetings - aiming for one hour of work
369
At each meeting, assign someone to record topics discussed and decisions made, and keep track of time.
Agenda
Include specific actions to be taken to achieve each goal.
Meeting agenda is circulated via email at least 12 hours prior to meeting time. Each member should be ready to participate at meetings.
Encourage Everyone to Participate The beginning of each meeting will consist of a team check-in where all members give an honest summary of their current motivation and status.
Respect Members When someone has the floor, do not interrupt Respect the meeting time limit and adhere to the agenda
Policy to Handle Disagreements We operate by active consensus. This means that everybody is heard before decisions are made. Not every person has to agree on every decision. We agree that each person will back the decision that the group makes and work hard to implement that decision, even if they disagree.
Team Dynamics
Consider steps that can promote a positive team atmosphere.
Time to chill! - Team will hold a social event at least every two weeks (minimum duration two hours). No business allowed!
Track Tasks - Roles & Responsibilities Create separate document detailing responsibilities and job descriptions (update as needed). All members are responsible for adhering to it. Identify and draw on team members' diverse strengths and interests during our work. Project tasks will be distributed in a way that takes advantage of the individual skill sets and yield the highest quality results. If a member does not finish a task that they were aware was assigned to them, they are responsible for financially backing the next team social event (e.g. must buy food and drinks).
370
Intrinsic Motivation Everyone has specific and attainable goals. Our work should allow each person to achieve their goals. Each member is committing to be motivated to the activities of the class and they acknowledge that their actions affect the grades and performance of the other team members. Continuously update progress on goals and revise if necessary. Celebrate successes!
Accountability Group tasks take priority over personal relationships within the group. If member fails to make valuable contributions to the project, we will pull the individual aside to make sure everything is okay. If nothing changes within a week, we'll set a meeting with our instructor.
371
Sample Team Charter #2

Team Goal
Articulate your team goals in mea- selves. We will know that we are succeeding if: surable terms.
Our team will meet the expectations of the client, our instructors, and our-
Our client approves of our decisions throughout the project and is pleased with our final prototype and presentation. Our instructors offer positive comments on all team deliverables. We feel proud of our accomplishments--both as individuals and as a team--throughout the project.
Methods of Communication
Specify each Routine communication will be through GroupMe. Team members will check method of commu- for and respond to messages regularly. nication in detail.
Written deliverables will be posted on Google Docs. In addition to our in-class meetings, we will meet at least once a week outside of class. We have all agreed that these meetings will be on Sundays at 7:30 pm, with the location alternating between North and South campus. If a person cant attend a meeting or must come late, he should notify the rest of the team asap. Responsibilities Each person has multiple responsibilities, and fulfilling these is essential to team success. Responsibilities include attending team activities (e.g., meetings, user observation, interviews, mockup building)) and completing assigned tasks (e.g., written deliverables, research gathering). In class and at team meetings, we will decide together on the assignment of responsibilities. We will record these assignments in team meeting minutes and RAM charts. We will review the RAM chart to ensure that responsibilities are divided fairly. If a team member falls into a pattern of not fulfilling assigned responsibilities for more than a week, we will address that at a team meeting. If the pattern continues, we will schedule a meeting with our instructors.
Decide on ways to achieve consensus on key decisions.
Specify how you will use project management tools.
Decision-Making Individuals may not on their own make decisions that affect the project direction. Instead, unanimous agreement is required for these fundamental decisions. We will achieve consensus through discussion at team meetings.
372
Individuals may make decisions on their own when it comes to their assigned tasks. However, at meetings, these decisions will be reviewed by the entire team to ensure that they are in keeping with the overall project direction. Roles The following roles are essential to our team's success: Acting leader. This position will rotate among various team members at two-week intervals. At mid-quarter, we will discuss whether this system of rotating leadership is working well. If not, we will discuss another leadership structure. The acting leader's responsibilities are to write meeting agendas (subject to approval by other team members) and to lead the meetings themselves (e.g., sticking to time limits, keeping discussion on track and constructive, making sure everyone participates, identifying action items at the end). Client contact. Jose will take this role throughout the project. He is responsible for being communication conduit between client and team. Project manager. Ann will take this role throughout the project. She is responsible for making sure that everyone knows their responsibilities for project activities, and for updating the RAM and Gantt charts.
Spell out key roles in detail.
Respect and Trust Our success requires that all team members respect one another and feel respected. Without that, individuals will stop trusting one another. To ensure that we demonstrate respect for one another, we must: Be open to all ideas expressed by team members and discuss them seriously. This does not mean that we have to agree with all ideas; rather, we should not dismiss any without serious consideration. Compliment someone whenever they do a job well. Never talk behind a team member's back. Encourage less confident team members.
Handling Conflicts Because conflicts will always occur in teams, we will confront them in a guidelines on how mature and constructive manner as they arise. When someone feels that there to manage conis an issue on the team that needs to be resolved, he or she should bring it up flict. privately with the team member concerned or at a meeting. In doing so, he or she should avoid being hostile or confrontational. The person being addressed should avoid responding defensively. The goal of the discussion should be to reach agreement on taking specific actions that satisfy the needs of all concerned. If one person remains dissatisfied, he or she should express that and continue to try to resolve the problem until all feel that they have reached genuine agreement.
See Chapter 13 for
373
In handling conflicts, if tempers flare and discussion threatens to get out of hand, the meeting leader should call for a break so that people can calm down. If the team feels that progress is not being made toward resolving the conflict and that the project is in jeopardy, we will arrange to meet with the instructors for guidance. Support To complete our project successfully, we should actively seek support from our client, instructors, and experts. If we feel that, despite our efforts, we are not receiving adequate support, we will schedule a meeting with our instructors to discuss how to improve in that area.
374
Appendix L: Sample Table of Contents
APPENDIX L: SAMPLE TABLE OF CONTENTS*
Table of Contents Executive summary ........................................................................... 1 Introduction ....................................................................................... 2 Users and requirements ..................................................................... .3 Design description ............................................................................ .4 Overview .................................................................................... .4 Big bite tube and valve ................................................................ 5 Reservoir ..................................................................................... .7 Pulley .......................................................................................... 9 Clamps ...................................................................................... 11 Design Rationale............................................................................... 13 Big bite tube and valve............................................................... 14 Reservoir ................................................................................... 15 Pulley ........................................................................................ 16 Clamps ...................................................................................... 17 Design limitations ........................................................................... .18 References ....................................................................................... 19
Proofread to ensure that the page numbers are correct. To create the table of contents, use the identical terms used for your headings in the body of the report. Use help sites on the internet for instructions on automatically creating a Table of Contents.
* Calderwood, S., Chen, P., Evitt, D. & Nikodem, R. (2005). Wheelchair drinking system: the ultimate drinking machine. Engineering Design and Communication, Northwestern University.
375
Appendix L: Sample Table of Contents
Appendices
Arrange and label appendices according to the order in which you refer to them in the body of the report.
Appendix A: Project definition ................................................. 21 Appendix B: User observation summary .................................. 24 Appendix C: Interview with occupational therapist .................. 27 Appendix D: First user test report ............................................ .29 Appendix E: Second user test report ........................................ .33 Appendix F: Performance test of clamps ................................. .35 Appendix G: Bill of materials ................................................... 37 Appendix H: Instructions for constructing prototype ............... 38 List of Figures Figure 1 Overview of drinking system ........................................... 4
Use help sites on the internet for instructions on automatically creating lists of tables and figures.
Figure 2 Big bite tube ..................................................................... 5 Figure 3 Big bite valve .................................................................... 5 Figure 4 Reservoir .......................................................................... 7 Figure 5 Pulley configuration ......................................................... 9 Figure 6 Clamp on handle bar ....................................................... 11 Figure 7 Clamp on vertical bar .................................................... .11 List of Tables Table 1 Decision matrix for clamping ......................................... .17 Table 2 Results of first user test ................................................... .31 Table 3 Results of second user test ................................................ 34 Table 4 Results of clamp performance test .................................... 36
376
Appendix M: Sample Executive Summary
APPENDIX M: SAMPLE EXECUTIVE SUMMARY*
Executive summary
With the help of our client, Sara Clark, at the Rehabilitation Institute of Chi- State the problem cago (RIC), we designed an adaptive apparatus to allow people with C5 and and the client. C6 spinal cord injuries to drink directly from a beverage container. While our users can move their arms using their bicep muscles, they have limited strength in their wrists and hands. We observed two users at RIC to understand the difficulties they face in drinking from beverage containers. We then built three mockups of alternative design concepts and tested them with the same two users. Based on the results of those tests, we developed a final design concept and built a mockup that we tested with one user. We used the results of that test to design and build our final prototype.
Briefly summarize the key specifics of your research and testing.
Our design, the Grip&Sip, features an adjustable Velcro strap to secure the Provide a design device around the wrist. Another Velcro strap enables the user to grip a con- overview. tainer securely. D-rings at the ends of both straps allow for independent use and easy adjustability, engagement, and disengagement. The Grip&Sip satisfies three needs that existing products do not: independence, stability, and versatility. Independence: The device is easy to use because D-rings allow users to control two tightening straps using just their thumbs. Then, to tighten the straps and the device securely around their hand and wrist, users simply need two easy motions that Velcro the straps in place. Stability: To prevent dropping beverages, a strap lined in Dycem that loops out perpendicularly to the palm ensures that a beverage will stay tightly pressed against the hand. Then, a rubber pad parallel to the hand makes contact with the container to ensure that it stays upright. Versatility: Beverages come in many shapes and sizes that must be accommodated by the Grip&Sip; it will hold both circular and square containers up to four inches in diameter.
Identify main requirements and how the design meets them.
* Donahue, K., Galfi, R., Sileika, T. (2006). Grip&Sip: final design report. Engineering Design and Communication, Northwestern University.
377
Appendix M: Sample Executive Summary
If appropriate, mention other features or limitations.
Other notable design strengths include the Grip&Sips comfort, washability, and low heat conductivity. One limitation is that the straps and relatively large D-rings make the device less discreet in appearance than users preferred.
If there is room, include a drawing or photo of design.
378
Appendix N: Sample Introductions to Final Reports
APPENDIX N: SAMPLE INTRODUCTIONS TO FINAL REPORTS
Sample 1*
Introduction
One way that water treatment plants measure the dirtiness of water is by using a turbidimeter. The turbidity is determined by measuring the refracted light from extremely small particles in the water such as bacterium, which range in size from 10-3 cm to 10-8 cm (Figure 1).
Figure 1: Use of turbidimeter to measure refracted light
Our team was asked to design a solution to a problem at the Kankakee water treatment plant: An in-line turbidimeter is becoming clogged and damaged Briefly explain the due to large particles (from coarse sand to grass) flowing through it. Large problem. particles (larger than 10-3 cm) also cause the turbidity rating of the water to become skewed. These problems cause a cascade of issues, including large amounts of time and money spent on repairing and replacing the turbidimeter. The Screen N Flush solves those problems by creating a filter that is nearly self-running and requires minimal maintenance. The filter removes the large particles from the water, but the turbidity is kept constant since it does not filter out particles smaller than 10-3 cm. When the filter begins to clog as large particles collect on it, the user can see the device needs cleaning. To clean the
* Cooper, J., Huffman, G., Kolodner, B. & Peng, J. (2007). Screen N Flush. Engineering Design and Communication, Northwestern University. Explain how your design solves the problem--in this case by describing how it functions.
379
device, a switch-operated back flushing system drives the particles out to a drain. With the financial support of the Eaton Corporation, we were able to construct a functional prototype of the Screen N Flush.
Preview the sections of the report.
This report explains the users, requirements, and specifications for the requested design, followed by a detailed explanation of the design and its rationale. We conclude with recommendations for testing.
380
Sample 2*
Introduction
Briefly explain the
People with limited wrist and hand strength, due to C5 or C6 spinal cord problem. injury, often need an apparatus that discreetly and comfortably allows them to drink directly from a variety of beverage containers. (See Appendix A for the project definition.) While the strength of the users varies, generally they have strong biceps and weak triceps. They also have little to no movement in their fingers. These issues cause difficulties in picking up and drinking from beverage containers. Current products are not effective in solving this problem. In some cases, a very long straw is added to a beverage so that picking it up and setting it down is unnecessary. A drawback to this solution is the need for assistance in putting the straw in the container. In addition, users have expressed a desire for something more discreet. A more discreet model, also commonly used, is a Velcro ring connected to a handle. While this device does function better, users experience difficulty attaching it to beverage containers. Also, the Velcro, in many cases, is not strong enough, working for only lighter containers. Another similar device employs a metal ring attached to a handle. The metal ring attaches to the container using screws; however, because of the limited strength and dexterity of people with spinal cord injury, putting on the apparatus independently is impossible. An additional flaw is the lack of versatility; the product does not fit all sizes of containers. Simply put, the devices currently available do not adequately address the entire problem.
If appropriate, explain how competitive products fail to solve the problem.
Our design, the Grip & Sip, satisfies three needs that previous products have not: independence, stability, and versatility. It features an adjustable Velcro strap to secure the device around the wrist. Another Velcro strap enables the Explain how your user to grip a container securely. D-rings at the ends of both straps allow for design solves the problem--in this independent use and easy adjustability.
case, by addressThis report discusses how the Grip&Sip addresses the problems with current ing the key requirements.
products. We present a detailed look at our method for evaluating users needs and designing the Grip&Sip to meet them. We also discuss limitations to the design and ways to address them.
* Donahue, K., Galfi, R., Sileika, T. (2006). Grip&Sip: final design report. Engineering Design and Communication, Northwestern University.
381
382
Appendix O: Discussion of Design Limitations in Final Reports
APPENDIX O: DISCUSSION OF DESIGN LIMITATIONS IN FINAL REPORTS*
Design limitations
Team Glowcrete has made significant steps in developing methods for synthesizing and testing phosphorescent concrete. The following limitations must be Organize limitations in order of addressed to advance the design:
importance.
Repetition of cement tests Samples tested for this investigation included only one data point for each combination of variables. More samples for each combination of variables should be tested. A broader range of glow powder and water ratios should also be tested in order to better determine the relationship between these variables and adhesion/phosphorescence. This would allow future researchers to report on the effects of adding phosphorescent powder with more accuracy.
Identify limitations in the final design or in the testing. Do NOT discuss limitations in the design Glow powder ratio process, e.g., lack The preliminary results obtained from the testing performed indicate that a of time, money, or 2.5:1 glow powder ratio is optimal, and that the optimal water amount expertise.
decreases with increasing glow powder quantities. Both results were unexpected and should be investigated further. Use of concrete samples
Recommend next steps to address All samples for this project were made with cement rather than concrete. limitations.
Given that cement is a large constituent of concrete, the procedures and results should be analogous. However, the work conducted with cement can be interpreted only as a proof of concept. All tests must be repeated using concrete.
* Long, A., Rein, J., Smith, A. & Smith, L. (2006). Glowcrete: A Thin-Layer Approach to the Development of Self-Illuminating Concrete. Engineering Design and Communication, Northwestern University. The project was to determine the feasibility of producing a phosphorescent concrete material that would provide added safety in parking garages, runways, etc.
383
Appendix O: Discussion of Design Limitations in Final Reports
Quantitative compressive strength tests This quarters work focused on the adhesion of the thin phosphorescent layer to the bulk sample. Based on expert opinions, the thin layer was not believed to adversely affect the total materials compressive strength (see Appendix E). Before Glowcrete can be used in structural applications, the compressive strength must be verified, especially if structural failure could cause bodily harm. Durability tests Only adhesion and phosphorescent properties were tested. Testing should be conducted to characterize the durability properties: thermal shock (freeze-thaw, then compressive tests) microhardness (Vickers hardness) resistance to common environments for applications (monitor weight/ thickness when reacting with sulfuric acid)
384
Appendix P: Progress Report
APPENDIX P: PROGRESS REPORT*
TO: FROM:
Professors Herbst and Herrick

Use memo format;
Section 23, Team 4: Dhaivat Buch, Tinlee Lin (primary authors), indicate primary authors in "From" Kelly Luckasevic, Garrett Thoelen
line.
DATE:
May 23, 2006
SUBJECT: Progress Report Two on Diaper Wipe Project

In the intro, state the specific key findings, decisions, and next steps that the report will elaborate on. Arrange and letter the appendices in the order in which you refer to them in the body of the report. Use headings and sub-headings to highlight key points.
Introduction This report informs you of Team 4s progress from May 4 to May 23 on the Procter and Gamble Baby Wipe Container project (see Appendix A for project definition). First, our surveys showed that the majority of parents would find a dry-to-wet baby wipe container to be useful. Second, we decided to use a modified ball-valve to release lotion onto dry wipes and have built a proof of concept model of this system. This model will go into a large-scale proof of concept model of our entire design. Third, we presented the ball-valve mockup for a design review, and the class noticed possibilities for leaks. Finally, we developed to-scale drawings of our design and are in the process of constructing a looks-like prototype of it. In the future, we will find solutions to the leak problems and finalize prototypes. (See Appendices B and C for RAM and Gantt charts.) Findings and Decisions since Report One User testing approved Dry-to-Wet Wipe concept On May 7, we surveyed five parents (who currently have children in diapers) at the Sheil Catholic Center on their wipe-purchasing habits and on our dryto-wet concept. (See Appendices D and E for survey form and results.) We learned that:
* Buch, D. Lin. T., Long, A., Luckasevic, K., & Thoelen, (2006). Progress Report Two. Engineering Design and Communication, Northwestern University. The project was to design an improved container for baby diaper wipes. NOTE: The appendices in the report have been omitted.
In the body of the report, include the most significant data to support findings and decisions; refer to appendices for comprehensive data.
385
3 out of the 5 parents purchase generic brand wipes most often because they are cheapest Only 1 parent purchases Pampers brand wipes regularly 3 out of 5 parents think a dry-to-wet dispenser would be useful Only 1 parent would buy the dry-to-wet dispenser if it was more expensive than regular Pampers dispensers
These results confirmed our decision to move forward with the dry-to-wet container design, but they also made it apparent that the product should not cost more than a brand-name container. Additional feedback also revealed that the product must be visually appealing and useful looking. Decisions on design concept development Modified ball-valve for lotion delivery We explored several methods of delivering lotion to the dry wipe within the container (see Appendix F for decision matrix). Table 1 shows the designs that we eliminated. Table 1: Analysis of Lotion Delivery Methods
Where appropriate, use tables to present information that supports design decisions.
Design Small ball valves Spray bottle Sponge Reason for not using Could be condensed into one valve Would need reservoir for excess spray Doubt in ability to of sponge to transfer lotion; evaporation due to large surface area Difficult to control leaks
Liquid pressure
Based on this analysis, we decided to use a cylindrical ball-valve design because lotion flow could be controlled simply by pressing upwards on the bottom cylinder with the desired pressure. There would be no opportunity for the lotion to evaporate because the container would be airtight and only one piece. We built a proof of concept for this design on May 15. Bear as visual concept Our final design is in the shape of a bear's head because bears are common children's toys and are unisex. On May 22, we began carving the design toscale out of yellow high-density foam. (See Appendix G for drawings.) Design review revealed leak issues in lotion delivery method We held a design review on May 16 with our class and presented our valve proof of concept and a diagram of how it would relate to the entire systems
386
(see Appendix H). Table 2 summarizes their major concerns and our possible solutions (see Appendix I for complete results). Table 2: Key Design Review Results
Concerns Container might leak if flipped Leak may occur in valve after wipe is pulled Wipe could break Our proposed solutions Cover top of valve; design a guard so the cylinder does not roll around Use suction cups to close valve 10 seconds after being opened Allow for full opening of side of container so wipe can be realigned
Latest drawings Most recently, we developed our latest drawings of our desired final product (see Appendix J). Next Steps
Be specific about These are tasks we need to accomplish before we present our final design on next steps; don't list the generic June 7: steps in the design process given in Further examine details of valve leak problem the syllabus.
Complete proof of concept prototype, including ball-valve Complete visual prototype in yellow foam Hold a second design review to assess our complete prototype Write report and PowerPoint for final presentation
Support Needed In our team/instructor meeting, we would like your help in: Addressing the leak problems in the valve Building our final proof of concept prototype
Conclude by concisely summarizWe have finalized our design, except for some leak-prevention issues we must ing the project address in the valve. Our visual prototype and proof of concept are about half- status and your way complete, and our goal for the next two weeks is to put all of our design major goals for the next phase.
Conclusion
components together into an appealing and workable product.
387
388
Appendix Q: APA Documentation formatting advice
APPENDIX Q: APA DOCUMENTATION FORMATTING ADVICE
This appendix provides information on how to use the American Psychological Association (APA) format in your reference list. As a supplement to Chapter 26, it covers the sources most commonly used in DTC. For information on APA format for other kinds of references, such as email communication, government documents, or encyclopedia entries, etc., see the Purdue Online Writing Lab site at http://owl.english.purdue.edu/.
BOOK
Basic format: (1) authors last name followed by first initial (if the author is unknown, begin with the title); (2) year of publication (in parentheses); (3) title (italicized; capitalize only the first letter of the first word, with the exception of proper nouns); (4) place of publication; (5) publisher. See the example below, paying special attention to the punctuation marks used. The punctuation in a reference list helps readers see at a glance what kind of source (book, article, etc.) you are listing.
Example:
Koglin, T. (2003). Movable bridge engineering. Hoboken, NJ: J. Wiley & Sons.
ARTICLE IN PERIODICALS ACCESSED IN LIBRARY DATABASES

The most commonly used library databases for finding magazine, journal, and newspaper articles are EXAC, Lexis/Nexis, Applied Science Index, and Academic Search Premier. Basic format: (1) last name of author followed by first initial (if the author is unknown, begin with the title); (2) year of publication (in parentheses): (3) title of the article (no quotation marks; capitalize only first letter of the first
389
word, with the exception of proper nouns); (4) title of the journal (italicized); (5) volume/issue number (if given); (6) date of retrieval and name of database.
Example:
Voelker, R. (2005). Rehabilitation medicine welcomes a robotic revolution. JAMA 294.10. Retrieved May 6, 2006 from Expanded Academic ASAP.
PAGE ON A WEBSITE
Basic format: (1) sponsoring organization or last name of the author followed by first initial (if known); (2) date (in parentheses; use n.d. if no date is given); (3) title of the page (italicized); (4) retrieval date and URL. For long URLs, use only the main part, followed by the word Path and the links that have to be followed.
Examples:
Snowsport GB. (2005-6). Adaptive. Retrieved May 2, 2006 from <http://www.snowsportgb.com/Adaptive>. Abledata. (n.d.). Audible Battery Tester. Retrieved May 3, 2006 from <http://www.abledata.com/abledata.cfm?pageid=19337> Path: Products; Blind and low vision; Audible battery tester.
INTERVIEW
In APA style, personal interviews (as well as emails) are not included in the reference list. Instead, cite the source as an in-text parenthetical citation:
According to Dr. David Hruska, a pediatrician affiliated with Evanston Hospital, a scale for measuring the weight of toddlers must be accurate to within 0.1 oz. (personal communication, April 14, 2005).
390
REFERENCES
Gibaldi, J. (2003). MLA handbook for writers of research papers. 6th ed. NY: MLA. Neyhart, D., Karper, E., Stolley, K. (2006, May 10). MLA formatting and style guide. Retrieved June 28, 2006 <http://owl.english.purdue.edu/owl/ resource/557/01/>. Publication Manual of the American Psychological Association (5th ed.). (2001). Washington DC: APA. Ruszkiewicz, J., Hairston, M., Friend, C., eds. (2006). Scott Foresman SF express. 2nd ed. Upper Saddle River, NJ: Pearson Prentice Hall.
391
392
Appendix R: MLA Documentation formatting advice
APPENDIX R: MLA DOCUMENTATION FORMATTING ADVICE
This appendix provides information on how to use the Modern Language Association (MLA) format in your reference list. As a supplement to Chapter 26, it covers the sources most commonly used in DTC. For information on MLA format for other kinds of references, such as email communication, government documents or encyclopedia entries, etc., see the Purdue Online Writing Lab site at http://owl.english.purdue.edu/. Note that MLA no longer requires the inclusion of URLs for online sources. Instead, use the words Web and Print to identify those two kinds of sources.
BOOK
Basic format for a print version: (1) author's name, last name first (if the author is unknown, begin with the title); (2) title (italicized); (3) place of publication, followed by a colon; (4) publisher; (6) date of publication; (7) the word "Print." For an online version of a book, include after the copyright date: (7) search engine or database used to find the book; (8) the word "Web"; (9) date of access.
Examples of print and online citations:

Koglin, Terry L. Movable Bridge Engineering. Hoboken, NJ: J. Wiley & Sons, 2003. Print. Koglin, Terry L. Movable Bridge Engineering. Hoboken, NJ: J. Wiley & Sons, 2003. Google Book Search. Web. 11 November 2009.
ARTICLE IN PERIODICALS ACCESSED IN LIBRARY DATABASES

The most commonly used library databases for finding magazine, journal, and newspaper articles are EXAC, Lexis/Nexis, Applied Science Index, and Academic Search Premier.
393
Appendix R: MLA Documentation formatting advice
Basic format: (1) author's name, last name first (if the author is unknown, begin with the title); (2) title of the article in quotation marks; (3) title of the periodical, italicized; (4) volume/issue number (if given) and date of publication; (5) page numbers; (6) name of database, italicized; (7) the word Web; (8) date of access.
Example:
Voelker, Rebecca. Rehabilitation Medicine Welcomes a Robotic Revolution. JAMA 294.10 (2005): 1191-1195. Expanded Academic ASAP. Web. 6 May 2006.
PAGE ON A WEBSITE
Basic format: (1) title of the page (in quotation marks); (2) name of the web site, italicized; (3) name of organization sponsoring the site; (4) date of publication (if no date is listed, use "n.d."); (5) name of sponsoring organization or institution (if known); (6) the word "Web": (7) date of access.
Example:
Autism. American Academy of Pediatrics: Dedicated to the Health of All Children. American Academy of Pediatrics, n.d. Web. 20 Feb. 2010.
INTERVIEW
Basic format: (1) name of interviewee, last name first; (2) Personal (or telephone) interview; (3) date.
Example:
Hruska, David. Personal interview. 14 April 2005.
REFERENCES
MLA Works Cited Page: Books. Owl Purdue Online Writing Lab. Purdue University, 2010. Web. 22 June 2010. MLA Works Cited: Electronic Sources (Web Publications). Owl Purdue Online Writing Lab. Purdue University, 2010. Web. 22 June 2010. MLA Works Cited: Other Common Sources. Owl Purdue Online Writing Lab. Purdue University, 2010. Web. 22 June 2010.
394
Appendix S: Terms used in Design Thinking and Communication
APPENDIX S: TERMS USED IN DESIGN THINKING AND COMMUNICATION
Every field has its own language, its own set of acronyms and buzzwords. Part of learning that field is learning the language. This glossary is a design and communication language reference, organized alphabetically. The following subcategories may aid your navigation.
Design process
Affordance Alternative designs Brainstorming Clustering Competitive product Conceptual design Decision matrix Design process Design requirements Design review Detailed design Downstream technology Engineering release Expert interview Failure modes Feature Field testing FMEA Forcing function Function Functional specifications Gantt chart Hierarchical organization Human-centered design Industrial design (I.D) Lab testing Latent defects Mental model Mission statement Mockup Model product Performance metrics Pert chart Product analysis Product specification Project notebook Prototype QFD Rapid prototyping Specification Upstream technology
Prototyping and manufacturing

Alpha Assembly Beta Blow Molding Breadboard BOM CAD/CAE CAM Cavity CNC Core DFM Draft Engineering check model Extrusion First articles Hard tooling Injection molding LCD Lead times LED MTBF Machine tool Mating parts Multiple cavity PCB Piece parts Pilot build/pilot production Pre-production parts Press Preliminary engineering Prototype Rapid prototyping Rapid prototyping machine Single cavity Soft tooling Solid modeling Surfacing SLA Three (3) D file Tooling Tweaking Wire frame
User testing and analysis

Demographics Ethnographic analysis Field testing Focus group Interview guide Paper tests Rapid prototyping Shadowing Stakeholders Structured group meetings User User observation
Visual communication
Concept sketch Control drawings Database Detail drawings Drawing Life cycle boards Mockup Model, visual Orthographic Project notebook Render Sketch Sketch model Solid modeling Surfacing Thumbnail Three (3) D file Wire frame
Written Communication
Design requirements Engineering release Functional specifications Meeting agenda Mission statement Product specification Progress report Project definition Project notebook Proposal Specification Technical brief
395
Affordance The set of possible actions a person can make on the product is called the affordances. Note that not all affordances are desirable: a person can throw, kick, and hide behind objects, even if this was not why they were designed. A good designer makes the desirable affordances visible, so that they are readily discovered and easily understood. Alpha An Alpha is a functional prototype. It is synonymous with prototype but is process related. (An Alpha always precedes a Beta). An Alpha is always generated by an engineering database or 2D documentation and is fabricated from materials appropriate for the application, but may not necessarily replicate production materials or finishes. Alphas will function, but will normally always require revisions and continuing development. Some limited product testing can be expected from an Alpha. Alternative designs Two or more design concepts that attempt to solve a design problem in different ways. Alternative designs are normally generated in order to elicit user feedback and to test functions in the lab or field. It is important to note that a final design will often combine features from various alternatives, as well as new features conceived while testing the alternatives. Assembly Logical grouping of parts in a product usually defined by the manufacturing process. Product hierarchy would start with raw materials or purchased parts; next highest would be process parts (blanks, unpainted, etc.); above that would be finished parts.These are put into subassemblies or assemblies; assemblies are processed into a finished product or major group (engine, transmission, etc.); at the highest level is the product as sold or SKU. Beta A Beta is a pre-production prototype. It is produced from as much production tooling as possible. A Beta may be hand assembled and is used to verify repeatability and reliability. It will accurately represent the finished design with production materials and processes. The unit is pre-production and therefore may not have production, finished graphics and labeling, based on need. These units go into the field for Beta testing. Blow molding A manufacturing technique that transfers a softened plastic mass (paraffin) into an opening of a mold which is then subjected to air pressure. The pressure forces the softened plastic to conform to the walls of the mold. Plastic bottles are blow molded.
396
BOM Bill of materialsA concise listing of every item that goes into a finished product, to include not only every screw and washer but also all labels and instructions. Often organized by assemblies and called a structured or indented BOM. Brainstorming A structured method for stimulating creative thinking and generating a large number of ideas quickly. Breadboard A proof of concept model that represents how a product will work but not how a product will look. Often used for conceptual development and built to prove feasibility of a functioning aspect or aspects of a concept. CAD/CAE Computer aided design or computer aided engineering. Generic term that refers to the range of computer tools that designers and engineers use for engineering development work. These tools are used for modeling/drafting, analysis, and simulation. CAD developed engineering is more accurate, easier to change and more efficient in converting from engineering documentation to a part. CAD very often is used in conjunction with CAM. CAM Computer assisted manufacturing. A technology that facilitates the programming for automated machining. Used to make both product tooling (e.g. injection molded tools) and piece parts. Cavity The piece of a mold that creates the exterior surface of a part. Normally thought of as the visual side of a part. Clustering The process of dividing a long list of data, information, or ideas into smaller groups for the purpose of evaluation. CNC Computer numerical control is an automated machine that uses computers and programming to control its operations, instead of human activation. CNC programs can be generated using CAD data without re-entry of the information. CNC machines are used to produce tooling for production parts, and prototype models in reasonably short time frames.
397
Concept sketch First level of client/management/team acceptable presentation. Sketches are rough color representations of the form and usually include sections and additional views to describe the features and functions. Constraints This term is used in two ways. First, rules that a design must not violate. An example would be that a new laptop computer have a weight of no more than 6 lbs. Second: behaviors that are not allowed in the use of a product. An example is the design of a 120 VAC power outlet, which constrains the insertion of a plug to the orientation that grounds the appliance's case. A good design trick is to use constraints on behavior so as to enforce the correct operation or minimize errors. DTC Forcing function. Control drawings A line development of all exterior surfaces of a product. Normally developed by industrial designers and used as a basis for developing the engineering database. Control drawings are also used by industrial designers as transfer documentation to be used by model makers in the development of visual models. Core The piece of a mold that creates the inside or interior surface of a part. Normally thought of as the non-visual or mating side of the part. Competitive product A product that is aimed at your users and your specific application, regardless of the technology it employs. Conceptual design The systematic process of developing a general solution to a problem but not performing all the calculations and the evaluations of components, materials, and manufacturing processes necessary for implementation of the design. Database An electronic file of (engineering) information. Engineering databases take the place of manual detail drawings. The database is developed on a 2D or 3D computer program. Decision matrix A tool that design teams may use to aid them in selecting among alternatives. The various design criteria are listed along one axis, possibly with associated
398
importance weightings. The design alternatives are listed along the other axis. Cells are filled in with scores indicating how well each design fares with respect to each criterion. Scores may be totaled to give an overall ranking of the design alternatives. These rankings, as well as rankings in specific categories, are factors that the design team should consider in making its final decision. Demographics Facts about interviewees that help define the user groups they fit into, and their level of knowledge and experience relevant to your design. Demographic questions are designed to elicit relevant facts, not opinions, about the interviewees. Design process In engineering, the systematic, creative solving of complex problems that involves applying technology to satisfy peoples needs. Design requirements A comprehensive, detailed, solution-independent list of what the client, users, and community stakeholders expect of a new product. Design review A scheduled, systematic evaluation of a design by knowledgeable people, the goal of which is to uncover problems, suggest improvements, and ensure that the design meets the needs of the client and users. Detailed design The process of performing necessary calculations and evaluating components, materials, and manufacturing processes in order to see a design through to implementation. Detail drawings A complete definition of a part using a physical drawing. The drawing is used in conjunction with standards and procedures to provide information required in the manufacturing process. DFM Design for manufacturingan approach during the design and engineering phase that assures efficient manufacturing techniques will be used. Downstream technology Using off the shelf and existing technology to create a new product.
399
Draft In engineering, the angle required to easily remove a part from the tool used to produce it. Waffles come out of the waffle iron more easily if the vertical walls are angled. The same holds true for molded, stamped, forged, or cast parts. Drawing A 2D rendering done either by hand or on a computer. An Orthographic drawing uses multiple 2D views of an object to define it, e.g. a front view showing height and width, a top view showing width and depth, and a side view showing height and depth. Isometric drawings render the object in a single view. Engineering check model Check models are generated from engineering databases or engineering sketches. The purpose is to verify fit and configuration of components; the models are functional only to the level necessary to validate basic engineering details. Engineering release The release of all engineering documentation that is required to build a product, including the data required for creating the tooling. Ethnographic analysis The process of observing people as they interact with a product. To get the most useful information, designers must look without touching. They go to the site where the product is normally used, and observe carefully how people interact with the product, with one another, and with the organization to get the task done. The designers methodology is based on this principle: Don't interrupt, don't ask; just watch. Expert interview Scripted dialogue with someone who has considerable experience with products, processes, technologies, and/or users relevant to your design problem. Extrusion A manufacturing process that uses a softened billet of material that is forced through a shape (die) to allow for a continuous form much like a pasta maker. Extrusion tooling is relatively low cost, while piece parts are relatively higher cost.
400
Failure modes The ways in which a product or process may fail, thus limiting its ability to perform as required. Feature A specific design component or characteristic that embodies a function. See also Function. Field testing Test of one or more functions of a prototype in the actual conditions in which the product will be used. See also Lab testing. First articles The initial run of parts from production machines. FMEA Failure mode and effects analysisa systemized group of activities that are intended to: 1) recognize and evaluate potential failures of a product/process and its effects; 2) identify actions to reduce the chance of failure; and 3) document the process. Focus group A research technique that presents concepts and ideas to a targeted audience of 8-10 people at a time. Forcing function A constraint that enforces appropriate behavior. Thus, if the doors to an automobile cannot be locked without the key, it is impossible to lock the key in the car: a simple use of a forcing function. The fact that the car cannot be shifted from neutral or park unless the brake is applied is another forcing function. Function An attribute of a design that enables it to fulfill a requirement. See also Design requirements. Functional specifications A comprehensive, detailed, solution-independent list of what a product will do and how well it must do it. Written from the perspective of the engineer, the functions are usually specified in terms of measurable performance criteria.
401
Gantt chart A bar chart used to schedule group work by duration. It lists project tasks and subtasks on the vertical axis and time frames (weeks, months) on the horizontal axis. Can also include resources and associated costs. Hard tooling Generally refers to full production tooling designed to deliver the quantity of parts required for production. Hierarchical organization A formal method for sorting information into categories and subcategories. Human-centered design A design process in which the requirements of the human users take precedence over the technological requirements. HCD starts with observations to determine the real needs of the user, then uses an iterative process of rapid prototyping, rapid tests, and redesign, repeating as often as possible and each time completing more of the design. Industrial design Also I.D. The discipline that marries the engineering requirement to the marketing need through conceptualization of a product based on manufacturing processes and material properties. Injection molding A manufacturing process that uses melted plastic pellets injected into steel or aluminum molds, which ultimately result in finished production parts. Injection molded tooling usually costs more than extrusions, vacuum forming or blow molding, but has reasonably inexpensive piece parts. Interview guide A printed script used for interviewing a client, users, or experts. It normally contains an explanation of the purpose of the project and interview followed by questions listed in the order in which they will be asked. Lab testing Test of one or more functions of a prototype under simulated conditions. See also Field testing.
402
Latent defects Design flaws that are not obvious and that may surface during use of the product. One purpose of the Design review and early user testing is to uncover latent defects. LCD Liquid crystal display. Flat screen display often used in control panels. LCDs are also used in flat screen monitors and televisions. Lead times The tooling time required before production manufacturing can begin. LED Light emitting diode. Tiny D.C. lamps normally used as signals in control panels, i.e. ON / OFF switch with indicator lamp. Life cycle boards The assembly of visual images that best represent a reflection of the emotional wants and/or perception of the end user. Machine tool A power-driven tool used to cut, shape, or form material. Examples: lathe, milling machine. Often computer controlled. See CNC. Mating parts A general reference to two parts that join together. Meeting agenda A printed list distributed before a meeting of discussion items in the order they will be discussed. Often lists individuals responsible for presenting each item, time allocated for each, and pre-meeting preparation required for each. Mental model The belief and understanding that the person using the product has about the way it works. The mental model is a conceptual model of the system; if it is inaccurate, the user is apt to make errors or be confused. Mission statement A description of the project objective: the problem to be solved, target users and other stakeholders, and focusing assumptions.
403
Mockup Often called a sketch model, mockups are generated from thumbnails, concept sketches, or rough layouts with some dimensions. The mockup is representative of the general concept and is used to review general shape without fine details. Materials used often include cardboard, foam board, urethane foam, or equivalent. Model product A product that uses new technologies to perform functions similar to those of your design. The product may have completely different users and purposes than yours. Model, visual Generated from control drawings or CAD database, a visual model (or just model) is an accurate representation of the concept. Materials used in the model are chosen to achieve required finish and texture. Visual models are used to review shape, colors, graphics (if appropriate), and overall design intent. The model is non-functional and is visually perfect. All visual models are suitable for photography and marketing needs. MTBF Mean time between failuresa measure of responsibility for a manufactured assembly. Multiple cavity A reference to a tool that molds more than one part at a time. Multiple cavity tools are in odd numbers. The normal multiple cavity for a typical run of 50,000-200,000 may be 2-4 cavities, while very large quantities of small parts (i.e. disposable pens) may use 24-48 cavity tools molding millions of parts per year. Orthographic A drawing that uses a linear projection of views of the part. Minimal views required for an orthographic drawing include the front, side, and top views. Drawings are done in a line format manually or with a computer program. Paper tests A method for getting user feedback early in the design process, employing drawings and other simple representations of, for example, a user interface. Enables users to imagine using a design so they can be observed and questioned.
404
PCB Printed circuit board. A board that interconnects electronic components using a minimal amount of space with great cost efficiencies. Performance metrics Quantitative data that a designer will gather in order to know that a function has successfully fulfilled particular user needs or requirements. Pert chart A timing chart that identifies the critical path and/or the longest time path of dependent steps of a project. Piece parts The individual parts that make up the whole of a finished component or assembly of a product. Pilot build/pilot production The first assembly of all the component production parts, generally taking into account production assembly methods. Preliminary engineering Initial attempt to integrate all components into a manufacturable assembly. Output can be two-dimensional orthographic drawing, three-dimension wire frame, or solid model. Pre-production parts Parts that are made from production tooling but have not been tested or qualified for final production release. Press Injection molding press. The term references the core half and the cavity half that come together (press) in much the same manner as a waffle iron. Product analysis The process of examining a product in detail in order to understand what it does, how it does it, and why it does it. See also Competitive product and Model product.
405
Product specification A document that describes all the critical aspects of a product including but not limited to physical requirements, appearance, functional requirements, reliability, mechanical requirements, environmental concerns, electrical requirements, legal considerations, safety agency approvals, manufacturing requirements. Includes Functional specifications, and is sometimes referred to simply as the Specification. Progress report An informative formal report, usually intended for project supervisors, summarizing what has been learned about key issues over a specified period of time and what next steps need to be taken. The report may include attachments that provide specific data and documentation. Project definition A formal document containing the project's mission statement, stakeholders, key constraints, and specifications. The design documentation is revised several times during the course of a project to reflect the team's continuing research and thinking. Project notebook In DTC, a three-ring binder that contains all documents relevant to the design project: correspondence, meeting agendas, sketches, drawings, photos, design documentation, action plans, research summaries, etc. Each document is dated and signed by the team member who produced it. Proposal A persuasive formal report, intended for the client (and people in the client's organization with an interest in the project) and project supervisors, explaining the recommended design, its benefits, and its implementation. The proposal may include attachments that provide specific data and documentation. Prototype When referred to as part of the process, a prototype may be described as an Alpha (see definition). As opposed to an Alpha, a prototype will always be fabricated to replicate the production finish to include texture, color, and graphics. QFD Quality function deployment. A methodology for converting marketing requirements into engineering specifications.
406
Rapid prototyping Building prototypes rapidly so that the ideas can be tested immediately and quickly. See Mockup and Model (Visual). Rough paper sketches are often fine. Computer-generated drawing models are useful but not necessary. As the design process continues, mockups from foam, wood, or cardboard are appropriate, as well as mockups made using commercial rapid prototyping machines. Rapid prototyping machine Machines that transfer solid computer 3D models into 3D physical models and are completed in a very short time frame. Methodologies may include SLA (stereo lithography), SLS (selective laser sintering) and CNC (computer numerical control). Render Process that industrial designers use to visualize their ideas by putting their thoughts on paper with any number of combinations of color markers, pencils and highlighters, or computers. Shadowing Observing end users in their natural setting. Single cavity A reference to a tool that is built one up and produces only one part at a time. Sketch A rough two-dimensional rendering used to capture and communicate a design idea quickly. Sketch model See Mockup. SLA Stereo lithography apparatus, one of the most popular of the rapid prototyping techniques. The basic technology includes a vat of photosensitive liquid polymer and a laser that is controlled by interpreting a solid computer model. The laser interacts with the liquid polymer and solidifies the polymer layer by layer (.005-.010 thick) as it interprets the layers of the computer model. Within a matter of hours, the SLA device can produce a solid part from a computer file.
407
Soft tooling Usually used as a pre-production method of prototyping or manufacturing in order to verify designs and materials prior to full production-level manufacturing. Solid modeling Computer modeling technique where the output reflects a complete mathematical model of a physical entity (part). In solid modeling, it is not unusual to present in a 3-D format all components of a product in their virtual relationship. Using virtual reality the parts can be fully rotated for viewing of any surface. Students at Northwestern have access to programs such as SolidWorks, NX, and Pro-E. Specification See Product specification. Stakeholders Individuals, groups, and institutions that have a vested interest in the performance and results of a design. Structured group meetings A research technique that differs from a focus group in that the participants commit to a written portion before and after any open discussions. Surfacing Computer modeling technique where the output reflects only the surface of the part. These parts can be photographically rendered with outputs that resemble photography. The most popular program for surface modeling is Alias. Task analysis A detailed analysis of the requirements of the task and of how people typically accomplish the task, including detailed behavioral descriptions. It is particularly important to include the range of approaches that might be allowed (different people seldom do things in the same way) and to recognize the prerequisites and failure modes of the task. Three (3) D file An electronic mathematical representation of a part in a 3D format. Can be wire-frame, surfaces, or solids. (See CAD/CAE, Wire frame, Solid modeling).
408
Thumbnail The most minimal form of sketching that represents a product idea. Tooling The development of the fixtures, molds, and dies used in process machines for the production of finished parts. Tweaking The process of making minor adjustments to a tool to allow for fine-tuning and adjustments prior to running first articles. Upstream technology Creating a new technology that may be borrowed from some other usage for the purpose of creating a new product. User Person for whom the design will perform desired functions (i.e. end users) and the person who will interact with it in other capacities (manufacturing, installing, selling, repairing, maintaining, administering, etc.). User observation Extended observation of users interacting in real settings with actual products or processes relevant to the design problem. Before the observation, designers usually write a task breakdown, a flowchart detailing the steps required to perform the task or process that will be observed. After the observation, designers usually write an analysis that lists each key observation, the design opportunity it suggests, and the direction the designer should take to follow up on that opportunity. See also Task analysis. Wire frame Computer modeling technique in which the output reflects a complete mathematical model of the external edges of an entity (part). An engineering file that reflects an individual part, or assembly, is done using computer technology to allow for complete rotation of the part. A lower level of definition than Surfacing or Solid modeling.
409
410
Index
See also the List of Examples (pp. xvi-xix) and glossary of terms (Appendix Q). A
Active vs. passive verbs 259, 299 Agenda meetings 142, 403 oral presentations 274, 275 Alternative designs 396 Alternatives matrix 69, 70 Analysis, in testing record 85 APA source documentation 267, 389 Appendices in final reports 245 in progress reports 233 Attachments to emails 190, 199 Audience 177
B
Background research 31, 153, 327 Bill of materials (BOM) 108, 397 Brainstorming 62, 397 clustering ideas 66 example list of ideas 64 facilitator guidelines 63 ground rules 63 Bullet lists 206 consistency when using 285 in presentation slides 284
C
Case studies curbside mailbox 42 electronic kiosk interface 216 filing system 11 Grip&sip 64, 70 highchair footrest 47 one-handed food cutting 31 paper shredder 47 seat back storage 37 wheelchair softball 32 Clarity paragraphs 250
411
sentences 256 Client communication email 190 initial interview 24, 188 meetings 191 telephone 189 Client interview summary 323 Clustering lists of brainstorming ideas 66 Communication square 176 Competitive product 31, 398 Conceptual design 7, 107, 398 Conciseness 258 figure labels 209 poster text 298 progress reports 233 sentences 259 slide text 284 table headings 205 Conclusions final reports 245 oral presentations 279 progress reports 232 testing record 86 Conducting meetings 141 Constraints 52, 398, 406 compared to requirements 53 defined 50
D
Decision matrix 89, 398 Defects, latent 105 Demographics in user interviews 36, 40, 75, 399 Design and communication compared 8, 175 Design limitations 244, 383 Design process 5, 399 recursive 6, 47, 59 Design review 99, 399 Design thinking 4 Detailed design 7, 109, 399 Document design 204 Documenting sources 266 APA style 369, 385 MLA style 393 parenthetical citations 268
412
Email 195 client communication 190 guidelines 196 tone 198 Engineering release 400 Essays EDC I 310 EDC II 315 format 319 Ethics and the testing record 83 in design 112 Executive summary 241 examples 377 Expert interview 44, 91 sample guide 341 sample summary of results 343
F
Failure modes 401 Figures 208 examples 210, 211 Final reports planning 238 structure and content 238 FMEA 93, 401 Focusing assumptions in mission statements 51 Fonts in poster presentations 299 in presentation slides 284 written documents 208
G
Gantt chart 165, 402 Generating alternatives 61, 68, 396 Google Scholar 28 Grants, acknowledging 241, 245 Graphs 211
H
Headings 204 Here 156

I
Instructions 219
413
audience 220 dangers 221, 222, 224 illustrations 224 organization 221 purpose 220 revising 224 Interviewing clients 24, 323 experts 44, 91, 341, 343 users about their needs 34 Introductions analytical essay 312 client interview guide 25 expert interview guide 46 final report 242, 379 instructions 222 persuasive essay 316 progress report 230 user interview guide 35
L
Latent defects 105, 403 Leadership 133 Learning goals 9 communication 10 design 9 teamwork and project management 10 Limitations testing record 86 Limitations, Design 383 Limitations, final report 244 Lists bullet 206 numbered 206
M
Margins, in documents 204 Matrix alternatives 69, 70 decision 89 Meetings agenda 142, 403 conducting the meeting 145 minutes 147 participation guidelines 147 with instructors 149
414
Methodology, in testing record 84 Mission statement 51, 403 definition 49 focusing assumptions in 51 in presentation slides 284 in project definition 59, 406 solution-independence 51 MLA source documentation 267, 393 parenthetical citation 269 references 268 Mockup 404 Mockups for user testing 70 role of the shop professionals in building 71 Model product 31, 404
O
Observing users 39, 327, 331, 335 Online sources evaluating credibility 30 search methods 29 Online sources, research using 28
P
Parallel structure 206, 220, 285 Parenthetical source citations 268 Passive vs. active verbs 259, 299 Performance testing 77, 359 reporting on 81, 84 sample guide 78 sample report on results 359 Performance testing report 359 Poster presentations 295 examples 303 poster design 296 preparing the presentation 300 Presentations oral design presentations 273 poster presentations 295 Primary users 54 Print sources research using 27 Progress reports 227, 369, 385 editing 233 examples 369, 385 organizing 229
415
planning 228 Project definition development of 59 format 58 Project deliverables 52 Project folder 151 contents 152 Project scheduling 161 Prototype in final presentations 290 in poster presentations 302
R
RAM chart 162 for planning project tasks 164 for planning team writing 156 Redundant wording 261 References formatting 267 in final report 245 in progress report 232 Requirements 54 and specifications 88 client 55 community 56 in presentations 279 primary users 55 Research plan 20 Responsibility Allocation Matrix (RAM) 162 Revising paragraphs 250 sentences 256 transition words 253
S
Scenario 43 Shop working in the 71 Slides, in oral design presentations 282 Specifications 57 Stakeholders 54
T
Table of contents example 375 in final report 240
416
Tables 214 examples 38, 42, 76, 215, 216 Team charters 129, 369 Teamwork conflict, dealing with 135 leadership 133 successful teamwork 127 Thesis statements 312, 316 Title page 239 Tone 176, 178 in email to clients 198 in instructions 220 Topic sentences 250 Transitions in paragraphs 254
U
User observation and interview examples 335 planning 327, 331 summary of results 42, 335 User profile 42 User testing examples 355, 363 reporting on 81 summary of results 76 Users 409 primary 54 secondary 54 testing 74, 355, 363
W
Writing as a team 141, 155
417
418
ABOUT THE AUTHORS
John C. Anderson is a lecturer in the Segal Design Institute, where he also serves as Instructional Technology Coordinator. He has taught courses in literature and composition at Northwestern for more than twenty years. He received his B.A. from the University of Michigan's Residential College and his M.A. from Northwestern University. Stacy L. Benjamin is Director of the Certificate in Design Thinking for the Segal Design Insti-tute. She is part of the teaching team for undergraduate Design Thinking courses and she mentors student teams on multi-disciplinary and multi-year project. One of these projects, the Nberwalker, received the international daVinci Award for universal design. Prior to joining Northwestern, Benjamin worked for nine years at the design firm, IDEO, as a senior project manager and mechanical engineer. Mark L. Bourgeois is the administrator of the Northwestern Center for Engineering Education Research (NCEER) and was previously an engineer in the telecommunications industry for firms such as Lucent Technologies. In addition to DTC he teaches medical and research ethics in a number of courses and summer programs in the Biomedical Engineering department. He also created and instructs the highly regarded Continuing Studies graduate course Ethical and Legal Issues in Regulation. He is a Ph.D. candidate in philosophy at Loyola University Chicago, with undergraduate degrees in physics and philosophy from the University of Illinois at Urbana-Champaign and an M.A. from Miami University, Ohio. Kathleen Carmichael, a lecturer in the Northwestern University Writing Program, teaches courses in composition and engineering communication. Her instructional strategies are informed by more than eight years of experience as a securities analyst, public relations specialist and educational consultant. Carmichael received her Ph.D. from Northwestern University. Jeanne W. Herrick is a faculty member in Northwestern Universitys Writing Program where she teaches courses in engineering writing at the undergraduate and graduate level, expository writing, and academic writing for international students. Herrick also consults with the law school on cross-cultural issues and ESL legal writing. Drawing on her ten years experience in sales and marketing for CBS television, Herrick, as managing partner of Herrick International, also consults with business organizations on intercultural issues, communication, leadership, performance management and project management. Her research interest is sociolinguistics, the study of how peo-
419
ple from different cultures and language groups communicate with each other. Herrick earned her Ph.D. from the University of Illinois at Chicago. In 2006, she received the School of Continuing Studies Distinguished Teaching Award. Penny L. Hirsch is Associate Director of Northwestern's Writing Program and Co-director of Design Thinking and Communication. For seven years she was the project leader for communication in the National Science Foundationsponsored VaNTH (Vanderbilt-Northwestern-Texas-Harvard/MIT) Engineering Research Center in Bioengineering Educational Technologies. In those roles, and as a partner in her own consulting firm, Communication Partners, she has run communication workshops for hundreds of professionals in law, medicine, healthcare, biotechnology, project management, and engineering. Hirsch earned her B.A. at the University of Michigan and her Ph.D. at Northwestern, where she was also recognized for teaching excellence as the University's inaugural Charles Deering McCormick University Distinguished Lecturer. Barbara L. Shwom, past president of both the international Association for Business Communication and the Association of Professional Communication Consultants, teaches writing in three schools at Northwestern University: the Weinberg College of Arts and Sciences, the McCormick School of Engineering, and the Kellogg School of Management. She also directs the universitys peer tutoring center, The Writing Place, and is the managing principle of a consulting firm, Communication Partners. A frequent presenter at professional conventions, Shwoms research interest is graphical and mathematical communication. She earned her Ph.D. at Northwestern University and has received several esteemed awards for her teaching and professional service. Deborah Leigh Wood worked for 14 years at the Chicago Tribune as a reporter, feature writer, arts reviewer, copy editor, and special sections editor. She also served as assistant editor of the alumni magazine of the Kellogg School of Management at Northwestern and was the main contributor to the coffee-table book Chicago: Heart and Soul of America. Before coming to DTC, Wood taught undergraduate and graduate copy editing at NUs Medill School of Journalism. She currently is an editor and writer at the Baha'i National Center in Evanston. Wood has a masters degree in interdisciplinary arts, a performance-based program that gave her a whole different set of communication tools. Charles Yarnoff, a Northwestern Ph.D. and faculty member in the Writing Program, has taught Design Thinking and Communication since its inception. In addition to technical writing, Yarnoff teaches courses in essay and fiction writing and literature courses on 19th and 20th century American fiction and poetry. He is co-director of the University's Summer Academic Workshop and serves as a freshman advisor in WCAS. Yarnoff has twice been named to the Associated Student Government's faculty honor roll, was recognized for teaching excellence when he was chosen as Northwesterns Charles Deering McCormick University Distinguished Lecturer for 2009-10, and has received the School of Continuing Studies Distinguished Teaching Award.
420

DTC Textbook

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DTC Textbook

Uploaded by

Copyright:

Available Formats

Design Thinking and Communication

Principles and Practice

Copyright 2003-2013 Northwestern University

Chapter 3: Writing the Project Definition ............................. 49

3.9 References ................................................................................................60

Chapter 4: Generating Alternatives ...................................... 61

Chapter 5: User and Performance Testing........................... 73

Chapter 6: Reporting on User and Performance Testing ... 81

Chapter 7: Deciding on a Design Concept........................... 87

Chapter 8: Failure Modes and Effects Analysis .................. 93

Chapter 9: Conducting Design Reviews .............................. 99

Chapter 11: Ethics and Design............................................ 111

Teamwork and Project Management

12.4 References ............................................................................................132

Chapter 13: Developing Leadership and Managing Conflict ........................................................... 133

Chapter 14: Conducting Meetings ...................................... 141

Chapter 15: Keeping a Project Folder ................................ 151

Chapter 16: Writing as a Team ............................................ 155

Chapter 17: Project Scheduling .......................................... 161

Chapter 19: Client Communication..................................... 187

Chapter 20: Email and Other E-communication ................ 195

Chapter 22: Instructions ...................................................... 219

Chapter 23: Progress Reports............................................. 227

Chapter 24: Final Reports.................................................... 237

Chapter 26: Documenting Sourcesand Avoiding Plagiarism ........................................................................ 265

Chapter 27: Oral Design Presentations.............................. 273

27.2.5 Rehearsing the presentation........................................................292 27.3 References ............................................................................................293

Chapter 28: Poster Presentations....................................... 295

Chapter 29: Writing Essays about Design ......................... 309

DTC course goals

A case study: real clients, real projects, real audiences

Key guidelines for the design and communication process

1.1 WHY TEACH DESIGN AND COMMUNICATION TOGETHER?

Mock-up and Test Alternatives

Refine the design

Decide on Design Direction

Figure 1.1: Recursive design process

Conceptual design vs. detailed design

Communication: a central design activity

Table 1.1: Comparing design and writing

Defining the problem

Making mockups Testing the mockups

Building more mockups Presenting the final deliverables

DTC COURSE GOALS

Teamwork and project management goals

1.3 A CASE STUDY: REAL CLIENTS, REAL PROJECTS, REAL AUDIENCES

Understanding the background: what the client wants

Becoming an expert and identifying the problem

Figure 1.2: Initial view of clients desk

Generating alternatives: What ideas might lead to solutions?

Figure 1.7: Final drawing for the tri-level organizer

Chapter 2: Defining and Researching the Problem

CHAPTER 2: DEFINING AND RESEARCHING THE PROBLEM

Key guidelines for defining and researching the design problem

Chapter 2: Defining and Researching the Problem

2.1 DEVELOPING A RESEARCH PLAN

Chapter 2: Defining and Researching the Problem

2.1.1 Generate a list of questions

Chapter 2: Defining and Researching the Problem

2.1.2 Group related questions into categories

Chapter 2: Defining and Researching the Problem

2.1.3 Identify likely sources to answer the questions