Dtc Textbook

Design Thinkingand Communication

Principles and Practice

2013 EDITION

Charles YarnoffJohn AndersonStacy BenjaminMark BourgeoisKathleen CarmichaelJeanne HerrickPenny HirschBarbara ShwomDeborah Wood

Copyright © 2003-2013 Northwestern University

iii

Table of Contents

Introduction

List of Figures .............................................................................................. xiiiList of Tables..................................................................................................xvList of Examples ...........................................................................................xviAcknowledgments.........................................................................................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

iv

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

v

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

vi

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

vii

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

Chapter 13: Developing Leadership andManaging 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

viii

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 Communication—Document 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

ix

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

x

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 Sources—and 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

xi

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

xii

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

xiii

List of Figures

Figure 1.1: Recursive design process...............................................................6

Figure 1.2: Initial view of client’s 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 presentation’s 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

xiv

xv

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

xvi

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

xvii

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

xviii

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 ofthe 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

xix

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 in-dustry from charges of ethical irresponsibility ......................................317

Example 29.9: Introduction of persuasive essay on importance of DTC project....................................................................318

xx

Example 29.10: Introduction of persuasive essay arguing that a design is ineffective ........................................................318

xxi

ACKNOWLEDGMENTS

The authors of the textbook would like to acknowledge the contributions ofseveral colleagues who have had a significant influence over the past sixteenyears on Design Thinking and Communication (DTC) and the development ofthis book.

Key principles of user-centered design that inform DTC and this book camefrom thoughtful input provided by two of the world's leading design firms:Herbst Lazar Bell, Inc., and IDEO Product Development. Particular thanksfor their contributions in this area go to Walter Herbst, a founder of HerbstLazar Bell, and to Stacy Benjamin, John Lake, and Amy Schwartz, who haveall worked for IDEO.

Edward Colgate, David Kelso, and Gregory Olson, professors of engineeringat Northwestern University, contributed substantially to course materials thatwe used as the basis for the current textbook. Clive Dym of Harvey MuddCollege taught with us when the course was in its pilot stage, and also helpedus develop our model of teaching user-centered design. Walter Herbst, thedirector of Northwestern's Master of Product Development Program, providedmany of the book's glossary entries. Don Norman of Northwestern Universityand the Nielsen Norman Group also contributed to the glossary. MichelleGreenberg of Northwestern’s Writing Program contributed important materialto the discussion of written communication. Matthew Glucksberg of North-western’s Department of Biomedical Engineering offered valuable advice onuser observation. Phillip Jacob, project coordinator for DTC, made key contri-butions to the chapter on client communication. David Gatchell, Director ofthe MaDE degree program in Segal, contributed a team charter example.Adam Goodman, Director of Northwestern’s Center for Leadership, contrib-uted valuable material to the chapter on creating a high performance team.

In preparing the book, we were assisted by several colleagues who reviewedsections of the text, including Bruce Ankenman, Jeanine Casler, Leslie Fis-cher, Ann McKenna, and David Sabo. The cover and several graphics weredesigned by Craig Stehle, who also helped plan the layout of the book.

We are grateful for everyone’s assistance and support.

xxii

PART ONE

INTRODUCTION

1

2

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

• DTC course goals

– Design

– Teamwork and project management

– Communication

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

– Understanding the background: what the client wants

– Becoming an expert and identifying the problem

– Generating alternatives

– Proposing a solution

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

3


• Throughout the process, employ good teamwork practices and effec-tive project management to ensure a high quality final product

The idea of design—of making something that has not existed before—is central to engineering.

– Henry Petroski, To Engineer is Human (1985, p. xi)

This textbook for Design Thinking and Communication ( DTC) will introduceyou to what most people consider the heart of engineering: complex problemsolving that leads to new products and solutions. The text has been writtenjust for you—McCormick freshmen in the introductory course in design andcommunication. DTC teaches you design while you actually do design. Fromthe beginning, you'll be working on real projects—involving real people whoneed your products and audiences who are not simply your instructors. Thetextbook will introduce you to the design and communication process you’llneed for doing that work well.

The best way to use the textbook is to read the required sections listed in thesyllabus, and then to review the specific sections that are relevant to yourprojects 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 pyra-mids, roads, or computers. It is the designer or engineer who synthesizes thesenew forms, who develops the ideas, goals, and requirements for the produc-tion of bridges, automobiles, and electric guitars. Henry Petroski, professor ofCivil Engineering at Duke University and author of Invention by Design: HowEngineers Get from Thought to Thing (1996), says that design and develop-ment distinguish engineering from science. Scientists primarily want tounderstand “the world as it is,” whereas engineers “wrestle” with ways toerect great monuments, or design defenses against enemies, or move peopleand goods across rough terrain (p. 2). Engineering, Petroski explains, is the“art of rearranging the materials and forces of nature” (p. 1).

Petroski’s formulation suggests that design thinking in engineering is as muchan art involving creativity as it is a rational process requiring a deep under-standing of science and technology. Moreover, since engineers design prod-ucts and systems intended to be used by people, design thinking must be“human-centered” and engineers must put themselves in the place of andempathize emotionally with those who will use their designs. Engineers needto understand the problem from the users’ point of view.

4


Because design is a creative process that varies from person to person, there isno one right way to do design. Nonetheless, most descriptions of design pro-cess include interrelated steps like the following, the steps we use in DTC andin 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 todevelop your designs. Like the main steps, these aren’t always done in thesame order. That’s because the design process is essentially iterative ratherthan sequential. Design engineers don’t just start at the beginning of a list ofsteps 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 asthey gain additional knowledge. The list above provides a hint of this in theiteration of steps that involve building mockups, testing, and revising thedesign.

5


Figure 1.1: Recursive design process

In your spring quarter projects, for example, your client may tell you that shewould like to develop a new type of automobile seat belt that can be fastenedeasily by people with arthritis. You will do research: interview seat beltexperts, analyze competitive and model products, and observe potential users.Based on this information, you will mock up some alternative designs thatyou think will accomplish your client’s and users’ needs. However, once youtest these mockups on users, you may find that users actually want somethingquite different from what the client first described to you and from what theywere originally able to imagine. So you go back to your client with this infor-mation, and may end up redefining the problem and designing a radically dif-ferent product, such as a handheld device that helps people manipulateexisting buckles. With this new idea in mind, you go back to users and expertswith new mockups. The design process is just as much a loop as it is a line:you continually move forward—closer to your goal—but not without retrac-ing many of your steps. As Tim Brown (2009), CEO and president of a lead-ing 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

��

��

��

��

��

� ��

� ��

� !�� "��#��

� �� $��

� ��#� ��#

��

� �� %� &�� '� ��#��

� (�� )�� #�� *��

6


ongoing process without disruption. At other times the dis-coveries 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 solutionto a problem but not performing all the calculations and the evaluations ofcomponents, materials, and manufacturing processes necessary for implemen-tation of the design. Detailed design, by contrast, is the process of performingnecessary calculations and evaluating components, materials, and manufac-turing processes in order to see a design through to implementation.

Beginning engineering students aren’t expected to take a project all the waythrough to detailed design. To do that, you'll need more advanced knowledgeof math, physics, and computers, and you will need to acquire expertise in aspecific engineering discipline, such as chemical engineering or materials sci-ence. DTC stresses conceptual design. Later in your engineering career, youwill take your design ideas through implementation.

Well before that time, however, you can familiarize yourself with design pro-cess and develop ideas for solving problems. That way, by the time you workon a capstone project as a senior or take a job in industry, you will alreadyknow how to define problems, generate alternatives, interview clients, writereports, and give presentations. You will also understand something about theethical issues that are prominent in design and the role that design plays insociety.

1.1.3 Communication: a central design activity

It makes sense to study communication while you study design because com-munication is an integral part of design: the design process requires communi-cation at every step of the way. In their book, The Engineering DesignProcess (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

7


stated and a record can be established for future reference (p. 470).

As a design engineer, you'll have to communicate with experts, clients, andteam members. You’ll be communicating not only when you write reports andgive oral presentations, but also when you sketch ideas, build mockups, andprovide graphs and equations. You’ll need strong interpersonal skills forworking successfully in client and team meetings. You’ll need to write min-utes, memos, emails, and project plans just to organize your work.

But the connections between design thinking and communication do not endthere. A real design, as opposed to a fuzzy idea, is something you can articu-late 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:

Like the design process, the writing process is iterative; that’s why writers calltheir different drafts “revisions” (“re-vise” means “to see again”). You canwrite a clearer final report once you ask a reader to review it. You can figureout if a set of instructions is clear by watching people try to follow it.

Good communication, then, isn’t just a matter of correct grammar and punctu-ation—or of eloquence and style. Rather, it’s a form of problem solving, likedesign. This is especially true of long, complicated documents that require

Table 1.1: Comparing design and writing

Design Writing

Gathering information Collecting the information you need to communicate

Defining the problem Identifying your main point, audience, and purpose

Generating alternatives Outlining different ways to organize the information

Making mockups Writing a rough draft

Testing the mockups Getting feedback from peers and instructors

Building more mockups Revising the draft

Presenting the final deliverables Delivering the final version of the report, proposal, and/or oral presenta-tion

8


clear organization of complex material along with visual cues, such as head-ings, to show readers where to find information.

Engineering students often worry about writing and presenting; you may feelmore comfortable with numbers and sketches than with sentences and para-graphs or with presentation skills. If so, then DTC should put you at ease; thiscourse will show you that good problem solvers have the logical ability to begood communicators, too. In both design and communication, you’ll use youranalytical skills to succeed.

1.2 DTC COURSE GOALS

Over the years, there have been DTC students who have approached thecourse as if there were nothing new to learn; they say that design and commu-nication are simply common sense, that all a designer needs is intelligenceand ingenuity.

But that is not true. If it were true, then there would not be so much bad designin the world. If it were true, then the course would not have the support of topengineering and design firms who say that DTC teaches what students need tolearn. If it were true, then employers would not value the abilities of our topdesign students so highly. And finally, if it were true, then we would not hearback from graduates who say what they learned in DTC was immediatelyapplicable in their jobs—and they are grateful to have learned it.

The fact is that design and communication, while not overly difficult, are alsonot intuitive. There is a lot to learn in DTC. Not only will the course give youan opportunity to apply what you are learning in Engineering Analysis (forsome projects), but it will also teach you skills and processes that lead to val-ued results.

The three lists below detail the learning goals of DTC in its three major areas:design, teamwork (including project management), and communication. Allof the topics are discussed in this textbook. Look over these lists at the begin-ning of the course to get an idea of where you will be going in DTC. Then atthe end of each quarter, review them. You may be surprised at how far youhave come.

1.2.1 Design goals

In DTC, you will learn how to:

• define engineering problems clearly and precisely with the client’s 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.

9


• 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 draw-ings

1.2.2 Teamwork and project management goals


• 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


• use writing and speaking to help develop and communicate design concepts

• use the writing process—gathering information, planning, drafting, and revising—to produce clear, concise, and persuasive documents

• write documents commonly used in engineering such as final reports, progress reports, technical posters, instructions, emails and Power-Point 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 areas—design, teamwork,and communication—in relationship to a design engineer's ethical obligationto make safety, integrity, and social responsibility a fundamental part of his orher 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 willlearn 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, andone 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 Coordinatorfor Industrial Engineering and Management Science in Northwestern Univer-sity’s McCormick School of Engineering, came to DTC with the request thatstudents design something that would help her to organize the large number ofpapers, folders, brochures, and pamphlets she kept on her desk. She was wellaware that office supply companies sell numerous filing cabinets, trays, andother equipment for this purpose. However, she believed that she would bebetter served by a revolving under-the-desk file cabinet tailored to her specificneeds. She was not looking for a product that she could market but rather onethat she could use to help her work more efficiently.

1.3.2 Becoming an expert and identifying the problem

Ms. Stuart’s description of the problem was helpful to the Filing System team,but they wanted to understand the problem better before agreeing that herdescription was correct and that her proposed idea—a revolving file cabinet tobe stored under her desk—would be the best solution. They needed to see forthemselves exactly how Ms. Stuart organized the material on her desk andwhat was ineffective about her methods. Therefore, they made an appoint-ment to meet in her office to learn about the problem firsthand. To prepare forthis meeting, they wrote a detailed script of all the questions they wanted toask. At the meeting, they not only asked her about her current methods oforganizing her desk, her problems with those methods, and her under-the-desk

11


solution, but they took photographs that they could analyze later (see Figure1.2).

The team also arranged to have a member return later in the week to spend anhour observing her as she went about her daily routine. This observation ses-sion proved invaluable in providing the team with an understanding of theproblem. Of particular importance was their observation that Ms. Stuart wasvisually oriented: she had to be able to see the needed materials on her deskclearly. If a file folder was hidden by something else, she tended to forgetabout it. This observation suggested that an under-the-desk solution would notbe appropriate because everything in that file cabinet would be hidden fromview.

Figure 1.2: Initial view of client’s desk

To further understand Ms. Stuart’s problem, the team interviewed andobserved other Northwestern program coordinators who were successful inorganizing their desk space. The students learned that these people’s successlay as much in organizational habits they had developed over the years as intheir specific desk equipment. For a short time, then, the team thought thattheir problem was to change Ms. Stuart’s habits by writing a set of instruc-tions for organizing her desk space. However, further observations and inter-views with Ms. Stuart persuaded them that her habits were so ingrained thatthis was an unrealistic goal. So they defined their problem as designing aphysical structure that would:

• significantly improve Ms. Stuart’s 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 documentcalled 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 alterna-tives for solving it. They brainstormed a large number of design ideas rangingfrom labeled trays, sliding shelves, and color-coding to wild ideas like ascrolling marquee of reminders. They also looked online at office supplycompany websites for ideas. Using all of these ideas, as well as the list of keydesign requirements they had compiled, the team generated three alternatives,which they quickly mocked up using foamcore. The team’s sketches of two ofthose alternatives (which they called “stackable sloped tray” and “lazysusan”) 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 usedto solicit additional information about possible features for the design. Forexample, which orientation of her papers would Ms. Stuart find easier to workwith: 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 herinstructions on how they thought it might be used. In each case, they returnedthe next day and interviewed her—using an interview script they had writtenfor this purpose—on what she did and did not like about each mockup.

With her responses in mind, they developed two new alternatives that had fea-tures of the previous mockups but were in general quite different. One—nowcalled “the filer”—incorporated the lazy susan idea but used a different con-

13


figuration of dividers. The other mockup—now called “the big one”—usedslanting shelves but no longer in stacked trays (because Ms. Stuart found itdifficult 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 instructorsand 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 torecommend both design concepts to Ms. Stuart. They fine-tuned both designs,

14


drew up dimensioned drawings (see Figure 1.7 for a dimensioned drawing forone design, now called “the tri-level organizer”), and presented their solutionto Ms. Stuart in an oral presentation and written final report. They also gaveher the more complete of their two mockups—the “Rotational Filer”—whichshe was delighted with and eager to use.

As you can see, the Filing System Design Team followed the design processdescribed earlier in this introductory chapter, but performed many of the stepssimultaneously or recursively. Communication was a key part of the processthroughout: 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 you’ll beworking on, you should take time to do research and come up with your owndefinition. There are two reasons for this: (1) The client may not have definedthe problem correctly, and (2) Studying the problem gives you a better graspof the project.

19


To understand the importance of correctly defining the problem, consider theproject described in Chapter 1. What the client defined as the problem wasactually a solution: an under-the-desk revolving file cabinet to help her orga-nize her papers. After observing that she was visually oriented, however, thedesign team concluded that she would do better with a system that wouldallow her to see her papers at a glance. In other words, they defined the prob-lem in “solution-independent” terms.

To appreciate the value of extensively researching the problem, consider asecond scenario. A design team was charged with preventing a child withDown Syndrome from repeatedly chewing on her fingers, a behavior that wasresulting in recurring infections. Although the mother had presented the prob-lem clearly, team members felt they needed to make themselves experts tosolve the problem in the best way. So they observed the child, talked to thechild’s physical therapist, and read studies on the behavior and developmentof Down Syndrome children.

Early in a design project, you can use the following methods to research aproblem 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 devel-oping 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 ofthe problem and gather information efficiently. The best way to develop a use-ful 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 tounderstand the design problem thoroughly. To avoid overlooking any aspect,generate every possible question you can think of. You can weed out overlap-ping questions later.

Here is an example of questions generated by a team designing a device toenable 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, thatwe need to consider?

What aspects of crocheting do the client, users, and other user groupswant 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 useit? 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 andcons 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 currentlyaddress 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, phys-ical 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 pre-ferred 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 userscoordinate 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 thearthritis 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 teamgrouped 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 doesthe 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 prosand cons of these devices?

If they don’t use a commercial adaptive device, how do users cur-rently address the problem? Does what they’re doing work?

22


What’s the best material to use for a crochet hook?

What are the preferred dimensions of crochet hooks used for a similarpurpose?

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 usergroups want the device to improve?

How easy would it be for a person to adapt to such a device or tolearn 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. Thesources that the crochet team decided to consult appear in parentheses aftereach category of research questions below. For some sources, the team wasintentionally vague until members obtained specific names and titles.

Example 2.3: List of potential sources

• Causes and extent of the disability (client, physical therapists, medi-cal 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, physi-cians, 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 anentire category of questions can be answered by consulting medical textbooksand databases, you might assign that category to a single team member. Inother cases, you may need to consult a single source to answer questions inseveral categories. Your client, for instance, can usually answer a wide rangeof questions, so you might assign one or two team members to write interviewguides containing questions from multiple categories. The next section of thischapter explains how to write interview guides that you can use to gatherinformation from clients, users, and experts.

Finally, you should document team members’ research assignments in aResponsibility Allocation Matrix (RAM) chart, which is discussed in Chapter17.

2.2 CONDUCTING THE INITIAL CLIENT INTERVIEW

The initial client interview serves to help you begin to define the design prob-lem and learn about user needs and other requirements. To gain as much aspossible from this interview and to establish a good working relationship withyour 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 accommo-date yourselves to his/her schedule. Tell your client that the interview willtake about an hour. You may finish early, but that’s better than not schedulingenough time.

2.2.2 Assign roles

If more than one team member will attend the interview, decide who will askthe questions and who will take notes. Even if you tape record the interview,

24


you should still have a note-taker in case there’s a mechanical problem withthe recorder. Also, be sure to get the client’s 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 client’s written description of the project), brainstorm a list of needs for vari-ous 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 wantsthe design to achieve, who the users and other stakeholders are, what theyneed, and what constraints affect your design.

Although your questions will depend on the nature of your project, the Sam-ple Interview Guide below gives you some helpful generic questions that youshould adapt to meet the needs of your project.

After the interview, a team member should draft a concise, well-organizedsummary for team review and records. In spring quarter, you will send thissummary to your client after your instructors review it.

Your team should then meet to decide your next steps on the project, based onthe information gathered at the interview.

Example 2.4: Sample interview guide

(Note: You will need to adapt these generic questions to suit your spe-cific client and project.)

Begin your guide by introducing your team and briefly explaining what you willprovide for your client: (1) a written report and final oral presentation thatexplain your design concept, research, and recommended next steps, and (2)a prototype that shows key functions of your design but is not necessarily afully functional product.

1. Questions about the client (these are particularly important when your cli-ent 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?

2. Questions about the problem:

• 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 don’t you like about it and why?

3. Questions about users and other stakeholders:

• Who will be the end users of this design? (NOTE: Encourage your cli-ent 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, manufac-ture, or sell it?

4. Questions about requirements, features, constraints, and other designs:

• What requirements do you have for the design? Why are they impor-tant 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 proto-types?

5. Questions about research:

• Can you suggest experts or other people we should talk to regarding the project?

• Can you suggest relevant books, articles, and websites?

6. Questions about the follow-up:

• How often would you like to receive email progress updates?

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 inter-view 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 misinter-pret 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 readerscan easily find the key information they are looking for. Despite having awell-organized list of interview questions, you may find that your client attimes threw out information helter-skelter. That means that you can’t just typeup your notes in the order in which you wrote them down. Instead, you’ll needto organize them into logical categories. These categories will probably not bethe same as the categories you used to organize your questions in the inter-view script.

For an example of one team’s summary of their first client meeting, seeAppendix A.

2.3 USING PRINT AND ELECTRONIC SOURCES FOR RESEARCH

All DTC projects require you to do research—not only direct meetings withclients and users, but also research in print and electronic sources.

Print sources include textbooks, handbooks, specialized encyclopedias, scien-tific journals, trade magazines, newspapers, catalogues, pamphlets, and gov-ernment publications. There are two reasons to consult print sources: (1)Often, the information you need is available only in print. (2) Print sourcesoften provide greater detail than do websites and interviews. Print sources areespecially useful for getting background and technical information. For exam-ple, if you want background information about a medical condition, it’s betterto use a textbook or an authoritative encyclopedia than a source like Wikipe-dia or How Stuff Works, which are fine for personal reference but aren't con-sidered authoritative sources for a formal report. Your engineering instructorcan refer you to the standard textbooks relevant to your project.

27


Electronic sources include websites, networked databases, and electronicmagazines, newspapers, and journals. Northwestern subscribes to a hugenumber of electronic resources that can be accessed through the NU librarywebsite: http://www.library.northwestern.edu/. For information on scientifictopics in general, use Web of Science. For articles related to the biomedicalfield in particular, use PubMed. There are numerous other databases to whichyour instructors and NU librarians can refer you.

2.3.1 Using Google Scholar®

Google Scholar®, which is different from Google®, is a particularly usefulway to find electronic sources that have the kind of credible research materialyou need for DTC projects. This search engine allows you to find specializedjournals that contain more detailed, technical information than you are likelyto get from general websites on Google®. In addition, the journal articles aregenerally “refereed,” meaning that before being published they go through arigorous process of review by recognized experts. You can also use GoogleScholar® to find patent information on designs that address the same problemas yours.

Here's how to search for information using Google Scholar®:

1. After going to Google to find Scholar, type in your search terms. Fig-ure 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 sub-scribed 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 it’s often desirable to have the most recent available infor-mation on a topic, you can specify that you only want to see articles after aspecific year. In Figure 2.3 below, the dropdown menu in the green bar hasbeen 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 atthe 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 Ref-erence 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. Todo that, consider the following questions:

• What is the author’s 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 documen-tation?

• Does the source have an obvious bias that makes its objectivity and reliability suspect? A team working on a wheelchair ramp was inves-tigating 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 com-pany 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 sev-eral ways:

• in the body of reports and presentations, to support your findings and decisions (see Chapter 26 for a discussion of principles of source doc-umentation)

• in the References pages of reports (see Appendices O and P for exam-ples of formatting)

• in appendices of reports

• in your online project folder

For an example of one team’s summary of their background research, seeAppendix B.

2.4 ANALYZING COMPETITIVE AND MODEL PRODUCTS

Much of what you will be searching for as you begin your research are exist-ing products that fulfill the same or similar functions as needed in yourdesign. Analyzing existing products allows you to identify strengths andweaknesses of previous solutions to your design problem and helps youunderstand why and how well these products work.

A competitive product is one that is geared to your users and their intendedapplication, regardless of the technology it employs. For example, severalteams recently designed a utensil that would enable stroke survivors with theuse of only one hand to cut food when they dine in restaurants. Using theInternet, the teams found pictures of and specifications for several existingproducts—a wide-bladed knife, a t-handle rocker, a saw-shaped knife, andothers—intended for the same user group and purpose. The most valuablecompetitive 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 aredesigning but is intended for different users and applications. For example,the teams who worked on the food-cutting utensil analyzed manual rotary fab-ric cutters used by quilters and pruning shears used by gardeners to gatherideas 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 thatshuts off automatically, you may want to analyze the auto-shutoff system inelectric irons and alarm clocks to determine if these technologies apply toyour product.

2.4.1 Analyzing competitive products

Begin by analyzing the product you've been asked to redesign or others thataddress 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 wheel-chairs 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 draw-ing 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 duct-taped 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 prod-uct 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 analyz-ing the photos and specifications they found on websites. The fol-lowing example provides the team’s 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 foodrather than the “dragging” method used by most knives. Certain models ofthe Rocker are collapsible, making it easy to transport to restaurants andother dining locations. It simply folds into its ergonomic handle, as in apenknife, to make it easy and safe to carry. A key disadvantage of thisdesign 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 ina dining setting.

The Saw is designed so that the handle of the knife is perpendicular to theblade for maximum leverage and ease in cutting. Like a saw cutting apiece of wood, this model uses the dragging motion to cut the piece offood. It is designed to transfer the cutting power from the arm to the cen-ter of the blade with minimal effort. The grip is large, comfortable, and fitsnaturally in the hand. Though this design may seem effective, it has twomajor flaws. First, it needs a strong stabilization device to keep the foodfrom sliding along with the knife. And it requires a long blade to be effec-tive, which is inconvenient for someone who wants to travel with the uten-sil.

The team’s analysis of competitive products helped them to focus on keyproblems they would have to solve, such as: How would they stabilize thefood if their design used a conventional sawing motion? What kind of devicewould minimize the upper arm strength needed to cut food? What are themost comfortable kinds of grips for various cutting devices? How would theymake the device portable? In addition, the analysis gave them ideas fordesigning the subsystems of their product, such as a penknife design to retractthe blade.

Because you will use the results of your competitive products analysis tomake design decisions, you must take care to be accurate. The team redesign-ing the crowded office space paid dearly for inaccuracy when memberslearned fairly late in the design process that they had mismeasured the size ofthe desks. As a result, the cubicles they had designed would be too small toaccommodate the desks, so they had to go back to the drawing board and lostvaluable time.

33


2.4.2 Analyzing model products

Look for model products that use technologies to perform functions similar tothose of your product. Analyze these model products by asking “how?” Ateam designing a bicycle headlight that would quickly attach to and detachfrom handlebars of any diameter got ideas by analyzing vise-grip pliers, bun-gee cords, test tube clamps and other products. The team asked, “How dothese devices perform an attaching or clamping function? Are any of thesemethods useful for our design?” This type of analysis will help you developspecifications for your design and give you ideas for technologies and materi-als you can use.

You can also analyze model products later in the design process. One teamworking on the food-cutting utensil decided to focus on a scissors-like design.The team’s 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 them-selves, and analyzed the features that added to or detracted from comfort.They even bought the most comfortable pair of scissors and used the grips tobuild 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 innova-tive design will address unmet needs, and meet more needs or meet needs bet-ter than existing designs do. Therefore, identifying users and understandingtheir 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 andmodel products, you already will have learned a good deal about users andtheir needs. This section of the textbook focuses on how to benefit from userinterviews, 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 dia-log that has been carefully written to ensure completeness and consistency inuser interviews, and to allow you to compare your findings and synthesizeyour information.

You will get the most useful, in-depth responses by interviewing users in per-son, or, if that’s not possible, by phone. One-on-one interviews provide theopportunity for users to delve into the “why” behind their answers. Althoughhaving users fill out surveys is less time-consuming, the results tend to bespotty and superficial because people aren’t as eager to reply to emails or takethe time to write out their answers when you aren’t there to encourage theirresponses. 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 teamreceived only a few responses, and those contained unhelpful comments suchas, “It’s hard to move around in here,” which the team already knew. As aresult, team members ended up doing one-on-one interviews that yieldeddetailed explanations of problems and possible solutions.

Often, you will combine your interview with a user observation, which isexplained 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 inter-view:

• 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 they’re willing to be interviewed.

2. Make an appointment. To improve your chances of securing an interview:

• 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 say-ing 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, iden-tify 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 contact—whether 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 person’s title, do a little research or ask the individual how he or she prefers to be addressed.

3. Write an interview guide, Your guide should include the following:

• A brief, introductory explanation of your project and the purpose of the interview. You might say something like, “We are working on a

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 con-cerns would you have about such a product?” Then move on to more probing, difficult questions: “What do you think is the most conve-nient way to unfold the seat into a stroller?” Make sure to ask ques-tions that your users are capable of answering, rather than those that require expertise.

NOTE: When appropriate, ask questions that users can respond to usingnumerical ratings or rankings so you can more easily compare and tabu-late responses. To determine the most and least important requirementsfor their design, the convertible car seat team might ask users to rankrequirements in numerical order:

Alternatively, team members might decide that because some require-ments are of equal importance, they should ask users to rate each require-ment:

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

Rate each of the following requirements on a scale of 1 to 6, with 6 being extremely important and 1 being unimportant:

36


Make sure that your questions are worded in an unambiguous way. Forinstance, don’t ask, “On a scale of 1 to 5, with 5 being best, how do yourate your current stroller?” because you will have no way of knowingwhat criteria your interviewee is using for the rating. Instead, ask, “On ascale of 1 to 5, with 5 being best, how do you rate your current stroller inits ease of folding and unfolding?” Similarly, when you ask questions thatmay have varying interpretations, be sure to follow up with clarifyingquestions. For instance, it may be useful to ask a broad question like,“How versatile is your current stroller?” because your interviewee mayinterpret the question in an unexpected way that yields valuable informa-tion for you. You may have meant that to be a question about the range ofheight and weight in children that the stroller can accommodate, whileyour interviewee interpreted the question to be about the varying weatherand other conditions in which the stroller can be used, something youdidn’t think to ask but are now glad to have learned. Just be sure toinclude a clarifying question like, “What range of height and weight inchildren 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 unex-pected 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 you’ve 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):

Safety 1 2 3 4 5 6Cost 1 2 3 4 5 6Appearance 1 2 3 4 5 6East of Use 1 2 3 4 5 6Size/Weight 1 2 3 4 5 6

37


Example 2.7: Table summarizing user preferences

Another team designing a patio chair for people with back problemsmight have devised the following template to organize comments fromusers about their likes and dislikes regarding existing chairs:

Example 2.8: Template for table to organize user comments

Some information from user interviews may not lend itself to tabularorganization. In that case, summarize the information in a series of brief,well-organized paragraphs and lists.

Component # of people who want it

Kleenex holder 22

CD pouch 20

Lap desk 19

Trash receptacle 19

Insulated food pouches with cold packs 17

Pouch for ice scraper 13

One large pouch 11

Cell phone mount 11

Several small pouches 8

Expandable file / accordion folder 7

Hooks 7

Removable mirror 6

Dry erase board 6

Notepad / Post-it notes 5

Pencil pouch 5

Clipboard 1

Likes Dislikes

User A : Getting in chair

: Sitting

: Getting out

: Other

User B : Getting in chair

: Sitting

: Getting out

: Other

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 seekthose people out and observe them where they encounter the problem you areattempting to solve. As Tim Brown (2009), CEO and president of design firmIDEO, comments, “[A]lmost every project we undertake involves an inten-sive period of observation. We watch what people do (and do not do) and lis-ten 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 theylower themselves into the chair? Do they show signs of difficulty in perform-ing these actions? Once they're seated, how do they move themselves into acomfortable position? How do they position their hands and body when get-ting out of the chair? Do they seem to have trouble doing so? By carefullyobserving your subjects’ body language and facial expressions, you can dis-cover things they themselves are unaware of.

You’ll probably observe users early on using competitive products, and laterinteracting with the mockups you have built. For instance, although the patiochair team would not want to risk having a person with a back problem try tosit in their mockup of the chair, they could learn a great deal by watching auser 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 experiencedoing 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, profes-sional attitude. In the long run, that approach is much more likely to put usersat ease and make them willing to serve as subjects.

Finally, be sure to record user observations carefully. Bring the tools you needwith you—camera, tape measure, graph paper, etc. Also, don’t trust yourmemory; record the information as the observation is proceeding, and taketime immediately after you leave to discuss the observations with your team-mates, 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, don’t 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 don’t 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 analy-sis.” 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 fol-lowing 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 prod-uct 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 unneces-sary or overly personal questions. For instance, there’s 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 theusers’ consent first. Take care that the users do not feel pressured to con-sent. Photos or videos taken to record information should have identifyingtags that say who took the photo, describe the action or object representedin the photo, and include appropriate references to human subjects (i.e.references that accord with the users’ requests). Even if users haveallowed you to make a photo or video record, this does NOT necessarilymean that they wish to be identified in the photo or video record. Be sureto find out if participants want you to use their names or wish to preservetheir anonymity. In certain cases, you may need to use Photoshop or videoediting programs to block out a user’s identifying features.

For an example of a team’s observation plan, see Appendix C.

5. After completing your observations, summarize the results.

• Provide an overview of key aspects of the session. Your team’s 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 fol-lowing:

– 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? Rec-ognize 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 user’s 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. Some-times 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 sepa-rate 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 com-piled by the patio chair team:

Example 2.10: Portion of an observation results table

• 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 team’s summary of findings from the user observa-tion, 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 likeand how will they use this design?” You can learn a lot about users even whenyou aren’t observing them if you can imagine what it’s like to be in their situ-ation. A powerful way to answer these questions is to engage in a special kindof role-play: that is, by generating user profiles and scenarios. A user profileis an imaginary but detailed portrait of a typical user for your design. It’s likea snapshot that will help you think of your user as a real person and an indi-vidual. Here are two profiles for a curbside mailbox designed to be theft-proof, vandal-proof, and crash-proof.

Observations Opportunities Follow-up

User grips chair arms tightly

Prevent users from cutting or chafing their hands

Put padding on chair arms

User initially pulls self for-ward by grasping the mid-dle of the chair arms

Make it easier to grab the mid-dle of the chair arms

Include pegs or other kinds of grips at the middle of the chair arms

User displays discomfort when pulling self forward and away from the chair back

Have the chair back provide support as the user pulls for-ward

Include a spring at the base of the chair back to allow it to move forward with the user

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 she’s been having problems with mobility. For the last few months, she’s been walking with a cane and doesn’t 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 can’t 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 wordslike “old people” and “children.”

If a user profile is like a snapshot, then a scenario is like a short video clip. Itimagines these users using the design. Here is a scenario created for the curb-side mailbox:

Example 2.12: Scenario

When Kim arrived at work at Dr. Brady’s office Monday morning, she needed to retrieve the mail that had been deliv-ered 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 advertis-ing circulars. By the time she gathers all this, traffic whizzes by again. Oops! Kim drops an envelope, and it’s 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. It’s the third time this year.”

Why concoct such an elaborate story? Because it lets you visualize a poten-tially real situation and the challenges that go along with it. You can practi-cally see Kim, nerves on edge, cursing the traffic and the mailbox, trying tokeep hold of her catalogues, retrieve her fallen bill, and get the mailbox

43


latched before it’s ripped from its hinges. What would make her job easier andsafer? How can she avoid the traffic problem?

Envisioning the problems of Kim, Claire, and Mickey helps you developrequirements 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 youabout technologies that may be critical to your design. They can also tell youwhat users want, who your competitors are, what shortcomings plague exist-ing products, what regulations are imposed by governmental agencies, andmany other facts that influence your overall design.

Like client and user interviews, an expert interview uses scripted questionsthat flow logically from one topic to another. Although you may not followyour 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 usedin the interview guidelines described earlier in this chapter.

Before the interview

1. Define your objectives. Early in your project, experts can provide back-ground 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 com-mon 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 shouldn’t 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, there’s probably a pro-fessor at Northwestern who has the answer.

• Family and friends. DTC students frequently find that parents, rela-tives, and family friends have the answers to their questions.

• Salespeople and product consultants. People who sell products simi-lar 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 you’re 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 differ-ent 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 interview-ing 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 feasi-bility 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, it’s good to do so again.

3. Speak clearly and be sure the expert understands your question.

4. Listen carefully. If you don’t understand an answer, don’t 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 con-versation back to its purpose.

7. Be flexible. If an answer triggers a question not in the guide, go ahead and ask it.

8. Don’t argue. Experts may make incorrect statements or state opinions as facts. Don’t 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 team’s guide for interviewing an expert, see Appen-dix 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 helter-skelter, and you'll have to sort it into categories.

2. Determine which information is relevant to your project and use it appro-priately. 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 expert’s 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 informa-tion 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 team’s summary of findings from their expert inter-view, see Appendix F.

2.7 ITERATING YOUR RESEARCH AND WRITING IT UP

In this chapter, we have emphasized doing research to make yourself anexpert 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 needto do research at later stages of the project, too. One team found this out whiledesigning a paper-shredding device for developmentally disabled youthsenrolled in a vocational training program. After the team decided on theirdesign concept and its components, they still needed to interview a materialsscience professor to find out about plastics, research the McMaster-Carr cata-logue to find out about the specifications of various electronic components,and interview an electrical engineering professor to learn about circuitry. Ateach new stage in the interview process, they needed to return to the tech-niques outlined in this chapter, and then to re-evaluate their research summa-ries and project definition in light of their new research findings. Even thoughthey may have written excellent summaries of their research earlier, theyneeded to revise those summaries as they went along.

Design is a continuous process of analysis and synthesis. Early in yourresearch, you analyze what you learn about the client’s wishes, the users’needs, important background information, and previously tried solutions. Youdecide what is most relevant to your design problem and then summarize itfor yourself. But, as you accumulate more information from additionalsources, you have to synthesize that information in your notes. Sometimesthis synthesis takes the form of a short report, such as a memo to your instruc-tors. Sometimes it’s a table comparing information about other solutions onthe market.

As you continue to gather information, you need to continue to highlightimportant information, eliminate irrelevant information, and apply what youlearn to your design problem. Consider how your team will act on this newinformation, and why your client should care about it. A team designing ahighchair footrest for children with Down Syndrome and cerebral palsy didextensive research online about those two medical conditions. They learnedthat many children with cerebral palsy exhibit spastic movements in their legsthat 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 theylearned more about their users’ needs, they continued to refine the require-ments for their design.

A key point of thinking in design—whether you’re doing the design itself orwriting up your research results—is to synthesize your researched informa-tion. Bring together information from sources in a way that makes sense toyour teammates and to others who will be reading your reports. Organize yourresearch so that it supports the decisions that lead to your design and backs upyour claims about your design’s effectiveness The amount of research and thekind of research you do are crucial to good design, but so are the ways inwhich you think about that research and write it up for others to understandwhat you’ve 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 inter-view guide. Engineering Design and Communication, Northwestern Uni-versity.

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 mea-surable 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 ideaof the problem your design must solve. In DTC, you keep track of the formu-lation of the problem through a document called a “project definition,” whichis 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 alter-natively a proof-of-concept scale model.

49


• Constraints: limitations imposed on the design by the client, regula-tors, 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 stake-holders want the design to fulfill, and the measurable values associ-ated 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,” “engineeringspecification,” and “the spec” are just a few of these terms.

Whatever it is called, the project definition is a living document that parallelsthe creation of the design itself. Although common sense may suggest other-wise, you don’t write the document first and then create the design. Instead,the document evolves along with your research and testing. The initial versiontypically has a first-draft mission statement, a general description of the finaldeliverable, perhaps a few client constraints, and some broad user require-ments, such as “easy to install.” As you learn more about users, your projectdefinition will become more detailed, specific, and focused. For example, anearly version of a project definition documenting the design of an innovativedesk organization system might include the specification, “must reduce deskclutter.” 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 andspecifications that prove irrelevant or unnecessary or too costly. The bottomline is that your final project definition will contain all the requirements ofyour design and the metrics for measuring its success.

A project definition’s 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 cli-ent, and the supervisors can evaluate the design.

You may be wondering if it wouldn’t be easier and more efficient to justobserve how well the design works. The reality is that members of the designteam need a project definition to help them evaluate as they are designing. Ifthey are unable to express what the design must do to meet the requirementsof users, clients, and other stakeholders, they won’t be able to tell if theirdesign will succeed. The project definition also typically outlives the designteam, allowing others to make the customary revisions and improvements.

When you first create your project definition, it will be solution-indepen-dent. That is, it will describe what the solution must do, but it will not actuallydescribe the solution. This stage is necessary because it allows your team tostay open to various solutions and explains to those who get involved later inthe 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 ofthat solution, as discussed at the end of this chapter.

In Appendix G you will find an example of how a DTC project definitionevolved over the course of the project. The team was designing a method ofstoring rainwater in a village in Kenya.

The following sections describe each part of the project definition in moredetail.

3.1 MISSION STATEMENT

A good mission statement not only succinctly summarizes the problem to besolved, but also provides direction and tells others what you are trying toaccomplish. 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, rotat-ing filing system. After they observed her at her desk, team members real-ized 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 client’s 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 tech-niques for changing her work habits), it doesn’t go into detail about thefeatures of the solution. Had the team designed an under-the-desk system,it would have proven unsatisfactory to the client since it would not sup-port 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”), thestatement makes it difficult to measure the success of the design becausethe term “user-friendly” is subjective and difficult to quantify. A bettermission statement would be:

51


Improved mission statement: Design a soda vending machine with a dispensing bin that can be reached with mini-mal bending.

Now the team can observe and measure the amount of bending users needto do and whether it is a comfortable solution.

The team working on the rain harvesting project crafted the following missionstatement in conjunction with their client, a representative of a non-profitorganization 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 andstore enough clear but unsanitized water from rainfall during the rainyseason 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 ofdistributing water from a centralized location, he requested that the team inte-grate the design with individual homes. In addition, to make the project morefeasible for the team to complete, he told them not to consider the issue ofwater purification in their design. Instead, that would be dealt with in laterphases 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 thequarter allows you to plan more effectively for that goal. Different types ofprojects will need different types of deliverables based on what is feasible inthe context of DTC. For example, a team designing a means for someone tochop vegetables with one hand can create a working prototype that reflectsboth the intended appearance and function of their design. But a team design-ing a lift system to help people with spinal cord injuries to get in and out of apool may not be able to build a working prototype. Instead, they can deliver aconceptual design and a model that demonstrates the intended function, but isnot capable of being used in a pool with users. When delivering a fully func-tional prototype isn’t possible, proof of design function can be supported withpartial mock-ups demonstrating key subsystems, performance test results,along with analysis and calculations. In all cases, thorough graphic illustra-tions of the design should be part of the project deliverables.

3.3 CONSTRAINTS

Almost all projects are subject to constraints, usually imposed by the clientand related to scope, cost, and regulatory approval. Constraints cannot bechanged and therefore limit the design space you explore. For example the

52


client may specify that the design must be manufactured using existing equip-ment 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 agen-cies (for instance, Americans with Disabilities Act guidelines).

If a client imposes constraints, review them carefully to understand why theclient thinks they are essential. If no clear rationale is stated, talk to your cli-ent about eliminating the constraint. For instance, a client initially said hewanted a beach umbrella that would hold its ground in windy conditions. Thedesign team asked him if the final design had to be an umbrella (as opposed toa canopy or tent). In other words, they wanted to know if “umbrella” was aconstraint on the design. The client said that it wasn’t, so the team had freerein to consider other possibilities. Things could have gone the other way,however, with the client saying it had to be an umbrella, perhaps because hemanufactured beach umbrellas and wanted to use existing factory equipment.

After discussing possible constraints with the client, the rain harvesting teamultimately had just one:

Example 3.2: Constraint for the rain harvesting project

Constraint

Enough water must be collected to support the needs of each familyin a cluster of homes (about 100 L/day)

The client imposed this constraint because he believed that this way of deter-mining water needs would be most equitable for the village.

Some students confuse constraints with user requirements. Here are two waysto 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 spe-cific, 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 condi-tions 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 Indus-tries Research Institute).

53


3.4 USERS AND STAKEHOLDERS

Composed of all those who are affected by a product’s success or failure,users and stakeholders fall into the following categories:

Primary users: end users, the client, and anyone else who makes importantdecisions about buying, using, or maintaining the product. Primary users canbe subdivided into demographic groups. For example, a team charged withdesigning a highchair footrest to help children with Down Syndrome andcerebral palsy sit up straight while eating divided their primary users intothree 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 foot-rest 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 thestructure.

Secondary users: those employed in the client's various departments (manu-facturing operation, service, marketing, etc.). Secondary users also includethose will interact with the product at some point: installers, repair people,salespeople, and others. In the case of the rain harvesting project, the second-ary users were other people living in Ribe.

Other stakeholders: Regulatory agencies, community organizations, and oth-ers who are somehow affected by the design and have an interest in its func-tioning. The rain harvesting team identified these stakeholders: fundingagencies 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 yourusers and stakeholders: the needs the design should fulfill for them. It’simportant to keep in mind that users and stakeholders are not always aware ofor able to articulate requirements. For example, users testing cell phones maynot have known they “needed” a built-in address book until they were in a sit-uation where they needed a phone number quickly.

To see how teams uncover user and stakeholder requirements, review the pro-cess used by the rain harvesting team. Members conducted research, follow-ing the methods outlined in Chapter 2 and illustrated in Figure 3.1Understanding user requirements below.

54


Figure 3.1: Understanding user requirements

3.5.1 Identifying client requirements

Face-to-face meetings provide a good opportunity to identify client require-ments (although some clients may give you written specifications). Askingclients the reason for each requirement will help you understand their think-ing. The rain harvesting team uncovered the following requirements in theirinitial 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 harvest-ing of solar energy

3.5.2 Identifying the requirements of primary and secondary users

You can identify the requirements of primary and secondary users throughobservation; interviews; analysis of competitive products; online and printsources; and user profiles and scenarios. Because their primary users live inKenya, the rain harvesting team was unable to conduct user observations andinterviews. However, they were able to do other kinds of research that enabledthem 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 forvarious uses, types of homes in Ribe, typical family size in Ribe, technicalabilities of residents, climatic conditions in the area, etc. Through thisresearch, they were able to add to their list of requirements:

• prevent physical contaminants from entering the water so that resi-dents 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. Forinstance, automobiles produce pollutants and require massive regular roadmaintenance. There are literally hundreds of public and private organizationsthat set standards and regulations. Some of the better-known ones are theFood and Drug Administration (FDA), the Federal Communications Commis-sion (FCC), the Federal Aviation Administration (FAA), the AmericanNational Standards Institute (ANSI), the Consumer Product Safety Commis-sion (CPSC) and various professional societies such as IEEE, ASME, andASCE. Virtually every engineering design has to meet a set of standards orregulations.

The rain harvesting team researched other projects undertaken by the commu-nity of Ribe to determine the level of cooperation and technical expertise theycould expect within the community. They also researched applicable stan-dards for rainwater harvesting reported on by the Global DevelopmentResearch 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. Tomake it easier to work with, you should place the requirements into appropri-ate categories. Here are two of the categories developed by the rain harvestingteam:

Example 3.3: Requirements for rain harvesting project

Water storage


• 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 turnthem into precise, measurable terms to evaluate whether their design satisfiesthose requirements.

For instance, a team designed a traffic flow plan for parents dropping off andpicking up their children in a grade school parking lot. The team couldn’tmerely specify that “parents need to be able to drop their children off quicklyand efficiently.” They needed to apply “quickly and efficiently” to a specificnumber of cars, a time period, and specific circumstances. After observing theparking lot for several mornings, the team determined the following specifica-tions 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 specifications—which were verified by the client—made it possible forthe team to measure the viability of alternative design solutions, revise theirproposed designs to meet user requirements, and test the success of their finaldesign. In presenting their final design to the client, the team could demon-strate how their traffic flow pattern could accommodate 75 parked cars and 50non-parking cars in the 20-minute drop-off period.

Metrics are used even for requirements that are difficult to quantify. For thehighchair footrest project, the team determined from user interviews that thefootrest must be easy to clean because of the food that children would drop onit and grind in with their feet. “Easy to clean” sounds self-evident and suffi-cient, but it does need to be specified with metrics: How much time will par-ents and daycare providers be willing to spend cleaning the footrest? Howdeep must a groove be before it becomes difficult to clean? How narrow aspace 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 theirconcepts.

57


In their original project definition, the rain harvesting team lacked the infor-mation 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 waterthat 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 team’s decision todesign a storage tank that would accommodate a cluster of households ratherthan a single one. The team made this important decision in consultation bothwith their client and professors. This change illustrates how the specificationsbecome more solution-dependent as the project moves toward completion.

Specifications must be derived from research, not guesswork. To define theamount of water a tank needed to hold, the rain harvesting team researchedthe amount of rainfall in that area of Kenya over a ten-year period, the dailywater needs of residents of rural Kenya, and the average family size in Ribe.

One final note about specifications: most requirements must be linked to met-rics to evaluate the success of a design. Some requirements, however, are sim-ply binary—the design either meets them or doesn’t. The parking lot trafficflow team stipulated that the existing entrance and exit of the parking lot beused in their design. This needs no further specification.

Subjective requirements, such as “aesthetically pleasing,” also tend not to belinked to numerical metrics. Instead, the specifications for “aestheticallypleasing,” might be the emotional qualities you want the design to convey tousers. For instance, suppose you are designing a new video game controllerfor people with severely limited use of their hands. Through user interviewsand testing, you learn that the aesthetic qualities these users want in the designare captured by the words “sleek,” “powerful,” and “dynamic.” Those termswould become your specifications, and you would test your prototype withusers 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, youwill find a variety of formats used to document a design. The format we use inDTC has two beneficial characteristics: (1) The project definition is easy toupdate as the design evolves. (2) The table format helps designers see the rela-tionship between requirements and specifications. The example below shows

58


the general structure of a project definition. Appendix G shows how the rainharvesting 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:

3.8 DEVELOPMENT OF THE PROJECT DEFINITION

You will produce several versions of the project definition, each more com-plete and detailed than the previous one. The first version, written early in theproject, may have a sketchy mission statement, constraints learned from theclient, and a few potential requirements picked up from initial reading. As youdo further research and testing, the project definition will change in manyways, 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

Requirements Specifications

59


• Your specifications will become more solution-dependent as you set-tle on a particular design. For instance, at a certain point the rain har-vesting 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 capac-ity 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 har-vesting team's project definition.

Finally, it is essential that you keep a copy of each version of your project def-inition in your project folder. These sequential drafts, which provide a papertrail of your thinking, are obligatory if your design turns out to be patentableor if you hand off your design to a new design team or product developers. Ifa future team wants to understand the rationale for a requirement, for exam-ple, 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 alterna-tives matrix

• Sketch and then build low-tech mockups of your alternative design concepts

Once you have begun to research and define the problem, it’s time to startgenerating solutions, an activity that continues in one form or anotherthroughout the design process. Notice that we speak of solutions in the plural.Why bother to generate multiple solutions, when the best one may seem obvi-ous to you? Here are just a few reasons:

• To stimulate your team’s creativity. It’s the most important reason for generating alternatives because it allows team members to approach the problem from different directions, build on each other’s ideas, and then choose the solution that combines the best of those ideas.

• To make the design process more efficient. Focusing on one design con-cept is like putting all your eggs in one basket: If, after months of work, your design doesn’t pan out, you’ve 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 don’t.

• 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 they’ll tell you what they think they like. Show them several designs and let them compare them, and you’ll get more helpful, specific answers.

• To improve the design’s ability to achieve multiple objectives. By gener-ating 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 fea-tures of both into the same product.

NOTE: Rather than have each team member develop his or her owndesign and then compete to see who’s the “winner,” it’s more productiveto work together on each alternative, and then take the best elements ofeach to produce your final design.

The next sections take you through the process of creating alternatives bybrainstorming, generating multiple design concepts, and making mockups.The following chapter explains how to gain valuable information from thosealternatives through user and performance testing.

4.1 BRAINSTORMING

Good engineering design requires creativity in developing solutions to prob-lems. But our own ingrained attitudes can interfere with our ability to thinkcreatively. A voice inside our head may censor ideas by saying, “Well, it’salways been done that way, so that must be the best solution.” Or, “That ideawill sound too weird to my team.” Or, “Let’s just evaluate and reject each pos-sible solution until we figure out the right one.”

To get beyond these restrictive attitudes, designers use the tried-and-true tech-nique of brainstorming. Developed in the 1930’s by advertising executiveAlex F. Osborne, brainstorming involves generating a large number of ideasquickly, a process which sets off a chain reaction of creative thinking.

Brainstorming is especially useful at the start of the design process, when youwant to be open to as many perspectives as possible. In the later stages, brain-storming is effective when you need to generate alternatives or possible mod-ifications of a design, or when you get stuck at any point in the designprocess.

62


The goal of brainstorming is to generate as many ideas as possible in a limitedamount of time. Two other steps usually follow it: clustering brainstormedideas 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 followthese rules for brainstorming (copyright IDEO Product Development, usedwith permission):

1. Defer judgment. This is the hardest rule to follow, in part because we’re 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. You’ll quickly learn that you don’t 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 can’t wait to get their ideas out on the table, but to keep the energy flowing and frus-tration 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 don’t just happen; someone has to lead them. That person is thefacilitator, who needs to:

1. Prepare for the brainstorm. Collect objects that are relevant to the prob-lem 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 partici-pants’ difficulty in following the “defer judgment” rule, maintain a posi-tive attitude and make only positive statements. Try to turn negative comments into positives, and questions into concepts to explore. If some-one 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 that’s already been sug-gested. 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 injurieswho have limited use of their hands and wrists to drink directly from beveragecontainers. Notice how the students viewed the problem from various angles:attaching the device to the hand or arm, attaching it to the container, and plac-ing the container back on the table. In addition, they paid attention to aestheticconsiderations 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 disen-gage

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. lightweight—titanium

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


4.1.4 Clustering the brainstormed ideas

Because it’s difficult to work with a long list of ideas, the next step is to clus-ter them so you can see connections.

There’s no one right way to cluster ideas, but some common ways are togroup them according to user requirements, cost, and functionality, to name afew. As you cluster and recluster, you will discover a wealth of ways to solvedesign problems.

After their brainstorming session, the beverage container team clustered theirideas in this way:

Example 4.2: Clustering the ideas generated in a brainstorm

Attaching to user

adjustable strapsbrace attachmentsnap bracelet with buttonsstrap around palmgloveglove with insettrack on forearmvelcrotwisty tie

Attaching to container

handled clampmotorized stringmagnetized glovemagnetized mittenTherabanddisk on palmrollerblade clip or strapsring clamphand bracketpouchglove with elastic bandconvex attachmentrubber band

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

66


seatbeltfunnel attachmentwire wrapbeanbag grippneumatic gripmemory metalmemory foamcell phone holderlariat

Securing container

magnet chainfingertip magnetshigh-friction materials—rubber, sticky handstretchy materialelastic harnessclamps with roller blade clipclamps on palmelectrical actuatorvacuumblood pressure cuffadjustable backpack strapSuper Glueduct tapesuction cupsscrew mechanismtwo clamps, one stationarymultiprong clampkelly clamp (forceps)ratcheting clampsqueeze clampmagnetic clamp

Putting down container

spatula with back ridgeplatform next to tablebumperscoop

Releasing container

bite switchturn off electricity to disengagerelease leverelectric bite switchswitch/joystick combinationcapo5-point harness; 2-point harnesscamera battery packspring on floppy drivewire guidebig surface to activate spring

67


mechanical rollerblade clipseatbelt button

Using discreetly

clear plasticlightweight—titaniumkeep close to handuse back of handhidden inside sleeveuse wrist braceuse less metalskin coloredpersonalize (logos, tie dye, write on)

As with brainstorming in general, the purpose of clustering is to choose cate-gories 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 categorizedbrainstorm 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 bedeveloping at least three design alternatives that are significantly differentenough to give you good information in testing.

Some teams develop alternatives by having each team member come up withan idea. This unsystematic approach, however, simply pits ideas against eachother and doesn’t allow members to build on each other’s 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 feasi-bility. That is, you’ll eliminate those ideas that are probably too expensive to meet the client’s constraints and are technologically beyond your capa-bilities. 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 require-ments 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

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 alter-natives 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 com-fortable to users? What kind of device will most securely grip and release the container? They mixed and matched the ideas into alterna-tives 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.

Attaching to user

Attaching to container

Securing con-tainer

Releasing con-tainer

• Brace attachment

• Glove• Strap

around palm

• Pouch• Roller blade

clip• Ring clamp

• Elastic har-ness

• Rubber sup-port

• Stretchy material

• Ratcheting clamp

• Wire guide• Release

lever• Springs• Elastic band

69


Sometimes, brainstormed ideas will not fit neatly into one set of alterna-tives. In that case, create two or more sets of alternatives. A team design-ing an alarm system to warn of malfunctions in an intravenous pump(Dickerson, Lee, O'Connell & Powers-Maher, 2007), generated two setsof alternatives, one with visual signals and one with audio:

Example 4.5: Two alternatives matrices for intravenous pump alarm project

4.3 CREATING MOCKUPS FOR USER TESTING

Mockups are two- or three-dimensional objects that embody your concepts ina physical form and that are developed fairly early in the design process to testkey functions, thus giving you valuable information to make decisions aboutyour design.

Example 4.4: Alternatives matrix for beverage container project

Attaching to user

Attaching tocontainer

Securing con-tainer

Releasing container

Alt 1: Ratchet Brace attach-ment

Ring clamp Ratcheting clamp

Release lever

Alt 2: Glove Glove Pouch Stretchy material

Elastic band

Alt 3: Harness Strap around palm

Roller blade clip

Elastic har-ness

Wire guide

Visual alarm alternatives

Location on pump

Alternative #1 Half screen

Alternative #2 Full screen

Alternative #3 Tubing station

Alternative #4 Handle

Audio alarm alternatives

Melody pattern Instrument

Alternative #1 C-E-G Brass

Alternative #2 C-F#-C Clarinet

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 alter-natives 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 didn’t 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 compo-nent 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 vari-ous canopies for testing, not the base and poles.

Mockups are useful in testing alternatives throughout the design process. Nearthe end of the project, you will build a “prototype” that embodies the keyfunctions 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 men-tors 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 andtechnical assistance as you plan and construct. They are also very busy, con-ducting shop training sessions and working with many different users of the

71


shop, from DTC teams to graduate students. Therefore, you should observethe 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 web-site.

• When you want to leave class to work on mockups in the shop, check with your instructors first. Explain exactly what you intend to accom-plish. 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 userand performance testing. These activities are discussed in the next chapter.

4.4 REFERENCES

Dickerson, B., Lee, J., O’Connell, T. & Powers-Maher, C. (2007). Progress report #2: medical infusion pump alarm. Engineering Design and Com-munication, 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 con-trolled conditions

• Write well-organized test result summaries for inclusion in project folder and reports

Different projects call for different methods of testing. User testing improvesa design and helps make sure that it meets user needs. By observing users asthey attempt to perform designated tasks using your mockups, you can dis-cover the pros and cons of those mockups. But user testing is only one methodfor learning more about the pros and cons of your design ideas. Drawbacks todirect 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 neces-sary 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 struc-tures, 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 observeusers having trouble with one of your favorite design features, try to figure outwhy 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 feed-back.

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 gen-eral, 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 theusers’ consent first. Take care that the users do not feel pressured to con-sent. Photos or videos taken to record information should have identifyingtags that say who took the photo, describe the action or object representedin the photo, and include appropriate references to human subjects. Evenif users have allowed you to make a photo or video record, this does NOTnecessarily mean that they wish to be identified in the photo or videorecord. Be sure to find out if participants want you to use their names orwish to preserve their anonymity. In certain cases, you may need to usePhotoshop or video editing programs to block out a user's identifying fea-tures.

Writing the user test guide and conducting the testing

User test guides provide a consistent methodology, ensuring that all membersof your team ask the right questions and that all users perform the same tasksand 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 natu-rally.

• Questions to get relevant demographic information. Avoid unneces-sary or overly personal questions. For instance, there’s 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 sugges-tions. 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 effec-tiveness 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.”

You’ll gain additional valuable information about users’ needs and prefer-ences by asking users to explain their numerical responses: “Why did yourank mockup 2 as the best?” “What made mockup 3 so hard to use?” Duringthis whole process, someone on the team should take careful notes on theusers’ steps, missteps, and comments. One final piece of advice: Resist thetemptation to defend your design alternative or explain the rationale behind afeature to your users. Your goal is to gather as much information as possiblefrom 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 proce-dures and results. Before writing that documentation, however, you shouldsummarize test results informally for yourselves, as the beverage containerteam (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 Observations and User Comments

Follow-up design ideas

Ratchet Open handle is a good idea since the user doesn't have to squeeze hand into something.

Users don't always wear their brace; can-not assume that the metal piece can be inserted under a brace strap.

Add an additional Vel-cro strap near where the apparatus comes to the wrist; use a D-ring so that it can be fitted by the user by him/herself.

Containers may slip while in the ratchet.

Use Dycem to reduce slippage and provide a better grip.

76


5.2 PERFORMANCE TESTING

In addition to user testing, you may need to test your alternative designs in alaboratory or other controlled environment to discover whether they work atall. For instance, one team was designing a toy rocket-launching kit, using atwo-liter soda bottle for the body of the rocket. In designing the launch mech-anism, trigger, fins, and nose cone that would attach to the bottle, the teamobserved and interviewed users—mostly children—to figure out the mostpromising ideas for these components. Then they mocked those up usingfoamcore and other easily available materials, attached the mockups to bot-tles, launched them, and measured their performance. These tests enabled theteam 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 evacuat-ing people from skyscrapers used computer modeling to test their design concepts.

Harness Holds containers very well but it's too hard for the user to install a container by him/her-self.

Abandon the use of the scrunchy or use a D-ring so that users can more easily adjust the scrunchy.

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.

Glove Too difficult for users to put on themselves.

Use gloves that have no finger holes.

Pouches are flimsy and don't hold the drink in an upright position.

Use firmer material for the pouch.

Effective design for discreetness.

User testing results and follow-up ideas

Model Observations and User Comments

Follow-up design ideas

77


A DTC team (Syed, Erisken, Kuo, & Tang, 2004) was designing a method toprevent a new, environmentally friendly paint from freezing when transportedor stored in cold conditions. One of their mockups consisted of a Styrofoamcontainer with heat packs. Below is the test procedure they developed, alongwith 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.”

Chapter 6 explains in detail how to document test procedures and results.Chapter 22 explains how to write specific, well-organized instructions.

Time Observations (i.e., degree of ice formation, condition of boxes, how hot heat packs are)

After3 Days

After5 Days

78


5.3 ITERATING THE TESTING PROCESS

Although you may have figured out a design direction after your initial roundof testing, you still must decide on the components of that design by continu-ing to generate and test alternatives. For example, the team designing the bot-tle rocket kit faced a host of questions after their initial tests led them tonarrow down the kind of launch pad and fin shape they wanted. So they con-tinued to generate and test alternative ways for the bottle rocket to attach tothe launch pad. Similarly, while they kept the basic shape of the fins that theirearly tests showed to be best, they had to mock up different-sized fins andattach them at several different positions on the bottle rocket. They alsoneeded to conduct these tests with potential users as well as with themselves.These iterative tests, which continued into the final days of the project, helpedthem make further decisions.

In DTC, you learn that good designs are user-centered—they take intoaccount and accommodate the full range of user needs, characteristics, pat-terns of behavior, and environments. For that reason, it’s often a good idea toevaluate your early design ideas through user testing. User feedback can helpyou eliminate unpromising ideas early in the design process.

But user testing is not the only way to learn more about your proposeddesigns. Performance testing also helps ensure your design's suitability foryour target users. Such tests let you learn more about how your design wouldbehave under circumstances that might be difficult or dangerous to simulate inthe context of user testing. In addition, the controlled environment of perfor-mance testing makes it likely that you will be able to obtain high-quality,quantified information about your design—especially important if you seek toestablish safety parameters for its construction or use. Finally, performancetesting takes advantage of the team's special skills and knowledge, allowingyou to gather information about the design that may not be readily apparentfrom a user testing session.

Consider this example: a team working with Engineers for a SustainableWorld (ESW) needs to develop a system for transporting drinking water tocattle that can be used, maintained, and repaired by inhabitants of a rural com-munity in Panama. The team must then provide the inhabitants with aninstruction manual for installation, maintenance, and repair of the system.

For such a project, both user and performance testing are vital to the successof the solution. Without user feedback, the team will be unable to evaluatewhich systems are appropriate to the environment or require too much techni-cal knowledge and expensive equipment for the users to maintain easily—orwhether the instruction manual tells them what they need to know. Withoutperformance testing, the team will have difficulty determining how the pumpand filter system would behave under adverse climate conditions, such aswhen the local stream is running low and clogged with debris. Without bothkinds of information—and iteration—the team is unlikely to develop a suc-cessful final prototype.

79


Keep in mind that the complexity of the testing process mirrors the complex-ity of the design problem. Any team that relies solely on one kind of testingprocedure or one set of tests will likely end up with a design that may work intheory, but fail in practice. In the final analysis, user-centered design typicallyrequires 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 ideasyour team generates through brainstorming, research, and expert consultationsmust be tested repeatedly to help you understand how your design will behaveand be used in a real-world context. Testing is an indispensable way to mea-sure your early ideas against user requirements so that you can eventuallytranslate those requirements into measurable specifications.

Design testing may take many different forms. In the first quarter of DTC, youtypically assess your design ideas by asking users to interact directly withyour mockups. In DTC 2, you often conduct user testing in addition to devis-ing other ways to evaluate the strengths and weaknesses of your early ideas.But whatever your methods, the information you gain from testing plays avital role in helping your team determine the final design.

81


For this reason, it is essential that readers of your reports and project note-books understand your testing strategy as fully as possible. What did you hopeto learn? What was the rationale behind your test methods? Did testing gowell, or did you run into difficulties? Answers to all these questions and moremust be provided in writing. This chapter explains the purpose of the testingrecord, 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 toevaluate the capabilities of your design. It comprises both the team's prepara-tion for tests as well as what you learned from them, including results andinterpretation.

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 documenta-tion; you will learn more about them as you progress in your chosen field.This chapter is intended to make you aware of some fundamental principlesfor good record keeping and clear documentation.

The testing record takes two basic forms: notes from testing and formal docu-mentation. In Chapter 5, you studied the first part of the testing record—goodnote-taking. If you do a good job of organizing your notes initially, it is mucheasier to write your formal documentation.

6.1.1 Purpose of the testing record

Formal documentation, in contrast to your testing notes, is the refined recordof the full design testing process as it appears in reports, proposals, and pro-fessional publications. Formal documentation is written to explain the testingprocess to a reader who may know little about the design problem, appropriatetesting methods, or the full range of possible solutions. For that reader, yourformal documentation of the testing process serves as important evidence ofthe design’s (and the team’s) credibility, and should foreground informationthat anticipates and answers concerns of experts. Thus, it is important to pro-vide readers with a clear, logically organized, and economical account of thetesting process so that they understand how your results informed the team'sdecision to select one design solution (or one set of features, functions, mate-rials, or construction methods) over another.

Moreover, a well-written account of your tests and findings will tell the readerabout much more than just the design itself. Thorough documentation allowsan experienced reader to assess both the complexity of the design challenge

82


and the quality of the team's performance, providing answers to questions likethe 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 team’s 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 withtheir rough notes from testing, since both are part of the official record of thedesign’s development. Among other things, documentation provides legalevidence of the team’s due diligence in testing, showing that the team tooksteps to ensure that the design addressed the design problem adequately andsafely. Moreover, should you wish to patent your design, such records willtestify to your detailed insider knowledge of the development process thatcreated the design. Finally, in the event of design failure, a full record of test-ing 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 withyou for only a short time. Maybe you tested with one or two users and arepretty sure that a broader range of users might make some unsuspecteddefects 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 ofinformation you had hoped.

Whatever the results from testing, you must record them scrupulously, even ifyou believe that the findings do not adequately reflect the possibilities inher-ent in your design. Failure to document problems that crop up in testing, care-lessness in acknowledging limitations of your testing methods, suppression ofundesirable results, or worse, fabrication of data all constitute seriousbreaches of recognized ethical standards. The National Society of Profes-sional Engineers’ Code of Ethics for Engineers (2007) leaves little room formisunderstanding:

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 indicat-ing 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 canlead to breakthroughs, encouraging you to seek information about the designor users that you hadn’t thought to look for. If your test failed, what new infor-mation or opportunities did it reveal? If you didn’t get the answers youneeded, did you find out how to ask better questions? For many reasons, ethi-cal record-keeping and good design go together.

6.2 ELEMENTS OF THE FORMAL RECORD

Your formal documentation of design tests should include the following fourelements:

• Purpose

• Methodology

• Results

• Analysis, conclusions, and limitations

Each element is discussed in greater detail below. Examples of reports onperformance 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 con-cisely. Keep in mind that in the course of design testing you may gather infor-mation that you had not anticipated. In such cases, you should neither reviseyour description of the design test’s purpose nor ignore the additional data.Instead, make sure your account of the results from testing includes the unex-pected findings with a simple notation stating that while the test had not beendesigned with the express purpose of discovering that information, your teamwill 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 gen-eralist reader can understand how the design was tested. Second, it can alsohelp your team double check the plan and make sure that the testing procedurewill 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 prepa-ration, 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 team’s analysisand interpretation of those results. Results of design tests themselves shouldinitially be presented objectively, without interpretation. Detailed informationon tests (including contextual information) is generally relegated to an appen-dix.

In addition, you should provide a short overview of any changes in the testingmethodology or unexpected circumstances, including the reasons for thechanges. This should be considered part of the basic contextual informationabout your tests (date, time, location, duration, etc.) and should appear in ashort paragraph at the beginning of the detailed account of test results. Be sureto provide reasons for the changes. Were the users too fatigued to work withyou for long? Had you been unaware of the limitations of your testing equip-ment? This information can both give your reader a better understanding ofyour user group and help future teams think about how to avoid such obsta-cles in future tests.

6.2.4 Analysis, conclusions, and limitations

Analysis

The most common mistake that teams make is to provide the reader with datagathered from design tests but little else, assuming that the results “speak forthemselves”—that the conclusions to be drawn from the data are obvious andincontrovertible. However, as experienced designers and researchers know,this is rarely if ever the case. The team must explain how they interpretedresults in order to justify their decisions about the form of the final prototypeand recommendations to readers.

The analysis of results from testing is distinct from the results, though some-times your results may seem to speak for themselves. For example, if yourdesign simply did not work as you expected under real-world conditions, itmay earn low ratings both in user and performance testing.

In other cases, however, findings may result from something that the team hadnot 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 teamdesigning a computer lap tray for users with disabilities presented their clientand users with four alternatives: three foamcore “looks-like” models, and onecommercially available product that lacked key features required by the users.In spite of the fact that the commercially available product lacked what theteam had determined to be key requirements, the client and users expressedstrong preferences for that design. After discussing the results of user testing,the team determined that the client's and users’ favorable responses to thedesign had been determined less by the design’s working features than by itsaesthetic qualities. The team decided to develop new mockups that addressedboth functional and aesthetic requirements.

For performance testing, your analysis should provide the reader with anexplanation of what the raw data mean in terms of design requirements anduser needs.

Conclusions and limitations

A short summary of the team’s conclusions should usually appear in the mainbody of the final report, leaving detailed discussions of your reasoning for theappendices. This part of the formal testing record is also a good place to men-tion 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 beenable to conduct enough tests to determine what materials would be best suitedto ensure the user's safety, that should be noted as a limitation. You shouldthen 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 thatyou 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 thedesign you will propose. You will need to continue generating alternativecomponents for those features, mocking them up, and testing them, but all thatwill 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 thefocus of your further work on the project? This chapter discusses severalmethods for making those decisions.

87


7.1 USING TEST RESULTS

If you have organized the results of your design concept clearly, aspects ofyour design direction will leap out at you. For instance, a team designing theinterface for an electronic kiosk to give shoppers information on restaurantsand entertainment (Johnson, Chen, Kidd, Lesperance, & Marvin, 2002)observed users operating three mockups: a touch screen, trackball, and key-pad. The average scores (on a scale of 1 to 5, with 5 being the best) were:

• Touch screen: 4.36

• Trackball: 2.12

• ATM: 2.15

Because their research had already shown that the three methods were compa-rable in price and durability, the team decided on the obvious favorite—thetouch screen. Sometimes, test results do not clearly favor one alternative fea-ture. When the kiosk team presented users with three alternative methods forsearching by location, price, and type (of entertainment or food), they gotthese results:

• Location: 4.09

• Price: 4.03

• Type 3.55

Users rated searching by location and price nearly the same, with searching bytype not far enough behind to be eliminated. In this case, the team decided toincorporate all three search methods into their design concept, because doingso stayed within the client’s budget and offered users several search methods.If you have tested your alternatives in a lab or other controlled setting, youcan use the results in the same way to make decisions.

7.2 USING DESIGN REQUIREMENTS AND SPECIFICATIONS

Your project definition—described in Chapter 3—is another important tool inhelping you choose the main features of your design.

A team designing a structure that would help their client organize the paperson her desk relied on the project definition to help them decide on their designconcept. When no clear favorite emerged after testing their three alternativemockups, the team turned to their project definition, which revealed that theclient wanted an individually tailored product because she had tried the prod-ucts available in commercial catalogues and found them all unsatisfactory invarious ways. The team realized that their alternatives were similar to cata-logue products, so they combined the best elements of all three alternatives inan 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 require-ments to determine which features of your alternative designs to use.

A simple and effective decision matrix lists the relevant design requirementsalong one axis and the alternative features along another. Each alternative isthen “scored” (using plus and minus signs or some other method) with respectto each requirement.

A team redesigning a stage in a church generated two alternatives—a rampand an electric lift—to accommodate users with walkers and wheelchairs.Many church members favored a ramp because they worried that a lift wouldstrain the church budget. Other members thought the ramp would take up toomuch room and that a lift would be easier to use.

With these conflicting views in mind, the team drew up the decision matrixillustrated below. The two alternatives are in the top row, and the requirementsare in the first column. The team used three requirements to rate the ramp ver-sus the lift: cost, ease of use, and efficient use of space. They gave the alterna-tive two pluses when it satisfied the requirement extremely well, and twominuses when it did so extremely poorly. Otherwise, they used a single plusor minus to rate the alternatives.

Example 7.1: Decision matrix for choosing between two alternatives

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 helpedthe team decide that the lift was a better option because it satisfied morerequirements.

The decision matrix also could help the team evaluate alternatives againstrequirements that are not equally important. For example, the team may havedecided, based on interviews with church members, that cost was the mostimportant requirement. In that case, they could have created a weighted deci-

Lift Ramp

Cost -- ++

Ease of use + -

Use of space ++ --

Total + -

89


sion matrix like the one below to help them evaluate the alternatives.

Example 7.2: Weighted decision matrix for choosing between two alternatives

KEY

++ = satisfies requirement extremely well


0 = neutral


-- = satisfies requirement extremely poorly

Using this matrix, the team might conclude that if cost is the driving require-ment, a ramp is the better choice, even though it is less effective in meetingthe other requirements. Then they could double-check their assumptionsabout priorities with the client.

Sometimes, a matrix might not lead you to a single answer, but will help youeliminate alternatives. User testing on the electronic kiosk showed that someusers wanted extensive information, such as restaurant menus, which wouldmean more time and money to build and maintain the database and possiblycause long lines at the kiosk as users pondered their choices. To figure out asolution, the design team created the matrix below to measure three alterna-tives against three requirements. The alternatives, in the top row, are: fullmenus; a list of featured dishes and their prices; and the type of restaurant andits location. The first column lists the key requirements: providing usefulinformation, keeping costs low, and ensuring efficient use of the kiosk.

Lift Ramp

Raw Weighted Raw Weighted

Cost (x2) -- ---- ++ ++++

Ease of use (x1)

++ ++ - -

Use of space (x1)

++ ++ -- --

Total ++ 0 - +

90


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 twoalternatives fared equally well. The next sections offer additional methods formaking decisions when matrices don’t yield definitive answers.

7.4 TALKING TO THE CLIENT

When you have tough decisions to make about your design, especially thoseinvolving costs, it’s important to seek input from your client, who can tell youwhat she is willing to spend and what is most important to her.

After eliminating complete menus, the kiosk team had to decide, based oninconclusive user testing, whether to list a restaurant’s featured dishes or justthe type of food and the address. The deciding factor was cost. A meetingwith the client confirmed that he was willing to spend the money required toenter 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 involveinterviewing experts and testing more mockups on users or in controlled set-tings.

Interviewing experts: When you don’t know enough to measure how well cer-tain features meet all relevant requirements, seek out experts. Even after inter-viewing church members and the client, the team designing the access to the

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 effi-ciently

-- ++ ++

Total -- ++ ++

91


church stage still couldn’t decide if the electric lift was the best choice. Theyassumed 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 wouldtake up more space. But they needed more than just assumptions, so theysought the advice of experts on handicap accessibility in rehabilitation insti-tutes, college faculties, and companies that make equipment for people withdisabilities.

Testing more mockups: Lastly, you can go back to users or the lab with newmockups that embody the alternatives you are stuck between. The kiosk teammight want to know whether users would be satisfied with a brief list of fea-tured items for each restaurant or how much time people would spend at thekiosk reviewing full menus. To answer these questions, they could quicklymock up pages that included the alternatives: lists of featured menu items,complete menus, and no extra information. Then they could show these tousers and give them a task—“Using these pages, decide where to go to dinnertonight”—and time their interactions with the mockups. Perhaps only at thatpoint could the team feel confident that they knew enough to decide howmuch 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 Uni-versity.

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, constructan FMEA chart that includes the following information for each failuremode:

• 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 risksrelated to the product being designed. Some risks are project-focused andoften have to do with schedules and budgets. These risks can be addressedthrough careful project planning and monitoring with tools such as Gantt andRAM charts and by creating contingency plans.

Other risks have to do with the product themselves. One useful tool for ana-lyzing 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 prod-uct could fail and to assess the potential effects of that failure on the productand any people interacting with it. Once all of the risks have been identifiedand 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 monitorsgenerally have two components: the baby unit and the parent unit. The babyunit is placed near the child to pick up sound, and possibly video, and transmitthis information to the parent unit. The device allows a parent to be in a sepa-rate room and still know if the baby is awake, asleep, crying, etc.

Table 8.1: Baby monitor FMEA

Item Failure Mode

Failure Cause

Failure Effect on Component

Failure Effect on System

Failure Detection Method

Sev

erity

*

Fre

que

ncy

**

Par

t F

ailu

re S

core Action

Plastic housing

break mfg defect

component broken

internal ele-ments exposed; may create sharp edges/small pieces

visual 3 1 3 inspect before pack-aging

break drops on floor

component broken

internal ele-ments exposed; may create sharp edges/small pieces

visual 3 4 12 design plastic hous-ing to withstand a drop test at 4 feet

come open/loose

missing screws

none potential expo-sure to internal elements

visual 3 2 6 include some snap features in addition to screws

Power cord

cord hous-ing cracks

stress at junction to unit

wires exposed, possibly bro-ken

may prevent use of device

unit doesn't work

3 2 6 add strain relief

becomes discon-nected

child pulls on cord

none child may play with cord: chok-ing, strangulation

adult super-vision

4 2 8 clear warnings in instruction and on base unit

Power button

non-func-tional

mfg defect

non-func-tional

system cannot be used

nothing happens when but-ton is pressed

2 1 2 test unit before packaging

pressed at wrong time

child presses button

none caregivers can-not hear child

change in sound on parent unit

2 2 4 place button in inconspicuous loca-tion, have indicator on parent unit for no signal

Battery door

missing door lost none batteries acces-sible by child

visual 3 2 6 consider hinged door or leash options

missing screws lost

none batteries acces-sible by child

visual 3 2 6 consider slide or snap in design in addition to child-resistant screw

alignment tabs break

stress concen-tration

can’t be assembled

batteries acces-sible by child

visual 3 3 9 more robust design needed

94


8.2 CREATING AN FMEA

To create the FMEA table, follow the steps listed below. (The title of the col-umn 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 prod-uct? What mistakes might a user make?

• How would users with various limited abilities interact with the prod-uct? What problems might they encounter?

• How might the product be misused or abused?

For misuse/abuse modes, it is not necessary to consider every possiblecontingency. Instead, focus on likely misuses and abuses. A toddler play-

Micro-phone

non-func-tional

mfg defect

non-func-tional

caregivers can-not hear child

cannot hear child


damaged child sticks fingers in open-ings

non-func-tional

caregivers can-not hear child/possible injuries to finger

cannot hear child/see injured fin-ger

3 2 6 all openings should be smaller than child's finger

LEDs non-func-tional

mfg defect

non-func-tional

caregivers need to test unit to be sure it is working

LED not lit when power but-ton pressed


non-func-tional

burned out

non-func-tional

caregivers need to test unit to be sure it is working

LED not lit when power but-ton pressed

1 1 1 select LED life to correspond with expected product life

*Severity Values (user/device)1 = mild annoyance/visual but not functional defect2 = really irritated/damaged part, still functional3 = minor injury/part requires replacement4 = serious injury/ device requires replacement

**Frequency Values1 = 1 in 10,000 uses2 = 1 in 1,000 uses3 = 1 in 100 uses4 = 1 in 10 uses

Item Failure Mode

Failure Cause

Failure Effect on Component

Failure Effect on System

Failure Detection Method

Sev

erity

*

Fre

quen

cy**

Par

t Fai

lure

Sco

re Action

95


ing with the power cord or randomly pressing buttons on the unit are bothlikely 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 consis-tency. 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 rat-ing. 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 takento improve your product. Low scoring items, such as something that is notlikely 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 addressit if there is an easy fix.

Higher-scoring items must be addressed. Depending on the failure, you maybe able to design it out. You do not need to describe the particular designchanges at the time of the FMEA; that can be a follow-up activity. In theaction column, you can list “design change.” By understanding all of the fail-ures that require design changes, you may be able to combine them to addressas many failures as possible with the minimal number of changes.

Some items cannot be designed out, such as preventing a user from putting thebaby monitor in a bathtub. You may have to resort to clear instructions in themanual and/or the use of labels. This should be a last resort due to limitedeffectiveness.

In the example of the baby monitor, only the components that were designedby the DTC team were included in the FMEA. If this monitor were being

96


manufactured in industry, the entire assembly would be considered, down tothe 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 knowl-edgeable people, particularly fellow designers. These people can also includethe client, members of the client’s organization, and outside experts. The pur-pose of the review is to help the design team ensure that the design meets cli-ent and user requirements.

A typical review begins with the team briefly discussing client and userrequirements. The team then presents its design (or design alternatives, if asingle design concept has not been decided on). The reviewers’ role is to eval-uate the design critically: ask questions, identify problems, and make sugges-tions.

Design reviews are an important way for a team to get an informed outsideperspective and to keep the project on track. In industry, they are often done atseveral points during a project. Each review helps designers to rethink andrefine their concepts.

99


In presenting your design for review, your goal is not to persuade the review-ers that it is wonderful. Instead, your goal is to encourage them to uncoverpossible problems in the design, to offer suggestions for improvement, and tohelp ensure that you have followed the design process rigorously with yourclient and users constantly in mind. Since you have invested so much time andenergy in the design, your natural tendency may be to justify what you havedone and to deflect criticisms and suggestions. Doing that may make you feelgood, but down the road it will hurt you, especially when you go to your cli-ent, who will demand that your design have no flaws and that it meet everysingle requirement. So use the design review as an opportunity to ensure qual-ity control at a point in the process when it’s not too late to correct mistakes.

The following three sections discuss how to prepare and present the review aswell as how to organize the feedback you receive. A final section discusseshow to offer useful feedback as a reviewer.

9.1 PREPARING THE REVIEW

Design reviews can be formal or informal. Follow these guidelines to planyour 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. It’s 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 client’s organization and the problem, using visual aids—such as photos and brief video clips—as needed.

2. Prepare visual aids. These may include your latest mockup(s). For fea-tures 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 exten-sive PowerPoint slides. Your visual aids just need to help reviewers understand the design problem and the key features in your latest solu-tion(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 ques-tions 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 engi-neer is to delay that failure and minimize its impact. Similarly, all designs have safety hazards. That’s 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 hand-outs 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 get-ting suggestions and criticisms of all aspects of the design, so review-ers 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 sug-gestions 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, we’ve 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 sugges-tion is not, “We tried that, and it didn’t work,” but “Here’s what hap-pened 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 thefeedback 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 com-ments you received orally during the review and those written on the review sheets you distributed. Post this categorized list so that it’s 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

Additionalcomments

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

Good if you are doing a lot of work in car.

EASE OF USE

Don’t like having seat down.

Too cumbersome to access from driver seat.

USABILITY

Only useful for driv-ers.

Cannot be used by back seat.

Can’t be used when there is a front seat passenger.

Not accessible while seat is upright.

FUNCTIONALITY

Too cluttered.

Too much stuff.

Hard to see all of the items.

Cup holder is too far away.

Safety issues.

Cover

Better places to put CD case

Mirror- safety issue

USABILITY

Most useful if driver is alone in vehicle.

Make it usable when it’s upright as well.

Prioritize user needs.

VERSATILITY

Try not to be so specific with the pouches—more versatility.

COMPONENTS

Only things I would use would be the Kleenex, pencil holder, and expand-able file.

People usually unlock the front door first; getting the ice scraper would be a pain.

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 team’s 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

*Solution still needed—immediate action item

9.4 OFFERING USEFUL FEEDBACK AS A REVIEWER

When you are a reviewer, your job is to offer constructive feedback and prob-ing questions that will help your fellow designers improve their design. To dothat, keep in mind the following guidelines:

• Say what you like and dislike. You don’t 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,

Suggestion/criticism Implementation

Side joints do not seem strong enough. Suggest triangular supports.

Add metal L-brackets between side panels and base.

Round off sharp corners or add rubber padding for safety.

Add rubber strips on corners.

Add lip on bottom shelf. Add lip on one side of cart.

Bungee cord seems unsafe; use mesh.

Add mesh netting on both sides of cart.

Objects on bottom shelf may obstruct stick storage extending through shelf*.

Use indentations in a wood block to secure new stick configuration—work in progress.

Make sure all the games fit in cart, including Team 2’s large games.*

Continue to work with Team 2 on their games.

Cart needs a design and/or paint.*

Add some type of finish: paint, varnish, or oil. Ask Prof. Jacobson which is best.

Use peg dividers instead of wood slats.*

A simpler divider system is needed—work in progress.

104


they will discover a great deal about its strengths and weaknesses on their own.

• Be on the lookout for “latent defects”—design flaws that are not obvious and that may surface during the product’s use. You will be very helpful to the designers if you present scenarios for the product’s use that may uncover a defect they have not anticipated. The Y2K problem is a classic case of a latent defect that had enormous reper-cussions. 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 misinter-pret “00” as “1900.” It is estimated that over $300 billion was spent in order to solve the problem.

• Ask questions about the design’s reliability and safety issues. In par-ticular, ask probing questions about the team’s 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, constructa Bill of Materials that includes the following information for each itemused:

• 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 solvesthe client’s problem and addresses user needs. To test that concept and dem-onstrate it to your client, you will have to move part way into the secondmajor phase: detailed design. In DTC, that phase will consist of producing aprototype that embodies key features of your design. You will need to figureout exactly where certain components will connect, how far apart holes mustbe drilled, what kinds of fasteners to use, and other such problems.

In a few cases, your detailed design might include a fully functional “lookslike/works like” prototype. This most often occurs if you are creating a “oneoff”—a unique design for a single user, such as a toy for disabled children atChildren’s Memorial Hospital or a wheelchair ramp for a specific client’sfront entrance. In completing a detailed design, you will produce a bill ofmaterials and dimensioned drawings that depict all components of the system.

107


The bill of materials and other considerations that go into detailed design arediscussed below.

10.1 BILL OF MATERIALS

The bill of materials (BOM) is a comprehensive listing of every item that goesinto a finished product. For each item, the BOM includes the description,quantity, part number, unit cost, and total cost. The BOM tells the clientexactly how much the design costs and eases the process of ordering parts ifthe client decides to manufacture it.

Here is the BOM from a project to design swimming goggles for people withspinal cord injuries:

Example 10.1: Bill of materials

Item Description Qty Source Part # Unit Cost

Total Cost

Dive mask U.S. Divers Admiral Mask 1 Sports Authority 2173701 $29.99 $29.99

Ratchet Union snowboard bind-ing ratchet & ladder sys-tem

1 Shredd Shop N/A $5.00 $5.00

Aluminum plates Corrosion-resistant alu-minum (alloy 5052), 1/8" thick, 1" width, 12" length

1 McMaster Carr 9135K111 $8.01 $8.01

Polypropylene rib Polypropylene strip, 1/16" thick, 1/2" wide, 12" long

1 McMaster Carr 8742K131 $0.15 $0.15

Nylon fabric Nylon webbing, 3/32" thick, 1" wide, 12" long, black

1 McMaster Carr 3510T121 $0.51 $0.51

Elastic fabric Elastic fabric, 0.055" thick, 1" wide, 12" long, black

1 McMaster Carr 88225K68 $0.24 $0.24

Squeeze buckles Light duty plastic buckle for 3/4" wide webbing, sew on, squeeze release

3 McMaster Carr 29705T82 $0.44 $1.32

Machine screws Type 316 SS pan head Phillips ma-chine screw 4-40 thread, 1/2" length

6 McMaster Carr 91735A106 $0.12 $0.72

Nuts Type 316 SS machine screw nut 4-40 screw size, 1/4" width, 3/32" height

6 McMaster Carr 90257A005 $0.09 $0.54

Rivets Aluminum pop rivets, 1/4" head, for material thick-ness 0.126" - 0.187"

4 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 becomesmuch more complex than in the case of a one off—and beyond the scope ofDTC. But because detailed design for production is such a crucial aspect ofthe work you will do as an engineer, you should have a general understandingof what it involves. Here is a partial list of considerations that typically go intodetailed 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 isn’t 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 manufac-tured by injection molding, blow molding, rotational molding, com-pression 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 Intro-duction (2000), Clive Dym and Patrick Little give this example:

[A]ssembling a ballpoint pen might require that the ink-holding 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, pro-viding redundancy so that systems can be operated while maintenance continues, specifying preventive or predic-tive 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 pro-duction. Clearly, no one engineer can master them all. That’s partly why com-panies assemble cross-disciplinary teams to work on design projects. Thepoint is, however, that no designer can afford to overlook these considerationsin completing a project.

10.3 REFERENCES

Dym, C. & Little, P. (2000). Engineering design: a project-based introduc-tion. New York: John Wiley and Sons.

Foley, P., Kanesathasan, A., Schuster, D. & Willer, M. (2008). Tap-tight gog-gles:tap on, tap off. Engineering Design and Communication, Northwest-ern 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

• Consider ethical decision-making in relation to:

– cost-benefit analysis

– risk assessment

– organizational context

– regulatory compliance

The first thing to recognize about engineering ethics, and professional ethicsgenerally, is that they do not entail a fundamentally new and different basisfor ethics than you already have. Professional ethics do not ask you to adoptone set of values at the workplace and another set in your personal or civiclife. Logically and ethically, the founding principles of our actions must godeeper than circumstance. This means that your personal and professional eth-ics are not entirely divorced from one another.

Personal and professional ethics ultimately rest on the same foundation ofmoral commitment, even though above ground they may branch out in differ-ent directions and entail different responsibilities as the context varies. If weignore that common foundation, we would make professional ethics an ethicsof convenience or an exercise in mere rule-following. Ideally, professionalethics should be an extension of the ethical values you already hold, carefully

111


and responsibly applied to your professional work in recognition of the dutiesand consequences particular to it. Without this common foundation, studyingprofessional ethics would not mean anything.

But this is not to say that there is no difference between personal and profes-sional ethics. Although the underlying values will have much in common,professional situations entail fiduciary obligations and involve profoundlynew and different contexts for your actions—contexts that could entail far-reaching ramifications for others. This difference in context means that youractions take on a different significance when they are part of your professionalwork. This is the reason that professional organizations create and promotetheir own codes of ethics. For example, the National Society of ProfessionalEngineers, NSPE, publishes a Code of Ethics for Engineers that attempts tolay out, in a general sense, the basic ethical duties an engineer assumes as aprofessional.

What is different about ethics in the professional context? Ethics, at its mostbasic level, is about taking responsibility for your actions by anticipating theirpotential consequences—both intended and unintended—and acting so thatthose consequences will be positive. As future engineers, your professionalwork may greatly influence your users, your community, and even society atlarge—perhaps in non-obvious ways. Personal integrity is essential. Butintegrity and good intentions are only prerequisites in a professional environ-ment in which you are entrusted with specific responsibilities whose exercisecan have complex and far-reaching implications for others. You must alsogain 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 engineer-ing from all other professions is the subject of this course: design. Designmeans the development and creation of new products and systems that collec-tively can substantially affect society—for better or worse. Thus, ethics inengineering means that you—the designer and your design team—areaccountable for helping shape the impact that your design (and the processesthat surround it) will have. Only such an approach will allow you to managethose consequences and do what is possible to ensure that they are positive.

Of course, engineers do more than just design things. They may be consul-tants or advisors in a variety of contexts, and there are other aspects of ethicsrelevant to engineering (professional ethics, conflicts of interest, endorse-ments, confidentiality, teamwork, etc.). But as this is a course on the primarytask of engineers—designing and building things—we'll focus primarily onethics in design. That actually turns out to have fairly broad implications.

Ethical engineering—that is, engineering that hopes to maximize its positiveeffect on users and on society—requires addressing complex design questions

112


ranging from the selection of the problem to the choice of a design solutionand its manufacture; from the method of testing to the post-market life of theproduct. This is because these consequences exist not just in the use of thedesign, but throughout its whole lifecycle, from development through testing,manufacture, sale, deployment, use, disposal, and beyond. Every phase of thedesign's life carries social implications, and thereby presents ethical risks andopportunities.

Thus, engineers must try to anticipate likely consequences—and evenunlikely ones—at each stage as much as possible. Ethics in design is not aboutsimply 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 yourdesign, the more you can control the effect it will have in the real world. Thisis a core part of an engineer's competence—not an optional specialty. It is alsoone of the more difficult skills to master.

Of course, there are reasonable limits to this principle. No one can be heldpersonally responsible for everything that follows from every action he or shetakes, if for no other reason than we are not omniscient, and cannot predict (oreven know after the fact) all of those consequences. But taking responsibilitysimply means making the effort to anticipate as many potential consequencesas we can.

11.2 NATURE AND SCOPE OF DESIGN CONSEQUENCES

Like design itself, ethics involves more than just safety. A design is not auto-matically a good one merely because it is safe; still, an unsafe design is prob-ably not a good one. Similarly, an unsafe design is probably not an ethicalone; but a safe design is not automatically an ethical one, either. Safety is justone necessary aspect to both good and ethical design. An understanding of thefull lifecycle of a design, and the many other impacts it can have, is crucial tounderstanding what else may be involved. Let's consider the main areas inwhich 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 solved—ideally, 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 deci-sion—what 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 resources—for 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, espe-cially when these resources are found only in politically or economically unstable regions of the world (for example, demand for the mineral Col-tan used in cellular radios has helped fuel civil war in the Congo). In addi-tion there is the manufacturing phase itself, which consumes further natural resources in the form of energy and can also significantly influ-ence 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 broadly—even by all of society. Among the examples here are automotive emissions, which affect everyone, regard-less 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 amelio-rate 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 opportu-nity 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 individ-ually, in practice all of them are unified in the design process. After all, thenature of the design determines, or at least heavily influences, the materials,manufacturing, safety, and end-of-life issues. Of course, issues in some ofthese areas may also arise after the design has been completed; at that pointthe 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 withexamples of the accompanying ethical considerations.

Table 11.1: Examples of ethical considerations in each lifecycle stage

It may seem that many of these impacts, while important, are too large for anyindividual engineer, or even any single design, to be able to influence. Itwould, for example, certainly be difficult for engineers on a medical deviceteam to do anything meaningful about the high costs of healthcare to whichtheir product might contribute—though they might be able to do something tohold down costs for their own product.

Nevertheless, all engineers should still be thinking about these impacts for anumber of reasons. First, it is important for each of us to better appreciate thefull context of our work for personal reasons and as informed citizens in ademocracy. Second, if everyone on a project had such awareness, the positivechanges possible would become greatly magnified, just as they would ifeveryone in an industry attained such awareness. And third, you may be in aposition later in your career, as a team leader, project manager, or even aCEO, where you will be able to exert a more substantial effect.

Moreover, many of these impacts will be under your influence for at leastyour product. While it will always be more difficult to influence the globalscale, the differences in your product alone—preventing a failure mode orrefining the user testing—could make all the difference in the lives of thosewho come into contact with it.

11.3 GOOD DESIGN AND ETHICAL DESIGN

Ethical consideration must be integrated into the design process because it isin design that all consequences are best accounted for, and negative ones min-imized or eliminated as possible. Can we say, then, that the ethical dimensionsare already accounted for in ordinary engineering design? That ethical designjust is good design? There is some truth to this. But it is not the whole truth,because not all important ethical considerations—i.e., not all the impacts a

Lifecycle stage Example ethical considerations

Design, development and validation Setting design goals, user testing, clini-cal trials

Manufacture, assembly, distribution Mining, petroleum and energy inputs, outsourcing, worker safety

Direct impact on users and customers Safety, reliability, performance, cost

Social/environmental impact of design in use

Internet, auto emissions

Social/environmental impact of design at end of life

Pollution, disposal, recyclability

115


design may have—are directly built into normal engineering design goals.Indeed, many of the most important social impacts a design makes may notfactor into typical engineering design criteria.

For example, vehicle fuel efficiency can be a selling point for the buyer and atsome level is likely to be an explicit engineering design goal; but this consid-eration does not reflect the full social impact of burning fossil fuels, especiallywhen gas is cheap. Likewise, safety has aspects that affect the users andaspects that could affect others. The aspects that affect others, such as pedes-trian safety, are not likely to factor directly in customer safety needs, such ascrashworthiness. Therefore, without regulations (which now exist), pedestriansafety would not always factor into the explicit design goals. But a more ethi-cal 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 pro-cess. But ethical, responsible design will consider other needs as well. Engi-neers, like all professionals, have a responsibility that extends beyond ourusers or customers and encompasses our broader role in society. This is onecrucial aspect that distinguishes engineering ethics from ordinary “good”engineering. It isn't exclusively about your immediate users and customers,because—as we have just seen—the impacts of engineering touch us all,directly and indirectly, before and after use. Engineering ethics ultimatelymeans expanding the metrics used to evaluate a design, considering aspectsthat begin with but might go beyond immediate and obvious user needs. Engi-neering ethics is a matter of scope.

This scope, as we saw above, also extends beyond consideration of the prod-uct per se, and includes the processes that inevitably accompany it—fromtesting to manufacture to disposal. Explicit engineering design goals tradition-ally focus squarely on the product itself. They may implicate peripheral pro-cesses—for example, manufacturability—but typically only as they relate tothe end result of the product itself (for example, simplifying manufacturing tokeep the unit cost low). Engineering ethics, on the other hand, must be con-cerned with processes for their own sake—for example, whether the testingphase 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 engi-neering design; it is integral to good design—and yet it is not reducible togood design alone.

11.4 ETHICAL DECISION MAKING

Thus, in ethical design, thinking through the many potential impacts of yourdesign, 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 basicguidelines, scenarios and information that can be helpful.

116


11.4.1 Cost-benefit analysis

One common approach to addressing problematic design consequences is thecost-benefit analysis. This seemingly simple idea involves comparing thecosts 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 theoreticallystraightforward approach offers an important perspective, but it is actuallyfraught with complex ethical questions. The foremost among these is that, ifthe identified impact involves the risk of death or injury, it requires placing adollar value on human suffering or even on human life. Only then can thecosts be compared on a dollar basis. On one level, this valuation may seemabhorrent. But there are many cases where this is necessary, particularly whenthe scale of the issue is very great. For example, in crafting safety regulationsthat will govern entire industries, the government agency in charge must usesome dollar figure to compare the benefits in saved lives to the cost of the pro-posed rule. If they did not, we would go broke trying to eliminate every con-ceivable risk. But this approach requires tremendous care. History is repletewith cases where a company cut corners figuring that the cost or risk wascheaper than doing things right—and people paid with their lives.

The other major ethical dimension involved in a cost-benefit analysis con-cerns how the costs are counted. Even when a dollar value is used to countlives saved, those lives must be accounted their full value regardless ofwhether or not they represent literal costs to the company. If not, a cost-bene-fit analysis could ignore those harmed so long as they do not represent actualmonetary expenses that the company is likely to bear. If those harmed do notfigure into the calculations, the result can be to justify deeply unethical deci-sions based solely on the company's own financial interests.

It is worth noting that, historically in those cases, when the company's reason-ing became public, the damage to the company's reputation often became anenormous cost, one that had also not factored into the analysis. These impair-ments 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 prevalenceof the impact requires attention. That is, how likely or common is the negativeimpact to be and for whom? Is it a risk that all users bear or only users in cer-tain circumstances? Is it a risk that can be avoided if users follow directionsand use the design properly? If so, how likely are they to do that? And will theusers be aware of the risk? Alternatively, the issue may not be a risk for theuser, but for someone else—perhaps a factory worker assembling the productor the person who disposes of it. It may also be a risk that is not specific toanyone but is socially distributed, such as groundwater contamination afterdisposal. It may even be one that presents itself to an entirely different popula-tion than your user base, as when electronics containing toxic elements arecrudely recycled in poorer parts of the world. In any case, evaluating the mag-nitude 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 any-thing, to do about it. These technical issues cannot be addressed here, but theethical duty can be: to be honest and unbiased in the attempt to assess thatrisk, and recognize to whom it applies.

Once a problem has been detected, and its nature and risk level examined, theobvious next question is what to do about it—whether that means changingthe design itself, the materials used, the processes to manufacture it, or simplyissuing safety guidance to the user. Clearly, whatever is decided on, that alter-native presents a new variation of the design—which then itself must be ana-lyzed. This is the normal, iterative design process, but, as above, withadditional metrics in mind. Also note that, as with the regular design process,choosing what to do about a negative impact will involve the creative genera-tion and comparison of many potential alternatives, not just the first solutionyou think of. There may not even be a clear-cut “fix.” The goal, as always, isto find the best compromise solution.

11.4.3 Organizational contexts

In the foregoing, it was assumed that you, as the engineer, have direct influ-ence on the design and the choices that go into it. In DTC, although you workwithin a team and with a client, this is largely the case. In industry or otherprofessional environments, however, the context is very different. You maystill 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 himor her, there is an executive management team, a corporate board, perhapseven shareholders. In addition, there may be other teams competing forresources, higher-level corporate goals, company policies, market conditions,indeed, innumerable other factors that may influence the conditions of yourwork. All of these may constrain your ability to make decisions.

So, if you are working on a design and have identified an undesirable outcomeit is likely to have, the first question that arises is what scope you have tomake changes that would help. In many cases, if it is an ordinary designrefinement, consulting with your team and manager to arrive at a superiordesign will suffice. However, some changes may be more fundamental or mayinvolve other aspects of the overall project. In such cases, you may need toraise the issue with those in higher level positions or with those working onthe relevant aspect of the project. Companies will often have explicit channelsfor raising such concerns, but typically it will begin with notifying your teamleader or manager, who then assumes the responsibility for seeing that theproblem 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 thatthose who would actually be impacted (e.g., end users or community mem-bers) should be brought into the decision-making process to offer their owninput. This is especially true in cases where there is a particular, inevitable andconsequential tradeoff to be made.

118


It is conceivable that there may perhaps come a time when you perceive amajor ethical problem with the way that things are being done in your organi-zation—whether that be a dangerous design flaw, a troubling safety record orsome other problem—that you are unable to satisfactorily resolve within yourorganization's official processes. If this should occur, many larger organiza-tions today offer one additional channel: an ethics office. In fact, even North-western University operates one (see www.northwestern.edu/ethics). Thepurpose of an ethics office, among other roles including education and regula-tory compliance verification, is to serve as a confidential venue for reportingethical concerns. If you feel the need to, you should not hesitate to take advan-tage of this important avenue, particularly if you believe you have exhaustedconventional channels and that the problem poses substantial risks.

Of course, in extreme cases, it is possible that even the ethics office, assumingit exists, will not be able or willing to do enough to address the problem. Inthese cases, you may be forced to consider becoming a “whistle-blower.” Theterm simply refers to someone who publicly “blows the whistle” to call atten-tion 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 toforce it to address the problem. While some of the most important cases inrecent history have been initiated by conscientious whistle-blowers (includ-ing, for example, cigarette dangers), it is also true that whistle-blowing can bepersonally a very risky thing to do, threatening relationships as well asemployment and even resulting in lawsuits. However, if the issue is importantenough, potentially affecting many people or threatening serious injury, youmay have no ethical choice but to go public. Fortunately, such cases are notcommon. In addition, federal law today exists to protect and even rewardwhistle-blowers.

11.4.4 Regulatory compliance

Engineers, and even entire engineering companies, do not operate in a socialvacuum. Because of the large impact of engineering and engineered productson society, there are a plethora of laws, regulations and codes that govern itspractice and products. Regulations are part of the social compact betweenindustry and society. Society desires the products of industry—whether theybe iPods, automobiles or new drugs—but not at any cost. Regulations,abstractly speaking, exist to mediate the quality of and the means by whichthese products are developed and sold. Complying with these regulations isthus also an ethical, as well as legal, responsibility.

We cannot hope to cover all or even many regulations here. But you should beaware that they exist, and of the important role they play, so a rough overviewof our regulatory system is in order. The regulatory environment is very dif-ferent for the different phases of a product lifecycle described above. Differ-ent federal agencies, for example, will have jurisdiction over different kindsof activities. Below are a few of the more prominent ones in the U.S., and abasic idea of their purviews.

119


Environmental Protection Agency (EPA). The agency most responsi-ble for preventing the pollution of air, water and land, the EPA hasrules which may influence all phases of the product's lifecycle, frommining for raw materials to production waste products to the energyefficiency of the final product itself.

Occupational Safety and Health Administration (OSHA). OSHA isresponsible for establishing and enforcing safety standards for theworkplace, including industrial sites. Their rules may influence man-ufacturing aspects in order to protect factory workers.

Food and Drug Administration (FDA). The FDA is charged with pro-tecting the safety and efficacy of all medical products (drugs anddevices) as well as the safety of many foods. If your product is a med-ical device or a drug, you must have FDA approval to market it in theUS. This often requires clinical studies demonstrating both safety andefficacy. The FDA also regulates promotion and marketing claims forthe products it has jurisdiction over. It shares its jurisdiction over foodproducts with the United States Department of Agriculture, USDA.

Federal Trade Commission (FTC), including their Bureau of Con-sumer Protection (BCP). The FTC's mission is to promote fair andhonest competition across all sectors of industry. To this end they reg-ulate advertising and product claims, among other things. Their rulesmay influence sales policies and product marketing. For food, drugsand cosmetics, FDA has primary jurisdiction.

Consumer Product Safety Commission (CPSC). The CPSC is a smallagency, but it has a large job. It is responsible for policing the safetyof any product not regulated by FDA or other agencies. For example,it has rules around lead content in children's toys. The CPSC canmandate recalls of products it determines are toxic or otherwiseunsafe.

Local regulations. There are of course an unlimited variety of locallaws. Building codes are one important example. Codes are set bystates and municipalities and govern in detail the construction stan-dards of new buildings. There may also be local regulations aroundmany other activities relevant to engineering.

This list is just a sampling of some of the more prominent sources of regula-tion in this country. Other countries will often have comparable agencies. Thepoint is that the engineer, or someone in his or her company, must be fullyaware of the relevant regulations. Ignorance of the law is never considered avalid defense and unfortunately some of the regulations can be complex. Ifyou are doing business internationally, you must comply with the local lawseverywhere you operate, which adds to the complexity. Many organizationshave entire offices, called compliance departments, dedicated to understand-ing, keeping up with, and ensuring compliance with applicable regulations.

120


But smaller companies lacking such departments are often equally subject tothe 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 isnot confined to any one area or stage of engineering. Nor is it a skill that isever fully mastered. Rather, it is suffused throughout engineering practice, inways large and small. And it is a skill that you will continue to hone and growin throughout your career. The main premise of engineering ethics is toalways keep in mind the potentially profound impact your work may have—and which engineering, collectively, certainly has—both locally and globally,on your users as well as on society.

121


122

PART THREE

TEAMWORK AND PROJECTMANAGEMENT

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 proj-ect

• 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 theengineering design process more efficient and productive, and teams arebeing used more and more frequently in all professions you may enter. Thefollowing two factors explain the importance of teamwork.

1. Teams make the engineering design process more efficient and produc-tive:

• 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 member’s 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 findteams in factories, corporate offices, research laboratories, universities,hospitals, law offices, government agencies, and other places. Accordingto Harvey Robbins and Michael Finley (1995), two authorities on team-work, “The world is teeming with teams”:

Work teams, project teams, customer support teams, supplier teams, design teams, planning teams, quality teams. Func-tional 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 accelerat-ing complexity of the decisions that need to be made. According to research-ers 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 enter-prises, the more complex they are likely to be. Solving these complex problems demands the integration of many diver-gent 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, youknow that successful teams don't just happen; they are built by individualsworking together. This chapter offers you a deeper understanding of howteams develop, what makes them succeed, and why they fail. In subsequentchapters, 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 acommon purpose, set of performance goals, and approach for which they holdthemselves mutually accountable.” They contrast a team with a “workinggroup,” in which overall “performance is a function of what the members doas individuals. A team's performance, by contrast, calls for both individualand mutual accountability.” This added factor of mutual accountability meansthat the team's overall performance exceeds the sum of its parts, its individualmembers.

Katzenbach and Smith emphasize that in order for the team to reach its fullpotential, “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 pur-pose.” 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 draw-ings, 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 char-ter, 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 per-son's strengths and enable people to play to those strengths through-out 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 communica-tion. 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 back-ground 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 hon-est 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 actu-ally 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 they’ve been given.This is unwise. In hindsight, many teams trace their failures to not havingshared expectations and specific ground rules. Research shows that teamsshould start with the question “how will we work together?” not “what's theright answer to the project?” Numerous experts have emphasized the impor-tance 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 onhow they will work together to complete the project successfully. Amongother things, the charter expresses the team's agreements on the followingquestions:

• What’s 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 person’s (or group’s) expectations?

• Who has authority to make what decisions? What decisions can indi-viduals 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 comprehensiveand 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 con-front. (p. 92)

In DTC, your team charter consists of three main sections:

1. Mission: This is identical with the mission statement in your project defi-nition, as discussed in Chapter 3.

2. Performance Goals: These identify the major objectives guiding the pro-cess that the team will follow to achieve its mission with a high level of quality.

3. Team Standards: These specify the behaviors and performance expecta-tions that the team will follow in its day-to-day functioning.

The following team charter is neither comprehensive nor specific, so it isunlikely to help the team as the project proceeds and demands more of eachmember's time and effort:

Example 12.1: Vague and Ineffective Team Charter

Mission: We will design a system that enables people in wheelchairs totransfer to and from the leg press machine at RIC quickly and comfort-ably.

Performance goal: Our mission is to fulfill the requirements of our projectas 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 berespected.

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 thoseof the entire team.

While the mission statement is clear, the performance goal sets only a mini-mal standard of achievement, and the team standards lack detail and leaveimportant 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 couldaddress these gaps as they arise later in the project, but that would waste timeand energy when they can least afford to do so. In such cases, experts find thatthe team is likely to “spend undue time grappling with teamwork issues thatwere not outlined initially and to suffer performance consequences” (Matthieu& Rapp, p. 92).

Effective team charters can take different forms and emphasize differentexpectations and behaviors. The key is to schedule, at the start of the project, ameeting whose purpose is for you to discuss and agree on a specific and com-prehensive charter that you feel confident will help you to become a high per-formance team.

For examples of two different but effective team charters see AppendixK.

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 strat-egies. 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 ANDMANAGING 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 fes-ter

To get your team to the “performing” stage described in Chapter 12, you needto develop an effective leadership structure and learn how to confront andmanage conflicts productively.

13.1 DEVELOPING A LEADERSHIP STRUCTURE

Whereas in industry, team leaders are assigned by management, in DTC theteam 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-motivatedand comfortable taking charge of a particular aspect of a project. Onemember may be responsible for prototyping, another for user and clientinteractions, and a third for written deliverables.

133


• Rotating leadership

This model works well when team members have time constraints at dif-ferent points in the project. Rotating leadership also is a good choice forteams with members who have strong personalities and are reluctant togive leadership over to one person. One DTC team rotated leadershipwhen members recognized that their relationships and quality of workwere deteriorating. One member directed activities during the testingphase, another during the design review phase, and a third during thepreparations for the final presentation.

• Single-person leadership

This model works well when one member is good at managing, motivat-ing, and communicating with his or her teammates or when sharing lead-ership is causing confusion about roles, missed deadlines, and poorcommunication.

As one student commented, “I learned that it is necessary to not be afraidto be a leader. If you feel like your team is falling apart, it is essential thatyou step up and take charge when the rest of the team needs you themost.” Another student found that his team faltered without his leader-ship: “I was the one running all the meetings, setting up times, and callingpeople. One week when I was out of town, my team forgot to meet. Whilethis was very frustrating, it made me realize that I really did hold the lead-ership role in my group. While this took up a lot more of my time, I alsofound it was rather rewarding when the team functioned to produce a finalproduct.”

However, when one person is acting as the leader, it’s important for himor her to also be a good team member and to avoid being bossy. Goodleadership involves following the guidelines below.

When your team hits the storming stage, discuss whether leadership—or lackthereof—is causing problems, and then choose a form of leadership that suitsmembers’ 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 isn’t up to par and take it upon themselves to redo the work. This can cause resentment and infighting, so it’s 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 experi-ence: “I don’t 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 some-thing. 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 back-fire. 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 pro-cess 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 team-mates.” 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 dis-covery, 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 discus-sion 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 arewell-matched. In fact, some conflict within a team can be a positive thingbecause it shows that team members are considering very differentapproaches to their design. A successful team performs well not because it hasno conflicts, but because it has learned how to manage them.

Here are the three main sources of team conflict. (NOTE: These examples arereal, but the names have been changed.)

1. Differences of opinion about goals and decisions. One DTC team couldn’t 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 mechani-cal 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 Greg’s reticent personality would weaken the team’s 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 didn’t 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. It’s important not to let one person who doesn’t 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 it—and 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 person’s or a group’s needs without nec-essarily giving them what they claim they want.

The above-mentioned team, who were split over whether to take a conser-vative or innovative approach to their design, resolved their conflict bydiscussing their needs rather than defending their positions. Joanne, Nel-son, and Stacy—the “conservative” members—needed to feel theywouldn’t jeopardize their grades by adopting a risky approach. Veraneeded to express her creativity by choosing a more experimental design.To meet the needs of both sides, their instructors suggested a three-partapproach: (1) The team would generate conservative and innovative alter-natives, which the instructors reassured them would help their grade. (2)Members would analyze the alternatives and choose the one that best fitclient and user needs. (3) The team would then produce a design based onthe chosen alternative: a prototype if it was “conservative” and CADdrawings if it was “innovative.” With the conflict resolved to everyone'ssatisfaction, the team was able to move ahead creatively and productively.

2. When you have a problem with a team member’s 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 mum-bling so I can understand him?” “I wish she'd quit being so negative.”“Just because he has computer programming experience, he thinks heknows everything.”

If you decide the person can’t, or won’t, change, figure out what youwant to accomplish in the long run. For example, if the person’s“problem” is low participation due to reticence, get him or her to par-ticipate by having everyone on the team come to the next meetingwith one idea for each agenda item, have team members email ideasto each other, or have each member speak on an agenda item at ameeting. Approach the conflict the same way you approach designproblems: 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 necessarywork. Greg's drawings would provide evidence for the presentationsthat Ann was preparing. And Carla, the third member, would coordi-nate 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 personal-ities involved, and the goal to be accomplished. In some situations, aformal team meeting is the ideal setting. In others, it’s over coffee orin 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 focusthe discussion and prepares the person to listen. Remember to be tact-ful and to listen.

e. Precisely describe the irritating behavior and when it occurred.

Avoid generalizing and name-calling. Insults will only make yourteammate feel defensive, hostile, and less willing to resolve the prob-lem. 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 wouldnever work. At the last meeting, when I suggested we interviewour client again to nail down the problem, you said that was ridic-ulous because the problem was already clear. And at the same

137


meeting, you laughed when I said we needed to do moreresearch.” These examples give each of you something specific towork from and demonstrate that your reactions derive not fromimagined slights but from actual incidents.

– Next, explain how the behavior affects you and the team.

In the situation above, you might say, “I’m to the point where I nolonger want to contribute ideas during our meetings because Iworry about being embarrassed by having them put down. Thatmeans we might lose out on some potentially good ideas.Besides, it’s going to make everyone uncomfortable if I just sithere saying nothing during meetings.” Explaining the behavior'sconsequences gives everyone a stake in reaching a resolution.

– Finally, offer a suggestion.

In the situation above, you might say, “I’d like you to hear me outwhen I have something to say. And if you disagree, then I'd likeyou to be specific about which part you don’t like and why.”Sometimes you might not know what to suggest. In that case, pro-pose that you work together to reach a resolution so the problemdoesn'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 it’s 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 prob-lem 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 con-flict?

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 that’s 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 seeit that way. In the case of the introvert and extrovert, Greg and Annsaw each other as less hard-working because neither understood the

138


value of the work the other person was doing. They needed to appre-ciate 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 inter-vene.

In one DTC class, three team members worked hard while one,George, did very little. When he failed to follow through on new taskshe agreed to do, even at the persuasion of his instructors, his teammembers decided that worrying about him was distracting them fromthe project. After consulting with their instructors, they divided thework among themselves, started having fun, and developed an out-standing design.

If George had behaved this way on a job, he would have been trans-ferred, or even fired. In DTC, those are not options. But becauseteamwork is required, George received a low grade for failing tocooperate with his team.

13.3 REFERENCES

O’Brien, 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

• Follow these guidelines for effective meetings:

– come on time

– have everyone participate

– make decisions by consensus, not majority rule

• Post minutes after the meeting, using this structure:

– date/time/location

– participants

– scribe

– topics, key points, and decisions

Team meetings will play an important role not only in your work in DTC butin your professional career as well. Researchers who surveyed over one hun-dred engineers with an average of fifteen years of experience found that“meetings and informal interpersonal situations are the places where a signifi-cant amount of engineering work gets done and provide the context for creat-ing and sustaining productivity in daily practice” (Darling, Dannels, 2003, p.8).

141


In DTC, class periods don’t give you enough time to work on your project, soyour team should meet at least once a week outside of class to plan tasks, ana-lyze information, write reports, and practice presentations. In addition, yourteam 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 commit-ments so that work can be distributed in the most realistic and produc-tive way.

• Meetings are an incentive to complete your work, knowing you’ll 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 hamper-ing 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 ofyour time. Set the agenda by having team members contribute items. Theagenda 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 that’s safe and convenient for everyone, or rotate locations.

• Meeting objective. Be as specific as possible in your meeting objec-tive so you don’t 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-cuttingdevice for stroke survivors. The first agenda was for a meeting held by teammembers 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 anadvisory grade based on the team’s 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


Finally, here is an agenda for a team meeting with the client. It was held threeweeks before the scheduled final presentation, and its goal was to get the cli-ent’s feedback on the final design direction that the team had chosen as aresult of user testing. It is less detailed than the agenda used for the meetingwith instructors because the client does not need to know the planning processused by the team for each topic. However, the time allotted for each topic isincluded 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 Designatrium

Objective: Get feedback on final design concept from client

Meeting leader: Alicia

Scribe: Jessie

Timekeeper: Vera

Topic Presenter Time Outcome Process Preparation

Review of action items from previous meeting

Vera 2 min. Instructors know key findings resulting from completion of action items

Oral summarywith reference to minutes of preced-ing meeting and to progress report

Review progress report and minutes of preceding meet-ing

Mockups for user testing

Nirav, Ali-cia, and Vera

10 min.

Instructors provide feedback on mockups

Oral summary with mockups

Review progress report; make sure everyone brings mockups

Plan for get-ting users

Jessie 5 min. Instructors review and offer suggestions for revising email to client asking for users

Copies of email are distributed

Jessie types email and circulates it among team for review; makes cop-ies of edited ver-sion for meeting

User test guide Jessie 8 min. Instructors review and offer suggestions for user test guide

Copies of user test guide are distrib-uted

Jessie types guide and circulates it among team for review; makes cop-ies of edited ver-sion for meeting

Questions and comments from instruc-tors

Vera 8 min. Instructors have oppor-tunity to raise issues and concerns

Discussion Make sure project notebook is updated and complete in case material is needed to answer questions

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 relativelyshort meeting, it's well worth doing because it helps members accomplishwhat 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 teammeeting.

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 some-thing on the topic at hand.

• Make sure all agenda items are discussed. If that isn’t 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 deci-sion that has emerged from the discussion. If so, ask for further dis-cussion to clarify and resolve the disagreement.

• Help the team identify what actions need to be taken based on deci-sions 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, cor-rections, 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 dis-cussed in greater detail in the last section of this chapter.

Topic presenter:

• Prepare the material specified in the agenda and bring it to the meet-ing. 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 you’ve prepared the mate-rial but find you can’t 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 O’Brien (1995) urges participants to abide by the ground rule, “Everyone must respond out loud.” This “energizes the team, and it confirms agree-ment 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.

• Don’t 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 meet-ings, 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.

• Don’t reject ideas out of hand. Such behavior can take many forms: insulting (“That's ridiculous”), condescending (“That’s 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 rea-soning behind it.

• Require consensus, not majority rule, on major decisions. As Har-rington-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 tasksassigned. In this way, minutes help keep the project on track. Instructors canrefer to these minutes (in the project notebook) to make sure everyone on theteam is involved in the project. And the team can refer to the minutes whenthey plan email updates to the client. Meeting minutes shouldn’t be a recordof everything that is said at the meeting. Instead, they should include the fol-lowing 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 deci-sions 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 byteam members.

Here are minutes written by the team designing a food-cutting device forstroke victims.

Example 14.4: Team meeting minutes

Location, date, and time of meeting: Tech Express, May 12, 2:30 to 3:45p.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

• Features disliked by users:

– Mockup 1: shortness of blades

– Mockup 2: awkward angle of handle

– Mockup 3: difficulty of getting fingers through holes in handle

• 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 thescribe has taken good notes at the meeting. The payoff is a valuable referencefor the team and the instructors.

14.4 CONDUCTING MEETINGS WITH INSTRUCTORS

In spring quarter, each team will conduct at least two half-hour meetings withtheir instructors. The purpose of these meetings is to review team decisions,plans, and questions so that your instructors can offer constructive advice foryour project work and evaluate your project management and teamwork.

The team is responsible for planning and conducting the meeting. As you dothat planning, keep in mind the following guidelines:

• Focus the meeting on key design decisions and plans for the upcom-ing weeks. Your team will have submitted a progress report to instruc-tors 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 for-ward.

• 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 dis-cuss but also what the others will. If one person dominates the meet-ing and others are foggy on project details, your instructors are likely to question the effectiveness of your project management and team-work.

• Review action items from the previous meeting. A major purpose of the meetings is to develop a list of actions that the team should com-plete in the upcoming weeks. By the time of the next meeting, make sure that you’ve 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 them—they are no longer relevant to your project or the people you need to contact are unavailable—you 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 dis-cuss 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 impor-tance of talk: A report on the role of oral communication in the work-place. 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.

O’Brien, 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 team’s 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, mock-ups, 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 it—don't wait till the end of the proj-ect

15.1 PURPOSE

Professional engineers and designers know the importance of keeping com-plete records of all their projects. The most common tool for doing this is theengineering notebook, which has two purposes. (1) It provides a central loca-tion for recording research plans and results, design ideas, data, notes, andsketches—all of which are used by the team and others who continue the proj-ect. Because employees sometimes leave one company for another in the mid-dle of a project, the remaining members of the team need to have a permanentrepository of everyone's work in order to move forward. In addition, compa-nies looking to improve their existing products depend on these repositoriesof project-related material to fill in subsequent teams. (2) It serves as a legalrecord of design activity to preserve patent protection. In industry, this is oftena bound notebook that serves as a legal record, and to which pages cannot beadded or deleted.

151


In some cases, all records are kept electronically. In DTC, each team main-tains an electronic version of a project folder using Google Docs. As the quar-ter progresses, the team will generate a large collection of documents:interview guides, research plans, research results, report drafts, emails, pho-tos, drawings, and more. Think of the collection in this way: If your team wonthe lottery midway through the project and decided to go on vacation for therest of the quarter, another team could use the materials in your collection toretrace 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) whocreated it. Dating each document is a good habit to develop early in yourcareer. Later, when you may engage in research that leads to patents, you willfind that dated notes serve to document priority in patent disputes. Includingthe names of team members who created the respective documents will helpyour instructors (and, later in your career, supervisors and others) determinewho did what during the course of the project.

Your instructors will review your documents periodically. They’ll be check-ing to see that the team has been following the design process, completing alltasks, and recording all results accurately and comprehensively. They’ll alsobe looking for signs of good teamwork and individual participation, which areevident in the scope of the material, and in the initialing and dating of thatmaterial.

The project folder counts as part of your team's project management grade. Itwill also be used to help calculate each student's team and individual partici-pation grades. For this reason, it's important that all team members contributematerials to the folder, and that the team scrupulously document individualcontributions.

15.2 CONTENT AND ORGANIZATION

Each team will have its own collection of Google Docs; other Google Appsare also available for the teams to use (Groups, Sites, Calendars, etc.). Spe-cific instructions and help sessions will be available to all DTC sections andteams.

Your instructors will give you ideas for how to organize and categorize yourproject information in Google Docs. Organizing such a large and diverse col-lection of materials can be a challenge. Include clear and specific titles for allof the items and attached files in your document collection so that they areeasy to identify. For instance, instead of “Meeting_agenda,” use a moredescriptive file name like “Team_Meeting _October_12_agenda_v1.”

Below is an alphabetically arranged list of categories that that shows a repre-sentative 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

– Brainstorming sketches (scanned)

– Brainstorming lists (initial list and clustered version)

• Client contact

– 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

• Design review

– 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

• Final report

– All drafts of the various sections of the report (including instruc-tor feedback)

– Final version of the report

• Mockups

– Alternatives matrices

– Mockup planning sheets and sketches

– Pictures, descriptions, and operating procedures of mockups

• Performance Testing

– Performance test guides

– Raw data from and summary/analysis of performance testing

• Poster presentation

– All drafts of the poster

– Notes used for presentation

– Visuals (besides the poster) used for presentation

– Handout given to judges

153


• Project definitions

– Initial project description from client

– Project definition (all versions)

• Project management

– Course syllabus

– RAMs

– Gantt charts

• Prototype

– 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

• 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

• Team meetings

– Agendas

– Minutes

• User contact

– User observation/interview guide, notes, and summary/analysis

– User testing guide, notes, and summary/analysis

• Visuals

– Photographs

– Drawings & sketches (scanned)

– Maps, charts, & tables

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 terminol-ogy

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 andtalents, and solve difficult intellectual and business problems. Sometimes onemember of the team will write a draft, especially when the document is rela-tively short, and the others will edit it. At other times, each member will con-tribute sections or appendices, and hand it over to another member toassemble. 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 andeffective way to write—or a burdensome procedure. The following guidelinescan 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 audi-ence 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 read-ing 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? For-mal 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 sec-tions but for assembling and editing those sections into a coherent, consis-tent whole

Here is an example of a team that used a RAM chart to allocate responsi-bilities:

Example 16.1: Use a RAM chart to allocate final report responsibilities

Due date Yasmin Fiona Dale Edward Person who com-pleted task (and date completed)

First draft of report

Title page 27-Feb x

Table of contents 27-Feb x

Executive Summary 27-Feb x

Introduction 27-Feb x

Users and Require-ments

27-Feb x

Design Concept 27-Feb x

References Update 27-Feb x

Appendix Revisions 27-Feb x

Limitations 27-Feb x

Conclusion 27-Feb x

Design Rationale 27-Feb x

Assembling/editing the draft

1-Mar x x

Revised final report

Title Page 5-Mar x

Table of Contents 5-Mar x

Executive Summary 5-Mar x

Introduction 5-Mar x

Users and Require-ments

5-Mar x

156


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 stron-gest writers, so they assumed responsibility for assembling and edit-ing 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 mem-bers' 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 column—“person who completed the task”—in part indicates whether the designated team member has actually completed the assigned task.

Another way to record team writing responsibilities is in team meeting min-utes:

Design Concept 5-Mar x

References Update 5-Mar x

Appendix Revisions 5-Mar x

Limitations 5-Mar x

Conclusion 5-Mar x

Design Rationale 5-Mar x

Assembling/editing the revision

7-Mar x x

Final version of final report

Editing the final ver-sion

15-Mar x x

Copying and binding the report

16-Mar x

Due date Yasmin Fiona Dale Edward Person who com-pleted task (and date completed)

157


Example 16.2: Use meeting minutes to allocate final report responsibilities

Team 4 Meeting Minutes

Date: May 21, 2010Time: 7:30 pmLocation: Lisa's Cafe

Objective: Discuss goals of the report and divide up work for the first draftof 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 com-municate 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 text-book.

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. Conclusions and Recommendations: Vic

j. References: Vic

k. Appendices

i. Project Definition: Vic

ii. 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 indi-vidual 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 inden-tation 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, it’s crucial to share the work-load, coordinate your activities, and establish and stick to a schedule. Success-ful teams use meeting minutes, the course syllabus, and two other importanttools to help them stay on top of things: the Responsibility Allocation Matrix,commonly called a RAM chart, and the Gantt chart. The RAM chart detailswho’s in charge of what and when it’s due; the Gantt chart is a schedule oftasks using a timeline.

You may wonder why you need a RAM and Gantt chart in addition to a sylla-bus. The answer is, they offer something more: A RAM chart gives you adetailed view of tasks (not all of which are specified on the syllabus) andshows who is responsible for performing the task and by what date. A Ganttchart displays at a glance what work needs to be completed, when it shouldstart 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 theweekly “to do” list to help you follow through on that plan. Activities on theGantt chart generally take a week or two (with the exception of milestones,which are single events). The RAM includes the specific tasks embedded inthose activities. If you were to try to include that level of fine detail in a Ganttchart, 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 detailson a week-to-week basis and to help the team stay on target with the Ganttchart schedule.

17.1 RESPONSIBILITY ALLOCATION MATRIX (RAM CHART)

The RAM chart is a good project-planning tool because it shows the primaryand secondary tasks of each individual on the team. It is also a good record-keeping tool because it helps instructors, supervisors, and others know whodid (or was supposed to do) what. The most useful RAM charts divide com-plex tasks and major deliverables into subtasks. For instance, testing amockup might be divided into getting materials for the mockup, building it,writing the user interview guide, testing the mockup, and writing up theresults. Some RAM charts include a column for noting who completed a taskor when it was completed. This helps the team keep a record of whether peo-ple 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 teammembers and due dates on the other. If a square is marked with an X, a 1, oran equivalent mark, this means the person assigned to that task has primaryresponsibility 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 corre-sponding team member is not involved in that task. A well-written RAM chartdivides large tasks among team members, rather than giving all members pri-mary responsibility for all or most tasks.

Here’s a RAM chart that fails: Because the tasks are not subdivided suffi-ciently, it allocates responsibility to everyone for almost all tasks. And even ifeveryone is involved in a task, it’s 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 com-pleted task

Mockups 5/19 X X X X

Write Client Meeting Summary # 2

5/19 0 X

Design Review

5/24 X X X X

Proposal Draft

5/26 X X X X

Write Prog-ress Report # 3

5/28 0 X 0 0

Write Meet-ing Agenda for Team Meeting # 3

5/28 X

163


The following revised RAM chart succeeds because it sufficiently dividestasks and indicates what each team member needs to do and by what date:

Example 17.2: Revised RAM chart with effective task division

Key: X=primary responsibility 0=secondary responsibility

Creating the RAM chart should be a team activity so that it draws on every-one’s knowledge and makes members feel invested in performing the tasks.After your team has figured out the necessary tasks, has assigned them basedon members’ skills and interests, and has chosen realistic due dates, have onemember type up the chart, post it to the team’s online workspace, and place itin the project notebook.

You should prepare a new RAM chart every one to two weeks, closely detail-ing who will do what in the coming weeks. In addition, your instructors mayask you to write a less detailed RAM chart at the beginning of the project inorder to familiarize yourselves with the project deliverables, distribute theworkload equitably, and begin surveying the skills and interests of team mem-bers in order to allocate tasks effectively. In DTC, you are required to submit a

RAM chart (5/12 to 5/28)

Task Due date Sinem Sharifah Jeff Sean Person who completed task

Prepare alternatives matrix 5/12 X 0 0 0

Schedule appointment with shop professional

5/12 X 0

Prepare mockup planning sheets

5/14 X 0

Order materials for mockups 5/15 X 0

Build mockups 5/19 0 X

Write client meeting sum-mary # 2

5/19 X 0

Do lab testing of mockups 5/20 X 0

Analyze test results 5/22 X 0

Synthesize information for design review

5/22 0 X

Make design review slides 5/23 0 X

Make design review ques-tionnaires

5/23 X 0

Write first proposal draft 5/26 X 0

Write progress report # 3 5/26 0 X 0 0

Write meeting agenda for team meeting # 3

5/28 X

164


RAM chart with your written deliverables, and to include all charts in yourproject folder as a way of documenting teamwork.

17.2 GANTT CHART

Named for its inventor, management theorist Henry Gantt, the Gantt chart isthe most widely used method of scheduling group work by due dates. Usingboth a table and bar graph format, the Gantt chart lists key project tasks on thevertical axis, and time frames (by weeks or months) on the horizontal axis. Abar across the columns indicates the time span for each task. These bars alsoindicate which tasks overlap, are interdependent, or take place simultane-ously.

Gantt charts are used for internal team planning, as in a progress report to asupervisor or client, and for external reporting, as in a project proposal. Likeall project documentation, a Gantt chart undergoes modification as you com-plete portions of your project and better understand it. That’s why you need tokeep updating the chart throughout the project.

NOTE: Do not include individual assignments in the Gantt chart, such asessay and graphics assignments. Nor should you include small project-relatedtasks, such as emailing the client or interviewing experts; those belong in theRAM chart. In general, keep in mind that the Gantt chart represents the “bigpicture” view of the project.

Here is an explanation of a generic Gantt chart, produced with MicrosoftExcel:

• At the top are the project title, section number, team name (or num-ber), 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 team’s design process, not individual assign-ments (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 com-pleted 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, it’s useful to consider two types of milestones. The first includes dead-lines 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 con-struct a high-quality prototype.

166


Example 17.3: Generic Gantt chart

Project ABCTeam 2Updated 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

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 sub-tasks.

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.

One-handed crocheting project - Gantt ChartTeam 2 Section 12Updated 2/16/05

Weeks2 3 4 5 6 7 8 9 10

TasksPreliminary ResearchResearch disability Research existing productsInterview crochet expertsInterview clientObserve usersConcept GenerationBrainstorm/Cluster IdeasGenerate alternativesBuild MockupsConcept TestingPerformance testingUser testingDesign ReviewPrepare reviewAnalyze resultsAdjust project plans/tasksFINAL DELIVERABLESPrototypeBuild/Test New MockupsBuild PrototypePosterBrainstorm Poster DesignsCreate PosterWrite Oral PresentationFinal ReportWrite Final Report

KEYcompleted tasksuncompleted tasksprogress report

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 note-book.

8. There are many YouTube videos that provide instructions on making a Gantt chart. Here’s 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.

• Under “View,” go to “Toolbars” and click “Border” and “Drawing.”

– 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.

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. Martin’s 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 SOURCES—AND 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 anew engineer (Davis, Beyerlein & Davis). The survey identified as a key ele-ment of communication competence the ability to organize and convey“thoughts clearly and concisely, both in speaking and writing, with necessarysupporting materials to achieve desired understanding and impact.” As AtilaErtas 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 communica-tions tend to be relegated to passive roles in this process.

173


They become information receivers and not information gen-erators and thus gradually find themselves out of the main-stream, 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 inter-views

Engineers often use several kinds of communication at a time: They supportoral presentations with written slides, which may contain drawings, tables,and other visual elements. They write reports using mathematical elementssuch as statistical analysis of test data, which may be illustrated by visual ele-ments such as tables and graphs. They use written agendas to organize teammeetings, where they focus on sketches of design ideas.

In communicating, engineers use a variety of media: paper, email, electronicfiles, fax, telephone, video, projectors, etc. Each medium imposes specificrequirements on engineers as they shape what they want to communicate.

This chapter provides an overview of how to think about communication notonly 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 itis the most commonly used form of communicating among engineers. Writingprovides a formal record of your work, allows you to communicate with mul-tiple readers, serves as a reference for those who will continue your work, andpermits people to review your ideas at their convenience.

Engineers write a lot of short, quick messages to arrange meetings, ask oranswer questions, request support from a supervisor, and so on. To be effec-tive, these communiqués need to be clear, complete, well-edited, and respect-ful.

As an engineer, you also will write more complex documents, such asresearch reports, progress reports, and proposals. Developing these longer

174


pieces mirrors the design process because, in most cases, you’re designing adocument (Table 18.1):

As you can see, both writing and design are iterative and recursive. For exam-ple, after writing a rough draft you may need to gather more information inorder to write a clear, persuasive revision, which your peers and supervisorswill review before it is delivered in its final form.

Writing is particularly important in DTC. Not only does DTC serve to fulfillthe McCormick writing requirement; it is also the place where you are intro-duced to all the functions of writing within the design process. In DTC, youwill do a range of writing (Table 18.2):

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 thetable above. Designers routinely document their meetings and designs, writereports, prepare persuasive documents, and send correspondence. DTCessays, although not part of design practice, give you an opportunity to ana-lyze and critique designs that you see and use each day—and thus to reflect ondesign while you get help and instruction in individual writing.

Table 18.1: Comparing the design and communication process

Designers: Writers:

Gather information Gather information

Define the problem Define the audience, purpose, and main point of the document.

Generate alternatives Explore different ways to organize material and develop a persuasive

argument

Make mockups Write rough drafts

Gather user feedback Get feedback from readers

Improve the design and iterate the process (make more mockups,

get more feedback)

Revise and rewrite

Table 18.2: Types of writing in DTC

Reports Progress reportsFinal project reports

Project documentation Project definitionMeeting minutes

Presentations PowerPoint presentationsPosters

Correspondence Emails

Essays AnalyticalPersuasive

175


18.2 DESIGNING YOUR COMMUNICATION DELIVERABLES

The sole purpose of business and technical writing is to communicate to getwork done. The best way to do this efficiently and effectively is not to thinkabout rules but to think about writing as a problem to solve. To solve anycommunication problem, you need to keep in mind these four elements:

Audience: Who will be reading your writing? What does your audiencealready know? What do they need to know? What questions will be on theirmind? What decisions will your document help them to make?

Purpose: What do you want your audience to do or know after reading thedocument? What does your audience expect the document to help themunderstand or do?

Content: What do you need to say to accomplish that purpose? What is thebest way to organize what you will say?

Tone: How do you need to sound to accomplish your purpose? Formal orinformal? Assertive or questioning?

Beginning writers of engineering documents tend to think only about content.They also think there’s a template for every writing situation. But experiencedwriters think about strategy, consciously or unconsciously using a tool like the“communication square” below to help them plan everything they write (seeFigure 18.1).

Figure 18.1: The communication square

In addition, experienced writers think about the genre (type of document) andthe communication technology (phone, fax, email, written document, etc.)they will need. Below is a more detailed explanation of the key elements inthe “communication square.”

176


18.2.1 Audience

Researchers have found that “the audiences with whom engineers engage aremany and complex. Engineers speak to other engineers, to clients, to govern-ment agencies and to support staff. Some of those audiences have technicalbackground and others do not” (Darling & Dannels, 2003, p. 13). Theresearchers conclude that because audiences for communication are sodiverse, “engineers probably need a dozen different ways to state and clarifyany individual idea or piece of technical communication.”

Typically, in DTC you will write documents for the following diverse audi-ences:

• 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 atthe same time. For instance, your poster should communicate effectively toyour client, who knows a great deal about your project, as well as to a visitorwho has never heard about it before. Similarly, although the main audience foryour final report is your client and instructors, it also may be read by thoseless familiar with project details: other people in the client’s organization, anoutside contractor who will build your design, and future DTC teams workingon a continuation of the project.

18.2.2 Purpose

Just as important as defining your audience is focusing on what you’re tryingto 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 exam-ple, might be written primarily to inform your instructors of the research thatled to your design concept, but it also may be used to persuade them of yourwisdom in choosing that concept. Likewise, your final report is intended notonly to persuade clients to accept your design but to inform them of yourresearch.

Also, keep in mind what your readers expect from a particular document. Forexample, your instructors want your progress report to tell them the mainthings you’ve learned and decided regarding your project. Therefore, youneed to select the data that best illustrate and support these expectations andorganize the data so your instructors can easily find the important results.

One final point: State the purpose of your document in the first paragraph, orby the end of your introduction, so readers know immediately what to expectfrom it.

18.2.3 Content

Determining your purpose and audience will help you decide what content toinclude in your document. For example, if you are writing to ask your instruc-tors to extend your deadline on a progress report, you know your purpose andaudience, so you can imagine what your instructors will want to know. Theywill be convinced to grant your request only if they understand the reason forthe extension—succinctly stated—and the date on which you will submit thereport. You can also briefly reassure them that you are otherwise on top of theproject.

As you plan your content, it’s also important to ask yourself organizationalquestions such as: How do I want to structure the document? Do my mainheadings accurately reflect the categories I’ve chosen? How should I start andfinish? Which points do I want to emphasize and what details do I need tosupport them?

18.2.4 Tone

The tone of your document tells readers something important about you andthus can enhance or undercut your purpose. Readers will have a very differentreaction to your communication depending on whether they see you asrespectful or arrogant, serious or frivolous. The email below, from a studentteam to a client, illustrates a serious problem with tone:

178


Example 18.1: Ineffective tone in an email

hey, sue,

we can’t make it to the meeting at 2, so we’ll be there at 3 insted. we need the list of user fone numbers from you at that time. see you at 3. Jason.

Jason didn’t intend to antagonize his client, although that would be the likelyresult of this inappropriate email. By using incorrect punctuation and gram-mar, and making assumptions about his client’s willingness to reschedule, hecomes across as flippant and demanding. Here’s 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 adap-tive 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 dis-cuss 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 for-ward to hearing from you about arranging an alternative meeting time.

Yours,

Jason Firth

Jason’s tone is polite, considerate, and positive, and it demonstrates concernfor the client’s needs. This is the correct level of formality to use in an emailto clients or users even if they have invited you to call them by their firstname. You can never go wrong by being polite and respectful.

Another common problem with tone occurs with the use of “we,” which cangive your document a self-congratulatory tone, as in this introduction to afinal 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 peo-ple 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 nar-rowed 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 islikely to get the idea that the team is more interested in themselves than in herneed for a successful design. Here’s a revision that emphasizes the designinstead 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 team’s 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 yourpurpose.

18.3 WRITING TO EXPLAIN DECISIONS AND CONCLUSIONS

Many students mistakenly view the writing done by engineers as merely therecording and delivery of information. They believe that the informationspeaks for itself. However, as Dorothy Winsor (1996), a researcher on techni-cal communication, explains, “As study after study has shown,…data seldomor never speak for themselves…[D]ata are almost always used rhetorically.They are one of the means by which engineers convince one another that theirvision of reality is the correct one” (p. 32). In writing your reports, you mustpresent information clearly and convincingly in order to explain conclusionsand decisions that you have reached concerning your design.

In the following example—a progress report written by a team designing awheelchair ramp—the team is reporting to their instructors on their prelimi-nary research on materials (Conroy, Linsenmeier, Taam & Willson). Theyhave reached a preliminary decision to use aluminum. In the rough draft, theysimply list the data, expecting that their instructors will understand how theyreached that decision:

180


Example 18.5: Unclear presentation of data to support a decision

We considered the following materials for the ramp and have tenta-tively 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 shrink-resistant

Pressure-treated wood has preservative chemicals that preventdecay

Must be constructed using nails, screws, bolts, and metal framingconnectors

Dangers: Joints and connections can rot or degrade due to normalwear 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 team’s instructors found it difficultto figure out why the team had decided on aluminum. Since facts do not speakfor themselves, writers need to help readers draw the correct conclusions fromthe facts. If the writers do this kind of work—explaining the facts—then theirwriting will be easier to read and also more persuasive.

The team revised their presentation by clearly stating the decision, the ratio-nale, 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 hasfocused on the relevant facts and has organized them clearly so the instructorscan understand how they relate to the project requirements. The team alsomoved 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, galva-nized steel, and aluminum (see Appendix D). Based on the threemajor client requirements, we have made a preliminary decision touse aluminum:

Portability: The client’s most important requirement is that the rampbe portable so that it can be easily removed and stored during theextended periods when it is not needed. Aluminum is the lightest ofthe four materials and can be fitted with simple pin connections thatallow for easy assembly and disassembly.

Cost: While wood is cheaper than aluminum ($800 vs. $1,000 per12'), 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 connec-tions can rot or degrade due to normal wear and tear; thus, mainte-nance costs would increase the overall cost of a wood ramp.

Safety: Concrete and galvanized steel have a much higher loadcapacity than aluminum (2,000 lbs, 1,500 lbs, and 800 lbs., respec-tively). However, the load capacity of aluminum is well within ADAguidelines. Galvanized steel exceeds ADA specifications for non-skidsurfaces, so we will need to research whether a suitable non-skid sur-face can be added to an aluminum ramp without exceeding the cli-ent’s budget.

Note that in explaining the decision, the team does not misrepresent or ignorecontrary data. For instance, they acknowledge that galvanized steel has anadvantage in safety. So in using data to support decisions and conclusions,you have an ethical and professional obligation to present all the relevantinformation and its relationship to your main point.

Another team's project was to design a low-cost solar water heater for use inthe Dominican Republic (Millea, Nieman, Suszko & Wroblewski). They per-formed testing with their final prototype to confirm that it heated water withinthe required specifications. However, in reporting on those tests in a progressreport to instructors, they did not explain how the data supported the conclu-sion 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 effective-ness of our design:

Test 1 description:

Weather condition: sunny, no clouds

• Rubber hose: 875 ml

• Start Time: 9:40 a.m.

• Start H2O Temp.: 61°F

• Start Ground Temp.: 27°C

• Start Air Temp.: 63°F

• End Time: 11:30 p.m.

• Total Test Time: 1 hr., 50 min.

• End Ground Temp.: 29°C

• End Air Temp.: 69°F

• End H2O Temp.: 132°F

• T: 68°F

Test 2 description

• Weather condition: sunny, no clouds

• Rubber hose: 875 ml

• Start Time: 12:30 p.m.

• Start H2O Temp.: 62°C

• Start Ground Temp.: 26°C

• Start Air Temp.: 64°F

• End Time: 2:30 p.m.

• Total Test Time: 2 hrs.

• End Ground Temp.: 32°C

• End Air Temp.: 71°F

• End H2O Temp.: 134°F

• T: 72°F

As in the case of the wheelchair ramp report, the instructors had great diffi-culty interpreting the data and picking out the key points. In the revisedreport, the team not only presented the data but also explained how the dataconfirmed their design’s effectiveness. Below is the explanation that theyadded 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 effective-ness of our design. As the data below indicate, the prototype oper-ated within required specifications, which were to be able to heatwater to a temperature of at least 120°F within two hours at an airtemperature of around 60°F. We tested the prototype both in themorning and early afternoon for two hours to determine whether theangle of the sun affected the results; the air temperatures were 63°Fand 64°F, respectively. In both cases, the water temperatureincreased approximately 70°F to just over 130°F.

In much of the writing you will do in DTC and, later, as an engineer, you willneed 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 willthey be better served if you explain the data clearly but you will, too, becauseyou will be seen as a good communicator.

18.4 CONCLUSION

Although this chapter has focused on writing, you can apply what you’velearned here to other forms of communication. For example, you can use thecommunication 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 direc-tion.

• 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 thesame kind of rhetorical decisions that you make in a final report—how to pro-vide evidence for your assertions, explain your design decisions, interpretyour data, etc.

You may wish that there were a simple recipe for writing any document ordelivering any presentation. However, just as there are no rules for determin-ing the “right answer” to a design problem, there are no absolute rules forwhat to say and how to say it in engineering communication. Communicationis “socially constructed”; that is, effective communication varies dependingon your profession, your company, and even your communication technology.That’s why, as in design, there is a process you can follow to compose thosedocuments and presentations effectively, one grounded in the “communica-

184


tion square.” This process requires you to take the same problem-solvingapproach to communication as you take to design.

Engineering communication, however, does include certain genres—progressreports, formal proposals, etc.—that do have typical characteristics and followspecific conventions. These characteristics and conventions provide a valu-able framework, but they do not replace the thought you must put into devel-oping a strategy for each communication. Your emails, reports, slides, posters,and so on will only be as effective as the informed consideration you give toaudience, 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.


Davis, D., Beyerlein, S. & Davis, I. (2005) Development and user of an engi-neering profile. American Society for Engineering Education Annual Conference & Exposition. Retrieved on July 26, 2012 from < http://www.eerc.wsu.edu/documents/DevelopmentandUseofanEngineerPro-file.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 fol-low-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 agood start, avoid misunderstandings later on, and communicate effectivelywith him or her throughout. It is important to know that clients voluntarilysubmit project proposals and come from a variety of backgrounds and per-spectives. While many clients are professionals in their own right, they bringwith them diverse experiences, motives, and expectations. Some clients arereadily available to their teams, while others—because they are out of town orhave many demands on their time—may be less available. One client mayhave a fairly well developed design already in mind, whereas another maysimply identify a problem without the technical knowledge to provide expertadvice. While most projects are presented by individuals, in some cases a cli-ent represents an organization or business; therefore, several colleagues havea stake in project progress.

One implication of all this variety is that the kind of client you have in yoursecond quarter of DTC may be quite different from the one you had first quar-ter. Another implication is that you need to understand your client in order toestablish a good working relationship with him or her.

187


Because clients come from such different perspectives, one tool used to estab-lish shared understanding at the initial meeting is the Client and StudentUnderstandings form (downloadable from “DTC Documents” on the Black-board website). Taking a few minutes to review this document with your cli-ent will help all involved to understand each other's roles through the durationof the project.

The most obvious reasons to maintain good communication with clients are toobtain 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 orshe may lose confidence in your abilities, and not devote the time to givingyou help when you most need it. On the other hand, if you keep the lines ofcommunication open, your client is likely to feel encouraged and enthusiasticabout helping you. And at the end of the project, your client is likely to appre-ciate the research and thought that went into the final design and to be con-vinced of its success.

19.1 WHEN TO COMMUNICATE WITH CLIENTS

In the first quarter of DTC, your engineering instructor serves as the interme-diary between you and the client. In the second quarter, however, your team isresponsible for client communication.

How often should you contact your client? More often than you think. Stu-dents sometimes mistakenly believe that after conducting their initial inter-view, they don’t need to contact the client until they have decided on theirfinal design. This leaves clients wondering how, or even if, the project is pro-gressing. To prevent this problem, ask your client at your initial interview howoften he or she wants to hear from you. Some clients like to receive weeklyemail updates. Others prefer that you email them at key points in the project,such as when you’ve developed alternatives, completed user testing, and con-ducted your design review. Regular written communication with your clientbetween face-to-face meetings (client interview, user testing, and final presen-tation) should prove effective.

19.2 WHAT MODES OF COMMUNICATION TO USE

Just as you need to be strategic about planning your final deliverables, youalso need to be thoughtful and strategic about how to contact your client.

188


Your communication mode (or technology) will vary depending on your pur-pose.

19.2.1 Telephone

Call your client when you need a quick reply or want to set up a meeting. If aclient can’t 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 you’re trying toset up a client meeting, team members should decide the purpose of the meet-ing and figure out when everyone can meet before you place the call. If youhave to leave a message, give your name, section number, team number, andproject; purpose of the call; phone number(s); and best times to reach you. Ifyou don’t hear back by the next day, call again or send an email. Your cli-ent may have forgotten to follow up or not gotten the message. Instructorsdon’t want to hear that you called once but “never heard back.”

After your phone conversation, send your client a brief email summarizing themain 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 Observa-tion,” 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, whichestablished that Team 4, which is working on games storage, will be atEvanston Township High School at 3 p.m., Monday, May 2, to do userobservations. As a reminder, these are some of the tasks we will be work-ing 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 tai-lor the Storage Cart to their needs

189


We look forward to seeing you then.

Nicholas SzeSection 15, Team 4Games Storage Cart Project

19.2.2 Email

Use email when you don't need an immediate response, when you have haddifficulty reaching the client by phone, or when you want to present informa-tion that would be hard to convey by phone. Note: Keep emails short so thatthey can be read with little or no scrolling. If you have a significant amount ofinformation to convey, write it up as an attachment to a short email that brieflysummarizes its purpose. Assign one team member to email your clientthroughout the project so that your client does not get confused by messagescoming from different people on the team. When sending email it is custom-ary to allow a few business days for a response; however, your client shouldestablish a mutually agreed upon response time from the outset.

Chapter 20 explains how to write effective emails. In addition, you shouldreview Chapter 18 for advice on planning your communications. Here are thekey 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 request—cro-chet hook project.” If you find yourself writing several emails in a row to your client, don't keep using the original subject line. If you’re 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 open-ing, 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. Ifthe meeting is your initial client interview, write an interview script, as dis-cussed in Chapter 2. If you are meeting later in the quarter, prepare a detailedagenda that follows the format and guidelines discussed in Chapter 13. Alsoprepare visual aids—drawings, mockups, graphs, and charts—to bring withyou. If you are conducting the meeting as a videoconference, fax or emailthese visual aids to your client beforehand.

Another good way to prepare for a client meeting is to anticipate questionsyour client will have (particularly about the reasoning behind your researchmethodology and design decisions) and answer these questions in your pre-sentation, or be prepared to answer them if your client asks. Your projectfolder is an invaluable source of information. Always bring your laptop toclient meetings so that you can access the project folder if necessary.

Occasionally, because clients live far away, you will need to conduct meetingsby Skype, teleconference or videoconference, depending on the technologyavailable to your client. You may use the equipment in Segal’s conferenceroom. Just speak with your instructors to find out about reserving the roomand learning to use the technology. In addition, Northwestern offers studentsaccess to software that allows you to conduct videoconferences from yourpersonal 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 meet-ing, 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 whichmode of communication you use and where you are in the design process.Phone calls convey the least amount of information. Emails, which should bekept to a screen or two, allow for slightly more information. Meetings allowyou to communicate orally and visually, but be sure you stick to the mostimportant information: your conclusions and decisions, and the key researchdata and design tools that support those. For example, if you are presenting

191


your design direction after conducting user testing, you would show sketchesor mockups of what you tested, a chart summarizing the major results, a deci-sion matrix that enabled you to apply these results, and a sketch of your latestdesign concept. Further details, such as results from the brainstorming you didbefore deciding on alternatives, and the way you decided on those alterna-tives, are probably not of interest to the client.

Where you are in the design process also affects what you will want to sharewith your client. For example, it is not a good idea to show your mockups tothe client before you have done some user or performance testing. Your clientmay not understand that you are using the mockups simply to elicit informa-tion about your ideas; he or she may think the mockups are early versions ofyour final design and therefore may discourage you from pursuing a promis-ing line of investigation.

Finally, always bring your project notebook to the meeting to help you answerclient questions.

19.4 HOW TO BENEFIT FROM CLIENT COMMUNICATION

When it’s the client’s turn to communicate, take notes during phone calls andmeetings, follow through on suggestions, and report back with the results. Ifyou think the client’s suggestion is counterproductive, diplomatically explainwhy you would like to take a different direction. Ask your instructors forguidance if you need to.

Sometimes you may have to respond to criticism from your client. One clientsent an email chastising a team for failing to tell her they were coming to herworkplace to do user observations when she wasn’t there. The team had for-gotten that all observations must be coordinated with the client and hadinstead sought permission from someone else at the workplace to do theobservations. The team could have sent an angry, defensive email or ignoredthe client. They wisely decided to send an email apologizing for the miscom-munication and promising to make all future arrangements for user interactionthrough her. They also said they wanted to do the best job possible on theproject 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 andhelpful to the team.

If you receive a problematic or angry email from a client, resist the temptationto write an angry email in response. Instead, consult with your instructorabout the best way to proceed.

Maintaining good communication is essential if you are to develop a designthat your client finds successful. Moreover, you will discover that the goodcommunication practices you use with your clients in DTC will serve you

192


well in internships and jobs later on. Your employers and supervisors will belooking 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 e-communication

• 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 informa-tion 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, instruc-tors, clients, and other interested parties. As in the business world, most ofthis correspondence will be through email.

As you probably know, people in business and other professions receive alarge number of emails each day. A 2006 study at a technology companyfound 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 thereader pays attention to it, can understand it easily, and acts on it in the wayyou 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 don’t need an immediate response, when you want togive a person time to consider the message, when you have had difficultyreaching the person by phone, or when you want to present information thatwould be hard to convey in a phone call (such as test data or an attachedgraphic).

20.1.2 How to make sure your email gets read

Because of the large number of emails received every day, people often makequick decisions about which they’ll open and which they won’t. To make sureyour 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 message’s purpose, such as “Meeting request—adaptive 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. I’ll 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, don’t 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 message’s 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 accom-plish 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 infor-mation), to confirm something (an agreed-on meeting time or an understanding of the decisions made at a previous meeting), to pro-vide 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 short—with only one idea per paragraph—and 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 sufficientdetail so that readers understand your points. Here is an example of a state-ment with insufficient detail. The team is writing to their client to confirm therequirements for a project to design a drinking system that can be attached toa 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 requirementsbecause not all of them are stated and there is no explanation of the tworequirements that are stated. Here is a revision that provides enough detail tocommunicate the team’s 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 noti-fied if the time needs to be changed. If you are following up on under-standings reached at a previous meeting, ask to be notified if you misunderstood anything or if the reader has further information to pro-vide. If you are trying to set up a meeting, ask the reader to reply by a cer-tain 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 you’re being overly demanding. In addition, if that option doesn’t work for the reader, then you won’t achieve your goal in sending the email. So if you are try-ing to set up a meeting, don’t 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 don’t want. Therefore, when you are emailing your instructor, your client, or someone you haven’t met, such as an expert you’d like to interview, make the style more formal and polite than in an email to a friend. Here are some tips for conveying an appropri-ate 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 misspell-ing as a sign that you didn’t 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 provid-ing 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 com-plete” 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 wouldn’t 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 Northwest-ern, put your email address in the signature because it is sometimes diffi-cult 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 isessential that you keep your team and instructors in the loop. When team-mates don’t know what each other is doing because no one is being copied onemails, the entire team suffers. When instructors find out a week after the factthat your client emailed you that she can’t make it to the final presentation orwants you to change your mission statement, then you are denying yourselvesthe support and advice your instructors might have been able to offer.

Therefore, you should copy your instructors and teammates on all project-related email. This includes emails to team members, clients, experts, users,etc. When you receive emails from your client, experts, and users, be sure toforward them to your instructors and teammates. Finally, print out email cor-respondence with client, experts, and users, and include it in your projectnotebook 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 elec-tronically to save time, simplify drafting and revising by teams, and ensurethat documents are easily accessible to everyone. Sending files electronically,however, requires thought and preparation. Below are guidelines for prepar-ing electronic documents.

1. Give your files meaningful titles, version numbers, and other useful iden-tifying 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, postedby Team 2, Section 20. The suffix “.doc” tells what kind of file it is. Askyour instructors what file-naming conventions they prefer, and discussthem 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, saveand send your files in RTF (rich text format), which most word processorscan read. When publishing final versions, you can use PDF (portable doc-ument format) files, which can be read using Adobe’s free AcrobatReader. Software for creating PDF files is available in all public computerlabs 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 & Sidner’s “Email overload” ten years later. Proceedings of the 2006 20th Anniversary Conference on Computer Supported Cooperative Work

201


202

Chapter 21: Visual Communication—Document Design, Figures, and Tables

CHAPTER 21: VISUAL COMMUNICATION—DOCUMENT 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 engineeringdesign depends on visual communication—sketching during brainstorms, pre-paring mockups for user testing, and presenting slides and mockups in designreviews. Visual communication also includes document design and page lay-out so your reports will be attractive and easy to read, as well as effective useof figures and tables to communicate information clearly, concisely, and pro-fessionally. (Additional types of visual communication—posters and Power-Point slides—are discussed at length in later chapters.)

203


21.1 DOCUMENT DESIGN (PAGE LAYOUT) FOR WRITTEN DELIVERABLES

A document’s appearance and organization have an immediate effect on areader. If it looks professional and makes information easy to find, readers aremore likely to read it and to understand and be persuaded of your ideas. Foradvice about the overall appearance of DTC reports, see Chapter 24. Fordesigning pages that are easy to read, follow the directions below.

Each page of a document should look neat and professional, and be easy toread. This section explains how to use line spacing, margins, fonts, page num-bers, 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 documentsyou write in DTC: memos, reports, even documentation in your project note-book. Skip a line between paragraphs. In long reports, skip two lines betweenmain sections.

Use double-spacing for essays. Do not include an extra space between para-graphs; instead, use an indented first line to indicate a new paragraph.

21.1.2 Margins

Margins affect a document’s readability because readers need sufficient whitespace 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, mar-gin for all body text.

3. For the left margin, use block paragraph form (no indentation) if you sin-gle-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 themlook different from papers in English composition. In the latter, you presentyour ideas and supporting information in a continuous flow of sentences andparagraphs 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 indi-cate the main sections (1st level headings), subsections (2nd level), sub-sub-sections (3rd level), and so on. It’s unlikely that you will have more than fourlevels of headings, and if you do, you probably won’t 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 read-ers 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 don’t over-whelm 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, second-level 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 intro-duce.

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 theprogress report in Appendix P.

21.1.4 Lists

Most of the material in a report is written in complete sentences and para-graphs because that provides the best way to explain logical relationships andmake a persuasive case. However, the strategic use of lists can complementparagraphs, particularly when you want to highlight steps in a process andparts of a whole. Lists may consist of single words, phrases, sentences, andeven short paragraphs.

To present lists effectively, follow these guidelines:

1. Use numbers to present a sequence or series; otherwise, use bullets. Num-bers 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 low-ercase 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 grammati-cally 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

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.

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

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 client’s desk:

Example 21.2: Ineffective uncategorized list

loose papers (about 15 sheets)telephonecomputer monitorCPU towerpaper clip holderprinterpicture frames (3)stack of CDspen cupmouse pad and mousecatalogues (6)brochures (8)file folders (5)rubber bandsphone bookspeakersanswering machine

The list is random and difficult to understand. In their progress report theteam should subcategorize the list so they and their instructors can under-stand what the client needs help organizing:

Example 21.3: Effective categorized list

• Computer equipment

– CPU tower

– monitor

– printer

– speakers

– mouse pad and mouse

• Pamphlets

– brochures (8)

– catalogues (6)

• Work-related papers

– loose papers (about 15)

– file folders (5)

• Office supplies

– pen cup

– paper clip holder

– rubber bands

• Phone supplies

207


– telephone

– answering machine

– phone book

• Personal items

– picture frames (3)

– CDs

A word of warning about using lists: It’s easy to get carried away and writeentire 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 think-ing. 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. Thepage number may be placed in either a header or footer. See Chapter 24.2.3for when to use Roman numerals in a report’s “front matter.”

21.1.6 Headers and footers

Use headers and footers to provide additional information about the docu-ment, such as title, date, and version number. These are not required, but ifthey are used, they should be formatted consistently and not contain so muchinformation 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 headingsand one for body text. Use the same font for all body text. A standard, read-able font is 12-point Times or Times New Roman. Avoid using fonts largerthan 16 point or smaller than 9 point. Also, avoid changing sizes too often, asthis will make your work appear amateurish. Use boldface and italics spar-ingly and consistently.

21.2 FIGURES

Figures are crucial in technical communication. They help readers understandand visualize information that is often hard to understand from text alone. Theword “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 youplan your figures. Consider, for instance, the final report written by a teamdesigning a desk organizer for a client overwhelmed with clutter. The teamcreated highly detailed, dimensioned drawings of their final design, but the

208


client didn’t have the knowledge necessary to read them. To accommodatetheir client, the team used photos in the body of the report—the part that theclient would be most interested in—and put the dimensioned drawings in theappendix 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 inter-pret 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 represents—for 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 can’t 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 figure’s 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. Don’t 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, andgraphs.

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, O’Sullivan & 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-compli-ant 1-to-12 ratio ramp (Figure 4) that consists of inclines, plat-forms, 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 proto-type 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 you’ve

211


surveyed users about their preferences on a design’s 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 exam-ple, you would not want to use two side-by-side pie charts for com-paring 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 exam-ple, 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 software’s default views) and instead design graphs to be more like Example 21.7. (Note: your soft-ware’s 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 sig-nificantly 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

54

56

58

60

62

64

66

68

70

72

Mockup A Mockup B Mockup C

Seconds

213


When the scaling begins at 0 seconds (Example 21.9), the differencesamong the three mockups no longer seem significant:

Example 21.9: Graph presents data without distortion

For a good discussion of graphs and charts, refer to Sedlack, Shwom andKeller (2008)—see References.

21.3 TABLES

Tables allow readers to see relationships between numbers and concepts at aglance, without having to read painstakingly through a paragraph and visual-ize these relationships.

21.3.1 Guidelines: When to use tables

Use a table to (1) present categories with several shared characteristics orvariables; (2) show the presence or absence of specific characteristics; (3)compare items with a paired logical relationship. Each situation is discussedbelow.

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 achurch 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 liststhe relative importance, or “weight,” of that criterion, and the last three

0

10

20

30

40

50

60

70

80

Mockup A Mockup B Mockup C

Seconds

214


columns list the average rating of a particular criterion used to test eachmockup. The bottom row gives the weighted score for each mockup. Theteam used this table in deciding on their final design direction and to jus-tify their decision to their client and instructors.

Example 21.10: Decision matrix for church space redesign

KEYThe 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 table—which uses Xs, checks, or pluses/minuses—to 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.

KEY

++ = satisfies requirement well



-- = satisfies requirement poorly

Criterion Weight Library(mockup 2)

Library & meeting(mockup 1)

Library & meet-ing & storage(mockup 3)

Maximize space usage 1 8.6 9.6 6.5

Maximize bookshelf space

0.8 9.7 9.2 7.4

Minimize clutter 0.7 9.5 9.4 8.6

Maximize ease of accessibility

1 8.8 7.6 8.9

Maximize comfort level 1 8.7 9.3 6.3

Maximize capacity 0.9 9.5 9.6 8.6

Maximize safety 1 9.6 10 9

Maximize mobility 0.9 8.5 8.3 6.8

Score 66.31 66.55 56.5

Example 21.11: Sample decision matrix for church stage project

Lift Ramp

Cost -- ++

Ease of use + -

Use of space ++ --

Total + -

215


3. Use a table to compare three or more items with a paired logical relation-ship, such as before and after, features and benefits, and users and func-tions (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.

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/Bene-fits 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

Example 21.12: Features/benefits of electronic kiosk interface design

Feature Benefits

Touch screen Is easy and intuitive to useHas large buttons accessible to a wide variety of people

Link trails Allows users to quickly go back to ear-lier stages for quick navigation

Color-coded buttons Make certain categories stand out to users as being different from the other selections

Search by type Makes selections and comparisons of similar businesses easy

Search by location Allows users to find businesses in a specific district

Search by price Allows users to find restaurants within their budget

Index Provides basic contact information in an easy to read format

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 indi-cates”). The amount of explanation each table requires depends on its complexity.

5. Position the table effectively. Place the table immediately below its refer-ence 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., O’Sullivan, T. & Zhang, F. (2002). Final proposal. Engi-neering Design and Communication, Northwestern University.

Cameron, N., Collins, A., Rauwerdink, M. & Woodward, D. (2003). Fast clip bike light proposal. Engineering Design and Communication, Northwest-ern 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 communi-cation 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 catego-ries

• 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 tobuild, operate, fix, or maintain your design. For example, a toy designed forchildren with disabilities might include instructions for assembling, cleaning,storing, and safely using the toy. In addition, you may find it useful to writeinformal instructions for teammates to help them complete different tasks.

It’s wise to draft instructions early because doing so can help you figure outspecifications and uncover problems with a design. In addition, you may needto draft instructions for users who will test design mockups.

22.1 PLANNING

As with all technical writing, keep in mind the purpose, audience, and tonewhen writing instructions.

219


22.1.1 Purpose

Think of your purpose as defining the task or tasks that users will be able toperform as a result of reading the instructions, and state this purpose in theintroduction. For instance, here’s the first sentence of a set of instructions:“These instructions will lead you through the process of safely and efficientlysetting up the wheelchair ramp for Northshore Opera Company perfor-mances.”

When instructions explain more than one major task, the introduction shouldstate the multiple purposes. Here’s an example from the instructions written toaccompany a design for a footrest attachment to a highchair: “In these instruc-tions, you will learn how to attach the footrest safely and securely, adjust itaccording to the child’s height, and detach it for cleaning.”

Notice how the multiple purposes are described in grammatically parallelphrases (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 instruc-tions 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, don’t 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 tight-ened. 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 toalter the tone to fit your audience. For example, a team designing a device fora child with disabilities used a friendlier, more informal tone than is typicallyfound in instructions.

22.2 ORGANIZING

Organizing instructions might seem simple: you might think that all you needto do is give steps in sequential order. Unfortunately, readers are likely to getlost if they must follow a long list of steps or if there are too many actions inone step. They’ll also get lost if they can’t visualize the end result of theinstructions. Well-organized instructions give the big picture first. Then theygroup actions into logical units and divide actions into discrete steps.

Here’s a typical structure for instructions:

1. title

2. introduction

3. materials and equipment

4. theory of operation

5. directions

6. troubleshooting

Here’s what you might include in these sections to make the instructions easyto use.

22.2.1 Title

Use a title that indicates this is a set of instructions for performing a specificprocess. Instead of “Wheelchair Ramp,” write “Setup Instructions for North-shore 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? Peo-ple 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 instruc-tions 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 pro-ceeding, but people rarely follow this advice. Therefore, additional, more specific, suggestions are often helpful: “Two people are neces-sary 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 beused or according to type (large equipment, electrical tools, fasteners). Be pre-cise: Don’t 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 ofmaterials (BOM). A description and an example of a BOM are provided inChapter 10. If the BOM is long, you may include it at the end of your instruc-tions 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 fromvisualizing the end product and understanding how it should work. Theory ofoperation is not always necessary, especially in instructions for household andother consumer items. Instructions for highly specialized, technical equip-ment, 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 we’re 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; don’t combine steps in paragraphs, such as the following:

Slide module G into slot 3. Then pivot the module 45 degreesto the right. Lower the stabilizing rod on the module until rodlocks 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 intoplace.

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 instruc-tions 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 illustra-tions:

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 explana-tion, in front of the hazard they’re intended to prevent. Use “Warning” to label a hazard that might harm a person. Use “Dan-ger” 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 andways to solve them.

22.3 TESTING AND REVISING

Testing is a crucial part of writing instructions. Have users test your instruc-tions and provide feedback to help detect problems in the way they’re writtenand 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 againto 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 writteninstructions.

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 deci-sions

• 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 secondquarter of DTC.

A progress report concisely summarizes the current project status (includingkey research findings and design decisions), and next steps. It is intended tobe read quickly, so the body of the report should be concise and well-orga-nized. Focus on the most significant information. Use short paragraphs, head-ings, subheadings, and bullet lists to make the report easily readable. Editsentences for conciseness and clarity (see Chapter 25).

A progress report may be either an internal report addressed to the supervisorof 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 prog-ress reports addressed to your instructors. Although your instructors havebeen working closely with you on the project, they are also supervising sev-eral teams and may not recall all the details of your work. Therefore, it's veryhelpful for them to read a concisely written report that summarizes exactlywhere 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 trou-bleshoot 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 team’s project folder

Although one or two team members may be responsible for drafting it, thereport represents work done by the entire team. Therefore, all membersshould contribute to the report, especially the appendices. The primary writershould also circulate a rough draft so that team members can suggest revisionsbefore the due date.

In industry, you will find that different companies and managers have differ-ent requirements for progress reports. The same is true for the various instruc-tors in DTC. Therefore, you should discuss with your instructors theirpreferences for the organization, format, and length of the progress reportsyou submit. Appendix P at the end of the textbook contains an excellentprogress report submitted in DTC. Review it with your instructors to getideas for your own reports.

23.1 PLANNING THE REPORT

To illustrate how to write a progress report, let’s look at how one team plansits report by considering each element of the “communication square” (seeChapter 18). The team’s project is to make the entrance to a local churchwheelchair-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. How-ever, we can’t assume they know much about ramps and stairlifts.

• Purpose: To inform our instructors of our major decision and per-suade 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 won’t actu-ally 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 specificpreferences for the format, organization, and length of the report. In this sec-tion, we present general guidelines.

23.2.1 Overall format

In DTC, as in many businesses, you will prepare your reports as memos withappendices. That means you should follow the conventions common tomemos, with a heading like the one in Example 22.1 below.

• Single-space the report, skipping a line between paragraphs and sec-tions.

• Use a memo heading that consists of Date, To, From, and Subject. The From line should indicate the section and team number, the report’s 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 (primaryauthors), 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 proj-ect, purpose of the report, and dates it covers. In stating your deci-sions and findings, avoid generic statements that apply to all projects. Here's an example of an uninformative, vague sentence in an intro-duction and a greatly improved version that offers specific informa-tion (Buch, Lin, Luckasevic& Thoelen, 2006):

Example 23.2: Make specific statements in the introduction

• 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:

Vague Specific

We conducted user sur-veys and learned a lot from them. We also made significant decisions that will enable us to develop the design.

Our user surveys showed that the majority of parents would find a dry-to-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.

230


Example 23.3: Organize the discussion of your progress around decisions and findings

• 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 sources—books, articles, and websites—cite 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 fol-lowed 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 ourdecision to move forward with the dry-to-wet container design.But it also made apparent that we must make the product visuallyappealing and useful looking, and the product should not costmuch more than a regular container (see Appendix D).

Decision supported with data from user testing: On May 7, wesurveyed five parents (who currently have children in diapers) atthe Sheil Catholic Center on their wipe-purchasing habits and onour dry-to-wet concept. (See Appendices D and E for surveyform and results.) We learned that:

• 3 out of the 5 parents purchase generic brand wipes most often because they are cheapest

Uninformative step-by-step 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 dry-to-wet wipe idea

b. Design concept development

• Modified ball valve for lotion delivery

• Bear as visual concept

c. Design review issues in lotion delivery method

d. Latest drawings

231


• Only 1 parent purchases Pampers brand wipes regularly

• 3 out of 5 parents think a dry-to-wet dispenser would be use-ful

• 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 thedry-to-wet container design, but they also made it apparent thatthe product should not cost more than a brand-name container.Additional feedback also revealed that the product must be visu-ally appealing and useful looking.

• State the next steps for the upcoming weeks. Be specific; don’t 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 andgetting further feedback on it, we will write the report and Power-Point for our final presentation (see Appendices D and E: RAMand Gantt Charts).

Specific statement of next steps: These are tasks we need toaccomplish 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 proto-type

• 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 cur-rent and planned expenditures

• Cite sources in a References page. You should list all the books, arti-cles, and websites you researched, as well as interviews you con-ducted. 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 defi-nition, RAM and Gantt charts, and any other backup information. But beselective; don’t 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 introduc-tion 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 meth-odology, 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, youneed to edit for clarity and conciseness. Guidelines for writing concisely arecovered in Chapter 25. Clarity, however, involves much more than writingstyle. In particular, you need to make clear to your instructors how the conclu-sions and decisions you've reached derive from your research and testing.Review Chapter 18 for an explanation of this key point. Then work to avoidthe 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 you’velearned about the problem and the rationale behind your decisions.

Below is a rough draft of a paragraph about environmental and safety consid-erations in designing mockups (Syed, Erisken, Kuo & Tang, 2004). Theproject involved designing a system that would prevent a new, environmen-tally 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 knowl-edge, do not harm the environment or create safety prob-lems. 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 alter-natives 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 environ-mentally 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 mockupsare safe, the team realized that one of their mockups was hazardous. This is agood example of how the communication process feeds into the design pro-cess.

23.3.2 Pitfall #2: Using a story format to explain your research

The story format (sometimes called “narrative organization”) used in thisexample is wordy and emphasizes the team’s 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 attach-ments 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 attach-ments 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 beendoing and where you are headed, giving your instructors the information theyneed 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 summary—explain the problem, requirements, and final design (in no more than a page)

– introduction—summarize the report's purpose and preview its organization

– discussion of major users and requirements

– design concept—use verbal explanations and dimensioned draw-ings

– rationale for the design—support the design with reference to research and testing

– design limitations—explain aspects of the design that need fur-ther testing and development

– conclusion—summarize 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 willwrite this kind of report at the end of each quarter of DTC. The goal is to per-suade the client (and others in the client’s organization) that a proposed designsolves the problem in a way that fulfills the major stakeholder needs. It mustalso include whatever information is necessary for your client to proceed withthe project, particularly a discussion of limitations of the design concept andinstructions for building and using the prototype.

24.1 PLANNING A FINAL REPORT

To understand how to plan a final report, let’s look at how one team considerscontent in relation to audience, purpose, and tone (see discussion of “commu-nication square” in Chapter 18). The project was to design a new library for alocal elementary school.

• Audience: Our clients—the 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 objec-tions to, our design features. It’s 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, sup-ported by our research.

• Tone: Businesslike and straightforward. We should avoid engineering jargon. Also, although we are trying to “sell” our design, we shouldn’t 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 guide-lines that writers must follow. In DTC, your final report should include thefollowing 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 (preferablyspiral, but Velo is acceptable). Ask your instructors what type of binding theyprefer. 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 num-ber

3. Date of document (the final presentation date)

4. Name of the organization for which the team works (Northwestern Uni-versity, Design Thinking and Communication) and the names of your instructors

5. Name of the client and the client’s 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 pageand are numbered in italics (see the Note on numbering below). These usuallyinclude a Table of Contents, List of Figures, and a List of Tables. Some orga-nizations require an abstract instead of an Executive Summary.

Note on numbering pages

Formal reports typically include two sets of page numbers. Pages in the frontmatter —Table of Contents, List of Figures, List of Tables—are numberedconsecutively in lower case Roman numerals. The title page is not numbered,but the Table of Contents usually is ii. All page numbers—Roman and Ara-bic—are 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 thetext.

Table of Contents

In order of appearance, the Table of Contents comes first. It lists the headingsand subheadings of the document and the page number on which each begins.Subheadings should be indented. Make sure the headings and subheadings inthe 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 appen-dix separately, along with the page number on which it begins. Each appendixshould have a letter and title (for instance, Appendix A: Design Specifica-tion).

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 tothe 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 afterthe Table of Contents. Figures include illustrations, sketches, photographs,graphs, charts, and maps. The list should contain the figure number, the figuretitle, and the page number on which the figure appears.

NOTE: Consecutively number the figures throughout the report using Arabicnumerals (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 theList 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 numberon which the table is found.

NOTE: Consecutively number the tables throughout the report using Arabicnumerals (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 reportso that executives and managers can read it quickly to make administrativeand budgeting decisions without reading all of the detail in the body of thereport. 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 refer-ence to the client (one or two sentences)

3. A brief statement of the purpose and scope of the project (one or two sen-tences). 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: inter-views, 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 design’s 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 limi-tations of the design

The executive summary should be written after you write the rest of the reportso that you know exactly what to include and can even borrow sentences andperhaps a figure from the report.

The executive summary appears after the table of contents (or list of figuresand list of tables, if they are included), and should be written to stand on itsown so it can be read independently of the report. It is NOT an introductionand therefore should not contain statements such as, “as the report willexplain” or “see Appendix 4 for more detail.” (Similarly, the report should bewritten so that it can be read independently of the executive summary; thereport will need a separate introduction.)

Those who read an executive summary may not be experts in your engineer-ing 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 waythat persuades the client that the design meets all stakeholder needs. The bodyof the report starts on the page following the executive summary and usuallyconsists of the following parts. Naturally, the report should appropriatelyreflect the project, so if your project does not lend itself to this structure, talkto your instructors about alternative ways of organizing the report.

• Introduction that summarizes the problem and the report’s 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 pur-pose of the report, and lists its main sections. If the client is not the only per-son in the organization who will read the report, then you may need to explainthe problem in greater detail. Write the introduction as if it will be the firstthing 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 deter-mined that meeting the requirements was essential to the success of thedesign. It isn’t necessary to detail each stakeholder group and need becausethe complete list is contained in your project definition. For that detail, youcan refer readers to the appropriate appendix.

Design concept

This is the heart of your report, the section that will be of greatest interest toyour readers. That is why you describe your design and explain how it worksrather than giving readers a narrative about the design process you followed toget to this point. Below are guidelines for explaining your design clearly.NOTE: Your prototype is not, in most cases, identical to your design; it illus-trates key features and functions of the design. In writing this section, there-fore, describe your design concept, not just your prototype. Use pictures of theprototype only to illustrate the design.

242


1. Begin with an overview of the design. Explain the design’s 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 fol-low.

2. Present design subsystems and features using words, numbers, and pic-tures. 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 soundresearch and will indeed solve the problem. Again, avoid a chronological dis-cussion of the process you followed. Instead, organize the discussion aroundthe 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-costsolar water heater to be built and installed during the construction of homes inthe Dominican Republic (Millea, Nieman, Suszko & Wroblewski, 2003). Tosupport its general approach of using thermosiphon heating, the team drew onits email correspondence with an expert on solar energy and research from anauthoritative 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 tosupport its decision to combine black rubber hose with an acrylic-roofed boxto 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 acrylic-roofed 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 tosupport the choice of a particular feature. The project was to design an appara-tus to allow individuals with limited wrist and hand strength, due to spinalcord 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). Dycem®—a non-slip, non-adhesive mate-rial—has 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 projectsculminate in a fully functional product. More commonly, they offer a proto-type and detailed drawings. Teams do not have time to test the functionality ofall the features to be sure the design will work as expected. Moreover, thedesign may not address all the requirements. As responsible engineers, youshould, therefore, make clear to your readers what the design’s limitations areand how they might be addressed. See Appendix O for an example of howone team discussed the limitations of their design.

244


Conclusion

The body of your report should conclude by summarizing how your designmeets 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 tem-peratures 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 that’s 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 vol-unteer 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, arti-cles, websites, and interviews you’ve used to explain your problem and yourrationale. This list appears at the end of the body of the report, but before theappendices. See Chapter 26 for more detail on documenting sources. NOTE:If the project was funded by an outside grant, indicate that above the list ofreferences.

Appendices

Most reports require appendices that support or supplement information in thebody 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 clientwants to build your design, he will refer not only to your instructions but tothe Bill of Materials to find vendor names and materials needed. If he wants tohave more work done on the design, he may need to see what performancetesting you have done and decide whether more testing is needed.

245


Useful appendices:

• Project definition: This is generally the first appendix. Its major pur-pose is to show that your design adequately addresses the require-ments 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 theproject. You are writing for a real audience, whose time and attention are lim-ited. You are not trying to impress your client or professors with bulk. There-fore, include only the material your readers might find useful in understandingand validating your design process, or in implementing your design. You donot, for example, need to include class work, such as your list of brainstormedideas.

Conversely, be careful not to bury important supporting data and illustrationsin the appendix; these belong in the body of the report—because most readerswon’t read the appendices (and the body of the report should make a persua-sive argument on its own). When determining where to put information,assume readers will not refer to the appendix the first time they read the docu-ment.

Inexperienced writers often have no idea how frustrating it can be to readers ifreports are poorly organized, incomplete, or incorrectly numbered. Below aresome 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 intro-duction 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 appendi-ces properly, the effort is worth it. Poorly handled appendices greatly undercuta report’s credibility.

24.3 WRITING STYLE FOR A FINAL REPORT

A good design report is written in a professional style so that all of its ideasare clear and unambiguous and the report itself underscores your argument bybeing attractive and correct in all its detail. Naturally, if you have an inade-quate design that fails to meet your design requirements or can’t be justifiedby research and testing, then no amount of good writing and pretty pictureswill turn your material into a good report. But the opposite isn’t true. If youhave a good design that you can’t adequately explain or justify, your clientwon’t understand it; and if you submit a report that has interesting content butcontains grammatical errors or typos, your client will begin to doubt your rea-soning and question your attention to detail.

To write a good report, follow the guidelines for page design, visual commu-nication, documentation, and revising for clarity and conciseness in the rest ofthis 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 Univer-sity.

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. Ulti-mately, writing clearly means paying attention to details like paragraphs andsentences. Paragraphs are the main organizational unit for writing, and readerstend to skim paragraphs to find main ideas. As a result, paragraphs need to bewell structured so that main ideas appear early, in topic sentences, and alldetails in the paragraph support the key point. Similarly, sentences need to bewell structured so that readers can easily find key points and act correctly onthe information presented. In addition, engineers must write concisely, notonly because readers are busy and want to get the information quickly, butbecause wordiness can obscure meaning and, as with vagueness, lead to mis-takes. This kind of writing is like detailed design in the design process, gettingdown to a level of precision and accuracy that may not be present in earlierstages.

249


Revising for clarity and conciseness is a huge topic, so this book cannot offercomprehensive advice in these areas. In this chapter, however, we presentimportant ideas about the professional writing style you should use in docu-ments related to design, and techniques for revising and editing to achieveclarity, conciseness, and correctness.

25.1 REVISING PARAGRAPHS FOR CLARITY AND COHERENCE

Well-written paragraphs allow readers to identify main points easily, under-stand the reasons behind those points, and assimilate the information. In thefollowing sections, you will learn how to make sure that each paragraph has astrong topic sentence (usually the first sentence in the paragraph) and that sen-tences 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. It’s the mostimportant part of the paragraph because readers are likely to pay the mostattention to it; in fact, they may merely skim the rest of the paragraph. There-fore, 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 andconcisely? Does it capture the essence of the paragraph? With these questionsin mind, you might do one or more of the following to improve the topic sen-tence:

• 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 sen-tence to each

Each type of revision is discussed below.

1. Adding a topic sentence. Sometimes you’ll come across a paragraph you have written that lacks a topic sentence. You may have become so bogged down in details that you didn’t 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 one—the three-compartment storage—due to its versatil-ity 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 doesn’t state the main point of the paragraph—the deci-sion to focus on alternative one—and so is not a topic sentence. Here is arevision:

Example 25.2: Revised paragraph with a topic sentence

We have decided to focus on alternative one—the three-com-partment storage—for 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 insignifi-cant spread among user preferences. After speaking with our client, we decided to focus on alternative one due to its ver-satility 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 stor-age needs.

The topic sentence mentions client and user input, and nicely sums up theideas 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 brain-stormed ideas, and developing at least three design alterna-tives. We will then mock up these alternatives in foamcore and test them on users in our target group—children between the ages of 5 and 12.

Following is a revised topic sentence that replaces the vague phrase “con-tinue 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 group—children 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 para-graph 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 ofthe 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 doesn’t.Also, the body of the paragraph mentions usability, but the topic sentencedoes not. The ideas were connected in the writer’s mind, but weren’texpressed in the paragraph. Therefore, both elements of the paragraphneed revision:

Example 25.6: Revision with consistent topic sentence and body of the paragraph

To keep costs down without sacrificing usability, we have cho-sen 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. Here’s 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-resis-tant, 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 thebenefits of the plastic used for the case. But the body of the paragraphalso makes important points about the dimensions and lock. The revisionbelow divides the information into several paragraphs each with its ownmain 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-resis-tant, 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 case’s 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 visuallyappealing on the page, but they mesh more effectively with the way thatpeople read and notice information: people notice and best rememberinformation 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 thatsays the paragraph is about research results, you should clearly state results ormake a point about results in each succeeding sentence. You should also usetransitional words and phrases between sentences and paragraphs to highlightthe logical connections. Table 25.1 lists some transitional words:

As you edit paragraphs for logical flow of ideas, don’t just add these transi-tional words indiscriminately. Instead, think first about how all the sentencesin the paragraph relate to each other, and then edit to clarify these relation-ships.

In the rough draft paragraph below, it’s difficult to determine the relationshipsamong 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 cli-ent'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 sen-tences do not indicate the steps that were taken. For example, the team saysthey “were advised by professors” to do something, but that’s a step that theirprofessors, not they, took. Second, the sentences do not always relate to oneanother: In the last two sentences, did the professors tell the team that theyshould meet with the client and that the client would not want to go forward

Table 25.1: Transition words and phrases

Transition categories Transition words

Adding to also, furthermore, in addition, moreover

Showing sequence then, next, after, finally, first/sec-ond/third, one/two/three

Contrasting however, nevertheless, in con-trast, on the other hand

Showing cause and effect therefore, as a result, conse-quently, thus, for this reason

Providing examples for instance, for example

Showing similarity similarly, likewise

254


with the current approach? Or, after talking to their professors, did the teamgo to the client and learn from him that they should not go forward with theirapproach? 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 cli-ent'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 alsois unclear. The team’s intention in this paragraph was to make a case for theirdesign by citing three advantageous features. But because they didn’t statethat 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 com-pleted 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 sec-ond. The shape of the swivel-grip makes its use intuitive. Users were able to attach the prototype without any instruc-tion or prompting from us.

In the following revision, the team clarifies its point by stating the paragraph’spurpose 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 design’s 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 approxi-mately one second. Third, the shape of the swivel-grip makes

255


its use intuitive. Users were able to attach the prototype with-out 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 com-plicated sentences can confuse readers and make them doubt your credibility.Consider the following rough draft paragraph from a final report intended fora 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 coeffi-cient 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 questionthe 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 rec-ommended for wheelchair ramps? What does “rather difficult to slip” mean—will wheelchairs slip under certain conditions? What is the difference in costbetween the two types of sheeting? In the phrase “this seemed ideal to addressthe needs,” what is “this,” why does the sheeting only “seem” ideal, andwhose needs will be addressed? Which experts were consulted? What weretheir credentials? How were the tests performed and what were the results?

The vague wording in the paragraph falls into the following categories. Notethat the precise revisions often require more words, but that does not makethem “wordy.” Wordiness refers to writing that is longer than necessary, not toextra 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 Clear

The ramp will be reasonably safe. 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:

3. Vague pronouns: this, it. Use specific words to avoid ambiguity:

4. Vague references to research methodology. State who you interviewed, how you tested, etc.

5. Vague references to research results. As with research methodology, state the results precisely:

Example 25.15: Eliminating vague verbs

Vague Clear

Our expert interviews appeared to support it strongly.

Our expert interviews supported it strongly.

Example 25.16: Eliminating vague pronouns

Vague Clear

Our expert interviews supported it. Our expert interviews confirmed that the sheeting would prevent wheel-chairs from slipping on a wet ramp.

Example 25.17: Eliminating vague references to methodology

Vague Precise

Our expert interviews We interviewed two professors in Northwestern University’s Depart-ment of Materials Sciences (see References page).

We did tests under very wet condi-tions.

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 in a manual wheelchair.

Example 25.18: Vague references to results

Vague Precise

It performed really well.

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:

Here is a revision that eliminates vague language from the paragraph inExample 25.13:

Example 25.20: Revised paragraph using precise wording and details

Covering the ramp in sheeting keeps wheelchairs from slip-ping in rain or snow. The sheeting we used is a 20 mesh minus crumb rubber with urethane binders (see Appendix F). The sheeting’s 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 profes-sors 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 wheel-chair. The wheelchair did not slip at any point.

The precise language and quantified detail in this paragraph make it clear andpersuasive.

25.3 REVISING SENTENCES FOR CONCISENESS

Wordiness in engineering reports and memos also obscures meaning andslows down the reader. The following rough draft is wordy because it usesmore 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

Example 25.19: Adding clear quantities

Vague Precise

less expensive sheeting less expensive sheeting ($2.50 per sq. ft. as opposed to $4.50 per sq. ft.)

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 rea-son that we intend and plan to incorporate into the unit a fea-ture 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 uncovertheir meaning. Here is an edited version:

Example 25.22: Revised paragraph that is concise and clear

We have generated four design alternatives and begun test-ing 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 rea-son, 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 per-forms the action stated by the verb: Our team (subject) built (verb) threemockups. In sentences with passive verbs, the subject receives the actionstated by the verb: Three mockups were built by our team. A comparison ofthe two sentences illustrates why passive verbs lead to wordiness:

The sentence with the active verb has five words; the sentence with the pas-sive verb has seven. Sometimes writers in engineering and science avoidactive verbs because they’re trying to avoid personal pronouns; they may

Three mockups were built by our team.

Our team built three mockups.

259


believe they’ve said “we” or “our team” too often. However, many thingsother than people can do an action in a sentence. For example, “data” canindicate, “testing” can show, “an analysis” can demonstrate.

Use “Grammar Check” on your word processing software to find passiveverbs and decide whether you can replace them with active verbs that clarifywho or what is performing an important action. Similarly, use your softwareto 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 intoconcise active ones:

This chart shows how to replace wordy, passive and weak verbs with concise,active verbs:

We don’t mean to suggest you should never use passive verbs. In the follow-ing circumstances, passive verbs are effective because they help to place theemphasis in the right place or they promote coherence and clarity:

Example 25.23: Avoiding “it is” and “there is”

Wordy Concise and active

It was apparent to us why users did not like that feature.

We realized why users did not like that feature.

There is a crucial flaw in the design. The design has a crucial flaw.

Example 25.24: Eliminating passive or weak verbs

Passive Active

A total of four design alternatives have been generated by us.

We have generated four design alter-natives.

The process of their being tested on users has begun.

We have begun testing them on users.

Significant information is being learned by our team.

Our team is learning significant infor-mation.

Another piece of crucial information that has been revealed by the testing is…

The testing has revealed another cru-cial piece of information.

There is concern among users about the safety of the storage unit.

Users expressed concern about the safety of the storage unit.

This is interpreted by us to mean… We interpret this to mean…

It is for this reason that we intend… For this reason, we intend…

When items are being retrieved by users…

When users retrieve items…

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 you’ve 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 it’s acceptable to use passive voice because you’re 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 mostcommon 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.

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 don’t, choose the one that best conveys your meaning and omit the others:

Example 25.25: Eliminating redundant modifiers

Wordy Concise

A total of four design alternatives Four design alternatives

has begun in earnest has begun

completely prevents prevents

makes total sense makes sense

Example 25.26: Eliminating words from a series

Wordy Concise

important and significant information important information [or significant information]

we intend and plan we plan [or intend]

261


3. Repeated words. Instead of looking for a synonym to a repeated word, omit it:

4. Unnecessarily long phrases. These may be harder to spot than other kinds of wordiness:

Revising for clarity and conciseness can be difficult because the original ver-sions may not seem wordy to you. You wrote the sentences and know exactlywhat they are supposed to mean. Using the techniques suggested above canhelp you identify vague and wordy sentences. You should also have team-mates look at your draft and offer editing advice.

25.4 EDITING FOR CORRECTNESS

Revising and editing are two different procedures. Once you’re satisfied withyour written text—and you’ve revised it for clarity and conciseness—you stillneed to edit it to give it a professional finish. This means proofreading to finderrors in grammar, spelling, and punctuation. It also means checking headingsand font styles for consistency, and section and appendix numbers for accu-racy.

While a spell-checker is immensely helpful for final editing, you cannot relyon it completely because it cannot differentiate between similar words that arespelled correctly but have different meanings. Are you designing an exerciseapparatus to strengthen users’ “mussels” or “muscles”? When you’ve written“it’s,” do you really mean “it is,” or did you mistakenly add an apostrophewhen referring to “its dimensions”? Mistakes like these, while minor in manyways, can undermine your credibility. Readers are likely to think that if youwere careless about final editing in your report or your presentation slides,you may have been equally careless in your design calculations. They will be

Example 25.27: Omitting repeated words

Wordy Concise

do favor and do not favor do and do not favor

we plan to incorporate into the unit a feature that prevents the lid from col-lapsing when users retrieve items from the storage unit

we plan to incorporate a feature that prevents the lid from collapsing when users retrieve items from the storage unit

Example 25.28: Eliminating long phrases

Wordy Concise

we have begun the process of testing them on users

we have begun testing them on users

must be at least as safe and, what would be even more preferable, safer

must be at least as safe if not safer

262


especially frustrated if they try to check one of your references only to findthat the information didn’t come from the website in your reference list, or ifthey refer to one of your appendices looking for specific information only tofind that your appendices are misnumbered.

Proofreading for grammar and punctuation are equally important. In designreports, the most common grammatical problems involve pronouns that lackantecedents and faulty parallelism in lists. As you proofread, make sure thatevery “it” or “which” or “this” refers to a specific noun that precedes it. Simi-larly, check items in every list for parallel structure so that the list won’t beconfusing. See Chapter 21 (section 21.1.3) for a discussion of parallelism inlists. The most common punctuation problem is the “comma splice”—using acomma instead of a period, to connect two complete sentences. As you proof-read, pay special attention to commas. Make sure that all sentences are com-plete, but no sentences are overly long. If punctuation is difficult for you, tryproofreading out loud. Or read with a pencil in your hand to encourage you tofocus on each word.

Final editing is a tedious task, but one that represents your whole team’s 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. More-over, final editing should be done by someone proficient in English, espe-cially if the team has members for whom English is not their first language. Itis not cheating to get help with final editing—such as using Northwestern’sWriting Place or asking your instructors for help. Try to finish your writing intime to get this extra help, and be especially scrupulous about prominent partsof your report, like the title page and executive summary, or work that will beon display, like your poster for the DTC project fair.

263


264

Chapter 26: Documenting Sources—and Avoiding Plagiarism

CHAPTER 26: DOCUMENTING SOURCES—AND AVOIDING PLAGIARISM

Chapter outline

• When to document—and 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

Documentation—or citing your sources—is a key part of any writing in aca-demia and much professional writing. This chapter explains why and how todocument your writing in DTC. Failure to document your work is a seriousviolation of academic integrity. You can find yourself in trouble—and accusedof plagiarism and cheating—even if your failure to document is unintentional.Thus, read this chapter carefully, and discuss any questions you have aboutdocumentation with your professors.

26.1 WHEN TO DOCUMENT AND WHY

In writing related to engineering design, as in all academic writing, you needto credit each source you use in your reports, presentations, and essays,

265


whether your information comes from printed material (books, articles, manu-facturers’ 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 them—in other words, of plagiarizing

You may be surprised to learn that people want to know how you are buildingon other people’s ideas and will even respect you more for knowing “the liter-ature,” that is, what else has been written in an area, rather than looking as ifyou’ve developed every idea by yourself (which would be impossible). Youmay also not realize that in academia you are responsible for giving credit toothers’ ideas even when you don’t quote them directly. When you write,you’re actually joining a new community, a conversation that has been goingon before you entered it and to which you are now contributing. Documenta-tion 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 willwonder what you’re contributing to a paper or report. Your own voice—youranalysis and your ideas—needs to dominate your writing. Whatever youquote or paraphrase should be used to support your ideas.

Document your ideas as you go along; do not wait to add your citations afteryou’ve written your entire draft. There are several reasons for this. First, ifyou don’t write down your sources as you do your research, take notes, andwrite your research summaries, you may omit required information that willbe hard to find later (and will lead to a waste of time). Second, if you don’tadd citations as you draft your documents, you may forget what you’vequoted and plagiarize material unintentionally. Finally, to give you the mostvaluable feedback, your instructors need to see which of your ideas are basedon research, what kind of research you’re doing, and how you’re analyzingwhat you find. Without accurate documentation, they won’t be able to assessyour work properly and give you helpful advice.

26.2 GUIDELINES FOR DOCUMENTING SOURCES

Documentation consists of two parts: a reference list and citations within yourtext. Below are guidelines for both.

266


26.2.1 Reference lists

1. Include a reference list at the end of all documents (reports, research sum-maries, 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 docu-ment. 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 ref-erence list to see if you’ve based your analyses and arguments on impres-sive, well-chosen, up-to-date information. In many cases, your referencelist is like a snapshot of your research.

A reference list does not need to include everything you’ve read for yourproject; it should include only what you’ve used. For example, if yourefer to a dictionary or encyclopedia to get some general backgroundinformation that most people know and that you’re not using directly inyour report, then you should not cite that information.

2. Use the citation format your instructors prefer. Three commonly used for-mats come from the MLA (Modern Language Association), APA (Ameri-can Psychological Association), and the IEEE (Institute of Electrical and Electronics Engineers).

Appendices Q and R contain details on APA and MLA formats, but onlyon the most commonly used kinds of sources in DTC. For additionalinformation, good advice can be found online at NuWrite, Northwestern'snew online writing resource for students and faculty, and at the PurdueOnline Writing Lab site (OWL) at http://owl.english.purdue.edu/. Forinformation 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 listentry. Whichever format you choose, follow those rules exactly becausereaders from different fields are used to reading reference lists in a con-ventional way.

Here is an example of a short reference list in MLA format and, belowthat, explanations of some of the items. Note that MLA format no longerrequires you to give the URL for electronic sources; you simply includethe 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 Corpora-tion. Web. 27 June 2003.

Yarnoff, Charles. Personal Interview. 20 June 2003.

The first three items are online sources: a newspaper article and two web-sites. 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 author’s 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 orparaphrased, and for any facts you have gotten from a specific source. Theseshort citations show readers that your information comes from somewhereelse 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 you’ve 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 prac-tice 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 quo-tation marks when you paraphrase; just cite the source using paren-theses 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 source—for example a statistic or other number—cite that source at the end of the sentence contain-ing 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 youuse for the reference list. Each style has minor differences. For example,MLA style includes the name of the source in a parenthetical reference and, ifapplicable, the page number. APA style also includes the date of publication.

The following section from an analysis of Northwestern’s Marlok key systemillustrates key guidelines in using parenthetical citations. (See Example 26.1for the paper’s 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 doesn’t rec-ognize a key’s code, it means the key holder hasn’t been authorized, and the door will not open. The second advan-tage 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 visit-ing 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 doesn’t 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 summa-rize information or ideas from an outside source. When your paraphraseextends beyond one sentence, you need to ensure that readers understandwhere 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 YorkTimes"). Note: If you are using APA format for your documentation, youwould also include the year in parentheses, e.g., "According to Smith (2008)".The reader will know that your paraphrase begins with the reference to thesource and ends with the in-text citation you will put at the conclusion of theparaphrase. Below you'll see a passage from a journal article followed by thecorrectly 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, conve-nient, tasty meal). Codifying its operations (Converting heu-ristic to algorithm -- Kroc systematized McDonald’s).

Example 26.4: Correctly done paraphrase of the passage (MLA format)

Roger Martin, Dean of the management school at the Univer-sity 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) Develop-ing a systematic method of operation (37).

The reference to Roger Martin indicates the start of the paraphrase, and theparenthetical reference to the page number at the conclusion of the para-phrased passage indicates the end. Note, too, that in addition to giving theauthor's name at the start, the student has mentioned his credentials to lendcredibility to the information. The student has also been careful to use quota-tion 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 indicateyour source at the end of the paraphrase. However, using the methoddescribed here is more accurate because it helps readers distinguish yourvoice and your original thinking from the voice and ideas you are borrowingfrom 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

• Delivering the presentation

– Effective delivery

– Using the prototype to communicate your design

– Managing presentation technology

– Presenting in a professional way

– Rehearsing 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 fea-tures

• Face the audience while speaking and project your voice

• Use precise language in your explanations

• Answer questions non-defensively and clearly—with 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 explainproblems, propose solutions, persuade others to take a particular action, andgive reasons for their decisions. Researchers who surveyed over one hundred

273


engineers with an average of fifteen years of experience found that “for theindividual interested in career advancement, the ability to give a formal pre-sentation is essential” (Darling & Dannels, 2003, p. 13). This chapter explainshow to plan an effective presentation, including how to make good Power-Point 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 consideringwhat you want to accomplish (your purpose), who you are communicatingwith, and what that implies for your content and tone. The primary purpose ofyour spring quarter final presentation is to explain your design and persuadeyour client that it is an excellent solution to the problem. In that final presenta-tion, your audience will comprise four different groups:

1. your client—and possibly others from your client’s organization—who wants to know how your design solves the problem

2. your instructors, who will evaluate your presentation for clarity, persua-siveness, 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, yourteam will need to work together to deliver a solid group performance.

In DTC you will have 30 minutes for your final presentation, the typicallength of many business and professional presentations. In the first part—nomore than 20 minutes—you will describe your design and its benefits. In theremaining 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) sum-mary, (7) recommendations, (8) conclusion, and (9) Q & A. Sometimes theproblem is explained in the introduction and thus precedes the agenda. If thecontent of your presentation does not lend itself to this outline, talk to yourinstructors about alternative ways of organizing it. This same advice appliesto all the examples in this chapter. Do not use the sample slides and otherexamples as templates. Instead, adapt them to your content, audience, andpurpose.

274


1. Introduction. People typically use one to three slides for their introduc-tion. 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 com-ing. 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 Northwest-ern, 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 tointroduce your topic by using a detail that will grab your audience’s atten-tion. For instance, a team designing a toy grocery store checkout counterto teach children about nutrition might begin with a slide that presents thestartling facts about the rise in childhood obesity. While that slide isshowing, 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 edu-cate 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 thesestartling facts about the rise in childhood obesity. This slide would pre-cede an agenda slide.

2. Agenda. Following this introductory story, state the purpose of your pre-sentation and the major topics it will cover. If you decide to do this on an agenda slide, avoid clichéd, 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 hierarchi-cally (like an outline) so that the audience can see which are the majorsections 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 andthen make User Testing and Performance Testing subheadings.

An agenda does not need to be a list. Some of the most effective agendasare diagrams, such as flow charts. PowerPoint is a visual media, so youshould 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 importantinformation. The team further explained the problem with slides detailingthe mission and requirements. In some cases, you might need only toexplain the mission statement because it includes the main requirements.If you have several user groups, you might also include a slide that liststhem.

276


Figure 27.2: State the mission

Figure 27.3: User needs

4. Overview of solution. Give your audience the “big picture” of your solu-tion, but don’t 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. Here’s 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 test-ing, reasoning, and the opinions of authoritative sources. The hamstringstretcher team used the following slide to demonstrate that users preferredtheir shoe strap system to two other systems they had tested. This slide isespecially effective because it starts with a heading that conveys impor-tant 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 proto-type’s key features.

7. Recommendations. Recommend steps to refine, further test, and imple-ment the design. These steps should parallel those explained in the corre-sponding section of your final report, but you should avoid over-emphasizing 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 needn’t 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 topresent evidence and reasoning to support your claims As mentioned in #5above, this evidence may come from the authority of experts, the results oftesting, or your own analysis.

The following slide illustrates the use of expert authority. A team workingon a project for the BridgeClimb Tour of Sydney, Australia—which sponsorsa climb of the Sydney Harbour Bridge—had to solve the problem of noisyclimbing equipment that bothered area residents (Hertog, Nelson, Ng &Parikh, 2004). To offer persuasive evidence that the equipment creates a both-ersome noise, and to identify the type of noise, the team drew on expertauthority— a consulting firm in Australia. They summarized this authoritativeresearch in this slide:

279


Figure 27.7: Use expert authority to support claims

The next slide illustrates the use of evidence from testing. The BridgeClimbteam built a prototype and tested it in a chamber designed to measure noiseemissions. The slide compares the noise emissions with and without their pro-totype.

Figure 27.8: Use test results to support the design

The following slide illustrates the use of sound reasoning to support a designdecision (Tsuruta, Wong & Wuisan, 2004). A team designing a new library foran elementary school wanted to support its decision to use rooms 201 and 202for the library rather than rooms 202 and 203. They reasoned that using rooms201 and 202 allows for more efficient planning and use of space due to therooms’ 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 aboutyour design, you might orally summarize the statements of an expert youinterviewed.

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

2. Use “talking headlines” instead of topics. Talking headlines take advan-tage 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-

Example 27.2: Turn vague statements into precise ones

Vague Precise

We interviewed experts. We interviewed two professors in Northwestern University’s Depart-ment of Industrial Engineering.

We tested the mockup with users. We tested the mockup with five wheelchair users, all within our tar-get age range of 21 to 55.

The ramp will be safe. The ramp will keep wheelchairs from slipping in rain or snow and will bear loads of up to 800 pounds.

The cost will be fairly inexpensive. We estimate that the materials and building costs for the ramp will not exceed $750, as this slide shows.

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, “Won’t that feature pose a safety haz-ard?”, don’t say, “We looked at that and don’t 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 haven’t considered, recommend that future designers on the project address the issue.

4. Don’t 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 engi-neering 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 they’re a valuable tool invisual communication. As shown in the examples above, good slides help youexplain your design, summarize research results, highlight benefits, and pres-ent evidence. They help audiences visualize your message, stay on track, andremember key points. Poor slides, however, distract the audience from yourmessage. Therefore, our key advice is: Don't just write slides and slide pre-sentations. 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 presenta-tion.

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 prod-ucts, go on to give the team’s rationale for the design, and finally focus on the design’s 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 presentation’s 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 tem-plates 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 design—don’t use a template with a “law” theme for a product for a nursery school. Finally, don’t 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 fonts—one for headlines and one for body text—as 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 shouldn’t exceed two lines.

Here’s how one team restructured its mission statement slide to make iteasier 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 contain-ment 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

Here’s how another team whittled down the verbiage on its list of userneeds:

Example 27.5: Wordy list of user needs

• Design a prominent place for brochures and other informa-tional 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 environ-ment

• 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-ins”—bullet points that fly into the slide from above, below, or the sides—because 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).

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 rele-vant part of the graphic (Bosak, Davidson, Mitra & Ratz, 2001).

Figure 27.12: Use graphics to highlight design features

Problem

Battery cap is easily lost if light is dropped

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 client’s 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 eachslide coordinates headline, text, and graphics, and that the slide packagemakes sense to your audience. Slides should have a clear flow and tell a per-suasive “story.”

Note on including supplemental slides and using handouts: You may findit useful to make supplemental slides that include graphics you can refer toduring the question and answer session. For instance, you may include backupslides with data tables, graphs, photos or drawings of the design, etc. Theseslides are not meant to be part of your formal presentation but to serve asvisual 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 usea handout to supplement a slide.

27.2 DELIVERING THE PRESENTATION

A successful presentation involves more than just designing good slides. Youalso need to speak clearly and professionally and to demonstrate your proto-type 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 proj-ect 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 don’t 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 what’s 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. Don’t 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 it’s pretty close,” and “we’re 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 proto-type to establish its durability.”

• Avoid filler expressions like “uhm” and “right.” It’s okay to be silent for a moment while you’re 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


you’ve understood it. If you don’t 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 illustrateskey features and functions of the design. It’s important, therefore, to avoidconfusing your audience on this point. That means that you must be clearabout the features of your prototype that do and do not correspond with yourfinal design concept. For instance, if your prototype is made of wood, but youare 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 mostpowerful tool in illustrating the design and persuading the client that you havesolved the problem. Therefore, carefully integrate the display and demonstra-tion of your prototype into the presentation using the following guidelines:

• Decide when to show your prototype in the presentation. Briefly dem-onstrate your prototype near the start if you believe doing so will dra-matically 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 demon-stration of the prototype.

• Display the prototype prominently. Place it on a table in viewing range of the audience. If it’s small, have one team member hold it up while another explains its features. If it’s large, place it on the floor, surrounded by the audience’s 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 prototype’s functionality. Prototypes in DTC tend to have some fully functional features, some that are partly func-tional, and some that do not yet function at all. In addition, the proto-type’s 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 doesn’t work the way you say it does.

Using video to demonstrate a prototype: As an alternative to doing a livedemonstration, some teams have made a video of the prototype in use andshown 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 avoidthe possibility of embarrassing malfunctions during the presentation. The dis-advantage is that your video might not work (see the next section on manag-ing technology). If you plan to use a video, be prepared to discuss theprototype without the video in case something goes wrong.

27.2.3 Managing presentation technology

The technology you use to deliver your presentation should complement yourmessage, not overwhelm it. Be prepared for problems, and prevent them byfollowing these guidelines:

• To increase the likelihood that your presentation file will be compati-ble 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 you’ll be using at the presentation. To avoid this problem, copy large files to the computer’s 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 don’t 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 set-ting the lights so you can adjust them quickly and unobtrusively dur-ing the presentation.

27.2.4 Presenting in a professional way

All members of your team are expected to take a visible, active role in thefinal presentation and to present themselves professionally. Making a profes-

291


sional group presentation requires more than effective delivery by each indi-vidual. 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 vari-ous topics.

• Make smooth “handoffs” from person to person during the presenta-tion. For example: “That summarizes the problem and requirements. Now Jamal will explain how our design addresses those require-ments.”

• Stand and pay attention throughout the presentation, even when you’re 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 yourfinal presentation because it helps each person become more confident andrelaxed. It also provides an opportunity to make changes to your content,organization, and delivery. As soon as you speak your ideas out loud, you arelikely to gain new insights about what to say and even what to emphasizeabout your design. Moreover, practicing out loud will help you perfect yourtiming.

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 con-nect 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 practicepresentation 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, Northwest-ern 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.


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 Rela-tions/Publications. Northwestern University. http://www.northwest-ern.edu/univ-relations/publications/logo/downloads.html

Sedlack, R., Shwom, B. & Keller, K. (2008). Graphics and visual communi-cation for managers. Mason, OH: Thomson.

Tsuruta, F., Wong, C. & Wuisan, G. (2004). Pope John XXIII library renova-tion project. Engineering Design and Communication, Northwestern Uni-versity.

293


294

Chapter 28: Poster Presentations

CHAPTER 28: POSTER PRESENTATIONS

Chapter outline

• Designing the poster

– Layout

– Graphics

– Text

– Font size and style

– Color

• Preparing the poster presentation

– Planning the presentation

– Practicing the 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 clearly—with supporting data

• Dress professionally

A Fall/Winter Quarter DTC poster quickly illustrates the essence of yourdesign and its benefits. It contains less text than the posters used at most sci-ence fairs or professional science and engineering conferences because it ismeant to be viewed in a large room with dozens of visitors circulating ratherquickly among the offerings. Your accompanying two-to-five-minute presen-tation provides further details about the design, so the viewer has little time toread your poster.

295


DTC project fairs can last several hours, during which time you may be askedto give your poster presentation many times. To ensure a successful presenta-tion, make the poster visually compelling and have team members on hand toexplain and answer questions about your project. Your poster and poster pre-sentation should work together to convey your main message. You want youraudience to think, “That’s a great design and these are impressive students!”

At the end of this chapter, you will find three sample posters. Each takes a dif-ferent approach to communicating the problem and solution, but they all fol-low “best practices” in poster design. If you design a poster for a SpringQuarter project with more technical material, you may use more text—andeven tables and equations—than 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 solu-tion. Boil those down to two sentences: one that defines the problem usershave, and the other that highlights what you have designed—your design’sapproach to solving the problem.

Now decide what content the poster needs in order to communicate this mes-sage. Then consider secondary information.

Next sketch the poster on a large sheet of easel paper. Visualize your poster insections or panels that convey your main message. Use index cards or Post-itnotes to sketch the graphics and accompanying text. Move these around theeasel paper to determine what works best. You want the poster to have a clear,persuasive organization that conveys your message. Toward that end, orga-nize the various elements so that the solution clearly correlates with the prob-lem, and the key design features with the requirements that they fulfill. If youhave done research that goes beyond the typical DTC project—for instance,specialized lab testing or a large-scale survey—look for a way to highlightthat.

Now you can begin to work on the specifics of the poster: the layout, graph-ics, text, fonts, and color.

28.1.1 Layout

Here are tips for the layout of your DTC poster, which will measure 24 inchesby 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 visi-ble 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 it’s “problem/solution/implementation.”

Within these sections, organize information into blocks of figures andtext. Make the blocks of information easy to follow by followingthese 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 bot-tom of the poster (or make sure that it is part of the template provided to youby DTC).

28.1.2 Graphics

Emphasize graphics, not text, and select photos, drawings, tables, and othergraphics that clearly convey your main message. Here are tips for usinggraphics effectively:

• Eliminate unimportant information from each graphic. Remove extra-neous labels and dimensions from figures, and redo a table to make it less detailed. Don’t number figures or include explanatory keys and footnotes (although you should give each figure a caption). If the viewer doesn’t 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 bor-der 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, andinformative. One consultant on poster design recommends repeating this man-tra when editing the text: “There always is too much text. Always too muchtext” (Radel, 1999).

Strategies for writing concisely

• Pare down sentences and phrases. Here is a portion of a rough draft of a poster featuring a children’s 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

Here is the revision:

Example 28.2: Revised poster text that is concise and easy to read

Solution

Our solution addresses the problem with the following fea-tures:

• 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 chil-dren to occupy themselves by coloring on those long car rides. It’s 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.

Solution: Features and Benefits

• Flip-down game table

– Entertaining

– Easily accessed

• Slide-out drawing board

– Entertaining

– Space-efficient

• Labeled storage pouches

– Keep back seat tidy

– Are easy for kids to use

298


• Cut unnecessary details. List major features only.

• Emphasize the problem and the design solution. Include a few signif-icant 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 para-graphs. 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 currentrear seat designs are that there isn't enough storage space andthat 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

• Font style

– 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 impor-tance.

– Don’t use all uppercase letters for headings; they are hard to read.

28.1.5 Color

Keep poster colors subdued and functional so as not to distract from the con-tent.

• 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. It’s youelaborating on the poster's contents.

28.2.1 Planning the presentation

Review your poster’s main message, and then decide what you want to sayabout each block of information in the poster. Ask yourself which blocks ofinformation are self-explanatory and which require an explanation. For thelatter, jot down what to say to clarify the information.

Different viewers will have different levels of interest in your project, so pre-pare 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 tomore 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 you’re pre-pared.

28.2.2 Practicing the presentation

Practice the presentation with your team, your classmates, and others. Askthem for constructive criticism, and then practice again.

As you practice, concentrate on using body language effectively, guidingviewers through the poster, demonstrating the prototype, responding to ques-tions, and maintaining a professional demeanor.

Using body language

The most important rule to keep in mind is to look at your viewers, not yourposter. Facing the audience and maintaining good eye contact not only drawspeople into your presentation, but also helps them hear you. You’ll be in acrowded hall or room, so make sure you speak loudly enough. Never readdirectly from the poster or note cards: That conveys the impression that youare unfamiliar with your own project. Look away from your audience onlywhen you want to draw their attention to a graphic. Point to the graphic todirect audience attention.

Stand to the side of your poster so people can see it easily. Stand up straight toshow 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 theproblem is twofold: a lack of sufficient backseat storage space in the car and atendency for items to fall under the seat during long drives. Our designaddresses both those problems.”

Using the prototype

If your prototype is especially good at demonstrating the major functions ofthe design, feature it prominently during your presentation. However, avoidcalling attention to functions that do not work well in the prototype. It is per-fectly acceptable, by the way, to have one team member demonstrate the pro-totype 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 togive yourself a little more time to come up with the answer.

Typical questions address aspects of the prototype that obviously needimprovement, safety-related issues, and alternative methods of solving theproblem (for instance, “Did you think about implementing this other kind offeature instead?”).

Support your answers with information from testing and research. Avoidvague wording like “Our prototype is not exactly to scale, but it’s prettyclose,” and “We’re fairly confident our design will stand up to the wear andtear 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 every-day use. It’s made from Lexan, the plastic used for those super-tough Nalgenewater bottles.”

Finally, don’t interrupt one another. If you feel that a team member is notaddressing the question well, let him or her complete the answer before youadd your clarification. Interruptions send a message of team disunity to view-ers 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 itover. As they leave, thank them for talking with you, expressing interest, andoffering suggestions.

If visitors approach you in the middle of your presentation, greet them and tellthem where you are in the presentation: “Hello. I'm explaining how our designsolves 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 niceslacks 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 moretime you put into planning and practicing, however, the more confident andsuccessful you’re likely to be.

28.3 EXAMPLES

On the following pages are three examples of excellent posters. The first isannotated to highlight its outstanding qualities. The other two demonstratedifferent 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.owl-net.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 Univer-sity.

Guevarra, N., Matsuda, N., Tang, S. & Tsuruta, F. (2004). Wheelchair stabili-zation rings. Engineering Design and Communication, Northwestern Uni-versity.

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.biol-ogy.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, rea-soning, 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 Sources—and Avoiding Plagiarism

Much of the writing in DTC is team-based, or collaborative, writing. How-ever, because the course serves to fulfill your writing requirement, it is impor-tant that everyone have an opportunity to write on his or her own and to revisethat writing based on feedback from instructors and other readers, such astheir team members. Individual writing assignments in both quarters of DTCgive you that opportunity.

You'll be asked to write two drafts of the individual writing assignment andwill receive feedback from your instructors and perhaps from others betweendrafts. Four other chapters of this text provide advice that you will need touse:

• 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 format-ted 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 elim-inate vagueness and wordiness.

• Chapter 26: “Documenting Sources—and 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 docu-ment all quotations, paraphrases, and source-specific facts with in-text citations.

The individual writing assignments are determined by the writing instructorfor your section of DTC. In most sections, you will be assigned to write anessay on a design-related topic not connected with your team project. In somesections, however, the assignment may involve writing a portion of your finalproject report or another document related to your project. Since report-writ-ing is discussed elsewhere in this book, this chapter focuses on the content ofessay assignments not related to your team project. It ends with a brief discus-sion of visual communication in essays.

29.1 ANALYTICAL ESSAYS (DTC I)

The DTC first quarter essay generally focuses on analysis. For this assign-ment, you will write a 3-4 page double-spaced essay, analyzing a product orsystem from a design point of view. You can choose from a number of differ-ent approaches, as long as they have been approved by your section instruc-tors:

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 spe-cific 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 thewhole and relationships. A writer can explain how something works, examinethe cause of the problem, or break down a problem into sub-problems. Analy-sis involves the same intellectual process in writing that it does in engineeringproblem-solving. The most important thing about analytical discussion is thatits 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 consideritems in public spaces (for example vending machines) or items for sale instores. Your essay will be most interesting to you and your readers if youchoose a design that you know well and care about because it affects youdirectly. It will also be more interesting if you narrow the topic so that you cango into depth on it in three or so pages. Here are two methods for narrowingthe topic:

• Focus on a specific model. For instance, instead of writing about sev-eral computer keyboards, one student wrote about the Logitech Cord-less 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 andof people using the items; if you like you can also do some reading about theproducts, 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 (andideal) readers are. You might decide to write the essay for DTC students or foran audience of potential users of the product. Your decision about audiencewill affect every aspect of the essay: how you write the introduction in orderto interest your readers, how much background you present about the product,how much technical detail and terminology you use, how you conclude theessay 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 demon-strate 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 user’s 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 work-ing on large projects. (Matsuda, 2004)

In both cases, the thesis statements go beyond vague statements like “theproduct is a great design” by specifying what makes it great or who it’s greatfor. You should strive for the same precision in a thesis that criticizes the prod-uct.

The essay’s organization should derive from the thesis. For instance, here’sthe outline (excluding the introduction and conclusion) of the essay whosethesis was, “The Logitech Cordless MX Duo successfully meets the user’sphysical, cognitive, and emotional needs”:

Example 29.2: Outline for analytical essay on Logitech Cordless MX Duo

1. Methods of meeting physical needs

a Wireless technology

b Ergonomic form of keyboard and mouse

2. Methods of meeting cognitive needs

a Key positioning

b Labeling of F-keys

c Positioning of advanced buttons

3. Methods of meeting emotional needs

a Color and shape of keyboard

Each lettered item in the outline above was developed in a separate paragraphin the essay. In addition, each paragraph began with a clear topic sentencestating 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 howtwo different types of computer ports—Firewire and USB—developed as dif-ferent 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. Proces-sor 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, whatdesigners were trying to accomplish in designing new ports, who developedFireWire and how FireWire meets these goals, who developed USB technol-ogy and how that meets the goals, and finally the pros and cons of eachapproach.

The next introduction comes from an analytical essay that takes an historicalapproach. It analyzes how the design of golf balls evolved to make the golfballs 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 averagedrive of 300.6 yards, with Tiger Woods leading the pack averaging303.3 yards. The top ten most accurate players hit the greens in reg-ulation (two under par) 77.2% of the time, with Sergio Garcia leadingthe pack with an outstanding percentage of 81.9% (“Garcia”). Com-pare this to Arnold Palmer, “The King of Golf” who at the peak of hiscareer averaged 272.3 yards and hit 72% of greens in regulation(“Pro’s”)). One must wonder why golfers’ skills are increasing at suchan exponential rate. However, when you look at the equipmentthey’re using now, compared to previous technology, the answer isclear: the new golf ball design. The history of the technology of golfballs is over five hundred years of innovations and shows a story ofman’s 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 golfballs—and how those innovations affected the game of golf.

The following paragraph introduces an analytical essay that examines the rea-sons 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 cum-bersome window curtains? What about the color fading on the cloth on your furniture because the sun hits it through the windows? Isn’t 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 mecha-nism. Horizontal blinds also become dirty quickly and are dif-ficult 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 don’t 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 commonwindow coverings.

29.1.4 Supporting your thesis

Even though this essay is primarily analytical, you still need to provide per-suasive support for your thesis. To make the essay persuasive, include evi-dence and anticipate objections. Evidence can come from a variety of sources:magazine articles, product reviews, personal experience, surveys of otherusers’ experiences, illustrative pictures, explanations of the mechanics. Evi-dence that comes from articles, websites, interviews, etc. should be cited inparenthetical citations and a references page. It also needs to be carefullyevaluated. One student added little credibility to his essay about the superior-ity of Birkenstock sandals by relying entirely on claims and descriptions fromthe Birkenstock website. Review the end of Chapter 2.3.3 for a discussion ofevaluating sources for credibility.

Below is an example of a paragraph that uses a combination of product speci-fications and personal experience as effective evidence to support a pointabout 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 supe-rior to the other Cyber-Shot models. Weighing 206 grams and measuring 4.25 X 2.0 X 1.4 inches, which is slightly lon-ger than a business card, the P8 is one of the tiniest 3.2-megapixel digicams on the market (“The Imaging Resource”). It fits perfectly into my purse, backpack and even my shirt-pocket. Its compact size also enables it to fit nicely into one’s 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 one’s 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 logicalargumentation. Your instructor will give you a specific assignment; assign-ments may differ from section to section. You may, for instance, be asked totake a stand on an ethical issue, persuade readers of the importance of yourspring 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 case—andthen choose the claim you want to make and the best audience to whom youwill address your claim. For example, if you want to write an essay defendingthe ethics of companies that produce bottled water, your audience might beenvironmentally aware readers who take a dim view of these companies. Ifyou want to propose a new system for arranging the food lines at your dininghall, 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 effec-tive 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, rea-soning and/or authority; and to answer counterarguments.

29.2.2 Supporting your thesis

To support your thesis, include evidence from your reading, personal experi-ence, observations, surveys, interviews, or analysis. At the beginning of thewriting process, you may believe your claim is supportable but may not yethave any evidence. To develop that evidence, you may have to do substantiveresearch. This is part of the writing process—and one good reason to beginwriting early.

Note that some types of essays do not readily lend themselves to the use ofempirical evidence to support claims. For instance, if you are developing athesis in response to a hypothetical scenario about an ethical dilemma facedby an engineering student, you will not be able to draw on statistics andresearch studies for support. However, you can draw on the principles statedin professional codes of engineering ethics and the views expressed by ethi-cists to back up your claims. Similarly, if your essay is recommending achange in a design, you probably will not be able to support your claim withempirical evidence. After all, the change hasn’t yet been adopted and tested.However, you can support your claim with strong reasoning that convincesreaders the improved design is likely to work. In addition, you may draw onprinciples of design discussed by experts in the field, such as Professor DonNorman in his book The Design of Everyday Things.

As you draft your essay, it is also important to anticipate and address yourreaders’ objections. You can either provide counter-evidence that negatestheir objections. Or you can concede their point, but argue that it is out-weighed by other factors.

Below are the introductions of persuasive essays written by DTC students. Asyou read them, pay attention to their claims and imagine the kinds of evidencethey would need to support the claim. Also imagine what kinds of objectionsreaders would have.

The following is the introduction of an essay designed to persuade airportadministrators that the United Airlines check-in system at O’Hare Airportshould 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 O’Hare 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 lug-gage 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 orga-nized 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 imple-menting several relatively easy and inexpensive changes. (Pakula, 2005)

The essay supports its claim by providing evidence that the current system isinefficient and causes problems. To gather this evidence, the author observedUnited Airlines passengers waiting in check-in lines at O’Hare. She also inter-viewed passengers to get a clearer idea of what steps in the check-in processcaused problems. The essay also proposed several changes to the current sys-tem, with reasoning to explain why those changes will solve the problems.The author anticipated that readers might object that the changes would be tooexpensive. As a result, she provided evidence that most of the benefit wouldbe gained just by changing signage at O’Hare, a very inexpensive improve-ment.

The following introduction defends the bottled water industry from chargesthat 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 bot-tled water. It is estimated that by 2011, the global market for unflavored,bottled water will be approximately 4 billion gallons per year, or $86 billionannually.1 Obviously, a market this large draws the attention of many com-panies looking to make a profit. There is no reason why these companiesshould not be allowed to profit from a legitimate consumer demand.Unfortunately, the topic isn’t that straightforward. There are many argu-ments against legitimate companies selling bottled water. There is theidea that bottled water companies (BWC's) are creating massive amountsof waste in the form of plastic bottles that take up landfill space. There isthe argument that bottled water uses inordinate amounts of energy intransport from its bottling point to its distribution point. There is the argu-ment that tap water is just as good as bottled water in a developed coun-try like the United States. And most recently, as detailed in the book BlueGold 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 evenlyby the governments of the world.2 Through this essay, I will show thatwhile BWC's are completely ethical in their current business practices,

317


there is a potential for environmental improvement in their businessmodel. (Richardson, 2009)

The essay develops the thesis by refuting, point-by-point, the arguments lev-eled against the bottled water industry. Support for the thesis comes from sta-tistics on the tiny percentage of plastic bottles in landfills, references to theregulations and requirements imposed on the bottled water industry, andresearch on the recyclability of plastic bottles.

The following paragraph introduces an essay written to persuade engineeringdesign students that an DTC project—designing a pediatric scale—is address-ing 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 error-proof enough to ensure the healthy development of children. In pediatrics, accurate measurements are necessary because they profoundly influence a doctor’s ability to deter-mine 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 currentscales are not sufficiently accurate, based on interviews with physicians, and(2) evidence that inaccurate weight measurements can lead to health problemsfor infants based on research from the World Health Organization. The authoranticipated that readers might think that it should be easy to get accurateweights for infants; after all it’s no problem getting accurate weights foradults. To counter this preconception, the author provided a persuasive sce-nario to help readers visualize the problems that doctors and nurses have ingetting infants to stay still on scales.

The paragraph below introduces an essay arguing that fans in laptop comput-ers are ineffective and lead to both comfort and health problems. The essaygoes on to propose a new user-friendly fan. The audience is McCormick stu-dents.

Example 29.10: Introduction of persuasive essay arguing that a design is ineffective

It’s 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 liter-ally heating up. Laptops have fans designed to keep the CPU at a safe operating temperature; however, this operating tem-perature 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 pass-ing 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 pro-gramming. (Lee, 2005)

To support the claim the laptop temperatures are beyond the optimal comfortzone for human users, the author researched computer specifications for fans,measured temperatures from several computers, and researched the medicalliterature to identify the negative effects of prolonged high temperatures. Allthis information was cited in parenthetical citations and a references page. Tosupport his proposal for a user-friendly fan, the author drew a sketch to illus-trate that the fan could feasibly be moved to a safer location and then usedboth a sketch and reasoning to show how a different pattern of heat dispersalwould lower the external temperature of the computer. The author anticipatedthat readers might argue that laptop designers had already thought about thesethings and had placed the fans in their current locations out of necessity. Tocounter these objections, the author pointed to a specific brand of computerthat had redesigned components to make possible a change in fans.

As stated earlier, your choice of audience will influence every aspect of theessay. If, for instance, the student addressing the problems with laptop fanshad been writing to a computer manufacturer, the introduction would havehad to be very different. She could not have assumed the reader knew aboutMatlab and EA, she would have adopted a more businesslike tone, and shewould have ended with a thesis addressing the reader’s needs and interests:“Your company has an opportunity to gain an edge in a highly competitivemarket 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 aseries of paragraphs, paying no particular attention to the visual elements ofcommunication: systems of headings and subheadings, figures, tables, bulletlists. 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 inyour 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 Refer-ences 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 format-ting difference between DTC essays and reports is that essays are double-spaced, 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, Northwest-ern University.

Grafton, K. (2005). History of golf ball design. Engineering Design and Com-munication, Northwestern University

Heng, Y. C. (2004). Sony DSC-P8—a pursuit of perfection. Engineering Design and Communication, Northwestern University

Hoffman, J. (2005). The importance of the pediatric scale project. Engineer-ing 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 Communica-tion, 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 pro-cess at O’Hare International Airport. Engineering Design and Communi-cation, Northwestern University

Richardson, K. (2009). The ethics of bottled water: Are companies that sell bottled water doing something wrong? Engineering Design and Commu-nication, 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 FordBuilding. Daniel Cornew and Tim Park were present. The purpose of themeeting was to learn more about the problems that RIC was having with theircurrent leg press.

Problems

Our client emphasized four problems that users experience using the legpress:

• 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.

• 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 indicateany order of importance in the requirements.

• Ease of use

* 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.

Begin by stating what information the appendixcontains and how it was gathered.

Use headings and organize them in order of importance.

Include explana-tory lead-ins to lists wherenecessary.

323


– It must be easier for wheelchair users to get into the seat of the leg press.

• Universality

– Ideally, the new leg press design would be able to be used by both wheelchair users and non-wheelchair users, but it is more impor-tant that the leg press is usable for wheelchair users.

• Permanence

– The design must be a permanent fix to the problem and should be able to stay a part of the leg press machine.

• Comfort

– The seat of the leg press should be wider to provide more comfort and stability for the users.

• Safety

– The design must be safe for all users (wheelchair and non-wheel-chair) 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.

• Independence

– The design must allow the users to transfer to the leg press machine independently and then use it.

• Cost

– It must cost less than $6,500 overall.

• Creativity

– The design should be creative and innovative.

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 maxi-mum 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, Cyclecen-tric Biodex, MotoMeds, leg press.

The interview provided crucial information for understanding problem, users,and client requirements. It raised two questions that we will answer when wedo our user observation at RIC:

• What are the exact dimensions of the leg press?

Conclude with a summary of the findings and next steps.

325


326

Appendix B: Background research summary

APPENDIX B: BACKGROUND RESEARCH SUMMARY*

At the beginning of the project, we did background research on terms andconcepts mentioned by our client--a physical therapist at RIC--in his writtendescription of the project. The project involves designing a method forenabling people in wheelchairs to transfer comfortably into and out of a legpress machine. People with paraplegia due to spinal cord injuries often exer-cise on the machine to build their leg muscles. Our background researchhelped us begin to understand several aspects of this problem so that we werebetter prepared for our client interview. In particular, we researched: (1) basicinformation about the physiology of spinal cord injury; (2) the causes of diffi-culty in transferring from a wheelchair; (3) current products for aiding inwheelchair transfer; and (4) the leg press machine used at RIC.

Physiology of spinal cord injury

Damage done to a section of the spinal cord will cause some functions tocease for the part of the body that the particular section controls. All the partsof the body controlled by the sections of the spinal cord below the injured sec-tion are also impaired. However, if the vertebra damage is only partial, thensome functions may still have limited functionality (“What Is a Spinal CordInjury”).

In our case, according to the project description, there are some users whohave limited mobility of their legs and hands because of this condition. Lim-ited mobility usually means that the user is not able to grasp things tightly, butthey can move and grab things to varying extents. Users can move their legsslightly 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 isinjured in a specific area.

* 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.

Begin by explain-ing the topics and purpose of your re-search.

Use headings that correspond to the research topics listed in the appen-dix intro.

Include in-text source citations for all information.

327


Figure 1: Spinal Cord and Areas Affected by InjuriesSource: "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 greatdeal of pain in their upper limbs, especially shoulders, elbows, wrists, andhands. This pain occurs because they have to rely so much on their upperlimbs to perform their daily activities. In a recent study, 65% of the subjectssaid that this pain made it difficult for them to transfer to and from a wheel-chair (Koontz, et al., 2011).

Koontz et al. point out that during transfer, people typically encounter pain inthe elbows and shoulders. Forces on the hand and elbow go right to the elbow,dramatically increasing the stress there. In addition, increase of moments atthe 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 transferringbetween a wheelchair and another surface such as a seat, bed, or toilet. Theyare a transfer board, handle, and thigh lifter.

Use figures to illus-trate your research findings.

Label each figure with a number, descriptive title, and source.

328


Transfer board

The transfer board is the most commonly used assistive device. It is generallyflat and rigid, and is made of wood or plastic (see Figure 2). According toFairview 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." Userscan also learn to use it independently (“Transferring”).

Figure 2: Transfer boardSource: 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 thenext. In Figure 3, the handle is positioned at the top of a car window frame.

Figure 3: Handle assist deviceSource: Allegro Medical <http://www.allegromedical.com/daily-living-aids-c519/car-

caddie-helping-hand-p529623.html>

Thigh lifter

The thigh lifter allows the user to easily lift and move their legs by adjustingone loop around the thigh and one loop around the wrist (see Figure 4). Thisgives the user enough leverage to lift their legs without undue strain on their

Use sub-headings to highlight key points.

329


back. The double loop design also allows someone with little fine motor con-trol 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 isused at RIC. This leg press has a sliding seat that can be adjusted and is at a45-degree angle to the ground (“Sled 45-Degree Leg Press”). The user lowersthe seat by bending the knees until they are almost completely bent, and thenextending the knees to push the seat back up to the starting position (“Sled 45-Degree Leg Press”).

The proper way to use this machine is to keep a straight spine, pressing upagainst the back of the seat. The knees should never be locked as this couldput strain on the joints instead of the muscles. The knees should also alwaysbe kept in line with the toes. The leg press should be used in a fluid motionwithout stopping, slow enough to ensure the user is in control and not theweights (Rogers).

References

“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 wheel-chair transfer techniques.” Clinical Biomechanics 26: 9 (Nov. 2011): 923-929. 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.

Include an alpha-betically arranged listing of your sources.

330

Appendix C: User Observation Plan

APPENDIX C: USER OBSERVATION PLAN*

We plan to conduct a user observation at the Rehabilitation Institute of Chi-cago 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, ChristieCory, and Tim Park. We are students in Northwestern University's Engineer-ing Design and Communication program. We're working on a project todesign a more efficient, comfortable, and safe way for people who use wheel-chairs to transfer to and use a leg press machine. We were wondering if wecould ask you a few questions and then observe you as you transfer to the legpress machine and use the machine. Also, do we have your permission to usevoice, video, and photo recording? We are trying to find out what works aboutthe current design and what could be improved, as well as what you like anddislike and what you would like to see in the future. We will watch to see whatproblems you may encounter because that will help us determine how toaddress those problems in our design. Before we start, do you have any ques-tions for us?

* 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.

While the team did not read this intro aloud at the interview, writ-ing it out made them feel confi-dent about what they would say.

331


Background information

We would like to know a little more about you so that we can evaluate ourresults correctly.

We would like to know a little more about you so that we can evaluate ourresults 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)

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?

See Chap. 2.5.2 about how and why to create a task breakdown

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 fea-tures)?

• 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

End time:

Things to bring:

• Paper and pencil

• Digital camera

• Tape recorder

• Graph paper

• Tape measure

Note the start and end time because you will need to include that in your observation summary appen-dix.

333


334

Appendix D: User Observation Summary

APPENDIX D: USER OBSERVATION SUMMARY*

Emily Laning observed a user of the leg press machine at the RehabilitationInstitute of Chicago (RIC) on Wednesday, January 30, 2008. The following isthe information gained from the observation. Emily also spoke with clientEvan McDowell to get information about the leg press machine.

Information about the leg press machine

A key constraint on our project is that our design must be compatible with thecurrent leg press ma-chine. Here is information about the leg press at RIC.

Operation of the leg press

• 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.

Organize results in order of impor-tance; in this case information about a key project con-straint is given first.

335


Process of transferring to the machine

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)

• Lightweight—the 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

Table 1 lists the observations as well as the opportunities these created for ourdesign. It also lists the follow-up to these opportunities and suggestions theuser had regarding the problems.

Use a numbered list to indicate steps in a sequence.

The team adapted the chart in Chap. 2.5.2 to include a "user sugges-tions" column.

336


Table 1: User observation: opportunities, follow-up, and suggestions

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

• Bar between foot plate and frame of machine

– Length: 8 inches

– Height: 12.5 inches

Observations Opportunities Follow-up User suggestions

User can have difficulty transferring to the machine quickly

Provide method to speed transition

Use one of many prod-ucts to facilitate trans-fers

Something on the machine to grab onto; adjust seat height

User’s wheelchair moves during transfer despite brakes

Find a way to keep the wheelchair steady

Put wheelchair on rough material or set into a contraption

User can have difficulty transferring over han-dles next to leg press seat

Make the handles in a way so they won’t get in the way of the trans-fer

Remove the handles or make them retractable

User can have difficulty making adjustments (to seat, etc.)

Find a way to make adjustments simple

Automatic adjustments or easier to reach

Plate adjusts (back and forth) rather than the seat

User can have difficulty lifting feet and legs up to the plate

Provide easier method for getting feet onto plate

Make a device to facili-tate lifting the legs

Rotate the plate up and down; bigger surface to place feet initially

Straps used to hold feet are not sturdy

Have more sturdy mate-rial or have something tightly hold the feet

Add universal boots on plate or have someway to stick foot on plate

Universal boot

User can have difficulty staying in the seat

Prevent users from fall-ing out of the chair

Make the seat bigger or 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 and add smaller weights with smaller increments

Smaller increments

337


• Base/Frame of Machine

– Length: 47 inches


– Smallest height: 12.5 inches

– Largest height: 18 inches

– Sliders on machine (on which the base for the seat runs): 1 inch

• Seat

– Depth: 12.5 inches


– Back Rest

• Height: 30 inches

• Smallest width (at top): 9.75 inches

• Largest Width (at bottom): 16.5 inches

– Distance from ground at average setting: 23 inches (maximum 26 inches)

• Base the seat rests on

– 16 inches square

– Smallest distance to actual seat: 5.5 inches

– Largest distance to actual seat: 7.5 inches

• Lever to Adjust Seat

– Height from base of seat: 11 inches

– Distance width-wise from seat: 3 inches

• Handle on seat

– 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

• Weights

– 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

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 Adoles-cent Center at Evanston Hospital, to gain information about the use of andproblems with infant scales that we have not been able to gain through Inter-net research. In particular, we want to understand how scales are used in theday-to-day routine of a pediatrician's practice.

1. Introduction: I’m _______________ (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 Engi-neering 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?

* Hoffman, J., Kessler, J., Schickli, E. & Smith, A. (2005). Pediatrician interview guide. Engineering Design and Communication, Northwestern University. The team’s project was to design an improved scale for doctors to weigh infants.

This explanation of purpose is intended for the instructors, who may suggest revi-sions 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.

341

Appendix E: Expert Interview Guide

d. Is there anything that you particularly like or dislike about the scale compared to others you’ve 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 thrash-ing 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 scale’s 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, apediatrician at The Child and Adolescent Center at Evanston Hospital

Date 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 theother team working on the project)

Purpose of interview: to get doctor’s opinion on current pediatric scales; toask 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 anxi-ety or nervousness. For this reason, a waterproof scale is essen-tial. No padding, fabrics, etc.

c. Easy to clean: for the same reason as above.

d. Extended length: Fussy toddlers and those with spinal cord inju-ries 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.

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 team’s project was to design an improved scale for doctors to weigh infants.

Begin with the pur-pose of the inter-view and basic information about who, when, and where.

Organize informa-tion in logically defined catego-ries that empha-size key points.

Use underlined sub-headings to call attention to key points.

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 medi-cine, 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 inju-ries.

c. Use of “old fashioned” scales

i. They aren’t 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 it’s off (because it isn’t 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 can’t 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 pediatrician’s office on the follow-ing 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 devel-oped and clarified their understanding of the problem throughout the course ofa project that involved designing a method of collecting rainwater for use bythe residents of a village in Kenya.

As you read through the three versions, notice how the mission statementevolved, requirements became clearer, and specifications were convertedfrom unknown quantities to precise numerical metrics. The team was able tomake these changes as a result of their thorough research, which includedfrequent consultation with the client, research into climatic conditions in thearea, and calculations based on hydrological formulas.

347


Project Definition (Version One)

Project name: Rainwater harvesting structure to help the community of Ribe,KenyaClient: David Torkelson, Project Kenya Charity, Inc.Team members: Abby Hawley, Daiaunne King-Bey, Bruce Perry, Alex TilleyDate: April 14, 2010Version: One

Mission Statement: To create a home system that sanitarily collects rainwaterand stores enough for household use during the dry season and water short-ages, with potential to be adapted to collect solar power in the future.

Project Deliverables: A conceptual design of the rainwater system and amodel 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

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)


Water Storage

• Have a watertight tank in the structure

• Have a method to dispense water to the home and other villagers

• Store XXX liters of drinking water

• Be XX meters above ground

Safety

• Water must be disinfected in some way to make it safe for human consumption

• Be clear and without any visible con-taminants

• Have an acceptable level of microorgan-isms

The team will con-sult with instruc-tors and client to make the Project Deliverables more precise and detailed.

Although the team has tried to iden-tify constraints, they are as yet too vague. See their revision in the final version.

The team uses XXX as a place-holder for the pre-cise specifica-tions that they will determine through research.

348


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 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 sec-

tional 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 Cel-sius

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,KenyaClient: David Torkelson, Project Kenya Charity, Inc.Team members: Abby Hawley, Daiaunne King-Bey, Bruce Perry, Alex TilleyDate: May 17, 2010Version: 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 seasonto satisfy daily household needs for the rest of the year.

Project Deliverables: A conceptual design of the rainwater harvesting sys-tem, including the components and materials needed. Sketches and a model toillustrate the design.

Constraints

• Must be built according to a strict cost benefit analysis in order to require the minimum amount of funding from charitable organiza-tions

• Enough water should be collected to aid a large portion of the village (a few hundred people)

Users/Stakeholders

• People in Ribe, Kenya who will live in homes with the device (the main users)



• Other Non-Governmental Organizations and the Government of Kenya (potential sources of funding for the project)


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

• Store 4,000 liters of drinking water

• Maximum amount lost to evaporation: XX Liters/day

The client sug-gested that the team eliminate solar power collec-tion from their mission and focus on water collec-tion.

As a result of research, the team adds require-ments and includes numbers for their specifi-cations.

350


Safety

• Prevent physical contaminants from entering the collected water


• Allow for future addition of a way to sanitize the water

• 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.


• 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 sec-

tional 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




• Be able to withstand temperature extremes of XX and XXX degrees Cel-sius

Flexibility of Design


• 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,KenyaClient: David Torkelson, Project Kenya Charity, Inc.Team members: Abby Hawley, Daiaunne King-Bey, Bruce Perry, Alex TilleyDate: June 10, 2010Version: Final

Mission Statement

To design a physical structure for homes in Ribe, Kenya, that can collect andstore enough clear but unsanitized water from rainfall during the rainy seasonto satisfy daily household needs for the rest of the year.

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.

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 Non-Governmental Organizations and the Government of Kenya (potential sources of funding for the project)

The team explains Project Deliver-ables in detail.

As a result of cli-ent feedback, the team eliminated cost as a con-straint and speci-fied the water collection metric more precisely.

Specifications now include pre-cise numbers that define the solu-tion, e.g., exact cross sectional area of gutters.

352



Water Storage


• Limit loss of water due to evaporation

• Store 50,000 liters of drinking water

• Amount lost to evaporation fluctuates slightly year round, ~10 L/day.

Safety

• Prevent physical contaminants from entering the stored water


• 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.


• 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 clus-ter 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





• Be segmented so some operability is retained during repairs

• Be able to withstand temperature extremes of 9 and 39⁰C

• 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 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 thatwould fit into an automobile passenger seatback and be used to store andeasily access items such as snacks, a lap desk, etc. They devised two taskscenarios for testing using three full-sized foamcore mockups. Below is a pic-ture of one mockup. A breakfast storage pouch is on the left, and a lap desk ison the right.

* Shiao, C., Chen, S., Lee, C. & Srinivasan, S. (2003). Progress report #4. Engineer-ing Design and Communi-cation, Northwestern University.

355


User testing guide

We will use the following testing guide with users as they perform tasks withthree foamcore mockups. The mockups differ according to the angle of orien-tation: 45° tilt; 30° tilt; and flat.

The tasks involve: (1) placing and removing breakfast items in a designatedpart 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 bestfacilitate removing food from the insulated pouch in the mockup, and (2) howeasy or difficult it is to remove the lap desk from the three mockups. We planto test the mockups with at least four users.

Start time:

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 stor-ing and having access to food. We will have you perform a set of tasks, andthen ask you a few questions about each completed task. The mockups youwill be using are not intended to simulate the final product in terms of materi-als, appearance, etc. But your interaction with them will provide us with valu-able information so that we can move forward with our design. Please feelfree to ask questions and comment at any time.

Task one (breakfast storage)

(Note to team: Steps a and b below are to be performed with each of the threemockups.)

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?

b. Now remove the banana, yogurt, and juice box.

• 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?

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?

This initial expla-nation is not intended for users but for the instruc-tors, who may suggest changes to the goals and methodology for the test session.

Provide users with an overview of the purpose of the test session.

Word each task clearly and concisely.

Ask users for numerical ratings so that you can easily quantify the test results.

356


Second scenario (lap desk removal)

(Note to team: Step a below is to be performed with each of the three mock-ups.)

a. Remove the lap desk on the right side of the mockup.

• 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?

b. 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 have on your seat? Why?

End time:Include the start and end times because you will need to include the duration of each test in your user test sum-mary appendix.

357


358

Appendix I: Performance Testing Report

APPENDIX I: PERFORMANCE TESTING REPORT*

Purpose

Of the various possible ways to make phosphorescent concrete, the additionof a thin phosphorescent concrete layer on top of pure concrete appeared to bethe most promising. The material’s phosphorescent layer in our performancetesting consisted of a powder containing doped strontium aluminate additives.Our objective was to determine the adhesive properties of varying ratios ofphosphorescent powder to water in the thin phosphorescent concrete layers.

Methodology

Through the use of a compression test, adhesion properties of the thin layerswere observed. A spherical indenter was used to apply the load to each sam-ple. After the load was applied to the samples, the indent was observed usinga macro lens camera. We then compared the indents of these samples to thoseof the pure cement samples created under identical testing conditions. Allphotographs of such tests are shown in Appendix N.

In addition, a three-point bend test was used to test for adhesion. The amountof distortion and cracking was measured and used to help evaluate the adhe-sive properties of the samples. See Appendix O for how the layer adhesionswere evaluated.

Results

Figure 1 displays the control sample of pure cement, containing the idealamount of water. There are no cracks around the crater and no flaking aroundthe edges. Similar properties were seen in samples containing a 5:1 glow pow-der ratio entirely through. This indicates that any cracking or flaking was notdue to the phosphorescent material failing, but due to poor adhesion.

* Long, A., Rein, J., Smith, A. & Smith, L. (2006). Glowcrete: A Thin-Layer Ap-proach to the Development of Self-Illuminating Concrete. Engineering Design and Communication, Northwestern University. The project was to determine the fea-sibility of producing a phosphorescent concrete material that would provide added safety in parking garages, runways, etc.

Use the report structure explained in Chapter 6.

Reference other appendices with relevant informa-tion as needed.

359


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 toevaluate the adhesive properties of the samples.

*All ratios are by mass of cement to mass of phosphorescent powder or massof water.

Table 1: Strength of layer adhesion

Phosphorescent powder ratio*

Water ratio Layer adhesion

5.00:1 2.40:1 Weak

5.00:1 2.10:1 Strong

5.00:1 1.90:1 Strong

5.00:1 1.70:1 Strong

2.50:1 2.40:1 Strong

2.50:1 2.10:1 Strong

2.50:1 1.90:1 Strong

2.50:1 1.70:1 Strong

1.70:1 2.40:1 Strong

1.70:1 2.10:1 Strong

1.70:1 1.90:1 Weak

1.70:1 1.70:1 Weak

1.30:1 2.40:1 Strong

1.30:1 2.10:1 Weak

1.30:1 1.90:1 Weak

1.30:1 1.70:1 Very Weak

Use tables, graphs, and photos to convey test results

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 test-ing adhesion.

• The three-point bend test is not a usable method for testing the adhe-sion 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 can-not be explained at present. More samples should be made in the future to rep-licate these tests. Experts should also be consulted in order to help explain thecause of these results.

361


362

Appendix J: User Testing Report

APPENDIX J: USER TESTING REPORT*

Purpose

The purpose of our first round of user testing was to determine how the mod-ule for the passenger seatback should be oriented. To use our design, driverswill need to fold down the passenger seat and be able to easily see and reachdesired items. In this round we wanted to learn two things: (1) whether a tiltedor horizontal orientation would best facilitate removing food from an insu-lated 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 dur-ing the week of February 13. The mockups were constructed of foamcore.The mockups differ according to the angle of orientation: 45° tilt; 30° tilt; andflat. Below are photos of the mockup used in user testing. Figure 1 shows theoverall mockup. Figure 2 shows the middle panel containing the large pouchin 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. Engineer-ing Design and Communication, Northwestern University. The team was design-ing 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.

Use the structure explained in Chap-ter 6 to organize the report.

363


Figure 1: Overall mockup

Figure 2:Middle panel (45° angle)

Include clear, labeled photos or drawings of your mockups.

364


Figure 3: Pouch opened

The tests were conducted in a team member's parked car. The user sat in thedriver's seat, and the mockup was placed on the folded-down passenger seat.Three of the sessions were conducted with individual users, while one wasconducted with two users at the same time. The one-user sessions lastedbetween 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 outsidethe driver's door so users could be observed from different angles. The userswere read the tasks and given no other prompting during the tests. The testsconcluded with users being asked to rate the mockups in terms of ease of use.

Results

The following table summarizes the user testing results. In the ratings, 1 ishardest to use, 10 is easiest.

Where possible, present results using tables or graphs.

365


TASK 1: Breakfast storage

MOCKUPS

Flat Completely tilted

Half tilted Comments

Joe 7 8 8 both are easy to use, but tilted is easier

Scott 6 8 8

Karen 5 6 6 prefers structured pouch

Thanen 6 9 9 prefers latch instead of zipper

Chris 7 7 7 prefers that the pouch open from bottom: eas-ier to grab onto

TOTAL 31 38 38

TASK 2: Removing lap desk

MOCKUPS

Flat Completely tilted

Half tilted Comments

Joe 8 6 6 flat is eas-ier because hand does not get cramped

Scott 6 5 5

Karen 6 7 7 doesn’t think she would use lap desk: too bumpy

Thanen 6 6 6 depends on which side handle is on

Chris 7 5 5

TOTAL 33 29 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,the choice between them will be based on other criteria: safety, durability, andease of construction.

One limitation to our testing methodology was that in the two-user session,Thanen was able to watch Scott as he performed the tasks. We noted similari-ties in their responses to task one but not to task two. In future testing, eachsession should be restricted to just one user. In addition, because the resultsfor the lap desk are inconclusive, testing with additional users is needed.

Based on the analysis and limi-tations, identify decisions and next steps.

367


368

Appendix K: Two Sample Team Charters

APPENDIX K: TWO SAMPLE TEAM CHARTERS

Effective team charters can take different forms and emphasize differentexpectations and behaviors. This appendix contains two different, but effec-tive charters. The marginal annotations emphasize general principles to usein formulating your team’s own charter.

Sample Team Charter #1

Our mission is to earn an "A" grade for all team deliverables and to build aproduct 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.

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.

Protocol

• Set and adhere to a regular meeting day, time, and place throughout the project.

• No outside conversations through cell phone or computer, stay atten-tive during meeting.

• Efficient meetings - aiming for one hour of work

Specify communi-cation modes and frequency.

Include steps to be taken when expec-tations are not met.

369


• At each meeting, assign someone to record topics discussed and deci-sions made, and keep track of time.

Agenda

• Meeting agenda is circulated via email at least 12 hours prior to meet-ing 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

• 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 descrip-tions (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).

Include specific actions to be taken to achieve each goal.

Consider steps that can promote a positive team atmosphere.

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

Our team will meet the expectations of the client, our instructors, and our-selves. We will know that we are succeeding if:

• 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

Routine communication will be through GroupMe. Team members will checkfor and respond to messages regularly.

Written deliverables will be posted on Google Docs.

In addition to our in-class meetings, we will meet at least once a week outsideof class. We have all agreed that these meetings will be on Sundays at 7:30pm, with the location alternating between North and South campus. If a per-son can’t attend a meeting or must come late, he should notify the rest of theteam asap.

Responsibilities

Each person has multiple responsibilities, and fulfilling these is essential toteam success. Responsibilities include attending team activities (e.g., meet-ings, user observation, interviews, mockup building)) and completingassigned tasks (e.g., written deliverables, research gathering).

In class and at team meetings, we will decide together on the assignment ofresponsibilities. We will record these assignments in team meeting minutesand RAM charts. We will review the RAM chart to ensure that responsibilitiesare divided fairly.

If a team member falls into a pattern of not fulfilling assigned responsibilitiesfor more than a week, we will address that at a team meeting. If the patterncontinues, we will schedule a meeting with our instructors.

Decision-Making

Individuals may not on their own make decisions that affect the project direc-tion. Instead, unanimous agreement is required for these fundamental deci-sions. We will achieve consensus through discussion at team meetings.

Articulate your team goals in mea-surable terms.

Decide on ways to achieve consen-sus on key deci-sions.

Specify how you will use project management tools.

Specify each method of commu-nication in detail.

372


Individuals may make decisions on their own when it comes to their assignedtasks. However, at meetings, these decisions will be reviewed by the entireteam 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.

Respect and Trust

Our success requires that all team members respect one another and feelrespected. Without that, individuals will stop trusting one another. To ensurethat 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 amature and constructive manner as they arise. When someone feels that thereis an issue on the team that needs to be resolved, he or she should bring it upprivately with the team member concerned or at a meeting. In doing so, he orshe should avoid being hostile or confrontational. The person being addressedshould avoid responding defensively. The goal of the discussion should be toreach agreement on taking specific actions that satisfy the needs of all con-cerned. If one person remains dissatisfied, he or she should express that andcontinue to try to resolve the problem until all feel that they have reached gen-uine agreement.

Spell out key roles in detail.

See Chapter 13 for guidelines on how to manage con-flict.

373


In handling conflicts, if tempers flare and discussion threatens to get out ofhand, 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 conflictand that the project is in jeopardy, we will arrange to meet with the instructorsfor guidance.

Support

To complete our project successfully, we should actively seek support fromour client, instructors, and experts. If we feel that, despite our efforts, we arenot receiving adequate support, we will schedule a meeting with our instruc-tors 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

* Calderwood, S., Chen, P., Evitt, D. & Nikodem, R. (2005). Wheelchair drinking system: the ultimate drinking machine. Engineering Design and Communication, Northwestern University.

Use help sites on the internet for instructions on automatically cre-ating a Table of Contents.

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.

375

Appendix L: Sample Table of Contents

Appendices

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

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

Arrange and label appendices according to the order in which you refer to them in the body of the report.

Use help sites on the internet for instructions on automatically cre-ating lists of tables and figures.

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-cago (RIC), we designed an adaptive apparatus to allow people with C5 andC6 spinal cord injuries to drink directly from a beverage container. While ourusers can move their arms using their bicep muscles, they have limitedstrength in their wrists and hands.

We observed two users at RIC to understand the difficulties they face in drink-ing from beverage containers. We then built three mockups of alternativedesign concepts and tested them with the same two users. Based on the resultsof those tests, we developed a final design concept and built a mockup that wetested with one user. We used the results of that test to design and build ourfinal prototype.

Our design, the Grip&Sip, features an adjustable Velcro strap to secure thedevice around the wrist. Another Velcro strap enables the user to grip a con-tainer securely. D-rings at the ends of both straps allow for independent useand easy adjustability, engagement, and disengagement. The Grip&Sip satis-fies three needs that existing products do not: independence, stability, and ver-satility.

• 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.

* Donahue, K., Galfi, R., Sileika, T. (2006). Grip&Sip: final design report. Engi-neering Design and Communication, Northwestern University.

State the problem and the client.

Briefly summarize the key specifics of your research and testing.

Provide a design overview.

Identify main requirements and how the design meets them.

377

Appendix M: Sample Executive Summary

Other notable design strengths include the Grip&Sip’s comfort, washability,and low heat conductivity. One limitation is that the straps and relatively largeD-rings make the device less discreet in appearance than users preferred.

If there is room, include a drawing or photo of design.

If appropriate, mention other features or limita-tions.

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 usinga turbidimeter. The turbidity is determined by measuring the refracted lightfrom extremely small particles in the water such as bacterium, which range insize 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 watertreatment plant: An in-line turbidimeter is becoming clogged and damageddue to large particles (from coarse sand to grass) flowing through it. Largeparticles (larger than 10-3 cm) also cause the turbidity rating of the water tobecome skewed. These problems cause a cascade of issues, including largeamounts of time and money spent on repairing and replacing the turbidimeter.

The Screen N’ Flush solves those problems by creating a filter that is nearlyself-running and requires minimal maintenance. The filter removes the largeparticles from the water, but the turbidity is kept constant since it does not fil-ter out particles smaller than 10-3 cm. When the filter begins to clog as largeparticles 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. Engi-neering Design and Communication, Northwestern University.

Briefly explain the problem.

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 adrain. With the financial support of the Eaton Corporation, we were able toconstruct a functional prototype of the Screen N’ Flush.

This report explains the users, requirements, and specifications for therequested design, followed by a detailed explanation of the design and itsrationale. We conclude with recommendations for testing.

Preview the sec-tions of the report.

380


Sample 2*

Introduction

People with limited wrist and hand strength, due to C5 or C6 spinal cordinjury, often need an apparatus that discreetly and comfortably allows them todrink directly from a variety of beverage containers. (See Appendix A for theproject definition.) While the strength of the users varies, generally they havestrong biceps and weak triceps. They also have little to no movement in theirfingers. These issues cause difficulties in picking up and drinking from bever-age containers.

Current products are not effective in solving this problem. In some cases, avery long straw is added to a beverage so that picking it up and setting it downis unnecessary. A drawback to this solution is the need for assistance in put-ting the straw in the container. In addition, users have expressed a desire forsomething more discreet. A more discreet model, also commonly used, is aVelcro ring connected to a handle. While this device does function better,users experience difficulty attaching it to beverage containers. Also, the Vel-cro, in many cases, is not strong enough, working for only lighter containers.Another similar device employs a metal ring attached to a handle. The metalring attaches to the container using screws; however, because of the limitedstrength and dexterity of people with spinal cord injury, putting on the appara-tus independently is impossible. An additional flaw is the lack of versatility;the product does not fit all sizes of containers. Simply put, the devices cur-rently available do not adequately address the entire problem.

Our design, the Grip & Sip, satisfies three needs that previous products havenot: independence, stability, and versatility. It features an adjustable Velcrostrap to secure the device around the wrist. Another Velcro strap enables theuser to grip a container securely. D-rings at the ends of both straps allow forindependent use and easy adjustability.

This report discusses how the Grip&Sip addresses the problems with currentproducts. We present a detailed look at our method for evaluating users’ needsand designing the Grip&Sip to meet them. We also discuss limitations to thedesign and ways to address them.

* Donahue, K., Galfi, R., Sileika, T. (2006). Grip&Sip: final design report. Engi-neering Design and Communication, Northwestern University.

Briefly explain the problem.

If appropriate, explain how com-petitive products fail to solve the problem.

Explain how your design solves the problem--in this case, by address-ing the key requirements.

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 synthe-sizing and testing phosphorescent concrete. The following limitations must beaddressed to advance the design:

Repetition of cement tests

Samples tested for this investigation included only one data point for eachcombination of variables. More samples for each combination of variablesshould be tested. A broader range of glow powder and water ratios should alsobe tested in order to better determine the relationship between these variablesand adhesion/phosphorescence. This would allow future researchers to reporton the effects of adding phosphorescent powder with more accuracy.

Glow powder ratio

The preliminary results obtained from the testing performed indicate that a2.5:1 glow powder ratio is optimal, and that the optimal water amountdecreases with increasing glow powder quantities. Both results were unex-pected and should be investigated further.

Use of concrete samples

All samples for this project were made with cement rather than concrete.Given that cement is a large constituent of concrete, the procedures andresults should be analogous. However, the work conducted with cement canbe interpreted only as a proof of concept. All tests must be repeated using con-crete.

* Long, A., Rein, J., Smith, A. & Smith, L. (2006). Glowcrete: A Thin-Layer Ap-proach to the Development of Self-Illuminating Concrete. Engineering Design and Communication, Northwestern University. The project was to determine the fea-sibility of producing a phosphorescent concrete material that would provide added safety in parking garages, runways, etc.

Organize limita-tions in order of importance.

Recommend next steps to address limitations.

Identify limita-tions in the final design or in the testing. Do NOT discuss limita-tions in the design process, e.g., lack of time, money, or expertise.

383

Appendix O: Discussion of Design Limitations in Final Reports

Quantitative compressive strength tests

This quarter’s work focused on the adhesion of the thin phosphorescent layerto the bulk sample. Based on expert opinions, the thin layer was not believedto adversely affect the total material’s compressive strength (see Appendix E).Before Glowcrete can be used in structural applications, the compressivestrength must be verified, especially if structural failure could cause bodilyharm.

Durability tests

Only adhesion and phosphorescent properties were tested. Testing should beconducted to characterize the durability properties:

• thermal shock (freeze-thaw, then compressive tests)

• microhardness (Vicker’s 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: Professors Herbst and Herrick

FROM: Section 23, Team 4: Dhaivat Buch, Tinlee Lin (primary authors),Kelly Luckasevic, Garrett Thoelen

DATE: May 23, 2006

SUBJECT: Progress Report Two on Diaper Wipe Project

Introduction

This report informs you of Team 4’s progress from May 4 to May 23 on theProcter and Gamble Baby Wipe Container project (see Appendix A for proj-ect definition). First, our surveys showed that the majority of parents wouldfind a dry-to-wet baby wipe container to be useful. Second, we decided to usea modified ball-valve to release lotion onto dry wipes and have built a proofof concept model of this system. This model will go into a large-scale proof ofconcept model of our entire design. Third, we presented the ball-valvemockup for a design review, and the class noticed possibilities for leaks.Finally, we developed to-scale drawings of our design and are in the processof constructing a looks-like prototype of it. In the future, we will find solu-tions to the leak problems and finalize prototypes. (See Appendices B and Cfor 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 dry-to-wet concept. (See Appendices D and E for survey form and results.) Welearned 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.

Use memo format; indicate primary authors in "From" line.

In the intro, state the specific key findings, deci-sions, and next steps that the report will elabo-rate on.

Use headings and sub-headings to highlight key points.

Arrange and letter the appendices in the order in which you refer to them in the body of the report.

In the body of the report, include the most significant data to support findings and de-cisions; 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-wetcontainer design, but they also made it apparent that the product should notcost more than a brand-name container. Additional feedback also revealedthat 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 thecontainer (see Appendix F for decision matrix). Table 1 shows the designsthat we eliminated.

Table 1: Analysis of Lotion Delivery Methods

Based on this analysis, we decided to use a cylindrical ball-valve designbecause lotion flow could be controlled simply by pressing upwards on thebottom cylinder with the desired pressure. There would be no opportunity forthe lotion to evaporate because the container would be airtight and only onepiece. 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 commonchildren's toys and are unisex. On May 22, we began carving the design to-scale 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 valveproof of concept and a diagram of how it would relate to the entire systems

Design Reason for not using

Small ball valves Could be condensed into one valve

Spray bottle Would need reservoir for excess spray

Sponge Doubt in ability to of sponge to transfer lotion; evapora-tion due to large surface area

Liquid pressure Difficult to control leaks

Where appropri-ate, use tables to present informa-tion that supports design decisions.

386


(see Appendix H). Table 2 summarizes their major concerns and our possiblesolutions (see Appendix I for complete results).

Table 2: Key Design Review Results

Latest drawings

Most recently, we developed our latest drawings of our desired final product(see Appendix J).

Next Steps

These are tasks we need to accomplish before we present our final design onJune 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

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

Conclusion

We have finalized our design, except for some leak-prevention issues we mustaddress in the valve. Our visual prototype and proof of concept are about half-way complete, and our goal for the next two weeks is to put all of our designcomponents together into an appealing and workable product.

Concerns Our proposed solutions

Container might leak if flipped

Cover top of valve; design a guard so the cylinder does not roll around

Leak may occur in valve after wipe is pulled

Use suction cups to close valve 10 seconds after being opened

Wipe could break Allow for full opening of side of container so wipe can be realigned

Conclude by con-cisely summariz-ing the project status and your major goals for the next phase.

Be specific about next steps; don't list the generic steps in the design process given in the syllabus.

387


388

Appendix Q: APA Documentation— formatting advice

APPENDIX Q: APA DOCUMENTATION—FORMATTING ADVICE

This appendix provides information on how to use the American Psychologi-cal Association (APA) format in your reference list. As a supplement to Chap-ter 26, it covers the sources most commonly used in DTC. For information onAPA format for other kinds of references, such as email communication, gov-ernment documents, or encyclopedia entries, etc., see the Purdue Online Writ-ing Lab site at http://owl.english.purdue.edu/.

BOOK

Basic format: (1) author’s last name followed by first initial (if the author isunknown, begin with the title); (2) year of publication (in parentheses); (3)title (italicized; capitalize only the first letter of the first word, with the excep-tion of proper nouns); (4) place of publication; (5) publisher. See the examplebelow, paying special attention to the punctuation marks used. The punctua-tion 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, andnewspaper articles are EXAC, Lexis/Nexis, Applied Science Index, and Aca-demic Search Premier.

Basic format: (1) last name of author followed by first initial (if the author isunknown, 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 followedby 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 tobe 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 thereference 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 tod-dlers must be accurate to within 0.1 oz. (personal communi-cation, 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 LanguageAssociation (MLA) format in your reference list. As a supplement to Chapter26, it covers the sources most commonly used in DTC. For information onMLA format for other kinds of references, such as email communication,government documents or encyclopedia entries, etc., see the Purdue OnlineWriting 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 ofsources.

BOOK

Basic format for a print version: (1) author's name, last name first (if theauthor is unknown, begin with the title); (2) title (italicized); (3) place of pub-lication, followed by a colon; (4) publisher; (6) date of publication; (7) theword "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, andnewspaper articles are EXAC, Lexis/Nexis, Applied Science Index, and Aca-demic 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 theperiodical, italicized; (4) volume/issue number (if given) and date of publica-tion; (5) page numbers; (6) name of database, italicized; (7) the word “Web”;(8) date of access.

Example:

Voelker, Rebecca. “Rehabilitation Medicine Welcomes a Robotic Revolu-tion.” 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 website, italicized; (3) name of organization sponsoring the site; (4) date of publi-cation (if no date is listed, use "n.d."); (5) name of sponsoring organization orinstitution (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 tele-phone) 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 designand communication language reference, organized alphabetically. The follow-ing subcategories may aid your navigation.

Design process Prototyping and manufacturing

User testing and analysis

Visual communication

AffordanceAlternative designsBrainstormingClusteringCompetitive productConceptual designDecision matrixDesign processDesign requirementsDesign reviewDetailed designDownstream technologyEngineering releaseExpert interviewFailure modesFeatureField testingFMEAForcing functionFunctionFunctional specificationsGantt chartHierarchical organizationHuman-centered designIndustrial design (I.D)Lab testingLatent defectsMental modelMission statementMockupModel productPerformance metricsPert chartProduct analysisProduct specificationProject notebookPrototypeQFDRapid prototypingSpecificationUpstream technology

AlphaAssemblyBetaBlow MoldingBreadboardBOMCAD/CAECAMCavityCNCCoreDFMDraftEngineering check modelExtrusionFirst articlesHard toolingInjection moldingLCDLead timesLEDMTBFMachine toolMating partsMultiple cavityPCBPiece partsPilot build/pilot produc-tionPre-production partsPressPreliminary engineeringPrototypeRapid prototypingRapid prototyping machineSingle cavitySoft toolingSolid modelingSurfacingSLAThree (3) D fileToolingTweakingWire frame

DemographicsEthnographic analysisField testingFocus groupInterview guidePaper testsRapid prototypingShadowingStakeholdersStructured group meet-ingsUserUser observation

Concept sketchControl drawingsDatabaseDetail drawingsDrawingLife cycle boardsMockupModel, visualOrthographicProject notebookRenderSketchSketch modelSolid modelingSurfacingThumbnailThree (3) D fileWire frame

Written Communication

Design requirementsEngineering releaseFunctional specificationsMeeting agendaMission statementProduct specificationProgress reportProject definitionProject notebookProposalSpecificationTechnical brief

395


Affordance

The set of possible actions a person can make on the product is called theaffordances. 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. Agood designer makes the desirable affordances visible, so that they are readilydiscovered and easily understood.

Alpha

An “Alpha” is a functional prototype. It is synonymous with “prototype” butis process related. (An Alpha always precedes a “Beta”). An “Alpha“ isalways generated by an engineering database or 2D documentation and is fab-ricated from materials appropriate for the application, but may not necessarilyreplicate production materials or finishes. “Alphas” will function, but willnormally always require revisions and continuing development. Some limitedproduct testing can be expected from an “Alpha.”

Alternative designs

Two or more design concepts that attempt to solve a design problem in differ-ent ways. Alternative designs are normally generated in order to elicit userfeedback 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 wellas new features conceived while testing the alternatives.

Assembly

Logical grouping of parts in a product usually defined by the manufacturingprocess. Product hierarchy would start with raw materials or purchased parts;next highest would be process parts (blanks, unpainted, etc.); above thatwould 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 produc-tion tooling as possible. A “Beta” may be hand assembled and is used to ver-ify repeatability and reliability. It will accurately represent the finished designwith production materials and processes. The unit is “pre-production” andtherefore may not have production, finished graphics and labeling, based onneed. 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 pressureforces the softened plastic to conform to the walls of the mold. Plastic bottlesare blow molded.

396


BOM

Bill of materials—A concise listing of every item that goes into a finishedproduct, to include not only every screw and washer but also all labels andinstructions. Often organized by assemblies and called a structured orindented BOM.

Brainstorming

A structured method for stimulating creative thinking and generating a largenumber of ideas quickly.

Breadboard

A proof of concept model that represents how a product will work but nothow a product will look. Often used for conceptual development and built toprove feasibility of a functioning aspect or aspects of a concept.

CAD/CAE

Computer aided design or computer aided engineering. Generic term thatrefers to the range of computer tools that designers and engineers use for engi-neering development work. These tools are used for modeling/drafting, analy-sis, and simulation. CAD developed engineering is more accurate, easier tochange and more efficient in converting from engineering documentation to apart. CAD very often is used in conjunction with CAM.

CAM

Computer assisted manufacturing. A technology that facilitates the program-ming for automated machining. Used to make both product tooling (e.g. injec-tion molded tools) and piece parts.

Cavity

The piece of a mold that creates the exterior surface of a part. Normallythought of as the visual side of a part.

Clustering

The process of dividing a long list of data, information, or ideas into smallergroups for the purpose of evaluation.

CNC

Computer numerical control is an automated machine that uses computers andprogramming to control its operations, instead of human activation. CNC pro-grams can be generated using CAD data without re-entry of the information.CNC machines are used to produce tooling for production parts, and proto-type models in reasonably short time frames.

397


Concept sketch

First level of client/management/team acceptable presentation. Sketches arerough color representations of the form and usually include sections and addi-tional views to describe the features and functions.

Constraints

This term is used in two ways. First, rules that a design must not violate. Anexample would be that a new laptop computer have a weight of no more than6 lbs. Second: behaviors that are not allowed in the use of a product. Anexample is the design of a 120 VAC power outlet, which constrains the inser-tion of a plug to the orientation that grounds the appliance's case. A gooddesign trick is to use constraints on behavior so as to enforce the correct oper-ation or minimize errors. DTC Forcing function.

Control drawings

A line development of all exterior surfaces of a product. Normally developedby industrial designers and used as a basis for developing the engineeringdatabase. Control drawings are also used by industrial designers as transferdocumentation to be used by model makers in the development of visual mod-els.

Core

The piece of a mold that creates the inside or interior surface of a part. Nor-mally 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, regardlessof the technology it employs.

Conceptual design

The systematic process of developing a general solution to a problem but notperforming 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 takethe place of manual “detail drawings.” The database is developed on a 2D or3D 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 withrespect to each criterion. Scores may be totaled to give an overall ranking ofthe design alternatives. These rankings, as well as rankings in specific catego-ries, are factors that the design team should consider in making its final deci-sion.

Demographics

Facts about interviewees that help define the user groups they fit into, andtheir level of knowledge and experience relevant to your design. Demo-graphic questions are designed to elicit relevant facts, not opinions, about theinterviewees.

Design process

In engineering, the systematic, creative solving of complex problems thatinvolves applying technology to satisfy people’s 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, thegoal of which is to uncover problems, suggest improvements, and ensure thatthe 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 toimplementation.

Detail drawings

A complete definition of a part using a physical drawing. The drawing is usedin conjunction with standards and procedures to provide information requiredin the manufacturing process.

DFM

Design for manufacturing—an approach during the design and engineeringphase 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 toproduce it. Waffles come out of the waffle iron more easily if the verticalwalls are angled. The same holds true for molded, stamped, forged, or castparts.

Drawing

A 2D rendering done either by hand or on a computer. An Orthographic draw-ing uses multiple 2D views of an object to define it, e.g. a front view showingheight and width, a top view showing width and depth, and a side view show-ing height and depth. Isometric drawings render the object in a single view.

Engineering check model

Check models are generated from engineering databases or engineeringsketches. The purpose is to verify fit and configuration of components; themodels are functional only to the level necessary to validate basic engineeringdetails.

Engineering release

The release of all engineering documentation that is required to build a prod-uct, including the data required for creating the tooling.

Ethnographic analysis

The process of observing people as they interact with a product. To get themost useful information, designers must look without touching. They go tothe site where the product is normally used, and observe carefully how peopleinteract with the product, with one another, and with the organization to getthe task done. The designers’ methodology is based on this principle: Don'tinterrupt, don't ask; just watch.

Expert interview

Scripted dialogue with someone who has considerable experience with prod-ucts, processes, technologies, and/or users relevant to your design problem.

Extrusion

A manufacturing process that uses a softened billet of material that is forcedthrough 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 highercost.

400


Failure modes

The ways in which a product or process may fail, thus limiting its ability toperform as required.

Feature

A specific design component or characteristic that embodies a function. Seealso Function.

Field testing

Test of one or more functions of a prototype in the actual conditions in whichthe product will be used. See also Lab testing.

First articles

The initial run of parts from production machines.

FMEA

Failure mode and effects analysis—a systemized group of activities that areintended to: 1) recognize and evaluate potential failures of a product/processand its effects; 2) identify actions to reduce the chance of failure; and 3) docu-ment the process.

Focus group

A research technique that presents concepts and ideas to a targeted audienceof 8-10 people at a time.

Forcing function

A constraint that enforces appropriate behavior. Thus, if the doors to an auto-mobile cannot be locked without the key, it is impossible to lock the key in thecar: a simple use of a forcing function. The fact that the car cannot be shiftedfrom 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 Designrequirements.

Functional specifications

A comprehensive, detailed, solution-independent list of what a product willdo and how well it must do it. Written from the perspective of the engineer,the functions are usually specified in terms of measurable performance crite-ria.

401


Gantt chart

A bar chart used to schedule group work by duration. It lists project tasks andsubtasks on the vertical axis and time frames (weeks, months) on the horizon-tal axis. Can also include resources and associated costs.

Hard tooling

Generally refers to full production tooling designed to deliver the quantity ofparts 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 prece-dence over the technological requirements. HCD starts with observations todetermine the real needs of the user, then uses an iterative process of rapidprototyping, rapid tests, and redesign, repeating as often as possible and eachtime completing more of the design.

Industrial design

Also I.D. The discipline that marries the engineering requirement to the mar-keting need through conceptualization of a product based on manufacturingprocesses and material properties.

Injection molding

A manufacturing process that uses melted plastic pellets injected into steel oraluminum molds, which ultimately result in finished production parts. Injec-tion molded tooling usually costs more than extrusions, vacuum forming orblow molding, but has reasonably inexpensive piece parts.

Interview guide

A printed script used for interviewing a client, users, or experts. It normallycontains an explanation of the purpose of the project and interview followedby 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. Seealso Field testing.

402


Latent defects

Design flaws that are not obvious and that may surface during use of the prod-uct. One purpose of the Design review and early user testing is to uncoverlatent defects.

LCD

Liquid crystal display. Flat screen display often used in control panels. LCDsare 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 controlpanels, i.e. ON / OFF switch with indicator lamp.

Life cycle boards

The assembly of visual images that best represent a reflection of the emo-tional 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 orderthey will be discussed. Often lists individuals responsible for presenting eachitem, 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 theway it works. The mental model is a conceptual model of the system; if it isinaccurate, the user is apt to make errors or be confused.

Mission statement

A description of the project objective: the problem to be solved, target usersand other stakeholders, and focusing assumptions.

403


Mockup

Often called a “sketch model,” mockups are generated from thumbnails, con-cept sketches, or rough layouts with some dimensions. The mockup is repre-sentative of the general concept and is used to review general shape withoutfine details. Materials used often include cardboard, foam board, urethanefoam, or equivalent.

Model product

A product that uses new technologies to perform functions similar to those ofyour design. The product may have completely different users and purposesthan 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 themodel are chosen to achieve required finish and texture. Visual models areused to review shape, colors, graphics (if appropriate), and overall designintent. The model is non-functional and is visually perfect. All visual modelsare suitable for photography and marketing needs.

MTBF

Mean time between failures—a measure of responsibility for a manufacturedassembly.

Multiple cavity

A reference to a “tool” that molds more than one part at a time. Multiple cav-ity tools are in odd numbers. The normal multiple cavity for a typical run of50,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 peryear.

Orthographic

A drawing that uses a linear projection of views of the part. Minimal viewsrequired 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, employingdrawings and other simple representations of, for example, a user interface.Enables users to imagine using a design so they can be observed and ques-tioned.

404


PCB

Printed circuit board. A board that interconnects electronic components usinga minimal amount of space with great cost efficiencies.

Performance metrics

Quantitative data that a designer will gather in order to know that a functionhas successfully fulfilled particular user needs or requirements.

Pert chart

A timing chart that identifies the critical path and/or the longest time path ofdependent steps of a project.

Piece parts

The individual parts that make up the whole of a finished component orassembly of a product.

Pilot build/pilot production

The first assembly of all the component production parts, generally takinginto 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 wireframe, or solid model.

Pre-production parts

Parts that are made from production tooling but have not been tested or quali-fied for final production release.

Press

Injection molding press. The term references the core half and the cavity halfthat 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 itdoes, how it does it, and why it does it. See also Competitive product andModel product.

405


Product specification

A document that describes all the critical aspects of a product including butnot limited to physical requirements, appearance, functional requirements,reliability, mechanical requirements, environmental concerns, electricalrequirements, legal considerations, safety agency approvals, manufacturingrequirements. Includes Functional specifications, and is sometimes referred tosimply as the Specification.

Progress report

An informative formal report, usually intended for project supervisors, sum-marizing what has been learned about key issues over a specified period oftime and what next steps need to be taken. The report may include attach-ments 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 sev-eral times during the course of a project to reflect the team's continuingresearch and thinking.

Project notebook

In DTC, a three-ring binder that contains all documents relevant to the designproject: correspondence, meeting agendas, sketches, drawings, photos, designdocumentation, action plans, research summaries, etc. Each document isdated and signed by the team member who produced it.

Proposal

A persuasive formal report, intended for the client (and people in the client'sorganization with an interest in the project) and project supervisors, explain-ing the recommended design, its benefits, and its implementation. The pro-posal 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 alwaysbe fabricated to replicate the production finish to include texture, color, andgraphics.

QFD

Quality function deployment. A methodology for converting marketingrequirements into engineering specifications.

406


Rapid prototyping

Building prototypes rapidly so that the ideas can be tested immediately andquickly. See Mockup and Model (Visual). Rough paper sketches are oftenfine. Computer-generated drawing models are useful but not necessary. As thedesign process continues, mockups from foam, wood, or cardboard are appro-priate, as well as mockups made using commercial “rapid prototyping”machines.

Rapid prototyping machine

Machines that transfer solid computer 3D models into 3D physical modelsand are completed in a very short time frame. Methodologies may includeSLA (stereo lithography), SLS (selective laser sintering) and CNC (computernumerical control).

Render

Process that industrial designers use to visualize their ideas by putting theirthoughts on paper with any number of combinations of color markers, pencilsand 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 atime.

Sketch

A rough two-dimensional rendering used to capture and communicate adesign idea quickly.

Sketch model

See Mockup.

SLA

Stereo lithography apparatus, one of the most popular of the rapid prototypingtechniques. The basic technology includes a vat of photosensitive liquid poly-mer and a laser that is controlled by interpreting a solid computer model. Thelaser interacts with the liquid polymer and solidifies the polymer layer bylayer (.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 acomputer file.

407


Soft tooling

Usually used as a pre-production method of prototyping or manufacturing inorder to verify designs and materials prior to full production-level manufac-turing.

Solid modeling

Computer modeling technique where the output reflects a complete mathe-matical model of a physical entity (part). In solid modeling, it is not unusualto present in a 3-D format all components of a product in their virtual relation-ship. Using virtual reality the parts can be fully rotated for viewing of any sur-face. 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 perfor-mance and results of a design.

Structured group meetings

A research technique that differs from a focus group in that the participantscommit to a written portion before and after any open discussions.

Surfacing

Computer modeling technique where the output reflects only the surface ofthe part. These parts can be photographically rendered with outputs thatresemble 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 typi-cally accomplish the task, including detailed behavioral descriptions. It is par-ticularly important to include the range of approaches that might be allowed(different people seldom do things in the same way) and to recognize the pre-requisites and failure modes of the task.

Three (3) D file

An electronic mathematical representation of a part in a 3D format. Can bewire-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 forthe production of finished parts.

Tweaking

The process of making minor adjustments to a tool to allow for fine-tuningand adjustments prior to running first articles.

Upstream technology

Creating a new technology that may be borrowed from some other usage forthe 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 productsor processes relevant to the design problem. Before the observation, designersusually write a “task breakdown,” a flowchart detailing the steps required toperform the task or process that will be observed. After the observation,designers usually write an analysis that lists each key observation, the designopportunity it suggests, and the direction the designer should take to follow upon that opportunity. See also Task analysis.

Wire frame

Computer modeling technique in which the output reflects a complete mathe-matical model of the external edges of an entity (part). An engineering filethat reflects an individual part, or assembly, is done using computer technol-ogy to allow for complete rotation of the part. A lower level of definition thanSurfacing or Solid modeling.

409


410

411

Index

See also the List of Examples (pp. xvi-xix) and glossary of terms (AppendixQ).

AActive vs. passive verbs 259, 299Agenda

meetings 142, 403oral presentations 274, 275

Alternative designs 396Alternatives matrix 69, 70Analysis, in testing record 85APA source documentation 267, 389Appendices

in final reports 245in progress reports 233

Attachments to emails 190, 199Audience 177

BBackground research 31, 153, 327Bill of materials (BOM) 108, 397Brainstorming 62, 397

clustering ideas 66example list of ideas 64facilitator guidelines 63ground rules 63

Bullet lists 206consistency when using 285in presentation slides 284

CCase studies

curbside mailbox 42electronic kiosk interface 216filing system 11Grip&sip 64, 70highchair footrest 47one-handed food cutting 31paper shredder 47seat back storage 37wheelchair softball 32

Clarityparagraphs 250

412

sentences 256Client communication

email 190initial interview 24, 188meetings 191telephone 189

Client interview summary 323Clustering

lists of brainstorming ideas 66Communication square 176Competitive product 31, 398Conceptual design 7, 107, 398Conciseness 258

figure labels 209poster text 298progress reports 233sentences 259slide text 284table headings 205

Conclusionsfinal reports 245oral presentations 279progress reports 232testing record 86

Conducting meetings 141Constraints 52, 398, 406

compared to requirements 53defined 50

DDecision matrix 89, 398Defects, latent 105Demographics

in user interviews 36, 40, 75, 399Design and communication compared 8, 175Design limitations 244, 383Design process 5, 399

recursive 6, 47, 59Design review 99, 399Design thinking 4Detailed design 7, 109, 399Document design 204Documenting sources 266

APA style 369, 385MLA style 393parenthetical citations 268

413

EEmail 195

client communication 190guidelines 196tone 198

Engineering release 400Essays

EDC I 310EDC II 315format 319

Ethicsand the testing record 83in design 112

Executive summary 241examples 377

Expert interview 44, 91sample guide 341sample summary of results 343

FFailure modes 401Figures 208

examples 210, 211Final reports

planning 238structure and content 238

FMEA 93, 401Focusing assumptions

in mission statements 51Fonts

in poster presentations 299in presentation slides 284written documents 208

GGantt chart 165, 402Generating alternatives 61, 68, 396Google Scholar® 28Grants, acknowledging 241, 245Graphs 211

HHeadings 204Here 156

IInstructions 219

414

audience 220dangers 221, 222, 224illustrations 224organization 221purpose 220revising 224

Interviewingclients 24, 323experts 44, 91, 341, 343users about their needs 34

Introductionsanalytical essay 312client interview guide 25expert interview guide 46final report 242, 379instructions 222persuasive essay 316progress report 230user interview guide 35

LLatent defects 105, 403Leadership 133Learning goals 9

communication 10design 9teamwork and project management 10

Limitationstesting record 86

Limitations, Design 383Limitations, final report 244Lists

bullet 206numbered 206

MMargins, in documents 204Matrix

alternatives 69, 70decision 89

Meetingsagenda 142, 403conducting the meeting 145minutes 147participation guidelines 147with instructors 149

415

Methodology, in testing record 84Mission statement 51, 403

definition 49focusing assumptions in 51in presentation slides 284in project definition 59, 406solution-independence 51

MLA source documentation 267, 393parenthetical citation 269references 268

Mockup 404Mockups

for user testing 70role of the shop professionals in building 71

Model product 31, 404

OObserving users 39, 327, 331, 335Online sources

evaluating credibility 30search methods 29

Online sources, research using 28

PParallel structure 206, 220, 285Parenthetical source citations 268Passive vs. active verbs 259, 299Performance testing 77, 359

reporting on 81, 84sample guide 78sample report on results 359

Performance testing report 359Poster presentations 295

examples 303poster design 296preparing the presentation 300

Presentationsoral design presentations 273poster presentations 295

Primary users 54Print sources

research using 27Progress reports 227, 369, 385

editing 233examples 369, 385organizing 229

416

planning 228Project definition

development of 59format 58

Project deliverables 52Project folder 151

contents 152Project scheduling 161Prototype

in final presentations 290in poster presentations 302

RRAM chart 162

for planning project tasks 164for planning team writing 156

Redundant wording 261References

formatting 267in final report 245in progress report 232

Requirements 54and specifications 88client 55community 56in presentations 279primary users 55

Research plan 20Responsibility Allocation Matrix (RAM) 162Revising

paragraphs 250sentences 256transition words 253

SScenario 43Shop

working in the 71Slides, in oral design presentations 282Specifications 57Stakeholders 54

TTable of contents

example 375in final report 240

417

Tables 214examples 38, 42, 76, 215, 216

Team charters 129, 369Teamwork

conflict, dealing with 135leadership 133successful teamwork 127

Thesis statements 312, 316Title page 239Tone 176, 178

in email to clients 198in instructions 220

Topic sentences 250Transitions in paragraphs 254

UUser observation and interview

examples 335planning 327, 331summary of results 42, 335

User profile 42User testing

examples 355, 363reporting on 81summary of results 76

Users 409primary 54secondary 54testing 74, 355, 363

WWriting as a team 141, 155

418

419

ABOUT THE AUTHORS

John C. Anderson is a lecturer in the Segal Design Institute, where he alsoserves as Instructional Technology Coordinator. He has taught courses in liter-ature and composition at Northwestern for more than twenty years. Hereceived his B.A. from the University of Michigan's Residential College andhis M.A. from Northwestern University.

Stacy L. Benjamin is Director of the Certificate in Design Thinking for theSegal Design Insti-tute. She is part of the teaching team for undergraduateDesign Thinking courses and she mentors student teams on multi-disciplinaryand multi-year project. One of these projects, the NÜberwalker, received theinternational daVinci Award for universal design. Prior to joining Northwest-ern, Benjamin worked for nine years at the design firm, IDEO, as a seniorproject manager and mechanical engineer.

Mark L. Bourgeois is the administrator of the Northwestern Center for Engi-neering Education Research (NCEER) and was previously an engineer in thetelecommunications industry for firms such as Lucent Technologies. In addi-tion to DTC he teaches medical and research ethics in a number of coursesand summer programs in the Biomedical Engineering department. He alsocreated and instructs the highly regarded Continuing Studies graduate courseEthical and Legal Issues in Regulation. He is a Ph.D. candidate in philosophyat Loyola University Chicago, with undergraduate degrees in physics and phi-losophy 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 Pro-gram, teaches courses in composition and engineering communication. Herinstructional strategies are informed by more than eight years of experience asa 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 University’s Writ-ing Program where she teaches courses in engineering writing at the under-graduate and graduate level, expository writing, and academic writing forinternational students. Herrick also consults with the law school on cross-cul-tural issues and ESL legal writing. Drawing on her ten years’ experience insales and marketing for CBS television, Herrick, as managing partner of Her-rick International, also consults with business organizations on interculturalissues, communication, leadership, performance management and projectmanagement. Her research interest is sociolinguistics, the study of how peo-

420

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 Programand Co-director of Design Thinking and Communication. For seven years shewas the project leader for communication in the National Science Foundation-sponsored VaNTH (Vanderbilt-Northwestern-Texas-Harvard/MIT) Engineer-ing Research Center in Bioengineering Educational Technologies. In thoseroles, 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 North-western, where she was also recognized for teaching excellence as the Univer-sity's inaugural Charles Deering McCormick University DistinguishedLecturer.

Barbara L. Shwom, past president of both the international Association forBusiness Communication and the Association of Professional Communica-tion Consultants, teaches writing in three schools at Northwestern University:the Weinberg College of Arts and Sciences, the McCormick School of Engi-neering, and the Kellogg School of Management. She also directs the univer-sity’s peer tutoring center, The Writing Place, and is the managing principle ofa consulting firm, Communication Partners. A frequent presenter at profes-sional conventions, Shwom’s research interest is graphical and mathematicalcommunication. She earned her Ph.D. at Northwestern University and hasreceived several esteemed awards for her teaching and professional service.

Deborah Leigh Wood worked for 14 years at the Chicago Tribune as areporter, feature writer, arts reviewer, copy editor, and special sections editor.She also served as assistant editor of the alumni magazine of the KelloggSchool of Management at Northwestern and was the main contributor to thecoffee-table book Chicago: Heart and Soul of America. Before coming toDTC, Wood taught undergraduate and graduate copy editing at NU’s MedillSchool of Journalism. She currently is an editor and writer at the Baha'iNational Center in Evanston. Wood has a master’s degree in interdisciplinaryarts, a performance-based program that gave her a whole different set of com-munication tools.

Charles Yarnoff, a Northwestern Ph.D. and faculty member in the WritingProgram, has taught Design Thinking and Communication since its inception.In addition to technical writing, Yarnoff teaches courses in essay and fictionwriting and literature courses on 19th and 20th century American fiction andpoetry. He is co-director of the University's Summer Academic Workshop andserves as a freshman advisor in WCAS. Yarnoff has twice been named to theAssociated Student Government's faculty honor roll, was recognized forteaching excellence when he was chosen as Northwestern’s Charles DeeringMcCormick University Distinguished Lecturer for 2009-10, and has receivedthe School of Continuing Studies Distinguished Teaching Award.