There are 2 principal problems with computers and software. The first is our understanding and the second our expectations. Think about this. In schools computer class implies teaching usage of the computer. If I suggested, 2 years of Geography should revolve around reading the map, you’d laugh. But we have no problem with our kids spending 2 years learning to use the computer. The same kids who teach us how to use our mobile and other futuristic gadgets. This leads all of us to start believing in the superiority of the PC, and treat it with almost God like reverence.

The second is our expectations. Our expectations from the software are very little. We expect a huge learning curve. And that’s exactly what we get. Creation of software is considered to be principally a development activity, a science. However, it is art and should be treated as such.

The user should be able to call the shots. The telecom industry has a great model. When we pick the phone, there’s a dial tone, we dial the required number, it rings, the called party answers and we speak. So simple that even 3 year old kids can use it. Software can and should be designed like that.

One of the reasons for the current complexity of software is the initial interaction between the developer and the final user. The user draws out his expectations and then is bombarded with a host of questions from the developer. What platform, what database, how many concurrent users, how many levels of security, and so on. The user with some help from his team tries and answers these questions, and this is the beginning of the end. After that the techies take over. And in an attempt to deliver a system that is really good, add as many features as they can. Whether it’s needed or not is besides the point.

The company that has mastered this art is Apple. Just when you think they have outdone themselves, they go do it all over again. The iPod with its phenomenal sales is but 1 example of their creative genius.

Another company that has converted designing simple software to an art is 37 signals. They have made it a virtue, marketed it intelligently and are a huge success.

The individual who has impressed us a lot and is the inspiration behind this article is Prof. Kirti Trivedi. Prof. Trivedi is a Professor of Design at the Industrial Design Centre at India’s prestigious IIT, Mumbai. His approach is very simple. A layperson, and he uses himself as an example (although we disagree), should be able to intuitively use the product with little or preferably no training. He has designed some highly innovative products, including the patented K-Yan. You can see some of his work at Trevue and at Trennova.

Nick Bradbury, the creator of HomeSite, TopStyle and FeedDemon has a blog series called “Simplicity Ain’t So Simple”, where he covered tips for simple software feature design. His 6 rules were simple and said it all. You can also read the articles at http://nick.typepad.com/blog/2007/07/really-simple-s.html

- Decide What to Hide

- Stop Showing Off

- Don’t Add Features You Can’t Support

- The Blessed Curse of Power Users

- Combine Features

- Simple = Secure

And let’s not forget Joel Spolsky and his famous article “Simplicity”. Where he makes an interesting point about the 80:20 rule. “A lot of software developers are seduced by the old ‘80/20’ rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies. Unfortunately, it’s never the same 20%. Everybody uses a different set of features.”

Designing complex software is difficult. Designing simple software is even more difficult. And to make this difficult task a little less difficult, here are my 10 commandments.

10 commandments to designing Simple Software

1. Identify the purpose. Find a simple solution. Simple for the user. Not you.
2. Identify and design for the minimum input required from the user. And ensure common inputs are required just once.
3. Identify and design for all the different outputs required from the system. Allow the user to customize and save. And then available at 1 click.
4. Design a prototype with the user interface. And get the user to check and test it. Observe the use. And listen carefully to what he says. And also to what he doesn’t.
5. Ensure that no matter what the user does, he can’t mess up. The system protects her and her data. Also allow rollbacks.
6. Create a visually pleasing and appealing interface. Sexy models aren’t the only pretty things people love to see.
7. Use everyday analogies in the design. If you want to indicate a book, show a book spine. Better still, iconize it.
8. Make the interaction intuitive. To the user. Not you. Check this extensively by observing first tome users. And listen to their questions carefully.
9. Have different interaction methodologies for first time users and power users. The power user controls can be hidden. But make sure they’re there.
10. Listen to user feedback. Interpret their responses. And implement whenever possible.