Why Some Software Is Not Simpler, Just Suckier

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.

Community

Google+

And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:

Google

Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Answers.OnStartups.com

Subscribe to Updates

 

30,000+ subscribers can't all be wrong.  Subscribe to the OnStartups.com RSS feed.

Follow me on LinkedIn

OnStartups

Current Articles | RSS Feed RSS Feed

Why Some Software Is Not Simpler, Just Suckier

 

There has been a lot of discussion on the web about the value of simplicity in software. Generally, I agree with the notion of simpler being better (all other things being equal). But rarely are all things equal.

The goal for software developers should not be to make things simpler just by reducing features. The goal of software should be to make it simpler for the user to do what they are trying to do.

Too often lately, I've seen software that makes users do unnatural things in the name of simplicity. The common defense for not adding something is that it would make the user interface more complicated and/or there's a workaround.

The behavior seems more motivated by selfishness than simplicity for the user.

When trying to decide whether a given feature or capability should be added to a software product, here are the things I ask myself:

1. What is the user trying to accomplish? Will this make it easier for her to accomplish it?

2. By not adding this feature, am I likely making the user go through an unnatural act?

3. Is the existence of this feature expected? Will it delight users by being there? Will it frustrate users if it's absent?

Of course, all of the above are reasonably obvious questions that boil down to one thing: Will the feature make the users you care about happy? A sub-optimal line of reasoning goes like this: "Users hate complexity. So, users like things that are simpler. By not adding feature [X], things are simpler. Hence, it will make users happy if I don't add [X]." This is an indirect way of thinking about making users happy. I prefer a more direct path: Will adding feature [X] make a majority of my users more happy?

There's also the temporal dimension: Things that make users a little unhappy today, might make them a lot happy later. Examples are advanced features that users are unlikely to want/need in their early experience with the software are often *critical* at some later point. A powerful "export" feature is often examples of this.

For those that think that I'll I'm doing rationalizing and promoting bloatware, I'm not. I hate bloatware. Not just because of the impact on user happiness but also because unused features are like unused inventory. It costs money and is bad for business.

For more on what I think on this topic, you can check out a previous article:

Disagreeing With 37Signals: Less Is Sometimes Less

By the way, this blog just hit the 8,000 RSS subscriber benchmark. If you liked this article, now would be a great time to subscribe: Here's the feed URL: OnStartups RSS Feed




Posted by Dharmesh Shah on Wed, Nov 28, 2007

COMMENTS

Nice post Dharmesh, These things are always hard to decide upon, even harder to generalize, but I'll give it a shot as well :) If implementing a new 'deep' feature requires you to add complexity to other broader parts of the product, there is a very valid need to reconsider adding the feature. Or in other words, if adding something that's going to make a couple of users really happy constitutes having to make a lot of users just slightly unhappy, you have to weigh serving a bigger crowd versus the quality of the overall user experience. We've encountered and decided upon many such trade-off situations while developing our software. The right balance between those two (user base / user experience) is determined by the goals you set for your product, there's no single ideal balance. That's one side of it, the other, as you mentioned above, is the development team not adding features that don't get in the way of the broader part of their user base using the 'less is more' meme as an excuse for the feature not being high enough up on their priority list or in the worst case lazyness.. I do believe that almost anyone who's developed a product that is in use by a whole bunch of people is committed to taking good care of his/her baby (the product that is). You may call it naivité, but I think laziness is rarely the actual reason for something not making the cut, especially in the start-up phase of the developing company and/or the product. cheers, dirk

posted on Wednesday, November 28, 2007 at 3:16 PM by Dirk Stoop


There is a very delicate line between just right and overboard especially with initial offerings. It will always be sensible to balance between the features of the product and its target market. More often, adding new features comes later when early feedback rises just before clamor. Best. alain

posted on Wednesday, November 28, 2007 at 7:30 PM by Alain


I agree that keeping your software/solution simple enough not to thwart users it is equally important to keep alternate ways like keyboard shortcuts to accessing more "deep" features. doing this would keep your UI simple and keep functionality available to a userset that desires it. anyways there can be workarounds wherein a user can define his/her own keyboard shortcuts for certain frequent used functionalities and thus overcome the "complexity factor" generally attributed to a vertically deep software/solution.

posted on Thursday, November 29, 2007 at 2:20 AM by paresh thakkar


With all due respect, I think there is a much more academically-rigorous way to address this question. Software is a means of making a machine act in a certain way. In this thread, we are talking about software that directs a machine to present a certain user interface. A user manipulates that interface to get the machine to accomplish certain tasks. The question of "features" is really a question of how well the abstract model of the system and its user interface matches or maps to the real-world tasks the user is trying to accomplish. If you have a good elegant match,we say the system is "intuitive" and it's easy to use. If there is a bad match, the system is difficult and annoying to use. Think of an automobile. The steering wheel and accelerator are very intuitive interfaces. I lean the way I want to go, and if I want to go faster I push harder. This is much better than the initial interface of a tiller and separate spark-advance and throttle levers. Modern German cars provide another (bad) example: these manufacturers have consolidated a lot of functions (sound system, navigation, security, climate control, etc.) into a single onboard computer and provided a computer-type menu interface to control it all. This interface is universally panned by auto writers and is so complicated that it has probably contributed to crashes due to driver distraction. In this case, the question is not "features" (ie, "does the radio have surround-sound?") but the mapping of the model between system and real world. As another example, Apple products have excelled at matching user interface models to the real world tasks the user is trying to accomplish. That's why non-geeks usually prefer Macs over PCs. They say the Mac is more "intuitive" -- what they mean is that the user interface model of the Mac matches the way they work and think better than the PC does. I think you will find that many "feature" discussions are really "user interface model" discussions. And for user interfaces, "fatter" is not better. Nearly always, if you do a good job of matching the user interface model to the real world task, you will have a simple, elegant, easy-to-use interface. (Mind you, it may take a lot of software to implement that interface. But in a successful system that complexity is hidden from the user, much as the complexity of the Toyota Prius hybrid car is hidden from the driver.)

posted on Thursday, November 29, 2007 at 9:06 AM by Carl Strathmeyer


Nice article Dharmesh. What I've always found interesting is the tendencies of small and large companies to introduce a new feature in its 1.0 form into their app or platform and then abandon further refinement or bug-fixing in order to introduce yet another 1.0 feature somewhere else. Innovation and adding new features is a great thing, but it's important to analyze your system and ensure that the next great 1.0 feature is a) something your customers really want (v. something an executive in your company really wants) and b) something that will integrate into your current platform with relative ease and be maintainable going forward. I think it's also important to heed the words of non-developers that are looking at these new features. If you have them on board, a good QA engineer or Business Analyst can be invaluable (and brutally honest) at informing you on whether or not your new, whiz-bang feature is 'usable'. Cheers.

posted on Thursday, November 29, 2007 at 9:23 AM by Drew Smith


Nice (and bold) post Dharmesh. These days coincidentally I've been through many articles discussing the feature bloating and then, going through yours discussing this is really like pulling me into the real world. Just now the idea comes to me of what "KISS" (Keep it Simple) means actually. It is not 'Keep it Simple' in implementation I think (because you cannot keep a large system away from some minimal complexity) but to keep the software interface simpler for user. In that way I think user is gonna love that additional new feature. (or may be an experiment can be done by hiding the new feature from UI, giving it out through some shortcuts to more experimental user base and getting the feedback..) Seamless integration of the new feature into what is already available as pointed by Drew is again an extremely important aspect to keep in view.

posted on Tuesday, December 11, 2007 at 4:07 AM by Manoj


I do agree that the whole "Less is simple" talk is mostly about the UI side. Carl did sum it best with "in a successful system complexity is hidden from the user".
Simple and intuitive interface is what any system needs. As about features, Joel Spolsky has a great post about it:
http://www.joelonsoftware.com/articles/fog0000000020.html

posted on Monday, December 24, 2007 at 9:33 PM by Sergei Podbereschi


Comments have been closed for this article.