Braden on a roll at nine, starting on the journey between Passau, Germany, and Vienna, Austria.

When I started the Industrial Design Clinic (IDC) over 22 years ago, it can be fairly safe to say I had no idea what I was doing.  I was a nonlinear physicist, essentially, by training — though my degree was in mechanical engineering.  Helped by my as-yet-unmade friend, Les Okonek, from ARCO/BP/now retired, and fellow refinery engineer Brett Emmons, I implemented a pretty standard design process.  This was further enhanced by the adoption of the book, Product Design and Development, by Karl Ulrich and Steven Eppinger. The First Edition came out in 1995, and it was the first textbook I folded into my efforts.  It may seem just a little dated now, but it’s a solid book, and describes what most people recognize as a canonical design process — in fact, it documents THE canonical design process that most people use.  There are variations on modification of design ‘gates’ and decision points, dependent on the agency and organization (is it any surprise, for example, that MILSPEC has ‘gates’?).  But it still holds up — and my students have literally built hundreds of designs using some modification of this process.

What’s the short version?

1.  Scoping.
2. Specification, using some form of Needs/Metrics/House of Quality toolset.
3. Conceptual and Preliminary Design, with a focus on generation of multiple designs, followed by review and down-select.
4. Final Design.
5. Manufacturing.
6. Benchmarking of the design against the specification.
7. Redesign (if benchmarks aren’t met) or Delivery to the Customer.

This all seems reasonable, of course.  And it is.  Yet like all knowledge products, its dominant characteristics are inseparable from our social/empathetic structure.  Both Ulrich and Eppinger are professors at MIT, and it’s not surprising that this design process sits squarely on the transition between the Legalistic v-Meme and the Performance v-Meme.  Design necessarily must have a large focus on performance and hitting goals, and these are rigorously enshrined in the process.

I’ve said that we can see that the knowledge product of the design process itself is a function of the v-Memes of the people documenting and generating it.  How?

1.  The process is meta-linear.  Varying diagrams may show this process as a straight line, or perhaps as a circle, but the bottom line is ‘we get one thing done, we move to the next one.’
2. Ulrich and Eppinger are big on a variety of algorithmic tools — more meta-linear, step-by-step processes that scaffold each of the heuristic steps, that lead in a predictable fashion to the next level.
3. Customers are included at the start of the project, as focus groups primarily.  Their input is then distilled into numbers (Measure to Manage!) and these are represented in the House of Quality/Metrics type tools.  Customers typically don’t loop around back into the process until the Benchmark/Delivery steps.
4. Empathetic development of the team does not allow for evolution of empathy and relationships with the customer.  The idea of evolving an experience along with the customer, while not particularly disallowed,  is not so much in the cards.
5. Larger synergies are not intrinsic between designers of the product and the outside world.  Synergies in that form are largely an afterthought — not surprising, considering the relative level of empathetic connection in the process.

As I’ve said earlier, we’ve used this process (and still use it!) for literally hundreds of successfully shipped products.  And for most products developed by the students in the IDC, it’s great.  Those products are necessarily Rev. 1, due to time limitations — the students only spend 4 months in the class.  Rev. 2 designs are sometimes commissioned by customers/sponsors, but are usually refinement projects (that algorithmic devolution thing again) — this system developed an unexpected crack during testing/use, etc., and the customer wants to take the extant design and improve it.

What is this design process great at?  Not surprisingly, it works very well for assembling engineered components (what I call ‘Lego Engineering’) into a new product, designing components with a large basis in the laws of physics (contrasting, evaluating and selecting, for example, different boiler designs), and some limited systems work, where interfaces are well-known.  Students often will be asked to visit a factory where a problem has been specified within a given system boundary, and students, in coming up with different preliminary designs, will often draw different system sizes and zones of inclusions.

Because multiple solutions are mandated in the preliminary design phase, there is the necessary headroom for different members of a group to be heard.  I often task everyone in the group with coming up with at least one potential design, and in order to dump a little empathetic development in the mix, often insist of pairing among students to generate ideas.  Students naturally tend toward solitary innovation — that comes straight out of their dominant authoritarian social structure (we’ve penalized them for working together their whole career — we call it cheating!) and so it is often necessary to order collaboration and sharing at the beginning of the project.  Students (and often multidisciplinary teams) will often take any project and fractionate it according to specific titles and established skill sets. Synergies, if any, will come at the end.

So much of what happens with this given design process will depend on the manager(s) of the effort.  If they implement things like pairing, the odds of synergies will increase.  If they insist more time spent with the customer, then it will happen.  Much rests on their Authority.  There is only a minimal level of emergent empathetic connection in the process itself.

And that shouldn’t be surprising.  That would be the natural construction of the professors who created it.

What’s especially fascinating is that in a follow-on paper, in the Harvard Business Review, Are Your Engineers Talking to One Another When They Should?, by Manuel Sosa, Steven Eppinger, and Craig Rowles — the same Eppinger of the book above — they recognize some of these problems.  They note the lack of metacognition — not with the language of this blog, but by stating in large projects (such as the Airbus A380) the existence of unattended interfaces.  They then state that the effort is really a failure of planning, and not surprisingly, introduce a set of algorithmic tools called Design Interface, Team Interaction, and Alignment Matrices — a Legalistic v-Meme intervention and tracking tool.  None of this is, of course, surprising.  The Principle of Reinforcement, where social/relational systems and their respective empathetic levels, reinforce and develop the behavior of its participants, and vice-versa, is at play even at MIT.

For things like large aircraft, where configurations are relatively fixed (look at the Boeing 737 family of designs) such tools are in themselves not such a bad thing.  Mapping out the interfaces, and who’s talking to whom is important.  There’s all sorts of implicit assumptions built into this, of course — that not only are they talking to each other, but the protocol that exists is actually getting the message across.  It’s an Authoritarian v-Meme idea that communication is 100% effective, even when it’s not.

But at the same time, the point of all this is that one must be aware of where our tools come from, and what kind of behavior they generate.  Ulrich and Eppinger’s process is great (not surprisingly) for the uses listed above.  Those map well within the social structure created to accomplish those given designs.  But we’ve got to think out-of-the-box, or perhaps better said, with a truly expanded sense of metacognition, if we’re going to attack larger problems, or larger synergistic systems — or cater more effectively to varying human preferences.  If we want more breakthroughs, we have to have more opportunities for larger rational empathetic interactions, and more nonlinear behavior.  We have to make a larger commitment to empathetically evolving the people inside the problem so they can naturally recognize and solve these types of challenges.  That’s not going to happen so much with the design process sketched out above.

And with the above design process, synergistic behavior is not intrinsic or emergent.  If leadership doesn’t order some of it up, with the social physics discussed in this blog, we likely won’t see it.  In fact, we may see failure because of a lack of it.  The system is not self-correcting.  Like Clint Eastwood as the character Dirty Harry so famously said — “A man’s got to know his limitations.”

Takeaways:  The canonical design process above is a huge step up from the arbitrary design processes of the past.  It successfully promotes multi-solution thinking, benchmarking with metrics, and working from a specification.  But there are limitations in generating new synergies, as well as tackling more complex, time-dependent projects.