My Own Personal Engineering Design Model
The following is my Engineering Design Model as of April 2014.
Purple - Start: To draw the reader's eye to location of the beginning of the flow chart.
Blue - Identification: To ensure the designer has accurately framed the problem.
Red - Analysis: This is mainly the conceptual design work. More big picture thinking and generating many solutions.
Green - Finalization: This is the stage where the product is finalized into the end product.
Note: This is a model, and must not be followed exactly!
Note: Reframing and Rescoping is not specifically mentioned in the design model. Reframing and Rescoping should be avoided, but if necessary, it may happen anywhere, but should be focused on the blue sections which are identification.
Identification Part 1:
My engineering design model begins with the questions, What is wanted? What is the end goal? From this, the designer develops objectives, metrics, constrains and criteria. Next, the designer must identify what is the problem in achieving this goal. I find this to be very helpful in laying the groundwork of what I want accomplished. Before I can proceed with designing a product, I must understand what is the problem and the limiting constraints.
Analysis:
The Designer begins functional decomposition, looking at exactly what could be causing that problem. For any main problem, you can always" peel back" the proverbial onion to go one layer deeper and understand the problem at a more fundamental level. Next, the designer will begin to analyze how to solve the problem at each of these fundamental levels. This is a brainstorming session where no idea is a bad idea. In figure 1, was my teams initial brainstorming page. We each thought of 8 different solutions and then passed the page around for comments. Good ideas such as card-based solutions were thought of as well as more outlandish ideas such as a chatroulette for Aphasia Patients. Now the designer chooses their preferred design method after using MCDM (Multi-Criteria Decision Making) tools such as Pugh Charts, Pairwise Comparison Matrix or a simple Pros and Cons Table. A big emphasis is on prototyping. In my experience, such as during a conceptual design report for Praxis I or any part in Praxis 2, one of the most helpful things that I did was making a prototype. My design team did this at many stages, such as in figure 2, to better grasp what the actual solution we are dealing with. Trying to get your ideas from being in your head, to being on paper or being a 3D model allows you to have a better understanding of what you are trying to actually design as well as a better sense of how well it will perform. That is why there is such a large emphasis on prototyping and it appears three times during one cycle of my engineering design model. After creating the first prototype, which will usually be of low fidelity, the designer must diverge solutions based on this prototype This is to ensure that the designer does not immediately use his first idea but takes a "step back" and considers alternate routes of solving the problem. Since the initial general solution was selected as the best choice, the divergent solutions at this stage should all be strong contenders. The designer should make prototypes of at least medium fidelity out of the divergent solutions that were created. This ensures that all the solutions are appropriately considered and provides a deeper understanding as to how they work.
[12] Figure 1: Beginning of Design Process where brainstorming for divergent solutions occurred.
[13] Figure 2: Low fidelity prototype that made during the brainstorming session to get a better representation of how a card-based solution would work
Finalization:
In this stage, the designer chooses the best design based on the metrics, constraints and criteria from the divergent 3-D prototypes he/she has created. After the design has been chosen, the finalizing details, such as types of screws, should be chosen. With these details, a final prototype of maximum fidelity should be created and tested. After testing and contemplation about the design, the designer must evaluate the design. If the designer is happy with the end product, this is the finalized design. Most likely, if this is the first time through the cycle, there will be some parts that are unsatisfactory in the design.
Identification Part 2:
If there are parts of the design that are unsatisfactory, the designer identifies what is causing the problems. Then, the designer re-enters the design process at the beginning of Analysis.
Conclusion:
My model of engineering design is not fixed in stone and each time I encounter a new engineering problem, I learn from the problem. When completing the design package (Design Brief, CDR, DDR, and KickStarter Package) for Praxis 1 or in Praxis 2 starting from scratch and writing the RFP and seeing the problem my design team saw come to fruition in real, exciting and tangible solutions, I learned the importance of prototyping as well as generating many solutions to a single problem. The first solution is not usually the best solution. In fact, in both Praxis 1 or 2, neither times has my initial idea been remotely close to the final design. Finally, perhaps the most important thing I learned was the idea that the design process does not proceed in a linear fashion where there is always a specific end. There can always be iteration and that is why my design model forms a circle. My Engineering Design Model matches the ideology of my Engineering Design definition by not specifying the type of solution, but rather enforcing a rigorous method at arriving at the solution which includes technical and non-technical solutions.
Thank you for reading my opinion on Engineering Design. I hope this proves to be useful to the reader as it is to me and to remind them of any key steps that they may have forgotten.
Reference:
[11] University of Toronto Praxis 2, "Praxis 2", 2014, Matthew McLeod, March 2014
[12] University of Toronto Praxis 2, "Praxis 2", 2014, Matthew McLeod, March 2014
[13] University of Toronto Praxis 2, "Praxis 2", 2014, Matthew McLeod, March 2014