A Morphological Chart is a diagrammatic technique to catalog and help evaluate combinations of alternative system elements.
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.
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.
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
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.
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.
It is very important that you avoid the choose-one problem, so learning to use the interface-transmitter-actuator pattern will be very useful.
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.