DFMEA: finding failure modes on paper, before they show up in the field

What DFMEA is

Design Failure Mode and Effects Analysis is a structured way of asking, for every function a product needs to perform, "how could this fail, and how bad would it be if it did," while the design is still open to change. For each function, the team identifies potential failure modes, the effects those failures would have on the end user or the next level of assembly, and the underlying causes rooted in the design itself: geometry, material choice, tolerances, or interfaces between parts.

DFMEA asks how the product could fail in the hands of a user; its counterpart, PFMEA, asks how the process that builds the product could fail. The two are sequential, not competing: a design characteristic the DFMEA flags as high-severity should hand off directly into the PFMEA as a process step that needs tighter control, since the process is often the mechanism by which a design weakness actually becomes a field failure.

Like PFMEA, current DFMEA practice generally follows the AIAG-VDA FMEA Handbook's seven-step structure, and it's an explicit expectation in most medical device design controls, referenced directly in risk management frameworks like ISO 14971.

DFMEA vs. PFMEA at a glance

The steps of a DFMEA

1. Planning and preparationDefine the system boundary: is this a component-level, subsystem-level, or full-product DFMEA. Gather block diagrams, requirements, and any known field history from similar designs.
2. Structure analysisBreak the product into its physical hierarchy: system, subsystem, component, down to the interfaces between them. Interfaces are where a disproportionate share of real failure modes live.
3. Function analysisState what each element must do in measurable terms, tied to a requirement. "Maintain electrical contact under 2 N spring force across 10,000 cycles" is analyzable; "make contact" is not.
4. Failure analysisFor each function, identify the failure mode (how it could fail to perform), the effect (what happens to the user or the next assembly level), and the cause, traced to a specific design element.
5. Risk analysisScore severity, occurrence, and detection. For DFMEA, occurrence draws on field history and physics-of-failure reasoning rather than production data, and detection reflects design verification methods: FEA, HALT, bench test, not inspection.
6. OptimizationAssign design changes that reduce risk: added margin, a more robust material, a geometry change, rather than relying on downstream testing to catch what a more robust design would have prevented.
7. Results documentationRecord the analysis so it flows into verification planning and, critically, into the PFMEA for any characteristic flagged as high-severity.

Worked example: battery contact spring fatigue

The action here targets the cause, material fatigue limit, rather than just adding an inspection step that would only catch a spring that had already degraded. That's the pattern a DFMEA should produce: a design change that removes the failure mode, with verification testing added to confirm the change actually worked, not as a substitute for it.

Common DFMEA mistakes

• Running it too late. A DFMEA done after layout or tooling is committed can usually only recommend testing around a risk, not designing it out.
• Scoring occurrence optimistically. Without real field or test data, occurrence estimates default to hope. Anchor them to similar past designs wherever possible.
• Confusing detection with prevention. A strong test plan doesn't lower the underlying failure rate, it only improves the odds of catching a failure before it ships. Both matter, but they aren't interchangeable.
• Not handing high-severity items to the PFMEA team. A design characteristic flagged as critical needs to become a controlled process characteristic downstream, not just a note in a design review.

Frequently asked questions