Skimming The Surface Of Axiomatic Design

It is based on such a fundamental design philosophy that it works for any design discipline and easily with other product development methodologies.

Reintroduce your design group to the fundamental principles of Axiomatic Design. Its success-driving practices are valid for mechanical, electronic, and software/firmware design.

For some design organizations, Axiomatic Design is the heart and soul of good design.  For others, Axiomatic Design was a little understood and rapidly passing design fad.  Others still may have adopted Axiomatic Design in some form, but abandoned or forgotten it when other methods such as Lean Product Development or Design for Six Sigma hit the scene.

I perceive that Axiomatic Design is rather simple to understand and incorporate.  Also, it is based on such a fundamental design philosophy that it works for any design discipline and easily with other product development methodologies.  In fact, I perceive that the very fundamental simplicity of the Axiomatic Design idea may be what has led to its short-lived limelight and easy sublimation from industry focus.

It’s unfortunate, really, because Axiomatic Design is like basic design hygiene; like brushing our teeth.  We don’t make a big deal of it because it is so obvious, but we shouldn’t go a day without it either.  Let’s give it a quick recap and bring it back to the surface of our recollections.

Simply put, Axiomatic Design is an approach to product concept development that focuses on understanding the relationship between customers’ functional needs, and the design parameters (elements of the design) that enable the fulfillment of those needs.  It seeks to separate those things that should be kept separate, “uncoupled” design elements, and simplifying the customer solution by combining, “coupling,” those things that can be combined for better advantage.  Coupling may be done to simplify the design for reliability or manufacture, but the first objective is to uncouple elements and simplify the user’s experience and improve the design’s ability to satisfy, even if this means creating a more complex design.

Axiomatic Design gets its name from two basic axioms (un-proven, but self-evident statements) that are used to guide design decisions.  The first is that independent functions should be kept independent.  The second is that the controls (or information) should be minimized and simplified.  It’s that simple.  The rest of Axiomatic Design is all about a methodology for identifying and understanding the functions that should be independent and mapping how the design elements and controls are simplified while enabling that independence.

Do you see what I mean about Axiomatic Design being so simple that some of us don’t take it seriously?  I think, sometimes, that we have come to expect better design methods to be highly structured, complex systems of solutions and we reject simple concepts out-of-hand because of those expectations. 

Axiomatic Design may be simple in concept and principle, but it can take a great deal of experience and creativity to conduct it effectively.  What this means to us is that it is very easy to incorporate into our design methods and practices, but it takes a concerted effort and some practice to get good at it. 

Let’s take a high-level look at a design challenge to see how the Axiomatic Design approach works.  Then we can reflect on how well our own design teams might perform the same thought exercises and decide if it is a practice that should be re-invigorated.  Let’s design a combat tank.

There are three basic design parameters that determine the successfulness of a combat tank.  They are as follows, and of course they conflict.

  • Mobility
  • Firepower
  • Defense or Armor

Naturally, we can complicate these design parameters to an infinite degree, but for the sake of discussion, let’s keep things simple.  Consider mobility to include both speed and an ability to cover a wide variety of terrain.  Firepower is the ability to deal out destruction of opponent or enemy assets; this includes destructive power as well as range and accuracy.  Defense or Armor includes every aspect of preventing the tank from being quickly or easily removed from action.

Now, let’s talk constraints.  We need our combat tank design to possess some reasonable manufacturability, producible in the thousands and with the possibility of rapid manufacture should we need more, quickly, during wartime.  We must seek to reduce the materials and complexity of the vehicle to the best degree possible without sacrificing performance.  This should sound like a pretty typical product design challenge.  “Give me all you can to satisfy conflicting requirements for the least cost.”

Let’s get started.  We’ll begin very basic, a drive system with a weapon on top.  First, let’s discuss the importance of uncoupling our design parameters to keep our independent functions independent.  If our weapon is a cannon, and it rests on top of our vehicle, then our firepower function is “coupled” to our mobility function.  In order to aim our weapon, we must point the entire vehicle.  This means, in order to point and fire, we must stop and momentarily sacrifice our mobility.

It stands to reason that if mobility is highly important, we should not give it up to fire our weapon.  The obvious alternative is to put our cannon in a turret so that we don’t need to use the vehicle’s mobility system to point our weapon.  This may limit the size of the weapon we can employ, but it keeps our functions independent.  If we go a step further and incorporate a computer controlled targeting system, we might be able to move and effectively fire our weapon at the same time.  Now we are maximizing both functions through complete independence.  Of course our manufacturability is paying a price. 

You see where the axiom of independence drives design decisions.  Our design is much more complex in order to maintain functional independence, but the effectiveness of the design is maximized.  Creativity is the best asset when it comes to preserving performance and minimizing complexity.  We also need a robust system for making design trade-off decisions.

For example, we might simplify the design by eliminating the turret and control system in favor of a guided-missile weapon, but at the cost of carrying less ammunition and at greater cost for each firing of the weapon.  This is typical design challenge stuff.

Let’s look briefly at the second axiom concerning minimizing the controls or information.  This can be taken several ways for our example.  On the surface, we probably want to minimize the crew, which also solves some of our other design challenges concerning weight, space, and protection.  If we mechanize the function of loading and arming the weapon, we can eliminate the need for at least one person, and therefore an interface or control.  Likewise, we want the vehicle to be simple enough that a single person can drive.

The real challenge might be to manage the tactical and communications function with those of targeting and firing the weapon and driving the vehicle.  Perhaps those functions are each different and complex enough that they should remain independent, and therefore our crew becomes 3 soldiers.  To accomplish this, all other functions must be simplified or automated such that a crew of 3 can operate the vehicle.

Let’s look at the weapon system again.  To put the weapon on target, at a minimum, two different factors must match up.  There is elevation of the weapon to address the range, and there is the rotation of the weapon to put it on target.  The simplest design would be to provide one control for each.  This is simplest for the design, but not for the user.

Imagine bouncing around in the vehicle, under combat conditions and stress, trying to manage two different controls to achieve a single function.  It’s not ideal.  Instead let’s consider a joystick, or trackball interface.  Now a single control will put the weapon on target.  This is the focus of the axiom of simplifying controls and information.  We can take it a step further if we can devise a control interface that reduces the impact of the vehicle’s motion on the gunner’s ability to work the control.  Perhaps a touch screen would be even easier to use than a joystick, who knows?  Again, we must get creative.

Similarly, we want related information and controls to be simplified, such as the relationship of the weapon’s aim to the front of the vehicle, or the quantity of ammunition remaining.  A simple visual at the targeting control would be much simpler than physically counting shells or missiles remaining.  Here we see how design elements can address processes. 

Simplifying user processes is a big goal of Axiomatic Design.  We keep independent functions independent to keep from making unnecessary user processes, and we couple control and information elements to reduce and simplify necessary user processes.

Briefly, let’s talk about the armor or protection system to wrap up the example.  Here is where some difficult design decisions must be made, and also where it becomes less clear whether we should prioritize the axiom of independence or the axiom of simplification.

First the obvious; the more armor we put on our vehicle the harder it becomes to satisfy the mobility function.  We can play with the shape of the armor to provoke glancing blows instead of direct hits, effectively reducing the amount of armor necessary for the same level of protection.  We can also play with materials or reactive-armor solutions to the same end.

Obviously, our mobility system and our weapon system need to be protected by the armor system, but we will want to maintain some independence if possible.  For example, it’s most certainly better to place the engine inside of the protection system than it is to try and armor plate the engine itself.  If we have a turret, it will probably need it’s own armor system because if we place it inside of an independent system, it will lose most or all of it’s independence from the rest of the vehicle and the mobility system.  The turret and its protection system must be coupled together to remain uncoupled from the mobility system.

Let’s take one quick look at protecting the mobility system.  We can put armor plate over the tracks or wheels to protect them, or we can design a track system that is robust to attack.  Considering the likelihood of land mines being an attack method, perhaps the latter is a good solution, even though it appears to violate the axiom of independence.  This is what I meant above when I said that the concept is simple, but the practice takes work.

Axiomatic Design provides a critical design philosophy and focus.  It is a guideline, not a law.  It takes some proficiency to learn when it is appropriate to couple functions in spite of the independence axiom, and even more practice to understand when decoupling controls is better than consolidating them.  However, these are the exceptions, and allowing our design process to focus first on the fundamental approach to Axiomatic Design is an excellent practice.

Let’s look at a more in-your-pocket example.  The touch screen interface on your smart phone is rapidly overcoming the complex interface of, say, the Blackberry.  I remember when the iPhone first appeared, its user’s manual was a folded up strip of paper smaller than a matchbook.  The Blackberry’s user’s manual was a book bigger than the Blackberry (figuratively).  I don’t know if Apple consciously, deliberately drove Axiomatic Design with the iPhone development, but the advantages of the simpler control and information interface is apparent.  Most smart phones now incorporate the touch screen interface.

Axiomatic Design works not just for mechanical and electronic systems, but for software systems as well.  Software is much easier to troubleshoot, maintain, and continuously develop and improve when separate functions are kept separate in the code.  It is easier to re-use code as well.  Likewise, software systems are much easier to use when the information and controls are simplified. 

Axiomatic Design principles are especially useful when developing firmware.  Sometimes design elements to satisfy functions will be shared between electronics and firmware.  However, if we can satisfy a function with one or the other, instead of both, it becomes easier to troubleshoot and sustain the design going forward.  They also tend to be more reliable, providing fewer opportunities for error or failure.

Take a good look at some of your team’s more recent design solutions.  Could strategic coupling reduce manufacturing costs?  Could your performance be improved in the customers’ perceptions if more independence of function were provided?  Could the interface or controls be simplified? 

Incorporating Axiomatic Design practices and fundamentals into your design process could help your team consistently build better solutions.  The best part is that because Axiomatic Design is so simple and fundamental in its focus, it can easily be incorporated into other design methods such as “Stage Gate” structures, Design for Six Sigma, or Lean Product Development methodologies.  Take a good look and see if your designs might not benefit from bringing back this all-but-forgotten idea.

Stay wise, friends.