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.