Design Handbook

A Guide to Engineering Design

Jing Bo Yang
UNIVERSITY OF TOROTNO

Contents 1 Preface..................................................................................................................... 2 2 Engineering Design Process ................................................................................... 3 2.1 Overview ........................................................................................................ 3 2.2 Problem Definition......................................................................................... 4 2.2.1 Framing and Scoping ........................................................................... 4 2.2.2 Scoping Diagram ................................................................................. 5 2.3 Conceptual Design ......................................................................................... 6 2.3.1 Problem Decomposition....................................................................... 6 2.3.2 MCDA Tools ........................................................................................ 8 2.4 Detailed Design ............................................................................................ 10 2.4.1 List of Common Details ..................................................................... 10 2.5 Prototyping ................................................................................................... 11 2.5.1 Sample Prototypes ............................................................................. 11 3 More Tools and Strategies..................................................................................... 14 3.1 Due Diligence Quiz...................................................................................... 14 3.2 Hexagulation ................................................................................................ 15 3.3 Team/Individual Task Card .......................................................................... 16 3.4 Synchronize Works Online .......................................................................... 16 3.5 Poster Design Strategies .............................................................................. 18 3.6 Reverse Engineering .................................................................................... 20 4 Special Terms ........................................................................................................ 22 4.1 Stakeholder .................................................................................................. 22 4.2 Objectives .................................................................................................... 22 4.3 Metric and Criteria ....................................................................................... 23 4.4 Sample Requirement Chart .......................................................................... 24 5. Works Cited........................................................................................................... 25

1 Preface
I have to appreciate what Engineering Science taught me in the past 8 month. I possibly learned more math, physics, and materials than I ever did in life, but most importantly, I learned the essence of engineering design. It was Praxis that got me started in understanding what engineering design is. Through the projects that I did in Praxis I and Praxis II, namely the Trident Lock, RFP for Reducing Headset Discomfort, and the ICE Cube, I can now claim that I am in some degree experienced in engineering design process. To my understanding, engineering design is a process which helps engineers to generate designs that satisfy given requirements. It not only has steps and instructions that ought to be followed, but it also involves strategic use of tools to streamline the process. In this handbook for engineering design, I will give detailed explanations to engineering design, and describe useful tools along the way. Some tools and strategies cannot be pinned into specific stages of design, and are explained in a separate section. For whoever is reading the handbook, good luck with your design, and hope this handbook can help your design go a long way.

Cheers to all engineers and engineering students, Jing Bo Yang 2014/4/16

2 Engineering Design Process

Engineering is more than an area of study. It is a systematic approach to design for realistic solutions. There sure are elaborate theories in engineering, but the main focus is on application, or to be more specific, it is the meticulous implementation of an engineering design process. Engineering design process is the back bone of all designs. Design processes vary from individual to individual, but they should all come with five stages: problem definition, initial preparation, conceptual design, detailed design and prototyping. It would be helpful to have an overlook of the entire process, and then examine individual parts.

2.1 Overview
The flow chart is a simplified model of my design process. This particular design process is developed based on Praxis I and Praxis II experiences [1], and have been used for the two major group projects this year. The Problem Definition stage gets the design team familiar with the problem in general. And it allows the team to clarify and make modifications to the requirements. During Conceptual Design stage, the team should try to go through a number of converging and diverting cycles to find Figure 2.1 Summary of design process solution to smaller problems identified during the process. The team should then decide on one design that is the most practical to move forward with. Detailed design stage is similar to the Conceptual Design stage, except that the focus of those cycles are on specific details.

The Prototyping stage collects results from the Detailed Design stage, and finalize on the design that should be prototyped. Depending on the project requirements, one or more prototypes should be made to demonstrate validity of the concept. Out of the five stages of design, conceptual design and prototyping has proven to be the most important and time consuming stages. They require the entire team to work together to make sure that the best ideas are put on the table, and to have a prototype that best demonstrates those ideas. Both of my Praxis I (Trident Lock) and Praxis II (ICE Cube) projects were highly successful because the team followed the above design process meticulously, and each member of the team made significant contribution to the projects. The following sections will explore each stage in detail, and provide examples on how tools are used to help with development of these stages.

2.2 Problem Definition

The objective of the Problem Definition stage is to become familiar with the give problem. This can be achieved through research and clarifying design requirements. If the problem is identified by the team itself, the team should already be familiar with the problem, and the initial research Figure 2.2 Problem definition stage should have been completed already. The design team would only need to refine its specified design requirements so they become more realistic, making the problem solvable by the design team. If the problem was given by an outsider, which happened both in Praxis I and Praxis II, the design team must first read through the problem statement carefully to understand the issue, then put in effort to find current solution to the problem and compare those with the strength of the team. Ideas like framing and scoping would be especially useful because they help limit the scale of the problem to something that can be solved by a first year design team. 2.2.1 Framing and Scoping Although similar in wording, framing and scoping are dramatically different in practice. Framing is determining the perspective of approach to the problem, while

scoping is to limit the focus of the solution [1]. For my Praxis I project, the Trident Lock [2], we are asked to to create a portable, safe, and effective product that will prevent and deter bicycle thieves from stealing a bicycle and its major components. Through our discussions, we concluded that we are only capable of designing a product in the given amount time. This means we are framing it as designing an actual product, rather than implementing a system or modifying city infrastructures. Moreover, we realized that all locks can be broken with powered tools like angle grinder, so we scope the problem to deter bike theft, which means we do not take into account of theft with special tools. In short, after the framing and scoping process, the focus is now on designing a product that would make the bike an undesirable target. Praxis II re-visited framing and scoping. When designing the ICE Cube, we found out that the frame of the given RFP was very narrow, and it would be hard to reframe it to another perspective, therefore we decided to broaden our scope [3]. That being said, the scope of our solution is all farmers who may want to go to the market. And to achieve this, one design consideration we had was modularity, because modular products have no problem in adapting to farmers of varying scale. 2.2.2 Scoping Diagram The scoping diagram [4] is a tool developed by the Praxis teaching team to help design teams with scoping. The diagram breaks up a problem into three discrete steps: foci, internalities, and externalities. Foci is the core issue addressed by the potential topic, while the latter two steps focus on gradually broader and more peripheral issues. The scoping diagram was used before we came up with any substantial issue to address for the specific community we have chosen. From those boxes, we found more problems that we can ask to get a better feeling of the communication operators. Questions listed on the sheet were actually asked later.

Figure 2.2.2 Scoping diagram used for Reducing Headset Discomfort RFP. [4] * Content filled by teammate Jessa Zabala and me.

2.3 Conceptual Design

This stage is the most important stage of the entire design process. Good execution of the convergence-divergence cycle plays a significant role on quality of the solution. As shown on the left, Conceptual Design stage always starts with decomposing Figure 2.3 Conceptual design stage the problem, which is also the start of a divergence process. The design team should generate multiple solutions to individual problems using appropriate ideation tools to help brain storming. Needless to mention that research on existing designs would help with inspiration. The convergence process takes those solutions and tries to merge the strength of them without increasing the complexity of the final design. It is desirable to either further decompose these smaller problems, or identify new problems that are associated with the conceptual designs. This means the design team should go through the divergenceconvergence cycle multiple times until no more problems can be identified, or the design team believes that the solution is satisfactory. The divergence-convergence cycle may generate multiple satisfactory solution, therefore appropriate MCDA tools should be used with engineering judgment to identify the best conceptual design. 2.3.1 Problem Decomposition Simple as it sounds, problem decomposition breaks a big problem into individual parts. Solution to these individual parts would together form a solution to the overall problem. I did not label this tool as functional decomposition because functional composition should decompose the function into sub-functions [5], and in contrast, we broke up the problem into sub-problems. These subproblems are not necessarily functions to be designed, but a guide to where the team should focus on. In fact, trees or flow charts created through problem decomposition can be called objectives tree.

Figure 2.3.1-1 Objective tree of a safety ladder [15]

As shown below, the overall goal is to find out why bikes get stolen. The branches further divides problems into sub-categories, and solutions are developed in response to each possible reason that a bike might get stolen.

Figure 2.3.1-2 Trident Lock, problem decomposition [2]

The same process was used for the meat refrigeration project, but there were fewer categories as the solution space to the given RFP was very limited. Nevertheless, it demonstrates the process of problem decomposition. Flow chart of the process is on the next page.

Figure 2.3.1-3 Flow chart of progress for ICE Cube [3] *Chart made by teammate Johnson Zhong

2.3.2 MCDA Tools Multiple-criteria decision analysis is an important operation in engineering design. It helps a designer choose a solution that best fits the requirements of a project by comparing solutions with some set criteria. There are many MCDA tools available, such as Pugh Chart, Pair-wise Comparison Matrix, and etc. These tools are frequently used in combinations to be more effective. However, MCDA tools must not be the source of final decisions, the final call must be made based on engineering judgement of the design team [1]. Pugh Chart Pugh chart is an example of decision making matrix developed by Pugh. It usually has candidates as one dimension and criteria as another. Each candidate is evaluated based on the listed criteria, and a mark is given depending on it performance. The marks can be based on some Borda-count-like system, or simply better/same/worse compared to

a reference design [1]. Total mark is sometimes added to the end of the chart. An example of Pugh chart used in my design experience is shown below. It was made during Praxis I Trident Lock project. Note that this chart uses Borda-count-likescoring, and contains two reference designs. At the time, we believe Figure 2.2.3 Pugh chart used for Trident Lock [2] that Borda-counting * Chart created by teammate Sara Maltese and Jessica Leung would best show the performance of each conceptual design. We decided to include two reference design because candidate solutions were very diverse. As explained before, the final decision was not based on the total scores. We zoomed into these two products and compared them using engineering intuition before finalizing on the Hub Lock concept. Pair-wise Comparison Matrix Unlike Pugh Chart which compares candidate designs against criteria, Pair-wise Comparison Matrix is a competition between candidate designs. Winner gets one point and a tie gets half of a point [6]. Again, there must be at least one reference design to make the comparisons meaningful. Needless to say that a decision cannot be made solely on result of the Comparison Matrix. The following is an example of Pair-wise Comparison Matrix used in my detailed design for the hook of a cloth hanger.

Figure 2.3.3 Pair-wise comparison matrix used for detailed design decision for bendable cloth hanger [7]. Description of each design is not shown for simplicity.

Note that only lower triangle is filled to avoid repeated comparisons. The diagonals are all 0 because they are comparisons among themselves.

10

2.4 Detailed Design

The Detailed Design stage is a small-scale replicaion of the Conceptual Design stage. All steps and tools used in the previous stage are still applicable, but require less work. Since the problem should have been well defined, it is often hard to further divide into Figure 2.4 Detailed design stage smaller problems. In addition, detailed design decisions often do not require innovation because the designs are likely to exist in the form of commercialized products or related patents. Neverthelss, designers should still go through the divergence-convergence cycle described before to find the best selection for these specified details. 2.4.1 List of Common Details The following is a list of details that may require some detailed design process. Some of the detailed have been encountered by my team and me in the past in projects like the Trident Lock [2], the ICE Cube [3], and detailed design report [7]. 1. 2. 3. 4. 5. 6. 7. Material selection Surface coating Ergonomic handle design User friendly interface (color/size of button, surface texture, GUI, etc.) Size (sometimes implies weight) Safety (hide electrical parts, fillet for sharp corners, etc.) Mechanical details (locking mechanism, attachment using screws/glue, etc.)

11

2.5 Prototyping
A conceptual design cannot be proven valid unless a prototype has been built to demonstrate its functionality. The Prototyping stage serves the purpose for designers to test their concepts. Although this stage can be extremely time consuming, it is Figure 2.5 Prototyping stage absolutely necessary for the product to gain credibility. The higher the fidelity, the more credibility it gains. It is often convenient to build a solid model on computer before any physical prototype has been constructed. This is step is particularly important if the designer is not sure about the size, or a full scale model is too difficult to construct. Physical prototypes can be small and non-functional in the beginning, but the design team should at least attempt to get full dimension and basic functionalities. Testing the prototype would further validate the design concept. 2.5.1 Sample Prototypes It would be helpful to show what first-year level, low to medium fidelity prototypes should look like. Trident Lock, Praxis I Three prototypes were made for the Trident Lock. The initial prototype was made using Solidworks; the second one was a test-of concept, low fidelity prototype made of pens; and the last one demonstrates functionalities of the lock.

12

The Solidworks model had been modified a number of times to finalize the exact dimension of the lock.

Figure 2.5.1-1 Dimensions of the

Trident Lock [2]

Figure 2.5.1-2 A very basic prototype for the

Trident Lock [2]

Despite that the first physical prototype is very questionable in nature, it allowed us to test on various size of bikes so we can finalize on the size of the lock. The final prototype for Trident Lock is made of foam board and long wooden dowels. It has most of the dimensions correct, but does not contain any mechanical details. The prototype was tested with all kinds of bikes, and brought to the critique to demonstrate its basic mechanisms. ICE Cube, Praxis II Three prototypes of varying fidelity were made for the ICE Cube. There were one solid model and two physical prototypes. The solid model was more for a proof of concept, and to gain intuitive understanding of the conceptual design, while the last physical prototype demonstrates full dimensions and full functionality. Although the physical prototypes never used solid model for ICE Cube [3] the stainless steel sheet specified in our design, we attempted to use aluminum sheet to demonstrate the metallic nature of the inner box. Our choice of using foam did not deter us from showing the full functionality because Styrofoam has a thermal conductivity comparable to that of a poor vacuum.
Figure 2.5.1-3 Cross-section view of

Figure 2.5.1-3 Final prototype [2]

13

Figure 2.5.1-5 Second prototype for the ICE

Figure 2.5.1-4 First prototype for the ICE

Cube. Made entirely out of foam. [3]

Cube. Inside box is made of aluminum, but

the outside is still foam. [3]

14

3 More Tools and Strategies

The tools and strategies described below can certainly be part of a design process, but it is hard to shovel them into specific design stages. They are things that might be useful if used wisely. For each tool/strategy, instructions are given as guides, and some examples of use are provided.

3.1 Due Diligence Quiz

The Due Diligence Quiz was created by the Praxis teaching team for the design teams to evaluate the teams progress in the development of conceptual designs [8]. In fact, the Due Diligence Quiz can be used for many other purposes, such as evaluating the final design/prototype and preparation for a design showcase. Just as the name implies, the Due Diligence Quiz tests how much work has been done, and the scores can be an indication of how much more work should be done. A sample of the Due Diligence Quiz is available on the design course website (https://design.engsci.utoronto.ca/courses/esc102/20141/Studios/esc102-20141--duediligence-quiz.pdf), but this specific quiz certainly does not apply to any other situation. It is best for the design team to develop a Due Diligence Quiz before the whole process has started, and add in more questions as needed.

Figure 3.1 Example of a Due Diligence Quiz for ICE Cube. It is not completed because we were confident in the amount of effort we have put in. [8]

15

When to Use The Due Diligence Quiz is typically used at the end of Conceptual Design stage. A team may decide to do more iterations if their Due Diligence Quiz score is lower than what they are expecting. The team should not continue until its quiz score has got up to an acceptable level.

3.2 Hexagulation
The Hexagulation worksheet was again created by the hardworking Praxis teaching team [9]. The purpose of this worksheet is to check whether the design team have had enough research into the subject matter. Unlike the Due Diligence Quiz, Hexagulation is more straight-forward, and always have the same format. It always have one central issue, and the design team needs to fill out six branches with some levels of detail. When to use It is common to use the Hexagulation worksheet at the end of Problem Definition stage because at this time, the design team must know enough details of the problem to continue forward, and doing Hexagulation worksheet is a good way of checking whether enough research has been done. Tips Although called the HEXA-gulation worksheet, it is not necessary to have exactly six details. More details the better, but fewer details does not mean a lot more research. For example, for the Reducing Headphone Discomfort RFP, extensive research only yielded limited number of details. It is up to the team to decide what has to be done. The hexagulation chart completed on the next page was done when we had no idea how to find more potential problems that communication officers might have. The problems outlined below are legitimate problems, but are not really suitable for further investigation. However, completing such chart helped us eliminate certain possibilities, which eventually forced us into investigating headphone comfort.

16

Figure 3.2 Hexagulation sheet done during brain storming for Reducing Headset Discomfort RFP [9].

3.3 Team/Individual Task Card

The Task Card is yet another tool designed by the Praxis Teaching team [10]. Its idea is to assign everyone some task before the next team meeting, and since the tasks are written down, the team can make sure things are done, and track down noncontributing members. When to Use All teams need to have a task card or an agenda in one form or another. A dysfunctional team may use the Task Card to push its members to work harder, while a perfectly functioning team may use the card to not forget things or leave tasks to the last minute. Therefore, use the Task Card, or create an agenda whenever possible.

3.4 Synchronize Works Online

It is obvious that teamwork implies documents are written by different individuals, therefore how works are synchronized is an interesting issue. I have used three different methods, and they will be described in detail below.

17

3.4.1 Google Doc Google Doc is a great web-based online office software for teamwork. It has MSWord-like abilities, and allows multiple people to work on it at the same time. In fact, editors can see who is online, and who made the last changes. With is great features, teams should use google doc when multiple people want to work on the document at the same time. It is especially convenient if the document is heavily text-based, or simply serve as a medium to dump resources. Since it is only an online tool, it has limited ability to handle pictures, charts, and etc. Do not use Google Doc if the team wants beautiful formatting done at the same time. In fact, a team can choose to do all the text editing on Google Doc, and copy-paste everything to a Word document to add in all photos and to do formatting. 3.4.2 SkyDrive(OneDrive) Doc This is a relatively new OneDrive feature, and it works together with MS Office 2013 to make online work-sharing easier. Its Office Online feature is perhaps more powerful than that of Google Drive, plus it is fully compatible with desktop MS Office. Unfortunately, it can only be edited by one person at a time, or unexpected problems may happen. If team members have totally different work schedule, definitely use features like Word-Online because it eliminates the need to create a separate document for formatting. The only concern would be teammate(s) not have Word 2013 installed. 3.4.3 Sharing on Facebook This is perhaps the most inefficient way of team-working on a document, and just imagine having several people all trying to claim theirs is the latest version gives me headache. Facebook allows users to update existing document, but the notification might get ignored as people turn off notifications when working. For one reason or another, the Reducing Headphone Discomfort RFP was completed with dozens of version flying around. As shown below, I still have multiple version of

18

our RFP even after submission.

Figure 3.4.3 Screenshot of many versions of the same document because teammates are working at the same time.

3.4.4 Comparison Edit Online Synchronize Compatible d Editing with MSOffice Y N CrossPlatfor m Y Comments Free

Google Y Y Y Drive OneDrive Y N Y N Y ~ Facebook N N Y ~ Y Y /QQ Sharing * ~ QQ does not have Linux desktop version, but has an online version with very limited functionalities * ~MS-Office is not free, Figure 3.4.4 A Comparison chart for but Office-Online is free. Office-Online is not different types of services used to share nearly as good. documents.

3.5 Poster Design Strategies

A well designed poster catches viewers attention right-a-way with its carefully crafted layout, attractive content, and outstanding color. These three elements will be explained below. 3.5.1 Layout The poste should let the viewer know what is being showcased at a glance. This can be achieved through a concise title (see next section), and a center-focused layout. The easiest way to have a center-focus is to have a big image of the product in the middle of the poster, with details surrounding it. The image does not have to be in exact middle, but have to be big enough to overshadow other components [11]. It is possible to have a secondary focus, but that focus should be on the side.

19

Figure 3.5.1 Original layout of the poster. Only has sections divided as to where things should go [3].

3.5.2 Color Factors associated with color are attractiveness and cost. Bright colour and high contrast makes the poster stand out from the rest, but large areas of colour also increases the cost by a significant amount. For professional posters, it is better to have white background with black text. But the poster used for purposes like Praxis showcase are not strictly professional, which means the poster can be more colourful, and more artistic. There is no best color for a poster, we decided to use light blue because we are emphasizing on cooling, which naturally comes with cool colour like blue.

Figure 3.5.2-1 First iteration. Slightly darker blue. [3] * Poster created by teammate Johnson Zhong

Figure 3.5.2-2 Second iteration. Brighter blue, looks a lot cooler now. [3] * Poster created by teammate Johnson Zhong

20

3.5.3 Content To not lose viewers attention, it is advised to have an explicit title with concise text. As shown above, first line of the title is the name of the product, while the second line is the purpose of the product. People frequently use the RFP title for the second line, but the fact is that viewers have no idea what the long RFP title is about, and loses their attention immediately. Having a general, yet explicit second line is key to draw viewers attention. The task then is to summarize detailed designs into short phrases, and highlight them in some form to make them memorable. More words simply creates more boredom in reading, so details must be in point form.

Figure 3.5.2 First iteration. Slightly darker blue. [3] * Poster created by teammate Johnson Zhong

3.6 Reverse Engineering

Reverse engineering is perhaps the best way to understand how a product is designed. Nowadays reverse engineering can be done with advanced technology, using CAD to analyze how the product is performing its desired functionalities [12]. We essentially look into the black box to reach for its essence. Key to successful reverse engineering is to document everything. Documentations are best done in the form of video-taping, or through pictures. This way the engineer can not only study the product, but also study the process later.

21

In the very beginning of the year, I disassembled an electromechanical device to find noticeable designs in the product. The task was called a tear down, but it is a premature form of reverse engineering. All the steps were documented carefully. From these

Figure 3.6-1 and -2 Holistic pictures like these two will be helpful for later studies. All parts should be laid out neatly. [14] * Right image taken by teammate Jing Xie

experiences, I learned exactly how a Waterpik functions, and how basic fax machine performs its functions.

22

4 Special Terms
4.1 Stakeholder
Stakeholders are people who may be affected by the identified problem or the proposed decision. People who are indirectly involved in the issue may also be counted as stakeholders, and their philosophies and opinions should be taken into consideration as well. In addition to identifying direct stakeholders, identifying indirect stakeholders requires in-depth thoughts. It is sometimes useful to investigate who have close relationship with the direct stakeholders. We were more inclusive during Praxis II to identify secondary stakeholders for our Reducing Headset Discomfort RFP. We not only identified call takers, callers, dispatched units, and the department as a whole to be stakeholders, but also included the manufacturer Plantronics, and eyeglass vendors, as a new design can change what the operators decide to wear for work.

4.2 Objectives
Objectives are what a design should achieve for it to be a valid candidate design. Definition of objectives in Praxis I and Praxis II are different, the former focuses on DfX, while the latter further divides objectives into high level objectives and details objectives without mentioning DfX [1]. In my opinion, dividing objectives into two levels help specify other requirements, so it is better to have two levels of objectives. The high level objectives are quite general, they usually focus on what must be done. For example, in the Reducing Headset Discomfort RFP [3], the high level objectives are: 1. Must reduce or eliminate discomfort caused by wearing glasses together with headsets for all operators wearing glasses. 2. Must not hinder any operators from performing their task. 3. Should be compatible with existing equipment and budgets. On the other hand, detailed objectives focuses on individual details, and they should be supported by corresponding metric, criteria and constraint. Note that one detailed objective may have multiple requirements, as will be shown after other requirements are explained.

23

4.3 Metric and Criteria

In short, metric is how a design can be evaluated, and criteria specifies what is preferred. It is important to have metrics that can be measured numerically, which means numbers are preferred over feelings [1]. It is often possible to convert feeling, or other non-measurable metrics into measurable ones. For example, instead of using discomfort felt by operators as a metric, we can measure force distribution on an operators face, and determine what force distribution is optimal.

24

4.4 Sample Requirement Chart

Figure 4.4 Reducing Headset Discomfort RFP requirement table [13] * Creation of the table was a team effort.

25

5.

Works Cited

Some of the following sources are not cited using precise IEEE citation formats, because the materials were not formally published or recognized. Should there be any concern over the use or misuse of these sources, please contact me. I tried to cite Praxis lectures, because they are helpful in general. The lectures altogether are cited as Praxis Lectures. It is impossible to cite one specific lecture as concepts are iterated multiple times. But I do appreciate what Prof. Foster and Prof. Irish taught me in class. [1] Jason Foster, Robert Irish, "Praxis Lecture," unpublished, Toronto, Lecture(voice and slides). [2] Sara Maltese, Jing Bo Yang, Jessica Leung, Aidan Malone, "The Trident Lock Project," unpublished, Conceptual Design Report, 2013. [3] Jessa Zabala, Kimberley Cota, Sheng Zhong, Jing Bo Yang, "The ICE Cube Project," unpublished, Design Task, 2014. [4] Praxis Teaching Team, "Scoping Diagram," unpublished, Studio Materials, 2014. [5] Universit of Michigan, "ME450: Functional Decomposition," Universit of Michigan, Ann Arbor, Michigan, 2002. [6] University of Alabama, "The Method of Pairwise Comparisons," University of Alabama, [Online]. Available: http://www.ctl.ua.edu/math103/voting/methodpc.htm. [Accessed 18 April 2014]. [7] Jing Bo Yang, "Shape Design for Cloth Hanger Hooks," unpublished, Toronto, Detailed Design. [8] Praxis Teaching Team, "Due Diligence Quiz," unpublished, Studio Material, 2014. [9] Praxis Teaching Team, "Hexagulation Worksheet," unpublished, Studio Material, 2014. [10] Praxis Teaching Team, "Team/Individual Task Card," unpublished, Toronto, Studio Material. [11] University of Guelph, "Effective Poster Design," University of Guelph, [Online]. Available: http://www.soe.uoguelph.ca/webfiles/agalvez/poster/. [Accessed 18 April 2014]. [12] J. Thilmany, "The Rise of Reverse Engineering," ASME, Februrary 2012. [Online]. Available: https://www.asme.org/engineering-topics/articles/modelingcomputational-methods/the-rise-of-reverse-engineering?cm_sp=ComputerAided%20Design-_-Feataured%20Articles-_The%20Rise%20of%20Reverse%20Engineering. [Accessed 16 April 2014]. [13] Jessa Zabala, Kimberley Cota, Sheng Zhong, Jing Bo Yang, "Reducing the

26

Discomfort of Wearing Headset with Glasses for Toronto Police Communication Operators," unpublished, Request for Proposal, 2014. [14] Jing Bo Yang, Jing Xie, "Waterpik Tear Down," unpublished, Tear Down, 2013. [15] Queens University, "Conceptual Design Techniques," Queens University, Kingston, 2007.