Systems Thinking

Trade-Off Analysis and Decision Matrices

How to compare design options against weighted criteria using a decision matrix, with a hand-checked example and notes on sensitivity and common pitfalls.

On this page
  1. Why trade-offs need a method
  2. Building a decision matrix
  3. A worked example
  4. Sensitivity: does the answer survive different weights?
  5. Common pitfalls
  6. Using the result

Why trade-offs need a method

Most real design choices involve conflicting goals. A material that is stronger may be heavier or costlier. A faster processor may use more power. A simpler design may be easier to build but harder to extend. There is rarely an option that wins on every criterion, so the question becomes which compromise best fits the situation.

A trade-off analysis makes that compromise explicit. The team lists the options, lists what matters, and compares the options against those criteria. A decision matrix is one common way to organise the comparison. It does not remove judgment. It structures the judgment so that it can be seen, discussed and revisited.

Building a decision matrix

  1. Define the decision. State what is being chosen, for example “the enclosure material for version one”.
  2. List the options. Include a realistic baseline, such as the current approach, and avoid listing choices that clearly fail a must-have requirement.
  3. Separate must-haves from preferences. Anything that is an absolute requirement, such as meeting a mandatory rule or a hard size limit, should screen options in or out before scoring. Scoring is for comparing options that already pass.
  4. Choose criteria. Pick the things that differentiate the options. Criteria that all options satisfy equally add no information. Fewer, clearer criteria usually work better than a long list.
  5. Assign weights. Give each criterion a number reflecting its importance. Weights are judgments and should be agreed with those affected by the decision.
  6. Score each option against each criterion on a consistent scale, such as 1 to 5, where a higher number is always better. Define what each score means.
  7. Multiply and sum. For each option, multiply each score by the criterion’s weight and add the results.
  8. Check and discuss the outcome before treating it as an answer.

A worked example

This example is an illustration with invented numbers. Suppose a team is choosing among three options for a small actuator: A, B and C. They agree on three criteria and weights that add to 10.

Criterion Weight
Cost 5
Reliability 3
Low mass 2

Scores from 1 (poor) to 5 (good), agreed after discussion:

Option Cost Reliability Low mass
A 4 3 5
B 3 5 3
C 5 2 2

Weighted totals (score x weight, summed):

  • Option A: 4 x 5 + 3 x 3 + 5 x 2 = 20 + 9 + 10 = 39
  • Option B: 3 x 5 + 5 x 3 + 3 x 2 = 15 + 15 + 6 = 36
  • Option C: 5 x 5 + 2 x 3 + 2 x 2 = 25 + 6 + 4 = 35

Dividing by the total weight of 10 gives averages of 3.9, 3.6 and 3.5. Option A ranks first, B second and C third. Notice that the gaps are small: a few points separate the three.

Sensitivity: does the answer survive different weights?

Because weights are opinions, a good habit is to test how much the result depends on them. Suppose that after further discussion someone argues that reliability should matter most, and the weights become cost 2, reliability 6 and low mass 2 (still totalling 10).

  • Option A: 4 x 2 + 3 x 6 + 5 x 2 = 8 + 18 + 10 = 36
  • Option B: 3 x 2 + 5 x 6 + 3 x 2 = 6 + 30 + 6 = 42
  • Option C: 5 x 2 + 2 x 6 + 2 x 2 = 10 + 12 + 4 = 26

Now B is clearly first. The ranking flipped because the weights changed, not because anything about the options did. That tells the team something useful: the decision hinges on how much reliability is valued relative to cost, so that is the question to resolve, perhaps with the people who will use or maintain the device, rather than arguing over the third decimal of a score.

Common pitfalls

  • False precision. Totals look exact, but they rest on rough scores. Treat small differences as ties, and avoid reporting results to several decimal places.
  • Double counting. Two criteria that measure nearly the same thing, such as “cost” and “price”, give that factor extra influence.
  • Hidden must-haves. If an option scores well overall but fails a must-have, it should not win. Screen first.
  • Inconsistent scales. Make sure higher is always better, including for criteria such as cost, where a low cost should receive a high score.
  • Scores added after the fact. If people adjust weights until their preferred option wins, the matrix only decorates a decision already made. Agree weights before scoring.
  • Ignoring uncertainty. Some scores are well-measured and some are guesses. Note which are which, and consider testing the uncertain ones, for example through prototype testing or engineering simulation.
  • Leaving out later stages. Criteria such as maintenance, support and disposal are easy to omit but can matter greatly, as the product lifecycle view shows.

Using the result

A matrix is an aid to a conversation. Its main benefits are that it forces the team to state what matters, makes the reasoning visible, and gives a place to record why a choice was made, which pairs well with decision records. If the result surprises the team, that is a prompt to check the scores and weights, and also to ask whether an important criterion was missed.

For decisions touching safety, legal compliance or ethics, a scoring table should not stand in for the judgment of qualified people and the standards that apply. Rules differ by country and industry, and weighting a safety requirement against cost in a matrix is generally not appropriate; such requirements are better treated as must-haves. This article is general background and not professional engineering advice.

The complete guide to systems thinking

Systems Thinking for Engineers
Read the guide

Keep exploring

Guides from other topics

All topics →