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.
Independent (approximate) components of the problem that can be addressed individually.
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.
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.
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.
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.
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.
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.
- 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
- 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
- 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
- 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
- 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)
- 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
- 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?
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 , and many educational sites  .
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.
 Teach Engineering, (n.a.). Engineering Design Process [Online]. Available: http://www.teachengineering.org/engrdesignprocess.php
 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/
 Abelson H. and Sussman J. G., Structure and Interpretation of Computer Programs [Online]. Available: http://mitpress.mit.edu/sicp/full-text/book/book.html