I might even say that it’s better to explore as much of the problem’s causal underpinnings as a first pass.
As a budding design engineer, one of the things that has been hammered into me is first to understand the problem in its wider context. Oftentimes just identifying a PROBLEM as opposed to a TASK is not enough: you need to understand the system that enabled the problem to exist. What aspect of the system is directly detrimental? Why is it detrimental? What features of the system influence that detrimental aspect? Why do those features exist in the first place? Can their core function be satisfied through a different principle of operation, or by restructuring the functions and flows of the system, or even by redefining your requirements?
Only once you understand the system holistically and identify functional requirements, causal structure, and your available tools can you really begin to accurately evaluate your options.
I might even say that it’s better to explore as much of the problem’s causal underpinnings as a first pass.
As a budding design engineer, one of the things that has been hammered into me is first to understand the problem in its wider context. Oftentimes just identifying a PROBLEM as opposed to a TASK is not enough: you need to understand the system that enabled the problem to exist. What aspect of the system is directly detrimental? Why is it detrimental? What features of the system influence that detrimental aspect? Why do those features exist in the first place? Can their core function be satisfied through a different principle of operation, or by restructuring the functions and flows of the system, or even by redefining your requirements?
Only once you understand the system holistically and identify functional requirements, causal structure, and your available tools can you really begin to accurately evaluate your options.