Engineering Process


Problem

Problem Understanding

Map out the causes and impacts of the problem as well as who it affects. Dig into research to really understand the cycle of influences.

Component
2

Problem module

Independent (approximate) components of the problem that can be addressed individually.


Prototype

Rapid prototyping

Test out the practicality of the proposed solution by actually making it. This filters out the concepts that are sound in theory but are impractical in actuality.

Functional decomposition

Simplify and approximate the problem cycle into a linear cause-and-effect model. Then treat each cause of the problem as a component, decomposing that down as much as possible.

Monomaniacal design

Generate specialized solutions for each component without worrying too much about holistic effectiveness.

Compare and select

For each component, select a few specialized solutions that are interesting, which encourages creative solutions as opposed to just selecting the most obvious and "effective" ones.

Create combinations

Combine the prospective component solutions by taking compatible and strong aspects of each solution. Keep these combined solutions in the solution pool for future iterations.

Compare and select

Select the best suited solution from the pool, judging based on the requirements and my own principles.

Solution Pool

An essential part of my design process is keeping my options open and solutions creative by holding onto solutions that didn't quite make the selection process but still has interesting components. These could be modified to be compatible with the solution in future iterations.

Tools Handbook

Basis of selection & refinement

The requirements of the stakeholders and my own design principles are the criteria for selection and refinement. The stakeholders are those who are affected by the problem, explored while understanding the problem.

  1. Understand problem

    • Consider the causes and impacts of problem to give basis for reframing
      • Physically reconstruct problem then apply physics models to analyze problem factors
      • Research literature relevant to problem
      • Set initial constraints and objectives to guide solution generation
    • Determine key stakeholders
      • who will use the solution
      • who will the use of the solution effect
      • who will produce the solution

  2. Break problem down to its components - what needs to be done?

    • Pick as independent components as you can (ex. drawing a picture --> outlining, colouring)
    • Keep breaking it down until the components are as independent and easy to approach as necessary

  3. Generate specialized solutions for each component problem (monomaniacal design)

    • Relate problem to one solved in nature (biomimicry)
    • Consider what can provide forces if something needs to be moved
    • Consider buckling or bending to fold something
    • Consider friction to hold two things together but still allow for lateral shearing
    • Keep all solutions inside the solution pool; no elimination as revision might use a previously rejected solution

  4. Compare solutions based on my principles, adjusted for what the context demands

    • Use Pugh chart for performance comparison
    • Use simple comparison matrix for general appeal
    • Don't be afraid to challenge stakeholder requirements if they haven't understood the problem

  5. Combine component solutions

    • Keep unused components inside solution pool, key to making the solution robust
    • Switch components if the requirements or environment changes (ex. now needs to operate in a corrosive environment)

  6. Prototype - allows better understanding of solution and possible issues with design

    • Have at least one purpose
      • Prove and communicate concept
      • Communicate shape and appearance
      • Demonstrate feasibility
      • Show functionality
    • Prototype is ideally physical, to scale, and functional
    • Start with conceptual drawings by hand or with Inkscape

  7. Refine solutions

    • Can one part perform multiple functions?
      • Can structural elements also become functional ones?
      • How will the user interact with it?
      • How will it be stored and cleaned?
      • How long do I have to spend explaining how to use it and what it does?

  8. Refine understanding of the problem at each step and adjust solutions accordingly

With experience, I found some tools helpful in progressing through each step, and their description and use are covered in the Tools Handbook

Analysis of Process

My process is characterized by being cyclical and by heavily relying on functional decomposition.

From experience, multiple iterations generally increase quality through integrating component solutions better, finding new component solutions, and addressing flaws found in the previous iteration. Cyclic design processes are also the norm in industry, promoted by NASA [1], and many educational sites [2] [3].

My prevalent use of functional decomposition distinguishes my design process from many others. It has proved very useful in promoting modular solutions, which in turn tend to be more robust and easily changeable. The solution can be changed by simply swapping in a different component solution without requiring change in other components, making multiple iterations more productive as less backtracking is done. This approach does not seem to be as prevalent as cyclic design in industry, since all the sources above present a single-branch approach, directly creating solutions for the entire problem. While that might be faster (allowing time for more iterations) than my multi-branch approach - generating component solutions for each part of the problem - I believe my approach requires less iterations to produce a quality product.

The keeping of a solution pool also distinguishes my personal design process. Its purpose is to allow effective responses to small changes in the problem. An analogy is the caching of websites - remaining on the same site (overall problem) will result in your browser caching site resources such as css, javascript, and images, so that switching to another page (small change to problem) will be fast and efficient, directly loading the resources from cache rather than the expensive route of downloading them again. This idea of solving a class of problems rather than a particular problem makes my solutions robust, and is endorsed by computer science giants such as Hal Abelson and Gerald Jay Sussman [4].

References

[1] NASA, (2008, Feb 7). Engineering Design Process [Online]. Available: http://www.nasa.gov/audience/foreducators/plantgrowth/reference/Eng_Design_5-12.html
[2] Teach Engineering, (n.a.). Engineering Design Process [Online]. Available: http://www.teachengineering.org/engrdesignprocess.php
[3] PBS, (2008, Feb 7). What Is the Design Process? [Online]. Available: http://www.pbslearningmedia.org/resource/phy03.sci.engin.design.desprocess/what-is-the-design-process/
[4] Abelson H. and Sussman J. G., Structure and Interpretation of Computer Programs [Online]. Available: http://mitpress.mit.edu/sicp/full-text/book/book.html