Ad hoc describes a process not planned and can be an adequate description of how some hardware designers and electrical engineer’s work. To some, this might sound a little scary or a little too free form because you aren’t using a clearly defined and planned approach. Without a structured design approach, how can you be sure you will arrive at workable solutions? How can we be sure the whole process doesn’t devolve into chaos?
The truth is an ad-hoc design process has merit. Many designers and engineers will use this type of process to get them unstuck when confronted with a problem. However, when is it more advantageous to adopt an ad-hoc design process versus a structured approach? Before we can decide, it’s important to understand the benefits and drawbacks of using either in our own work.
The structured design process has 5 main phases:
- Problem Analysis
- Problem Modeling/Design
- Development on that Design or Model
- Testing & Documentation
- Product Deployment
Within each of these main phases, we have many steps to accomplish, which takes a lot of time, knowledge, and experience. Our blog post, The Product Design Process, discusses this in further detail.
Mastering all phases and their steps will give you more flexibility in how you build products. The more structured and skilled you are at product design, the more you can take an ad-hoc approach and still deliver high-quality results in the same (or even shorter) time frame.
The Ad-Hoc Design Process: An Invaluable Skill in Your Toolkit
An ad hoc approach responds to the realities of product design. Rarely within your work as a hardware designer or electrical engineer will you be given a comprehensive set of system requirements and constraints needed to design a product. Thus, having the ability to switch to an ad hoc design style is necessary. Doing so means you can adapt, amend, and adopt elements of it to suit your purpose.
Believe it or not, an ad hoc approach does use a structure, however its structure isn’t pre-determined. This allows for more flexibility throughout the design process, especially if you happen to be working on a poorly defined task, or don’t have specified requirements and constraints. While it is never advisable to allow the overall design process to be completely ad hoc, implementing this approach when confronted with a singular problem (or series of related problems) within the overall design process will help you quickly find workable solutions; allowing you to fill in the missing details as you go.
Understanding the different stages of inception, design, development, testing, and deployment inside and out, backwards, and forwards is crucial. This will help you adjust on the fly to determine the processes and specify the criteria required “for this moment”. Knowing how to work in an ad hoc way is an invaluable skill to have in your toolkit as a designer or engineer as it allows you to easily move forward and find workable solutions when faced with design problems.
Disadvantages of an Ad-Hoc Approach
Forgoing a formal design process in favor of an ad-hoc approach can result in important steps being ignored or missed entirely. In addition, documentation can take a back seat, and time and budget constraints can be exceeded. The beauty of adhering to a structured design process ensures the different phases of the design process are carried out in full. This will help ensure requirements and constraints of the project are adhered to and don’t go down expensive side-tracks.
While it has its benefits, you must be careful this fly-by-the-seat-of-your-pants style does not spill over into multiple phases. The ad-hoc approach does not scale well when larger teams of people are involved in the design process. For instance, improvising too much on standard design phases like testing and documentation, may make the client dissatisfied and it would be almost impossible for others to review and evaluate your work. Others will have a hard time deciding the next actions required or checking requirement coverage. This is despite the recent trend within the software design industry toward no testing and no documentation. However, this is not an advisable move if you are working within a multiple team environment as an electrical engineer or hardware designer.
Conclusion
As designers and engineers, we need an in depth understanding of the structured design process. We also need to know how to do away with it as different situations might warrant. Both the structured design process as well as an ad hoc approach should be used in conjunction with one another. The trick is using the approach that will yield the best outcome for the project.
A maxim in electronics engineering is the longer it takes to find problems, the more they cost to fix. The beauty of knowing how, when, and why to use an ad-hoc design approach is it helps get you unjammed and identify issues quickly to avoid further snowballing of design problems.
