A design review should resolve a decision.

Name the decision

A design review works best when the team can state what will happen after it. Selecting a concept, releasing a test build and approving a production design are different decisions with different evidence needs.

Define that decision in a sentence, then list the requirements that determine it. This prevents an interesting but peripheral discussion from displacing the question the review was convened to answer.

Separate requirements from preferences

A requirement should have a clear source and a way to assess it. Preferences can guide tradeoffs, but they should not quietly become mandatory constraints. When two requirements conflict, make that conflict explicit rather than allowing each discipline to optimize a different interpretation.

For a motor, the review may need to distinguish peak capability, sustained capability, voltage and current limits, packaging and environmental conditions. A single rating rarely captures all of these.

Compare options on the same basis

An option can look superior because it was evaluated with more favorable cooling or control assumptions. Use a common comparison basis, and identify any assumption that cannot reasonably be shared.

Do not compress every tradeoff into one score too early. A short table of performance, constraints, uncertainties and implementation implications can show why the preferred option depends on the application.

Examine the evidence chain

For each consequential conclusion, ask where it comes from. A requirement should connect to an analysis or measurement, and that evidence should connect to a known configuration and set of conditions.

Distinguish predictions from measurements and observations from interpretations. A measured temperature is an observation. A claim about the cause of that temperature is an interpretation that may need additional evidence.

Prioritize what could change the outcome

Not every open question deserves equal attention. Focus first on uncertainty that could reverse the selection, prevent the required operation or invalidate a key assumption. A small discrepancy in a non-limiting region may be less consequential than an untested boundary condition.

A useful review action names the concern, its effect on the decision and the evidence needed to resolve it. Assigning only “investigate further” leaves the next team to rediscover the problem.

Close with a conditional decision when needed

Incomplete evidence does not always prevent progress. A team may proceed to a limited test build while keeping production approval open. The important point is to define the conditions and avoid presenting a narrow decision as a broader acceptance.

Capture the decision, its rationale, remaining conditions and responsibility for the next actions. That record becomes valuable when requirements or new measurements change the picture.