Functional Decomposition: Solving Complex Problems Without Complexity

This article has been edited from the original version dated October 2015.

Have you ever seen a product so complex—yet so elegant in execution—that you think its designer had some kind of divine inspiration? That in his genius mind, the design popped forth fully formed with countless elements depending on one another to perform a myriad of functions?

For me, this genius product is the writer automaton, which was designed and built by Pierre Jaquet-Droz in the late 1700s. Considered a remote ancestor of the modern programmable computer, this self-operating machine doll uses a goose feather to write custom text. It is a marvel of cams and movement, combined with meticulous craftsmanship. Watch its amazing features for yourself:

How did Jaquet-Droz solve this incredibly complex design problem? He broke it down into manageable pieces, of course.

In mechanical engineering school, most of us were taught to perform a functional decomposition. This process breaks a problem into a product’s inputs and outputs. Then each part is classified as one of the following three categories:

• Energy
• Material
• Information

While this functional decomposition process indeed breaks the problem down and helps separate designers from their pre-conceived product concepts, it’s also cumbersome and often too detached from possible solutions. Just look at this decomposition of a nail clipper by the University of Michigan.

Whoa. I’m not sure I’m any closer to designing a nail clipper. How would we map out the functional decomposition of a more complex product, like the Saturn V?

If you are just making an incremental change to your product—making it smaller or lighter or lowering the power, for example—a rigorous functional decomposition is probably not necessary. However, when facing truly new or difficult product-development challenges like Jaquet-Droz’s automaton, functionally decomposing the problem is essential to ultimately finding a solution. A practical approach is to break the problem down into its main functions. It’s easy to identify these functions without reducing the problem to the level of the above nail clipper.

But how?

If you aren’t sure where to start breaking down your problem, try tackling either:

• The problem you least know how to solve
• The show-stopper problem—the one that determines whether your product works or not.

The key: Focus on the major problems first. Work on finding these solutions without getting overly concerned with all the other issues of the design, like packaging or other interactions. (Yes, all those issues matter too. But if you can’t make the product work in the first place, it’s not all that important if it’s small or fits together well.) While this principle may seem obvious, many times in my career I have seen designs get bogged down as engineers get caught in the weeds. Too often questions like the following prevent forward progress:

• “What should that rake angle be on the cutting teeth?”
• “How large is the battery pack?”
• “How are we going to implement a safety interlock?”

And all the while, there isn’t even a functioning prototype.

Functional decomposition is a process of breaking a problem into smaller functional modules, concurrently solving each module independently, then merging the leading solutions.

There are three key steps at each stage of the functional decomposition process:

• Identify fundamental functions
• Prioritize them based on importance
• Solve each independently

This separates the effort to provide a systematic way to allocate limited development resources to critical design elements. Following these three steps also protects your team from getting distracted by downstream requirements (like product size and cost) at a point when fundamental functionality is not completely known. But, you ask, don’t I run the risk of breaking the problem down into products I already know? Isn’t that why I need the functional decomposition?

Yes, that is a risk. But remember to stay focused on functions, not forms.

This is one reason why in many cases you should separately develop functional prototypes (those that only consider a device’s functionality) and usability prototypes (those that do not function, but are made to test user interaction and form). To make these prototypes be most effective, don’t try to combine them too early.

At this stage, you might worry you’re going to get a Frankenstein product that separate parts to perform each function. Let’s go back to our trusty nail clipper: Isn’t this image below the logical result of functional decomposition? One solution for each function?

If you stopped at your initial decomposition, then a result like the nail clipper example is a distinct possibility. Don’t fret, just repeat the process.

Now that you have solved the big problems, begin looking for obvious ways to combine functionality (e.g., the blades and springs of the nail clipper are the same parts). If you’re working on a more complex problem, you will likely need to decompose it at a coarser level (more functions embodied at once).

Truly effective design is accomplished by following these iterative steps:

• Decompose the problem
• Ideate solutions
• Create physical mockups
• Evaluate/test
• Repeat

What do we learn from all this?

Even very complex devices, like Jaquet-Droz’s automaton, can be broken down to a manageable level to solve the problem.

As it turns out, that seemingly genius designer is just like you: Jaquet-Droz solved manageable problems, then combined and evolved his design over as many steps as necessary until the final solution was revealed.

This design—which on the surface seems irreducibly complex with myriad interactions and the elegance of Da Vinci—was designed by an intelligent designer. One who approached the problem systematically and worked diligently toward a complete product solution. By using the systematic approach outlined here, you too can solve your most complex problems.