A Theory of Simplicity

by Krishna on November 17, 2007

Simplicity is one of those goals that everyone talks about, but few achieve. When designing applications, simplicity is supposedly a paramount concern, yet many applications never achieve that state. Very often, we see simple applications that are very basic in terms of functionality. Or, we have highly functional applications that are very complex for end users.

I believe a reason for this situation is that people consider only 2 stages of simplicity — “simple” and “complex”, while in fact, there are 3 possible stages as follows:

Simplistic -> Complex -> Simple

The arrows designate the passage of time in designing and creating such applications.

When you design an application to meet a particular need, you create a “simplistic” application that caters to that particular need. It does not meet any other need, but it is easy to use. This is a good strategy for designing version 1.0 of an application. You can focus on the most important need for your customers and create an application that meets their needs, without making it cumbersome to use. In other words, do not try to make everyone happy, just your core customers.

Once your application is in production, users will clamor for more features that may or may not be directly related to your core product objectives. For example, they may ask for export functionality of certain data to another application. To stay in business, you must try to meet at least some of those demands; otherwise you will lose your users to your competition. As you add more features, the complexity of your application keeps increasing. When you add more clutter, your software becomes more difficult for new users who find it complex and hence may be lost.

The challenge, therefore, is to add new features without sacrificing ease-of-use of the application. One strategy is to let the application become cluttered, refactor the user interface, become cluttered again, repeat. Another, probably better strategy is to carefully understand user interface implications before adding new features. The latter is not always an option when you are faced with competitive pressures.

In the real world, we find different companies coming out with applications in each phase, and making the older products obsolete. For example, first generation simplistic cell phone just made phone calls. Then complex phones came out with several functions and accompanying complex user interfaces. And now you have the iPhone and other newer generation phones.

Many people confuse “simplistic” and “simple”. If your software doesn’t do much, it can be very easy for end users. It can also be very easy to develop. But your end users will get frustrated when the application does not grow to meet their needs. And, your application will be easy pickings for your competition to copy.

Thus you have a paradox: You have to continuously add complex behavior into the software while reducing (or least not increasing) the complexity it presents to the user. That is true simplicity.

Comments on this entry are closed.

Previous post:

Next post: