August 9, 2011
Innovation means testing a lot of ideas and methods, and unless you are obscenely lucky – failing a lot. The key question becomes: how early should I fail? Too early and you may not give an idea the chance to get iterated upon to make sense, or be polished enough to make sense to most people. Too late, and you've just wasted a lot of time and energy on something on something that was doomed from the word “puff”.
So where is the sweet spot? Even a team whose whole purpose is to innovate may not have the right answer. So we've been working with company live|work on a workshop spanning two weeks, meant to help us improve our process and attitude in prototyping. The main goal was to be "user-centered", and I guess we did learn from that, by running the whole process from observation and interviews in people's homes, to expression of needs, to quick prototyping of solutions.
When the workshop ended and we had a chance to reflect on it, one thing everyone was pleased with was how the team had built very early prototypes (paper and cardboard, mostly), had tested ideas with real people, and had gathered insights that could have saved us months of development as opposed to testing a “minimum viable product” – something most teams would already find horribly difficult already.
Something impressed me even more. I noticed that even the most hardened of our engineers, the kind that always starts thinking about "how we are going to build this" the moment an idea floats by, let go of this habit. Was it because we weren't "really" building a prototype that would end up in production (hence, lower expectations)? Was it because the schedule of the workshop gave us so little time from start to finish that we *had* to test with cardboard and paper and not really think through how we'd end up building the actual product if the idea turned out to be brilliant?
Whatever the cause, we weren't afraid to invoke magic.
How will it work? – Doesn't matter.
How long would it take to build? – Doesn't matter.
How hard would it be to make it work? – Doesn't matter.
The one and only question was "what if it worked?". Very liberating: the whole team, designers and engineers, team assistant and producers and managers, all equal in creativity. The only ones who didn't quite play the game, in fact, were the normal people who came to test our cardboard prototypes. A few couldn't quite accept the suspension of disbelief; one of them was adamant in asking “but how would it work?” and wouldn't take “Doesn't matter” for an answer.
Detail: Millenium Bridge, London, January 2011
Having finally had a chance to unpack some of my books from the cardboarded existence I’ve had to impose on them in the past few months, I have had a chance to do a bit of reading, recently. One of the books I’m almost through is Christopher Alexander’s “Notes on the Synthesis of Form”. An early work of the theorist of architecture and father of “pattern languages” (I seem to recall it was his doctoral thesis), “Notes” is often touted as Maths-meet-Architecture, for its focus on graph theory, systems, subsystems and their dependencies.
Il y a dans notre jardin un papillon qui bat des ailes; C'est si beau, si fascinant que l'on en oublierait tous ces ouragans lointains.