Fil Salustri's Design Site

Site Tools


Morphological Chart

A Morphological Chart is a diagrammatic technique to catalog and help evaluate combinations of alternative system elements.

Why use morphological charts?

You need to generate some design concepts. You have a system defined by a set of functional subsystems, a product architecture specification that describes how those subsystems interact, and a set of possible embodiments for each subsystem.

You need to catalog (and subsequently evaluate) the possible combinations of embodiments to find the combination that will result in the “best” design concept.

It's important to externalize the choices you have to make, because, per ORA, one will think better and more clearly if one is thinking about ideas that have been written down, rather than ideas “floating around” in one's head.

Also, it's important to document your options and your choices, because all design decisions must be justifiable.

Finally, you want to be able to review the possible embodiments easily to help ensure you have thought of as many reasonable ideas as possible.

However, you also want to also be efficient about that externalization of embodiments, so as to save time and resources.

Some examples of situations where this kind of imbalance can arise include:

  • choosing the best embodiments for a set of subsystem requirements in a design;
  • choosing the best activities to do on a vacation for a set of goals that define a “great vacation;” and
  • choosing the best combination of investments that address your diverse financial needs.

How do we construct a morphological chart?

Fig. 1: A morphological chart for an infrared imaging system from Stanford University. This chart captures 225 concepts.

mc2.jpgFig. 2: A morphological chart for a tricycle for delivering newspapers. This chart captures 1,280 concepts.

Fig. 3: morphological chart of subsystems of a human powered vehicle. This chart captures over 57,000,000 concepts.

A morphological chart is a chart that compactly shows the possible embodiments for each functional subsystem in your product system.

Some sample morphological charts are shown to the right.

In the left-most column of the chart, list each functional subsystem that needs to be provided by your product, one system per row. Functional subsystems are established during system design.

For each subsystem, fill out that row with a brief description or sketch of all the embodiments you ideated that can provide the necessary function(s). Ideally, you would show each embodiment as some kind of sketch and as a short phrase or label (see the examples).

Once you've completed the first pass through constructing the morphological chart, revisit it with your teammates.

  • Are you sure that each embodiment is separate from every other embodiment for a given subsystem?
  • Are you sure the subsystems themselves are separate (disjoint)?
  • Is anything missing? Can you think of any further embodiments that you may have missed during ideation?
  • Are you're embodiments clearly represented? If not, add some supporting documentation below/after the morphological chart that provides enough information for someone who is not familiar with your project to understand those embodiments.

Points of interest highlighted by the examples:

The number of design concepts represented in a morphological chart is the product of the number of embodiments for each subsystem. (Example: If there are three subsystems, and there are 11 embodiments for the first subsystem, 14 for the second, and 15 for the third, then the total number of concepts represented by the chart is 11 x 14 x 15 = 2,310.)

In the examples, the first column describes functions rather than subsystems. This is an alternative based on not having performed system design before concept design. Remember, however, that a functional system has a specific purpose (e.g. a “steering system”) that is functional in nature (e.g. “steering”) so in fact the two forms are essentially the same.

You do not need to have the same number of embodiments for each subsystem. Sometimes, it can be very difficult to ideate more than two or three embodiments. That is not necessarily a problem.

The number of embodiments can also depend on the nature and complexity of the design imbalance you seek to address.

You are expected to provide the total number of concepts implied by the contents of your morphological chart.

NOTE: You will find it useful to have short names for each embodiment. One way to do it is by assigning a letter to each system or function, and a number starting from 1 to each embodiment. So, for instance, the third embodiment of the fourth system would be identified as embodiment D3.


Beware the "choose-one" problem

Consider this example: you're designing a human-powered vehicle; you've determined that there must be a braking system in your solution; and you're filling in a row of embodiments in a MC for that system. You might end up with the following items listed in that row of the MC:

The problem here is that a single concept will require a brake type (of which there are four options), an activator (of which there are three options), and a force transmitter (of which there are two options) - but the MC method requires us to choose only one item from that row.

Another example is a “user interface” for a kitchen blender, which might include various switches, buttons, sliders, and knobs. We might need a knob for speed selection, a switch for power, and buttons for other settings - yet we can only choose one item from that row.

This is called the choose-one problem. It signifies that either your system is too general or your embodiments are too specific. However, it is often far more difficult to redefine the system or the embodiments than it is to recognize and take advantage of some fundamental system patterns.

One very popular pattern is the interface-transmitter-actuator triplet. It resolves both the examples above.

mc_braking_system.jpgFig. 4: A fragment of a MC for a braking system.

In the case of the braking system, we would split the system's row in the MC into three sub-rows (as shown in figure 4): one for the interface (handlebar lever, backpedal, and handlebar twister), one for the transmitter (cables or RF), and one for the actuator itself (disk, rim, drum, and spoon brakes). Now we can again choose one item from each (sub)row, maintaining the methodological rigor of the MC but properly allowing us to choose various embodiments as needed.

The blender interface example is handled similarly, but with a more substantial change. The technique here is to remove entirely the interface system of the blender, opting instead to embed a bit of the interface in each of the other systems. (Remember, systems need not bear any direct correspondence to the subassemblies of the end product.) For the blender, we might use the following approach.

  1. Create three sub-rows for the power system: one for the interface (a button, or a switch, or…), one for the transmitter (electrical wires, or a mechanical relay, or…), and one for the power system itself (a transformer to properly condition incoming electricity, or battery activation, or…).
  2. Create three sub-rows for the speed selection system (in a manner analogous to the power system).
  3. And so on.

It is very important that you avoid the choose-one problem, so learning to use the interface-transmitter-actuator pattern will be very useful.

Beware maximizing the MC

There is a tendency to ideate as many embodiments as possible. This will lead to a huge number of total concepts. It then becomes intractable for you to perform concept evaluation.

According to [Jon92], morphological charts work best when looking for novel solutions to known imbalances, initial solutions to newly identified imbalances, and relatively constrained design spaces. The more unconstrained a situation is, and the less understood it is, the less likely it is that morphological charts will be helpful.


In addition to a properly constructed morphological chart, some background of the embodiments must be provided. Typically, appropriate background information will explain how embodiments were ideated (e.g., via research, or the application of particular creativity methods, etc.) and why a particular embodiment is believed to satisfy the requirements that must be satisfied by the system being embodied.

Background need not be provided for every embodiment. Commonplace embodiments that are typical for a type of system need not be explained; the more atypical the embodiment, or the more exceptional how it was ideated, the more background is necessary.

Background ought to be provided in extended point form immediately following the morphological chart.

See Also


Jon92. a J.C. Jones. 1992. Design methods. John Wiley & Sons, New York.
design/morphological_chart.txt · Last modified: 2020.03.12 13:30 (external edit)