Faux simplicity

It's finally gotten cold enough here in North Carolina (it's 24 degrees outside right now) that I climbed up in the attic and got out our space heater for the kids' playroom. In doing so, it reminded me of one of my least favorite design techniques - what I call "faux simplicity". Take a look at the control panel for the heater:



Wow... it's soooooo simple that it only has ONE button! They even advertise the "1 Touch" interface below the panel. What could be simpler than one button?

How do you turn it on? You click the button.

How do you turn it up to the next degree setting? You click the button and the temperature goes up one setting.

How do you switch it from high to low? You keep clicking the button as it toggles through the high and low temperature settings.

How do you set it be always-on? You click the button until none of the temperatures are lit up.

How do you turn it off? You click the button and hold it down until it powers off.

SIMPLE! One button!

As a real life example, I usually have it set to Hi and 75 degrees. My kids wake up and they're cold so they click it twice (once to Hi/80 then to Hi/Always-on). Then I walk in, irritated, and tell them that the heater doesn't get any hotter just because it's set to always on (they think 75 degree is the temperature that the heater is running at, not the temperature that it shuts down automatically). So I want to switch it back to Hi/75. By clicking the button TEN TIMES.

1. Lo/60
2. Lo/65
3. Lo/70
4. Lo/75
5. Lo/80
6. Lo/Always-on
7. Hi/60
8. Hi/65
9. Hi/70
10. Hi/75

Woops... I clicked too fast and ended up on Hi/80. Now I need to click 11 more times to move it down one degree setting.

By having a single button, they didn't make it simpler, they made it more complex. They didn't simplify the feature set, only the interface, by overloading their single button with a bunch of different capabilities. The interface would be much simpler with an on/off button, "temp up" and "temp down" buttons, and an "always on/temp control" toggle. In this case, 4 buttons is simpler than 1.

The iPod has a similar example of this - the fact that you need to turn the iPod off by clicking and holding down the Pause button. This annoys me everytime. Please, people, On/Off buttons do not add unnecessary complexity in items that are turned on and off repeatedly!

We experienced this in one of our products a few years ago. Customers were complaining that our install was too difficult. At the time, our install process accomplished two things: it asked the few standard, necessary questions so we could put the product onto the machine (install directory, etc.), and a few questions that were required as "pre-configuration" so that the product would work the first time you used it (to our credit, we had reduced this set down to a bare minimum). So what was the proposal to simplify install? Simple! We'll separate the install into two parts! One part is the normal install that you see for every product and the second is a post-installation configuration wizard. By pulling the configuration out of the install, we'll make install way simpler!!

Of course, that's not simpler at all. From the customer's point of view, "install" translates to "all the crap I need to do before I can get the product running", including the post-installation/pre-configuration stuff.

We began referring to this as "small i" install and "big I" Install. Small i install is the "putting the bits on the box" process, and big I Install is the whole enchilada for completing and managing the installation. And we were able to successfully make the point that shifted some complexity from one place to another within the Big I Install is not simplifying anything for the customer, it's just changing where they encounter the complexity.

As discussed previously, "simplicity" is not a valid goal... it's a distraction.

Complex is better than simplistic

Courtesy of Joe Lamantia, I found Dan Ward's "The Simplicity Cycle". It's a quick read, it's free, and it's insightful... all good things. It basically centers around the graph to the right, which represents a product lifecycle.

The idea is that you start in the lower left hand corner, which is "simplistic" in the sense that it's simple because it doesn't do much. As new features get added, complexity increases but so does "goodness" because the user can do more stuff.

But then at some point you reach the middle of the graph and things get interesting. It's basically the complexity "tipping point", because now when you add more stuff (a.k.a. complexity), goodness starts to go down because users are unable to consume the additional complexity. The only way to increase goodness at this point is to decrease complexity.

That's the gist. I recommend reading the whole thing to get the details.

I like this for a couple reasons. First is that it suggests that complexity is not inherently bad. I couldn't agree more with this. Designers who think "simplicity" is the goal of design live in a different world than I do. I also like that Ward uses the term "unnecessary complexity", which is a favorite phrase of mine. Just because complexity isn't inherently bad doesn't mean that there isn't plenty of unnecessary complexity in most software.

I also like that it helps answer the question, "Hey, my product is complex AND successful, so why should I worry about design?" There's a limit to how many features you can add to a product before they become self-defeating. When your customers start to request features that are already in your product, it's a safe bet that adding even more features is going to be trouble.

So I think the graph represents a very useful concept, and makes it easy to understand.

Of course, like most concepts, if we starting poking on it we can find limitations. For example:

• Most products have problems with unnecessary complexity, and that is NOT what the complexity axis is measuring - but I would fear someone walking away from the graph thinking that complexity in general is not something to worry about until you get to the middle of the graph.
• Ward points out that reaching the bottom right of the graph is not the end of the story. The curve just starts back up again. But in reality, what happens is that different parts of a product are probably following their own paths - some in simplify mode and some in add feature mode, so a single line doesn't really represent a whole product.
• The place where complexity becomes too much is different for different users (and sometimes radically different). So the graph is really representing the perspective of one user group.
  

But these are just nits, because I think Ward's goal was to use the graph to present the concept, not to create a formal process or an accurate depiction of every variation under the sun. And it does a good job at that... the concept is useful and the book introduces it quickly and easily.

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.