Wednesday, August 29, 2007

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.

No comments: