Build only what's absolutely essential for your web application
Ask yourself how many times you've added a feature to a Web Application because it is relatively simple to build and you 'think' users will find useful? I've certainly done this as have many other developers, so you're not alone. The problem with this approach is that it's over complicating your application and probably creating lots of hidden costs.
The biggest cause of these 'feature battles' are down to the demands of our users. We constantly receive feature requests for all sorts of functionality, most of which will only ever serve a tiny percentage of our user base.
"Features used by only 10 percent of users, or used only 10 percent of the time, are added and get in the way of the remaining 90 percent of the features. They clutter an otherwise clean interface. They interfere with the features used most often." Robert Hoekma, jr.
Uncessary features will lead to user frustration The more features you build, the more complex an application becomes and the more frustrating it is for your users to use. You'll find that if you keep building features that aren't absolutely essential, these are the very features that you'll end up spending most of your time supporting, debugging and fixing. The focus needs to not be on building features but building features that are focussed on supporting the core activity your Web Application is designing for.
What can you do differently
Get away from this idea that killer features will keep you ahead of the competition and make your application more attractive to your user base. In the short term you might have some small wins but in the long run it will become exhausting for your users as your application becomes harder and harder to use. Time to think differently.
Drop nice to have features
Everyone has attended meetings with discussions along the lines of, "Wouldn't it be great if we had X?" or "I saw this really cool feature in X, can we do something similar"? These meetings are dangerous and we have to identify these nice to have features and cut them from our web application. One company that have done this incredibly well are 37Signals whose approach is:
"Don't be afraid to say no to feature requests that are hard to do. Unless they are absolutely essential, save time/effort/confusion by leaving them out". 37 Signals, Getting real.
Constantly ask yourself if this feature will contribute directly to the core task your users need to complete. If it doesn't, note it down and store it away.
The paraeto principle indicates that 80 percent of the consequences are the result of 20 percent of the causes. So applying this principle to web application design, means that 80% of an applications usefulness will come from 20% of it's features. Spend time on these key features that are going to provide 80% of the usefulness. Don't get bogged down spending 80% of your time satisfying 20% of your users.
Listen to your users an revaluate nice to have features
Once your application has launched, you can return to your list of nice to haves and see whether anything has changed. Let your users tell you what's really needed but don't falter under pressure for requests for features that don't support the core purpose of your web application. 37 Signals call this "tough love":
As a software development company, you have to act as a filter. Not everything everyone suggests is the right answer. We consider all requests but the customer is not always right. There are times when you just have to piss some people off. C'est la vie. 37 Signals - Getting Real.
If you've just started building an application, start off with saying no to every feature. Work it hard before it finds it's way into your list of features. Focus on only including features that help a user achieve the core activity of your web application. Listen to your users but put there suggestions through the same scrutiny as you would with your own suggestions. Your users are incredibly important but they're not always right. Final note - this post is based on the book "Designing the obvious" by Robert Hoekman. I'd highly recommend you take a look at this book if you want to find out more about this topic.Tweet