Why the MTBF of a teapot is longer than some Governments
November 29, 2010
Tim Brown raised interesting questions on the ideo blog:
“Firstly, why is the design of tangible things so reliable and secondly are there lessons from attempts to design in the abstract world of economics that may be useful to all design thinkers?”
I had to stop and think about it for a while to ask if the premise behind the argument made sense: The design process, as applied to products, buildings and other tangible things is quite reliable, while the design process applied to systems and abstract products (like new financial products fashioned by wily wall street professionals) or even software can be unreliable — and often fail.
|
|
|
|---|---|---|
| Examples | a stapler (product), is used to attach pieces of paper together. a building (architecture) provides a space for people to reside | a mutual fund or collateralized debt obligation (financial “products”) are used to obfuscate the consumer with unnecessary jargon and convey “informational superiority”. (What we’re doing picking stocks is high science and you wouldn’t get it, so you might as well pay us to do it) |
| a building (architecture) provides a space for people to reside | ||
| Role of Design | The design of tangible products is straightforward in how “apparent” it is. Human beings have a wealth of experience with tangible goods — both heuristically from a very early age, and historically, from the very beginning of “made” tools. As an end user, what you see is what you get (WYSIWYG) | The design of complex financial instruments is intended to convey complexity and inaccessibility by the consumer. In fact, most parts of finance are intended to exploit or highlight information asymmetries, and there is very little that is “apparent” about the process. |
| Repercussions | The stapler will end up in a landfill after its durable use. Any perverse effects that result from a stapler might be environmental degradation, but no large scale injury can be created. | Software can be used in a variety of different ways, have non-apparent bugs, and generally “live” past the originally intended use cases. Vague financial products that people don’t understand easily cause confusion and may have perverse effects including a financial meltdown. |
Despite our best efforts, on first blush, Design in the abstract (vs the tangible) seems to have many more consequences that are unforeseeable. Abstract design — mostly the kind needed today to mend large scale systems, software that has to serve a variety of purposes and needs while staying simple is much harder to get right. The coming years of Design and abstract product definition will continue to add a scientific diligence to the process that most nonpractitioners consider vague and driven by intuition. As Brown says, software — and particularly software startups (characterized by “Leanness”, fast prototyping, iterations, and transparency) is a good indicator of work processes that might overflow into other abstract systems.