設計者が設計した内容は「レビュー」「チェック」「承認」をする必要があります。以下で詳しく説明します。
レビュー
製品設計プロセスの中で作成されるアウトプットの一部（要求仕様書、詳細設計書、ＦＭＥＡ 等）を社内専門家がレビューする。
＜「レビュー」する目的＞
・設計のフロントローディング
⇒自社の英知を結集し上流工程で不具合をつぶし込む。そのためには関連技術の自社専門家（最も知識・経験のある人）がレビュアーになる必要がある。
・技術の高度化／複雑化
⇒一人の設計者ができることは限られている。違った側面から見ることにより担当設計者が気付かなかった不具合を抽出できる。
・設計精度の向上
⇒人に説明可能な（論理矛盾のない）設計にするように設計者に促すことができる。
・設計情報の文書化促進
⇒人に説明するために文書化することを設計者に促すことができる。設計情報を暗黙知化すると設計資産が増えない。
＜レビュー担当者（レビュアー）＞
部署によらず、参加可能な関連技術の自社専門家。
レビューに関しては多くの企業で以下のような問題を抱えている。
・レビュアーが効果的な技術的指摘ができず、設計者の仕事を増やすだけになっている。
・レビュアーの適任者は多忙であり会議への参加率が低い。
・設計者が効果的なレビューをしてもらえるような資料準備をしていない。
効果的なレビューができることが、製品設計プロセスを効率的に運用するベースとなります。レビューの仕組み（工夫された会議、帳票など）づくりと設計者、レビュアー両方の人材育成が重要です。
チェック
製品設計プロセスの中で作成されるアウトプットのすべて（要求仕様書、詳細設計書、ＦＭＥＡ、図面 等）をチェックする。
＜「チェック」する目的＞
・ヒューマンエラーの防止
⇒設計者のポカミスを未然防止し、後工程での手戻りや製品不具合を減らす。
・設計における不正防止
⇒不正ができない仕組みを作っておくことが不正防止の有効手段となる。
＜チェック担当者（チェッカー）＞
設計部門の直属の上司、品質保証部門の担当者など。自社の実情に合わせて設定する。
図面のチェック（検図）だけでは不十分です。また、「チェック」と「承認」は区別して考える必要があります。非常に負荷が掛かるように見えますが、後工程で不具合が発見された場合は、チェック負荷の何倍にもなって跳ね返ってくることを認識すべきです。
承認
製品設計プロセスの中で作成されるアウトプットのすべて（要求仕様書、詳細設計書、ＦＭＥＡ、図面 等）を承認する。設計のどの内容を組織のどの階層が承認するかを明確にすることが、製品設計プロセスを効率的に運用するポイントとなる。
階層別「承認」の事例
・アウトプットの一次承認⇒設計部門責任者（および品質保証部門担当者）
・上記一次承認項目のうち判断に迷ったもの⇒品質保証部門責任者
・品質保証部門責任者が判断に迷ったもの・安全性に関わるもの・コスト・開発リードタイム⇒社長
承認の階層を決めない場合、設計者は例えば要求仕様書の段階で直属の上司が承認したと考えていたのに、デザインレビューで社長に説明すると承認されなかったといったことが頻繁に起こります。デザインレビューの段階から要求仕様書の段階まで差し戻されることは非常に非効率ですし、設計者のモチベーションも大きく低下してしまいます。社長が承認すべき重要な内容であるならば、要求仕様書の段階で社長が判断するような仕組みにしておくことが望ましいと思います。逆に社長が承認する必要のないレベルの内容であれば、デザインレビューで議題にする必要すらありません。すべての内容の承認者を細かく決めることはまず不可能ですが、大まかな枠組みを決めることにより製品設計プロセスをスムーズに進めることができます。