I’m a little over a hundred pages into Marvin Minsky’s The Emotion Machine and came across this gem:
To understand how our thinking works, we must study each of those “very different things” and then ask what kinds of machinery could accomplish some or all of them. In other words, we must try to design — as opposed to define — machines that can do what humans do.
In my words, he’s taking about Designing to Define. I think that is an apt way to describe an interesting philosophy of doing to learn. In the software community the closest thing is rapid releases, rapid prototyping, etc. But what I’m talking about isn’t designing to improve — it’s designing to learn. That is something I’m not sure that product companies do intentionally. Maybe I’m wrong. But even if they’re not doing it now, they will (and those that are – you’re a step or two ahead).
Marketers, especially those of the direct variety, have always done this to some degree — if they do it right. On a very basic level they understand the values and motives of consumers through emergent design — the audience, the offer, the creative, endlessly reformulated in small increments, a plodding evolutionary approach. What makes that world complex, however, is 1) the spectrum of sophistication (or lack thereof) of other companies’ approaches and 2) the pure volume and breadth of direct marketing communication. Very few marketers actually take into account what else people are getting in their mail as a part of the audience, offer, creative equation. They don’t completely define context.
It is the proper atomization or disaggregation into component parts that is the difficult part of Designing to Define. I don’t have to understand all the workings and innards of a complex system, but rather I want to design a system that elicits the outcomes I desire in the appropriate contexts. Therefore:
1. I must be clear about my intended outcome(s)
2. I must understand the relevant components of context
3. I must be able to break the design features into mutually exclusive, collectively exhaustive parts
Doesn’t seem so easy when broken out that way. But the fourth element of DtoD is iteration. The outcomes, context, and design components must all be quantified and measured — then coupled in iterative ways that improve outcomes, are either specialized for specific contexts or rigorous enough for most contexts, and reduce time and cost of design and production.
I know. You’re thinking: this isn’t anything new. This is the scientific method. And I agree. But instead of designing experiments, just design products and services that are emergent and experimental while delivering value. Make the emergent qualities part of the value and assets of the company. You’ll get closer to actual “use contexts”, shorten the time to learn, reduce R&D costs in the long run, and make competively differentiated products and services that people use and will increasingly value.