Thursday, March 29, 2007

Essential Interface Complexity

After reading a very interesting and insightful post on the Subtraction Blog I got to thinking about what it means for an interface to be "as simple as possible".

The kernel of the post is that for most software if you are going to offend/annoy anyone, you want it to be the experts. This is because for most software the experience level of users is distributed along a bell curve. And that mean that the vast preponderance of users live smack dab in the middle (or at least in the suburbs of the middle).

Now, while true for some software, I think it is far from true for all software.

It is obviously true for the majority of consumer software (and products in general). I want my tools/products to do one thing and to do it clearly and well. Less really is more in this kind of simple "I want my music to play" or "I want that text to be red" kind of tool.

However, there is another kind of tool. That's a tool for dealing with very complex problems. There is an entire class of problems sometimes called "wicked" problems (ref. that don't really have a simple solution. In this case it may be best to think of the problem (and the UI) as having no beginner/intermediate users.

There are numerous tools that take this approach when the problem is hard (or there is a negligible number of non-expert users).

  • Mathematica
  • Call Center Tools
  • Development Tools
  • etc

It is perfectly fine to want an interface as simple as possible. But it still needs to be complex enough to capture the essential complexity of the problem you're trying to solve. And the problem(s) that these tools are trying to solve are either extremely complex or the novices get "learned up" real fast.

The Eclipse IDE is a good example of a product geared directly to an expert end user. There is little done to hide the complexity of the tool from the user. In fact, the tool allows an enormous amount of complexity (compare it to an iPod) in order to perform all of the tasks that are essential to the product.

But in a sense it is also about as simple as you could possibly make it without losing the essence of the problem that they are trying to solve with the IDE. On the other side of this is booking some travel on a site like Expedia. Here the actual moving parts behind making a booking are incredibly complex (I used to work for them and let me tell you, airlines and hotels do not make it easy on them). But what the user wants to do has little essential complexity.

"I want to go to Hawaii for 5 days next month and stay at the Hyatt on Maui" is pretty friggen simple.

That's why a "give me my crap and here's some money wizard works so well for sites like Expedia and Amazon. The user really wants something conceptually simple. It is also why a "write Office 2011" wizard would not work so well.

Easy? Yes.

Simple? Yes.

But it lacks something essential.