ALEXANDER CUBELLIS
The Linear Dynamic Model
In attempting to develop a personalized “design process,” I began to brainstorm certain elements of design that I believed were most important and the most widely applicable to any design problem. I recognized the importance of developing a model that would be readily applicable to as many different design situations as possible. In creating this model, I wanted to draw upon certain techniques and methodologies that I believe are important but at the same time develop a process that demonstrates my own personal creative sensibility and distinctly demonstrate what I believe to be the most important developmental components in a design process.
Developing the Model:
In my engineering design career, I have come to understand that the organizational environment in which design process is developed is dynamic and constantly changing. Therefore, I wanted first to develop a visual representation of the design process that demonstrated the dynamic and non-linear nature of the design. As such, I encourage the reader to interpret the schematic not as if the user must follow each step from A to B but rather as an evolutionary process. The only “linear” component of the process is illustrated by the arrows in the schematic which are meant to give the designer a suggested pathway which is open to interpretation. As the user develops a better understanding of the model, they will see that the steps are guides recognizing that the engineering design process is non-linear and stochastic. In other words, the designer must always be flexible while implementing and considering the suggested model provided.
The Linear Phase:
Interplay between Problem and Purpose:
In my definition of engineering design, I associate “purpose” and “problem” as being synonymous. To have a reason for designing something, there must be a problem that needs to be solved. This problem then gives the design process purpose.
Engineering design identifies an inefficiency, difficulty or inadequacy that the designer must attempt to “fix” by developing an elegant solution to the aforementioned problem. Often “engineering” is associated with the development of physical solutions to problems.
A quick Google search of the word engineer provides the following definitions:
In defining engineering design and the engineering design process, I would like to stay away from the abovementioned definitions as I feel that they do not fully capture entirely what it means to “engineer.” My opinion is that the engineering design process goes far beyond the creation of something “physical” and I believe that it is important to note before explaining the design process further, that engineering solutions do not have to be “physical” in the truest sense of the word. Engineering design encompasses many different areas. An engineering design solution can be increasingly more abstract like developing a software algorithm that automates trading in financial markets to developing a heuristic model to determine project scheduling conditions using heuristic models or even developing a method for developing methods which is the nature of this task at hand. Therefore, before proceeding with this engineering design model it must be noted that in creating this model I am effectively implementing some form of an engineering design process. As the engineers and designers of today, we must prevent ourselves from constraining our view of what an engineering problem is and we must broaden our perspectives to be as far-reaching and expansive as possible.
“Reframe/Redefine”
Once the problem statement has been defined, the designer must take a first step back to analyse the scenario with which he or she has been presented. Often, problem statements may be unclear or fail to address the “true problem” at hand. It is the responsibility of the engineering designer who is working for a client or stakeholder to communicate his or her findings and demonstrate that in fact the problem statement can be articulated in a more defined way.
The second possibility is that the designer may in fact discover that the factor that is directly influencing the problem may be different than how the problem is originally framed. This factor is known as the causal or causation factor [2]. As an example of a problem reframing, consider a stakeholder that has presented a designer with the need for a solution to the following problem: that beverages like coffee and tea are too hot to handle right after the water has been boiled to make them. Therefore the individual framing the problem may feel that the issue is that the cup is not insulated enough to prevent the user from being burned. An inventive engineering designer could abstract the problem to a higher level of thinking and suggest that in fact, the problem is not that the cup is not insulated sufficiently but the fact that the difference in temperature between the user handling the cup and the user’s body temperature is too great. Therefore increasing the temperature of the user handling the cup would in fact solve this problem. Although this example and its possible solution seems unrealistic, it serves as an example of the abstractive process that engineering designers must implement regularly when deciding if a reframing or a redefining of the problem is necessary. Although in this example this reframing can be easily discarded since it is impractical, when problems become more abstract and the solutions, less obvious, it may be necessary that this alternative method of thinking may be required.
Scoping:
Once the problem is clearly defined it is necessary that the designer determine the following:
-
High Level Objectives
-
Requirements
The scoping stage in the design process involves determining what requirements and high level objectives are central to solving the problem. The stakeholder identifies what the designer must address in his or her solution to the problem. With this information the designer can abstract the higher level objectives which he or she will use to gauge the effectiveness of the design solution. If the design solution meets these high level objectives to a high degree, it can be said that the solution was successful (see quantitative analysis method: pairwise comparison matrix, Pugh chart, etc.).
The Fractal Stage:
The fractal stage is the component of the design process in which the user begins to implement divergent methods to begin the iterative process. Some examples of these methods include challenging assumptions, the Osborn Method, biomimicry, etc. This component of the design process is referred to as the fractal stage because it can be likened to a fractal pattern in nature.
The Iterative Process: “Idea N”:
As the designer continues to iterate, multiple solutions to the problem will be generated. It is necessary that the designer compare each of the respective solutions so that as iterative process continues, the designer will have created multiple solutions that are distinct and address certain requirements, DFX’s, and high level objectives better than when compared to the other solutions. However, this design process “is much more than just a systematic application of rules and theory to solve a technical problem,” Seyyed Khandani, PhD. notes. As designers we must “start with existing solutions to the problem and then tear them apart-find out what's wrong with those solutions and focus on how to improve their weaknesses. Consciously combine new ideas, tools, and methods to produce a totally unique solution to the problem” [3]. This is when the “inverted fractal stage” begins. At this point in the design process the designer will implement convergent methods to bring together components of each of the solutions generated in the fractal process to develop a single highly effective solution that addresses all of the requirements. This iterative process can be completed N times until the designer and the stakeholder are satisfied with the solution. This part of the process is known as “synthesis" [3].
Quantitative and Qualitative Analysis Modelling:
During the iterative process, quantitative and qualitative methods can be implemented at any of the nth iterations. These methods may range from being as simplistic to developing a low-fidelity prototype such as a sketch to better visualize the dimensions of a possible device design to higher level more abstract quantitative methods like fuzzy set algorithms for engineering design applications or optimization modelling. This is a critical component of the design process as it can guide the designer in numerous directions. For instance, consider a civil engineer designing a bridge. They may feel their design is completely without flaw and ready to be pitched. However, if the engineer discovers by means of a truss designing software that one of the components of the bridge will fail under certain loading conditions, the designer may be forced to iterate once more or completely change the design and be forced to return back to square one.
The Dynamic Components:
The engineering design process is nonlinear and therefore, as designers, it is necessary to consider external factors that may completely change the design process. These factors are referred to as dynamic components and may present themselves at any stage in the design process and force the designer to change the direction, requirements, or high level objectives in the design process. Some of these dynamic components include time, financing, labour, aesthetic sensibility etc. For instance, consider a scenario where a software engineer has been informed that his or her deadline to port code has been cut back a week. The designer is then forced to work under conditions that do not provide him or her with enough time to meet all of the high level objectives or requirements of the stakeholder. As such, the engineer may be forced to re-evaluate or re-scope the problem.
Solution N and the Final Solution:
Once the designer has exhausted all means of iteration and analysis and is satisfied with his or her solution known as Solution N, this can be presented to the stakeholder. If this solution is accepted, it is referred to as the final solution. If the stakeholder does not accept the solution then further iteration may be required or the problem must be redefined or reframed. This can involve implementing further quantitative and qualitative analysis to refine the design.