I performed some testing over a year ago. I know I have a digital copy of the test results somewhere. But of course I can’t find them. I remember presenting them, having them up on a projector and discussing them. But now search as I might they’re nowhere. I dig into a project folder and there, thankfully, my original chicken scratch handwriting on the original test record. Keeping around that piece of paper just saved my bacon.
But what’s that have to do with a successful design? While hunting around for this elusive information I happened upon a handout that another engineer had given me. It might be written towards students or it might be written towards entry level engineering I’m not sure. It sort of reminds me of those little fact sheets and checklists that before we might have sent around the office via fax. Somehow they never made it to the email medium, everyone just has a hardcopy lying around and it becomes tribal knowledge.
Getting even a good design through the powers that be can be difficult. Fail to include something and you and your design get ripped apart. Tread on someone else’s product territory and you’re gone.
So I thought it would be interesting to repeat some of the good advice (paraphrased slightly) from this handout.
- Who has a vested interest in the design details, in the solution, and in the problem. Are they on your side?
- Who is presenting the problem, are they experienced enough that they understand what it really is? Don’t go about working on a solution for the wrong problem.
- Start with (1) objective (2) constraints and (3) assumptions.
- Do not be paralyzed about what you do not know.
- Are people’s expectations of the potential solution realistic?
- Are your layouts, details, views and cross-sections clear?
- Always start with the interior of your component, the housing is always finalized after the internals are complete.
- Be ready to look critically at your design in the way those who will be reviewing and approving it will. Try to answer the questions they will ask before you see them.
- Perform easy stress calcs while doing the layout, save the final stress analysis, heat treatment and material selection for once you are in the details of design.
All this got me thinking about a boss who had once said his criteria for signing off on a design was how confident the person was who presented it to him. I guess he used that as a baseline for whether the engineer had truly vetted their solution. This seems counterintuitive to me, as I’m sure confidence can be faked (or ignorance can be seen as confidence). But on the other hand, a good design should result in confidence. What do you think? What is your design process and what are your strategies for presenting them to the stakeholders?

Everybody likes being right and comes to the table with their own agenda. Doubly so in design reviews. Be prepared to defend your position and know your design well.
Great blog. Every technical team thinks that they can make anything work. That is the inert nature of an engineer. But, you need to remember that there are multiple parts of a good design. One is the technical aspect where you deal with the stresses, deflection, etc.
Another part is the financial one. Can you design, build it, assemble it, and test it for what you say it should cost? This is usually the one that is the biggest unknown especially for cutting edge technology.
What it cost to put together a working prototype really has no bearing on what it cost to design a production version of a piece of equipment. This is something that upper management really needs to understand.
Also, quantity and complexity of the design has alot to do with it. Designing a wigit for the automotive industry is much different that designing a wigit for the space shuttle. Designing for low quantities and unusual circumstances does limit you to the type of fabrication and assembly techniques you can afford to use.
A checklist is one way of making sure that you’ve crossed your “t” and dotted your “i”. I always liked to have a mini-design review before the real one. It doesn’t have to be anything formal, a review by several of your peers within and outside of your department (e.g. machine shop, etc) have saved my butt many a time.
Someone once told me that “you don’t know everything”. How true he was.
[...] the end use — In my case, I found myself thinking, “We are not process engineers, we are product designers!’ This is not always the case and there are some people that would love hearing about the [...]
[...] Do you test or retest changes to a product or process to ensure the problem is truly fixed? Or do you confidently declare that the design change was properly analyzed and that there will be no problems that will affect [...]