UIE: Interview with Scott Berkun

UIE has posted a short interview with Scott Berkun, author of The Myths of Innovation, which I have reviewed previously.

The best part of the interview is Berkun's response when asked whether there are situations when teams should NOT focus on innovation. Berkun replies:

Yes! Thanks for asking! I think innovation is overrated. Customers don't care about how innovative you are. They just want to be happy and satisfied. And that's about good design.

The best advice I can give is to focus on people and their problems. Few great innovators worried about anything else. The fact that they found a new idea had more to do with their passion for solving someone's problem than anything else. Innovation is a huge distraction these days. That's one of the myths I hope people will understand how to dispel from reading the book or attending my seminars.

I thought this was great, because I've always felt there was something hokey when companies encourage innovation for the sake of innovation. Who cares about innovation if the innovation is useless? The trick is create a culture in which problems that don't seem to have an existing solution are seen as opportunities for innovation, rather than dead ends. It's all about problem solving.

Book Review: "The Myths of Innovation" by Scott Berkun

Have you ever been to a party and met someone with a great job and a great sense of humor and ended up spending the entire party drinking beer and swapping interesting stories? That's what Scott Berkun's new book, "The Myths of Innovation", felt like to me. There are lots of books on my shelf that I know I ought to read, and many of them I struggle through and afterwards feel like it was a valuable investment of my time, however painful. This wasn't one of them - this is one of those rare books that feels like reading for pleasure, and yet you learn something along the way.

And I might add that the colophon alone is worth the price of the book (a sentence that perhaps has never been written).

I wonder how much time and research Berkun did on this book before he came up with the idea of orienting the book around myths? Was that the idea all along? Or did it emerge over time? Because it turns out to be a perfect way of presenting the material. First, everyone loves to feel like they know something that other people don't - the truth behind the myths. This "peeking behind the curtain" approach is a great way to keep the material interesting. Second, innovation is such a complex area that it would be very difficult to write a book about what innovation is -- it's a lot easier to talk about what it isn't. But by providing the boundaries via the myths, it inevitably provides great insight into how innovation really happens. And third, myth debunking seems to fit Berkun's auctorial voice. His casual, conversational tone is not only funny and engaging, but it naturally allows the type of speculation and interpretation that is necessary for the topic. In other words, a textbook-style examination of innovation would be a very poor choice.

While I enjoyed the entire book, I particularly enjoyed in the section on the myth of "the best idea wins". In it, Berkun describes the many factors that are involved in whether an innovation succeeds, and how being the "best" is only one of many factors. When it comes to design innovation in established software, the impact of "dominant design" is always a challenge - what is the cost of moving to something better when you have a large customer base who already knows how to use the product? One example in the book is the QWERTY keyboard that we all know and loathe. But to lesser degree this is always the case - I can't convince my wife to move from Paint to Photoshop for editing pictures because she knows how to use Paint. Whenever I try to tell her about how many great features there are in Photoshop, all she hears is "blah... blah... blah... [it will take lots of time to learn]... blah... blah... blah."

I recommend this book highly to anyone who has a job where innovation matters... which is just about everyone.

Is simplicity a valid goal?

There's been an interesting discussion happening within the online user experience community recently on the virtues of simplicity (or lack thereof). Legendary Don Norman kicked off the debate in an essay titled "Simplicity Is Highly Overrated". Excerpt:

Why is this? Why do we deliberately build things that confuse the people who use them?

Answer: Because the people want the features. Because simplicity is a myth whose time has past, if it ever existed.

Make it simple and people won’t buy. Given a choice, they will take the item that does more. Features win over simplicity, even when people realize that it is accompanied by more complexity. You do it too, I bet. Haven’t you ever compared two products side by side, comparing the features of each, preferring the one that did more? Why shame on you, you are behaving, well, behaving like a normal person.

Basically, Norman's argument is that people say they want simplicity, but when it comes time to make a purchase decision, they go for features.

Joel Spolsky followed up on Norman's essay with some thoughts on his own experiences, specifically that people often confuse simplicity with aesthetics. Excerpt:

Devotees of simplicity will bring up 37signals and the Apple iPod as anecdotal proof that Simple Sells. I would argue that in both these cases, success is a result of a combination of things: building an audience, evangelism, clean and spare design, emotional appeal, aesthetics, fast response time, direct and instant user feedback, program models which correspond to the user model resulting in high usability, and putting the user in control, all of which are features of one sort, in the sense that they are benefits that customers like and pay for, but none of which can really be described as “simplicity.” For example, the iPod has the feature of being beautiful, which the Creative Zen Ultra Nomad Jukebox doesn't have, so I'll take an iPod, please. In the case of the iPod, the way beauty is provided happens to be through a clean and simple design, but it doesn't have to be. The Hummer is aesthetically appealing precisely because it's ugly and complicated.

Not surprisingly, not everyone thinks simplicity is overrated. On Scott Berkun's blog, he provides a defense of simplicity. Excerpt:

It’s easy to confuse success with quality, and both articles discount our secret inability to make satisfying choices. We are attracted to things with more features, that cost less, or come in larger quantities, despite our inner suspicions that we’re likely to complain about those purchases soon after. We date people, eat food, take jobs and buy products for superficial, misguided reasons all the time. We’re easily seduced, and every marketer knows we always have been and always will be.

But we shouldn’t confuse the success of feature-laden crap as a signal for the irrelevance of simplicity any more than the success of Rocky IV and Burger King signaled the irrelevance of good film-making or fine dining. It just means there are gaps between what we need, what we want, and why we buy, and that the masses are by definition less discriminating than the niches of people with refined tastes for a particular thing.

Berkun is basically arguing that there is still a place for simplicity, even if most folks don't give enough thought into their purchases to look for it. He also concludes by saying, "Simple design doesn’t mean brain death: it means being being as simple as necessary to achieve a great experience for a group of people, but no simpler."

When it comes to enterprise software, I think this discussion is even more relevant. Those of us in user experience often here the calls to deliver "simplicity", whether we're working on a small troubleshooting utility or highly available, performance-tuned, enterprise-capable application serving capability. "Make it simple!" we're told. This has long been one of my pet peeves, and the articles above touch on my beliefs, but don't quite capture them. Ironically, in his defense of simplicity, Berkun comes closest to capturing why I think "Make it simple!" is a mistaken goal. I think that saying "...as simple as necessary... but no simpler," is another way of saying "simplicity is NOT the goal."

Let me use an extreme example to make my point. Let's say we could create an application server product tomorrow that is so simple that all it requires is an on/off switch (I believe this can be done through the use of pixie dust). We release it and everyone raves about how simple it is. Until someone tries to use it and asks, "Uh, it was really easy to turn on, but I need a way to actually deploy my application." Well, okay, so we add a button for installing an application. That's not too bad, just one more little button. Still simple... and then someone says, "Great, I have my application running. Now I have an update to the application. What do I do?" Well, we could add another button for updating an existing application, but why bother? The product would be much simpler if we just have the user create a new server and install the new version of their application on it -- then we don't need to add another button!

Obviously, that would be a terrible decision. Why? Because creating a simple product is not the goal. The goal is to create a product that allows users to achieve their goals... and sometimes those goals are complex. Especially when it comes to enterprise software. If a customer has a goal of trying to maintain the value of their legacy systems by creating external services on top of the old systems that can communicate with newer systems, an on/off switch is not what they are looking for.

Obviously, unnecessary complexity is a problem, and IBM needs to do a better job of eliminating unnecessary complexity. But not because simple = good and complex = bad. We need to reduce unnecessary complexity because it interferes with a user's ability to achieve their goals. Simplicity, in and of itself, is not particularly relevant.

Side note: Of course, the challenge for the user experience engineer is that a feature that adds unnecessary complexity for one user is absolutely critical for another, so providing the features necessary to allow users to achieve their goals while also eliminating unnecessary complexity sometimes makes me feel like a circus contortionist. But that's a topic for another day.