jump to navigation

The Art of Innovation February 7, 2011

Posted by bdlocks in Design Thinking.
2 comments

The Art of Innovation, by Tom Kelley, pays homage to IDEO, the world-class design firm for which Kelley is the General Manager. The book shares knowledge, expertise, methodologies, and work practices around innovation by drawing on IDEO’s experiences by mixing the firm’s innovation road map with glorified case studies.

Kelley discusses the need for innovation in all companies: “Out there in some garage is an entrepreneur who’s forging a bullet with your company’s name on it.” This mentality seems to align with Clayton Christensen’s The Innovators Dilemma, which highlights that companies sometimes focus on sustainable technology versus disruptive technology; Kelley and IDEO focus on the latter to help companies dodge “bullets”.

The IDEO method is broken down into five steps: (1) UNDERSTAND the market, client, technology, and constraints, (2) OBSERVE real people in real-life situations, (3) VISUALIZE new-to-the-world concepts and the customers who will use, (4) EVALUATE AND REFINE the prototypes in a series of quick iterations, and (5) IMPLEMENT the new concept for commercialization. Kelley dedicates several chapters to these five processes and interweaves fascinating IDEO stories as examples. These stories involve designing grocery shopping carts, toothbrushes and toothpaste bottles, medical devices, the interior design and layout of an Amtrak train, and a winged football with the perfect spiral.

I’d highly recommend the book to individuals who know very little about design and desire to learn some core principles while reading Kelley’s engaging IDEO stories. For those with some design experience, I’d recommend starting with the table of contents and jumping around based on your areas of interest. In line with IDEO, the book is very intuitively and logically laid out for readers to roam as they please. More than anything, Kelley provides an inside look at IDEO (especially in the early chapters), which even the greatest design guru would enjoy. It sure made me want to work there!

My favorite overarching principles in the book were leveraging the community and the importance of speed.

Leveraging the community is a significant part of the design process; whether it’s your team within a company, current or prospective users, or others that have experience with the problem you are trying to solve. You must go outside yourself and immediate team to find any and all solutions; even the really crazy ones. This concept of community impacts several stages of the innovation process. You must go out and watch people and observe how problems impact them. You must bring diverse point-of-views and talents to have truly effective brainstorming sessions. You must work as a cohesive team to solve a single problem but be open to any and all solutions. In every facet of innovation, the power of community far exceeds that of the lone genius.

The faster you can come up with innovations, the more likely you will achieve marketplace success. The book primarily focuses on the concept of speed through discussions of prototyping and rapid development, which are not mutually exclusive. Once you’ve identified the problem(s), prototyping helps identify both good ideas and bad ones. You determine which ideas to build off of and which ideas to be wary of as you continue to build. Prototyping mitigates the risks of excessive development and refactoring, but speedy development needs to be practiced. Companies and teams should look to break projects down into milestones so that they can practice rapid development and iteration.

I’m currently working on a venture where these concepts of community and speed have definitely struck a chord. I’ve always firmly believed in the fundamental of designing something around the solution to a problem. However, with this venture, even though we’re convinced that we’re addressing a universal problem, we only focused on our own and a few other’s perceptions of the problem to build our solution. We sent a survey to prospective users about features, but we didn’t observe or interact with people while they dealt with the problem we are looking to solve. We designed prototypes, but we didn’t test them with users. Instead, internally, we discussed (for weeks) what we thought was most important and how we thought people would use it. We then built (over two months) a working prototype for which we’ve just started user testing. The result: we have to make SIGNIFICANT changes to our design and we’re taking a huge step backwards and starting paper prototyping. Had we leveraged the community and focused on speed we’d likely have a product in hand. Lesson learned.