If you’ve ever been asked by a product team for an innovative design, you should read Don Norman’s recent article. Its in the March – April 2010 issue of Interactions Magazine. Don has a way of pissing people off with his ideas. This article “Technology First, Needs Last: The Research-Product Gulf” is a no exception. He says it was controversial even before it got published.

I like controversy because it makes me think.

Don says: “Design research is great when it comes to improving existing product categories, but essentially useless when it comes to breakthroughs.” He says that most design techniques lead to small incremental changes in product design. Breakthrough innovations are difficult. There is an interesting parallel in evolution. It is now believed that simple genetic changes based on Darwin’s theories caused only minor changes in species. The wide range of variations in species that exist today were caused by discontinuous changes brought on by mutation. It is as if genetic changes, like design theories and methods cause only small changes: for big leaps we need mutations. Design mutations perhaps?

If Don’s right (and I think he is), this is a big problem for a design team. Every design team gets asked for innovative designs. But, if all the techniques we have only make incremental changes, then we have a problem.

So what can a design team do when it gets told that the next release needs to be innovative? My reaction to this is something along the lines of “GREAT! Now lets talk!” I’m not into complaining that the product team doesn’t know anything about design (they don’t have to); or that the request for “innovative” sets the design team up for failure. I am delighted when I get to work with a product team that wants an innovative product. The opposite is a death march. When a product team says that the next product must be innovative, I hear two things. First I hear that they care about their product, though they may not have the vocabulary to express what their design needs are. Second I hear the product team say “Hey, we need a great product, can we count on you to deliver a great design?”

What we as designers need to do is to change the conversation. The conversation needs to move from creating an innovative product to one about the right design. Along the way the design team needs to build credibility and get the product team to trust the designs. This is not hard.

Interaction designers are great at understanding what users need. Most of us don’t apply that skill to understanding what the product team needs. We need to apply a little of that skill to the product team, to understand their motivations, what they consider a successful design, and what they consider innovative. That is a series of conversations between the design and product teams, and they don’t have to be formal. The conversations must be at two levels. One is the mundane: what are the feature and performance goals of the product. What should a user be able to do? What is the competition? What are the performance metrics? etc. This is all boiler plate design work that we all do.

The other set of conversations is aspirational. The product team needs to love their product. The design team needs to understand what it will take to make that happen. They must understand what the product team considers innovative. They should look at examples from the product team. They should have examples of their own ready to show the product team. By showing the product team what they consider innovative (and why), the design team builds credibility and shows that they know what innovation is. That helps answer the hidden question “Can we count on you to deliver a great design?”

The designers will usually find that the product team’s definition of  innovative can be broken down to a few relatively simple things. Sometimes its color: some teams like dark colors, others light. Some like gradients, some animations. These attributes serve to narrow down the range in which the designers need to explore, and can usually come up with a a set of variations that the product team likes and can choose from.

Next the design team needs to establish that they have the design chops that the product team is looking for. Once the product team has confidence in the design quality, the discussion will move away from “innovative” to “the right design.” For products that are old and crufty establishing design cred is surprisingly easy. The designers can build prototypes that do away with the cruft, and create a clean, simple experience.

The Caiman installer for Solaris / Open Solaris that we worked on a couple of years back is an example. The lead designer on this went back to the drawing board to design the installer. He thought about what a modern OS install experience would be like. He then backed up his ideas with thorough research of existing installers. He built an HTML prototype that looked like the real installer. This prototype was amazingly ‘lifelike’ and even faked a BIOS screen. When he demoed the prototype, he would put the browser in full screen. This made the prototype look completely convincing because the whole screen was taken up by the prototype and it looked like the OS was actually being installed. Two things worked in his favor. First, his research of the other installers was so solid that no one could tell him about an installer because he’d seen them all. Second, the prototype was magical. Everyone knew it was a web page. They could point their browsers at it. Yet, it looked exactly like the real thing. That bit of magic really made the product team pay attention. And when they looked at the prototype, they realized it was exactly what was needed, and the designer had all the credibility he could ask for. The team’s focus then shifted from creating an innovative product to creating the best experience possible.

Another way to establish that the designers have great design skills is to show the product team lots of quality variations. This can convince the rest of the product team to go with the design team’s recommendation.

Here is another example: We were designing the Java Store. For the ‘home screen’ we needed a way to let users explore the store content in a “non-linear”, sort of “guided exploration.” Its a bit like wandering down the specials aisle of a physical store. There was general agreement among the product team that we needed an “innovative” animation, but a lot of concern about what that meant. We had to move the conversation to one about “the correct” animation. One of the designers in the team was very very prolific, and could produce lots of animations in short order.  He teamed up with a visual designer who could keep the visual design quality very high. Between them they created a whole series of animations, some unique, some frivolous, all outstanding.

The design team had two concerns. First, we wanted to show that we could get the “right” animation. Second, we were concerned that the home screen was too busy. There was too much going on, and the users would get overwhelmed. So we showed the product team lots and lots of animations that we worked on. That made it clear that we knew what were doing and that we’d been quite thorough in our exploration. Once that was established, we showed the product team some of the things that concerned us, and they agreed. The animation that the store ended up is a simple flow, sort of like a “river”, in which product icons float by on a stream. Its pleasant, almost soothing. The team loved it. You can try it yourself: download it from the Java Store website.

So when a product team tells you that they want an innovative product, grab that as an opportunity to learn more about what they want, and you won’t be disappointed.