Design Education

I am currently (Spring semester 2009) a teaching assistant at Georgia Tech for ME 2110, “Creative Decisions and Design.”  It is the Mechanical Engineering Department’s flagship sophomore design class.  It’s been fun to help teach this class because–duh–I enjoy the content: design engineering.  Taking ME 6101, the graduate level “Engineering Design” class in the fall of 2008, gave me a whole new perspective on design education, and really taught me to see the relationship between my interest in philosophy and design itself.  Design is ultimately a journey of epistemology–proceeding from the abstract to the specific.  Understanding how your brain works by having a good grasp of the process of concept formation gives you a strong sense of how to use your mind to effectively design a successful product.

My students recently submitted a set of reports.  They were pretty terrible for the most part.  I saw how so many of their problems could be traced to slovenly epistemology and lack of clear thinking, foggy problem definition,  and an amorphous grasp of the purpose of the design tools they were supposed to use (or maybe it was just laziness on their part–hopefully not though).  I chose to send them an email about my thoughts on epistemology, and tried to frame a discussion on an abstract philosophical topic in terms and examples which they could hopefully see relating directly to their design/build/test project, while also trying to justify to them why it’s in their own self interest to understand this seemingly unrelated topic.  Here is that email:

Students of Section B,

I notice a disturbing trend which is:
 
A) costing me time when I grade,
B) indicates you aren’t thinking as clearly as you could about the topics in the report, and thus:
C) that your design development could be currently sub-par.
 
…  All of which are naughty.
 
These problems and the disturbing phenomenon which they define can be traced to slovenly epistemology–i.e., sloppy thinking.  What is epistemology?  It is a branch of philosophy; it’s the investigation of how people think and how our ideas can be regarded as valid.  In layman’s terms it is ‘thinking about thinking.’  In a moment, I will use an example to help me illustrate why “epistemology / knowing how your brain works” is important for this class–and beyond.  After all, it is generally acknowledged–and can be proven–that in order to succeed you have to think.  Since it is also generally acknowledged that your brain does most of your thinking, it pays dividends to know how your brain works.  Epistemology is basically the user’s manual for your brain, and getting to know that manual enables clear thinking and the greater success which clear thinking allows.
 
Here is the example I mentioned…  Consider the following list:
 
1) Your Dad’s Lazy Boy in the Living Room
 
2) “Chair”
 
3) “Furniture”
 
What do these things have in common?  They represent progressively abstract conceptual definitions of physical entities.  See how this is true:
 
Your Dad’s Lazy Boy in the Living Room: a specific and concrete entity, which is sitting in your living room.
 
Chair: a concept–a mental unit composed of several characteristics which, when these characteristics are observed in a physical entity, will then cause you to define that entity as ‘a chair.’  So, the previous listed item, ‘Your Dad’s Lazy Boy,’ is just one particular instantiation of the concept ‘Chair,’ because it has the characteristics which you define a chair by.
 
Furniture: a concept which is one level more abstract than the concept of ‘chair.’  ‘Furniture’ is a conceptual unit which groups and classifies concepts themselves together by their similar characteristics…  The concept ‘Chair’ (and the concept of ‘Table’…  and ‘Couch’…  etc..) is just one instantiation of the concept of ‘Furniture.’
 
Now, because we are dealing with physical entities in this mechanical engineering class, the “Lazy Boy –> Chair –> Furniture Spectrum of Abstraction” serves as a good example to illustrate what we are doing in this class: design. 
 
In design, we are essentially proceeding from the abstract to the specific.  Particularly: from the abstract problem definition to a specific machine which solves that problem.  Because design is iterative, it also will probably involve quite a bit of moving in the opposite direction as well: from concrete concepts back to the abstract guiding principles of your design project…  This will occur when a specific concept does not work, and you have to proceed back to the general problem definition to determine an alternative instantiation which might satisfy the problem requirements.
 
At the beginning of the design process (which is what this ‘planning’ report was supposed to represent), you are defining the broad, abstract boundaries of your machine by observing the competition rules, defining specification sheets with general numerical limitations for the device, and creating function trees which only include those functions which your team has deemed important to accomplish.
 
Now, here’s my beef: if your reports are any indication of what’s going on in your head w.r.t. your design progress, then they indicate to me that too many of you are getting fixated on specific and concrete solutions right now.  If this is the case, you are potentially losing the ability to see other promising concepts by not defining the problem at a more fundamental and abstract level, at this early stage of the design process.
 
Too often, I saw things like “retract arms” or “launch balls” in your function trees and the specification sheets.  This is way too specific for this stage of the design process.  By putting these things in your function tree or specification sheets, you are formally saying your machine has to have these features.  You are therefore limiting your machine’s ability to employ alternative, more promising concept designs.  Of course, design is an iterative process.  So, many of these early fixations hopefully, even necessarily, must be eliminated as new information comes to light.  As our professor put it when he was describing how he thinks the Segway engineers screwed up: “You don’t want to fixate on ‘TWO WHEELED TRANSPORTER’ early on.”  If you fixate on something silly early in the design process, you’ll end up with a dumb bum product.
 
Additionally, you guys really need to understand what defines the content of the rows/columns of the planning and design tools.  A “specification sheet” is comprised of numerical specifications.  A H.O.Q. has engineering requirements as column definitions (technical competencies which you can use to satisfy…), customer requirements as row definitions (non-technical wishes by the customer). 
 
I still see you guys putting things into these tools which do NOT fit the tool’s categories or purpose.
 
For example, people are putting non-numerical stuff in their specification sheets like “use mechatronics parts.”  “Using parts” is not a numerical performance specification, and therefore does not go in a specification sheet!  To put that in the context of the previous discussion, this would be like me asking you to give me an instantiation, a specific example, of the concept of ‘animal’ (corresponds to the “specification”) and you respond by saying LAMP (umm…  not related to the definition of “specifiction”).  COMPLETELY DIFFERENT CATEGORIES: UNRELATED CONCEPTS!!  Straighten out those definitions!  Clean up that epistemology!  And for God’s sake, don’t just fill up these design tools with baloney because I’m going to call shenanigans and grade you down for it.
 
 
– Justin