Navigation Menu




With Software, Sometimes Less Is Less


By Dharmesh Shah
Expert Author
Article Date: 2007-12-04

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

Comments

About the Author:
Dharmesh Shah is a serial software entrepreneur. He is the author of the widely read startup blog OnStartups.com which focuses on advice and ideas for startup founders and management teams. Dharmesh is also the co-founder of HubSpot.com, a software company building applications that help small businesses transform their website into a marketing machine.


Get Your Site Submitted for Free in the World's Largest B2B Directory!

Email Address:
* URL:
*
*Indicates Mandatory Field

Terms & Conditions

AppDevNews
FlashNewz
DevWebPro



Newsletter Archive | Article Archive | Submit Article | Advertising Information | About Us | Contact | Site Map

ApplicationDeveloperNews is an iEntry, Inc.® publication - 1998-2008 All Rights Reserved Privacy Policy and Legal

With Software Sometimes Less is Less