A Design FMEA (DFMEA) is a structured analysis of how a product's design could fail to perform its function, done while the design is still on paper. The team lists each function, the ways it could fail, the effects and causes of each failure, and ranks the risk so the worst failure modes get designed out before anything is built.
The word that matters is design. A DFMEA studies the product itself, its geometry, material, tolerances, and how its parts interact, and asks whether the thing as drawn can fail even when it is made perfectly. That is a different question from whether the factory can build it consistently, which is what a Process FMEA (PFMEA) covers. The two are siblings that examine the same product from opposite sides, and confusing them is the most common FMEA mistake on a launch.
What is a Design FMEA?
Failure Mode and Effects Analysis is a step-by-step method for identifying every way a design, process, or product could fail, and it was begun by the U.S. military in the 1940s before spreading to aerospace and the auto industry (ASQ, Failure Mode and Effects Analysis). A Design FMEA applies that method to the product design. The team works function by function: for each thing the product is supposed to do, they ask how that function could fail, what happens when it does (the effect), what in the design would cause it (the cause), and how likely the design is to let it happen and to catch it before shipping.
The reason to do this on paper is leverage. A weakness found in a DFMEA costs a tolerance change or a material swap; the same weakness found after tooling is cut costs a redesign, and found in the field it costs a recall. DFMEA is a core tool of Design for Six Sigma for exactly that reason: it is how you hunt failure modes while they are still cheap to remove, and it slots naturally into the Analyze and Design phases of a DMADV project.
How is a Design FMEA different from a Process FMEA?
This is the distinction that trips up most launches, so it is worth being precise. A DFMEA and a PFMEA share a method and a worksheet but analyze different things, are owned by different people, and produce different kinds of fixes.
| Dimension | Design FMEA (DFMEA) | Process FMEA (PFMEA) |
|---|---|---|
| Subject | The product design itself | The manufacturing and assembly process |
| Question | Can the design fail even if built perfectly? | Can the process fail to build the design correctly? |
| Failure mode example | Bracket cracks under rated load | Weld skipped or bolt under-torqued at station 4 |
| Typical owner | Design or product engineering | Manufacturing or process engineering |
| Typical fix | Change geometry, material, or tolerance | Add mistake-proofing, change setup, add a check |
| When | Early, during design | After the design freezes, during process planning |
Two practical consequences follow. First, a design flaw cannot be fixed at the PFMEA stage; if the bracket is too thin, no amount of careful welding saves it, and the DFMEA is the only place that catches it in time. Second, the two are not interchangeable, and a plant that runs only a PFMEA is quietly assuming the design is flawless, which no design is.
How do you build a Design FMEA?
The current automotive reference, the AIAG-VDA FMEA Handbook published jointly in June 2019, lays out a seven-step approach. Written plainly for a design team, the flow is this.
- Plan and prepare. Set the scope: which product, which boundaries, what is in and out. Assemble a cross-functional team, because the person who designed it is the worst judge of how it fails.
- Analyze the structure. Break the design into its parts and interfaces, so the analysis has a map. Many failure modes live at the interfaces between components, not inside them.
- Analyze the functions. For each element, state what it is supposed to do, in measurable terms. You cannot list failures of a function you have not clearly defined.
- Analyze the failures. For each function, ask how it could fail (loss of function, degraded function, intermittent function, partial function, or unintended function), then trace the effect of that failure and the design cause behind it. A fishbone diagram helps the team surface causes they would otherwise miss.
- Analyze the risk. Rate each failure mode on Severity (how bad the effect), Occurrence (how likely the cause), and Detection (how likely current design controls catch it before release), each on a 1-to-10 scale, then set an Action Priority.
- Optimize. For the high-priority failure modes, take action: change the design to lower severity or occurrence, or add controls to improve detection. Re-rate after the change to confirm the risk actually dropped.
- Document the results. Record the analysis, the actions, and the residual risk, and carry the confirmed design controls forward so they inform the Process FMEA and the eventual control plan.
How is risk scored, and what replaced the RPN?
For decades, FMEA teams multiplied the three ratings, Severity times Occurrence times Detection, into a Risk Priority Number (RPN) from 1 to 1,000, and chased the biggest numbers. The 2019 AIAG-VDA handbook replaced the RPN with Action Priority (AP), which sorts each failure mode into High, Medium, or Low priority using a lookup table rather than a single multiplied score (AIAG & VDA FMEA Handbook).
The change fixed a real flaw. RPN treated all three factors as equal, so a low-severity nuisance with high occurrence could outscore a safety-critical failure that was rare, sending teams to work on the wrong thing. Action Priority weights severity first, which matches how engineers actually should triage: a failure that hurts someone deserves attention even if it is unlikely. If you learned FMEA on RPN, the mechanics of Severity, Occurrence, and Detection are unchanged; only the way you combine them into a priority is different.
How do DFMEA and PFMEA hand off in a new-product launch?
The two FMEAs are not parallel documents that ignore each other; they are a relay. The DFMEA runs first, during design, and its outputs become inputs to the PFMEA. Specifically, a design characteristic that the DFMEA marks as critical, a tolerance the product cannot function without, becomes a "special characteristic" that the PFMEA must guarantee the process can hold, and later a checkpoint in the control plan the floor runs every shift.
That handoff is where launches succeed or leak. The DFMEA says "this weld must hold 500 newtons or the bracket fails," and hands that requirement to the PFMEA, which asks "how could our welding process fail to deliver 500 newtons?" and designs the fixture, the mistake-proofing and the inspection to prevent it. If the relay breaks, if the DFMEA's critical characteristics never reach the PFMEA team, the plant ends up controlling the wrong dimensions tightly and the important one loosely. A clean handoff is also what feeds the corrective action loop later: when a field failure traces back to a failure mode the DFMEA already listed, you know exactly where the analysis fell short.
Where does a Design FMEA go wrong?
The failure modes of the tool itself are consistent.
- Done too late. A DFMEA started after the design is frozen is a compliance document, not a risk tool. The leverage is gone once the geometry is locked.
- The designer grades their own homework. Without a cross-functional team, the analysis inherits the same blind spots that created the risk. Bring in manufacturing, quality, and service.
- Chasing RPN math instead of severity. Teams still trained on RPN can bury a dangerous, rare failure under a pile of high-occurrence nuisances. Action Priority exists to prevent exactly this.
- No action on high priority. A ranked list nobody acts on is worse than no list, because it documents that you knew. Every high-priority mode needs an owner and a due date.
- Broken handoff to the PFMEA. Critical characteristics that never reach the process team mean the floor guards the wrong things. The relay is the whole point.
How does a DFMEA connect to your plant floor?
A DFMEA is a live document, not a launch artifact you file and forget. Its value compounds only if the critical characteristics it identifies actually travel to the floor and the field failures that occur actually travel back. On most sites that loop is broken by paper: the DFMEA lives in an engineering folder, the control plan lives on a laminated sheet, and the defect data lives in yet another spreadsheet, so nobody can connect a field failure to the design analysis that should have caught it. Harmony closes that loop by digitizing station-level capture so the checks tied to a DFMEA's critical characteristics are captured as structured, timestamped data, and a defect on the floor can be traced straight back to the failure mode and the design intent behind it. That traceability is what keeps a DFMEA honest and shrinks the cost of quality it exists to prevent. See how digitizing the floor first plays out in the CLS case study. Run the DFMEA early, hand its critical characteristics cleanly to the process, and keep the loop closed. No rip-and-replace.