Trail up Meadow Creek, off the Selway River, Nez Perce National Forest, Idaho

There are some stories I’ve told myself so often, I forget that I haven’t completely discussed them on this blog.  One of these, alluded to, is the role of the customer in design.

The surface-level analysis of a customer in design leads to the usual conclusions, which are not, in and of themselves, wrong.  Customers provide information for specifications, and good engineers/designers analyze the customer’s situation, gathering data that leads to better designs.  It’s a virtuous connection, and certainly I’ve advocated for lots of interactions between designers and customers on this blog.

But what’s really going on in the knowledge space?  How does Conway’s Law play into this — and what does a customer, along with a developed sense of rational empathy, do?How does a customer enlarge the knowledge space that the design organization operates inside of?

Conway’s Law tells us that the design of a system or product will map to the social structure of the organization that designs it.  If that’s the case (and I’ve argued that it is!), then it should be relatively easy to map the final design to various departments and divisions inside the company that designed it.  I was reminded recently by a friend of the  classic example of this in the book Soul of a New Machine, where the engineers for the Data General MV/8000 mapped out Digital Equipment Corporation’s VAX engineering department on the motherboard.

But there were no real customers involved with, in any kind of iterative way, the design of those computers.  Both organizations were in-house, working as fast as they could, to create a faster mini-computer.

Customers complicate the application of Conway’s Law much more.  A design company interviewing customers has to account for the customer’s knowledge in some fashion. There’s nothing wrong with taking some snapshots of customer needs, turning them into engineering characteristics, and placing those fragmented pieces of information into a tool like a House of Quality and chunking away with a standard design process.  That little bit will take you a long way.  The customer is cast in the role of partial Authority for what they want, and as such, since Authoritarians communicate with knowledge fragments, it fills the bill — as well as the House.  The designer uses tools/algorithms like the various parts of the House such as the roof to explain trade-offs to the customer.  And then we’re off to the races.  Or happy design land.

But what happens if the design (or maybe better stated, the product conceptualization) is earlier in the development process?  What happens if we don’t know if the design is even physically realizable?  Many design projects I’ve been involved with have been shoved further down the development scale.  I like the NASA Technology Readiness Level figure, shown below, as a good indicator of judging how many potential unknowns, both known and unknown, one might expect to encounter in a design process.

NASA Technology Readiness Level Scale

You can be sure when you’re down in the research to prove feasibility range, you’re going to be encountering some unknown unknowns — and that’s tough to calibrate with typical project planning on the Gantt Chart.

Purely physical law-based designs (like an upgrade to a chemical rocket engine) only have scientific research to deal with.  Contracts can be let with various suppliers, both upstream and downstream, even for speculative things, that are based on physical experiments being performed.  Gates can be set up, and the contract can be based on various milestones being completed.  All information can be declared explicitly in all contexts — even the ones where the knowledge hasn’t been generated.

That’s not as easily done when a customer is ingratiated into the design process.  Any given customer may or may not know why they want what they want.  They just know they want it.  A simple example might be that a customer wants a red bike.  They may want their bike to be red because that’s their personal preference.  Maybe when they were growing up, their favorite bike was red, but they’ve since forgotten this fact.  The information is integrated and downconverted inside the customer’s brain.  The unnecessary stuff — or rather, the unnecessary stuff their brain decided 20 years ago was unnecessary stuff — has been discarded.

But maybe the real reason for the bike being red is that red happens to be the one color that drives bugs away when you ride the bike in that part of the world.  And if you had a red bike, you didn’t have to worry about june bugs flying into your eyes.  Maybe it mattered more to the customer than either you or he realized.

What you, as the designer, are doing when you incorporate that level of customer input is what I call metacognitive enlargement.  You are enlarging the social structure that matters not just to include the customer, but also the background knowledge generation that the customer went through to acquire that knowledge.  You’re not just integrating his or her eyes and ears into the design.  You’re tapping into their entire network.  And you’re adding in the stuff that you know you don’t know (explicit advice from the customer), as well as the stuff you didn’t know you didn’t know (implicit insistence for certain features from the customer.)

Appropriate metacognitive enlargement, with a smart customer, dramatically enlarges the potential solution space, as well as the number of solution structures you can use to actualize the design.  Now, instead of examples based on your organization’s past successes and failures, or as yet untapped creative, independently generated interactions existing within your design groups’ interactive minds, you have access to the customer’s as well.

But we’re not through yet.  Typically, not everyone in a given organization will deal with the customer. There will be people on the front end who do that interaction.  They will need to have evolved empathy, for two reasons.  First they need to be able to control their own egocentric projection involving the customer’s stated needs.  Accurate rational empathy/place-taking is a must, and as I’ve discussed, real transitions into self-awareness of bias takes you another big step up the ladder.

But it’s more than that.  The designers need to be able to assess, in some probabilistic fashion, how much they should trust the input the customer is giving them.  As the people on the interface, they have to make a decision about the level of veracity of the customer’s information.

Superficially, the design space is some merged set of customer and designer knowledge structures, that come directly out of the customer and designer social structures.  But it is up to the designer to decide how much, and how integrally, the customer input should be utilized in the design process.

And here’s the rub — often, the customer may know implicitly, meaning they WILL NOT be able to tell the designer explicitly, why something is important.  But just because they can’t verbalize it, or draw a picture, or give the usual evidence that a designer may be used to doesn’t mean it’s NOT important.  It is then that the designer’s empathy and ability to connect that matters.

Appropriately structured design organizations, with great independent relationships, scaffolded with appropriate technology and tools, can produce reliable designs.  But without accurate customer assessment, validity will suffer.  Because, all other things equal (e.g. the customer is not a nut, or a victim of their own Dunning-Kruger bias!) the customer knows what they need.

A great example of this how metacognitive enlargement works could be found with one of my student projects.  Students were tasked with making a heat transfer measurement system for water jackets for enormous, stainless steel vats used for making wine.  Controlling temperature in the vats is important — fermentation rates are a primary factor in managing whether wine will be good or not.  And the customer had asked the students to make the system out of stainless steel.

Stainless steel is de rigeur in almost all food and beverage-based applications.  But in this case, the temperature system was not actually touching the wine.  It was only tracking the cooling water circulating in the water jackets, that were never exposed to any part of the wine.  The clients insisted, however, that the device be made of all stainless steel, which made parts difficult to order.

The students groused, but managed to deliver the system on time and on budget. It was only after that occurred that the real reason for the temperature measuring system was revealed.  The device had to be taken to trade shows, and placed next to wine vats that were the real thing the company was selling.  There was a real fear that if everything in front of THEIR customer wasn’t stainless steel, there might be some question about appropriate material selection for the vats themselves.  That would result in reduced sales, and not worth the risk (one of the big vats cost $200K).  So building the temperature measuring system out of stainless steel fittings turned out to be one of global validity, in a venue where no technical justification could be given. It was a marketing decision — but a vital one.

Closing this up, I don’t have any formula or algorithm I can give you for a good customer — ‘good’ being defined as someone who pushes your design team to their maximum performance, while keeping it real inside their own expectations.  Because empathy is maximized when it’s a two-way street.  And there’s no question that a good customer is as vital to a great design effort as the team that does the design.