Members Only Logo  

or Subscribe by Email by entering your address below:

Powered by FeedBlitz
Learn about Subscriptions Follow me on Twitter!

The topics discussed here grow out of the bread-and-butter issues that confront my consulting and software clients on a daily basis. We'll talk about prosaic stuff like Membership Management, Meetings and Events Management and Fundraising, broader ideas like security and software project management, and the social, cultural, and organizational issues that impact IT decision-making.

Monday, April 03, 2006

Defeating Feature Fatigue

Harvard Business Review does not let you read their articles online, so I can only point you to an abstract of this interesting piece from the February issue on the HBR site. I'm back on the complexity in IT design issue again: this article provides some empirical support for the argument I was making in that post - that following users requests for system features can lead developers to build software too complex to use effectively. The three authors of this paper (Roland T. Rust, Debora Viana Thompson, Rebecca W. Hamilton ) were looking at a different domain - consumer electronics - but my observations are that their conclusions are right on. From the abstract:
...even though consumers know that products with more features are harder to use, they initially choose high-feature models. They also pile on more features when given the chance to customize a product for their needs. [Boldface is mine] Once consumers have actually worked with a product, however, usability starts to matter more to them than capability.
And indeed, in the study, they found that additional features lowered customer-reported usability and satisfaction. The researchers provided prototype 7- and 21-feature dvd players to the survey participants for actual home use in the final stage of the study. Despite the fact that users in the "customization" part of the study overwhelmingly favored adding features, users in the "actual use" component were happier with the units with fewer features.

So this is a real conundrum for folks like us who customize software applications and database systems for non-profit organizations. How do we convince users that some of the complex feature requirements that they present us with may in fact make their systems less usable, not more? Even better, how can we identify those feature requests? More on this later.
Tags: , ,

Comments on "Defeating Feature Fatigue"


Anonymous Anonymous said ... (April 3, 2006 at 9:02 AM) : 

NPR's Susan Stamberg interviewed Roland Rust on March 11. Listen online at Electronic Options Creating 'Feature Fatigue'.


Anonymous Anonymous said ... (April 4, 2006 at 8:47 AM) : 

As custom software developers we try to steer clear of what some organizations deem their "required features" and try to focus clients on usability and adoptability from day one. When working on design we also include system users as well as management to ensure that everyon'es on the same page.


Anonymous Anonymous said ... (April 4, 2006 at 10:19 PM) : 

That sounds familiar. As an ex-developer, I always had to struggle with this problem. That's why I'm so impressed with the developers at My org uses this product - it's fast, simple and intentionally reduced in feature set in order to accomodate a quick learning curve and I hope they keep it that way. On the other hand, they just rolled out an API for their app. Perhaps by offloading complexity to third-party developers, it can keep their product from developing a serious case of featuritis.


post a comment