Design Philosophy and Definition of Engineering Design
“Engineering design is the process of researching a problem to find multiple frames from which to approach it, systematically conceiving, analyzing, and selecting solutions that are operationally simple, usable, and economical.”
I emphasize simplicity, usability and economy in works of engineering design. Although it is true that aesthetically pleasing, scalable, and easy-to-manufacture designs are also aspects of good engineering design, the converse does not hold true. But for a solution or design to be a success it must possess the qualities of simplicity, usability and economy or else it has no merit. This is because simplicity, usability and economy are aspects of practicality and engineering is about practicality. Engineers create inventions to serve the world and they must be made with the end user in mind.
It is also worth noting that my definition puts emphasis on the process. The majority of engineering design definitions converge to the following:
“Engineering design is the process of creating an elegant, efficient, economical, [insert more adjectives here] solution.”
My earlier definition was not different, but I came to understand that my prior definitions of engineering design were too ‘final merchandise’ orientated. I had carelessly glazed over that ill-defined word ‘process.’ What my prior definition of engineering design did was define the components of the product of good engineering design. That is to say, good engineering design leads to those qualities. However; engineering design itself is the process of coming to that design.
For this reason, I do not believe engineering design has anything to do with creating an elegant and practical solution. These are the bi-products of good engineering design. To me, design is a verb more than it is a noun. A person ‘designs’ rather than creates a design. I am proud of having a unique definition of engineering design because I believe it allows me to see a tiny bit further.
Engineering design is not about the product, it is about the production.
Engineering Design Process
To attain define a problem is attain a deep, multi-layered understanding of the problem and all its components.
a. Identify the Problem
The first step to solving a problem is to know what problem has to be solved and this is important because in my experience, the problem is often separate from the client’s description of the problem. Identifying the real problem is vital and often non-intuitive because of the existence of common cause factors and root cause factors. A common cause has multiple effects and one of those effects causes problems for a client and needs to be stopped. A false relationship can be mistakenly created between two effects rather than the real cause and the effect that is troubling the client; we mistake one of the effects as the cause of the problem (because they appear to be positively correlated). This leads to wasted time and effort on solutions that address stopping the side-effect instead of the actual cause. In a similar fashion, problems can have superficial causes, but it can turn out that the superficial cause is itself created by a root cause. Phrased another way, an underlying cause has an effect that causes the effect that is problematic for the client (different from common cause where the root cause directly causes the problem effecting the client). This scenario is often much more difficult to analyze and overcome. But in both scenarios by addressing the root cause and the main problem can be more directly and often more permanently addressed. This can only be done if the real problem is correctly identified. It is important to note that framing (discussed later) can change what is considered the ‘root cause’, and there can be multiple root causes. The definition of ‘root cause’ is simply the origin of the problem and it is by no means unique.
b. Identify the Stakeholders
Stakeholders are people whom the problem and any potential solution affects. A comprehensive list of stakeholders is written. Next the list is ordered in terms of priority and then by the magnitude of the effect the design will have on them. This prioritization is most often very similar if not the same, but it can sometimes have differences.
This step is vital because only through the list of stakeholders can a list of objectives, requirements and constraints can be compiled and refined. This is because to encompass the needs of the stakeholders, the stakeholders themselves must be known.
c. Objectives and Requirements
Using the list of stakeholders a finalized list of objectives and constraints can be written down. It is important to note that this list is heavily derived from the list of objectives and constraints provided by the client but after a full understanding of the problem, tweaked by the engineering team to fit true needs. The list of final objectives is almost never changed unless it is actually appended to. The only thing typically modified is the list of constraints whose components are either rewritten using realistic caps or new and more effective metrics. This final list of objectives and requirements is typically permanent because they address the core purpose of the solution. It is important to note that this is done early and should not be done before conceptualizing solutions as to not pollute the list to favor pre-conceived notions of possible solutions.
To frame is to view a problem through a particular perspective. For example, the problem a client may arrive with is “lower the number of casualties caused by car accidents.” Assuming that the original problem is identified as the client’s description (too many casualties), the problem may be ‘framed’ in terms of protecting drivers or protecting pedestrians. With respect to drivers it can be further divided to reinforcing cars or training better drivers. In each of these ‘frames’ the root cause being addressed changes: ‘cars do not have enough safety features like seat-belts’ or ‘driving certification is too easy’ (note that these are examples: research would be required).
e. Research Similar Problems, Attempted Solutions and Reference Designs
One of my favorite quotes is:
“Only a fool learns from his own mistakes. The wise man learns from the mistakes of others”
― Otto von Bismarck
I would only rephrase this to: a typical man learns from his own mistakes (being the behavioral and therefore trainable animal that he is). An engineer will seek to learn from the mistake of others before imparting on well calculated risks.
Researching similar problems and attempted solutions provides insight in identifying the nature of the problem. Even if only some of their features, successful solutions have the capacity to be adapted to specialized solutions for the client. More importantly, by analyzing where the failed solutions fell short, a failed solution can provide valuable insight about the root cause and what the client truly needs (and why the failed solution did not meet their requirements). Finally, this also avoids repetition of failed solutions which only serves to waste time and effort. The only caveat is care should be taken as to not pollute creative thinking with preset notions of solutions.
The conceptualize step is where solutions are created based on the framing and using conceptualization techniques. In this section I will present the three methods I found most effective.
This is a creative tool aimed to address the potential deficiencies of brainstorming. The biggest problem with brainstorming is that the thought-processes of individuals are polluted by other ideas. Secondly, there is often more listening than thinking. During brainwriting, each member of a team isolates him or herself for approximately twenty minutes and they independently think of solutions. At the end of twenty minutes the team gets together and each member takes a turn presenting his or her solutions. I am a strong believer that a person is much more productive and creative when he works alone, however; he has a bias to his own solutions. In this way, the team is much stronger in analyzing and critiquing.
Wishing expands thinking. The idea is to think of fantastical and completely impractical solutions that would be really nice and convenient. ‘I wish’…’Wouldn’t it be nice if..?” The idea is to open up the box so that pre-set constraints in the mind do not limit imagination to possible solutions. After ‘wishing’ the idea is to try to make the wish practical and I personally found it surprising how easy it can be.
c. Re-definition and Challenge Assumptions
The idea of this exercise is to break imagined constraints we often impose on ourselves. Each time you find yourself saying, ‘well it has to be that…’, or ‘obviously…’, or ‘but that is getting in the way,’ ask why. Why does that even have to be there? Ask “what if?”
3. Critique and Compare
a. Conceptual Analysis
This step involves analyzing the solutions to the requirements previously set. It is done for every single conceived solution no matter how ludicrous. They are compared against each other and against the reference designs using a variety of tools like the Pugh Chart or Comparison Matrix. This form of analysis brings out infeasibilities of the solutions (not a bad thing). More importantly, I find this step very vital for two reasons: First, it reveals why solutions (which features) are good or bad. Second, it breaks expectations and intuitions of good solutions. For example, during the Praxis Concept Design Project, it was only after Pugh comparison that my group saw how bothersome and tedious our heavily favored solution was. We were temporarily mesmerized by the fact that it was extremely effective at solving the problem and forgot our core engineering design definition of simplicity and usability. This process forces detailed investigation and comparison of solutions with requirements instead of skimming over it.
Prototypes come in three types: low, medium and high fidelity, and each prototype has a purpose. The purpose of prototypes is to model a feature or multiple features so that they can be directly observed through one or more of our five senses. I believe that prototypes are very important in a full analysis of a solution because certain features can only be properly evaluated via the senses. For example, the ergonomics of a design absolutely required a physical prototype. But prototypes of solutions can be costly. Solutions are only prototyped past low fidelity if they show merit after the conceptual analysis (however, low fidelity quick prototypes made by a team member to show his or her idea is okay and encouraged)! Prototypes are created in increasing fidelity as the iteration loop progresses, as per my engineering design process showed in the figure. High fidelity prototypes that closely resemble the end product are only created near the end of the loop.
During the iterate step, solutions are improved and expanded upon. The previous step laid the foundation and exposed the weaknesses of solutions. Here, the same conceptualization techniques are used to expand and strengthen or create new solutions with this new enlightenment. Options to make infeasible solutions (which would be great otherwise) feasible can be explored. The most effective part of this step for me was to combine solutions. The critique and compare step showed which features are good and which were bad. This step can be used to delete bad features and bring together the strengths of each solution and this can be either great or very bad. As mentioned previously, the iteration step is really just a reversion to the conceptualization step. During each iteration, some solutions are dropped. By the end of this loop, one solution remains.
6. Test and Refine
After the iteration loop where each design was harshly critiqued and compared, a single design emerges as ‘the design.’ Each member of the team works on refining the design’s features and details. Detailed design reports are made describing every single detail including material selection, forming and manufacturing processes selections, aesthetics and color selection, down to screw and bolt selection. Numerous medium fidelity prototypes are created depicting specifics of ‘the design’ and the numerous options. In addition near the end very high fidelity prototypes are created. Similar to a ‘dress rehearsal’ these prototypes are effectively the end product and have the capacity to become the final model for the final production. After a battery of tests the prototype is finalized as the end design.