The Art of Innovation, by Tom Kelley

Amazon link

I’ve heard great things about Ideo, often called the leading product design firm in the world. Last year, in my “Managing Innovation” class, we watched a Nightline special called the Deep Dive, where Nightline gave Ideo one week to re-design the shopping cart. It was a great look inside the company’s innovation process, and it left me wanting to learn more. So I bought The Art of Innovation, a book describing that process by one of their general managers, and finally got a chance to read it last week once classes were done.

The book starts their redesign of the shopping cart for the Nightline special as an illustration of their innovation process:

  1. Observation: Go to local supermarkets to see how people were using shopping carts and the problems shoppers faced. The book calls this “a form of instant anthropology”. From this, extract the goals of the re-design (in this case, making it more child-friendly, safer, and more efficient)
  2. Brainstorming: Generate hundreds of ideas and sketches, from the silly to the sublime. After brainstorming is done, winnow those ideas down to a few promising candidates.
  3. Prototyping: Build mock-ups to see how those candidates will work and feel.
  4. Iteration: Evaluate and refine the prototypes, using the best ideas and what you have learned to generate the next round of prototypes.
  5. Implementation: Take the best of the prototypes and prepare it for commercialization.

I’m a big fan of this process, as might be expected since I advocate rapid prototyping whenever possible. The knowledge gained by letting users interact with prototypes lets you hone in on what’s important and what’s not.

The rest of the book is a collection of a whole variety of techniques that Ideo uses to spur innovative thinking, and how it has created a culture conducive to such thinking. So there are chapters on each of the steps above (observation, brainstorming, prototyping, etc.), but there are other chapters on culture concepts like “Expect the Unexpected”, “Barrier Jumping”, and “Coloring Outside the Lines”.

One of my favorite ideas of the book was to create the advertisement before you create the product. Take the time to make a print ad or a 30-second video that extols the benefits of the product you are creating. This focuses the team on what they are trying to accomplish with the design. I can think of a few projects I’ve been on where asking these sorts of questions at the beginning would have saved us lots of time and effort later.

I think the book may actually work better as a reference than as a narrative. While it was well-written and easy to read, the density of ideas was overwhelming – there were too many good ideas to keep track of, so I only remember a few. I’ll definitely keep this book on my bookshelf at work and flip through it whenever I’m feeling stuck and need some inspiration. I highly recommend it.


what’s important and what’s not: One favorite story I have from my days at Signature was when our instrument prototype was generating tons of data that nobody knew how to analyze. The “real” software team came and asked the biologists what software they needed to do the analysis, and the biologists told them that since they didn’t know what the data meant, they’d need to be able to graph every axis against every other axis and do all sorts of other crazy mathematical analysis. The programmers went off to go design and implement a solution to do what the biologists had asked, which was going to take months since they had asked for so much.

I knew the biologists better, though, and said “Here’s a tool to dump the data to Excel, where you can graph it yourself and play with the data directly”. They started playing around, figured out the two or three critical pieces of data for what they were observing, and then I built them an analysis tool that graphed only those pieces of data. We had a working solution before the “real” software team had even completed their design of the singing, dancing, do-everything software that had been requested in their naive requirements gathering process.

Leave a Reply

Your email address will not be published.