Last Wednesday, as part of our "Design Discussions" session, my team and I watched the "Paradox of Choice" lecture by Barry Schwartz. We had watched Barry's talk before but we loved listening to the talk again.
While the whole talk is relevant, one area that is particularly relevant to Product Design of Software is "Capability vs. Usability". Barry opines that customers buy a product on its "potential" or "capability" and its only later, during usage, that they become aware of its "Usability". He goes on to make many more important points that include the point that customers know that the usability of the product is not the same as its capability, and yet many products are bought on their mere capability. Now this is very significant if we extend and evaluate the way we design and sell software products. I know that Product Managers face the dilemma of whether to build features at the risk of feature-overloading or spend effort in keeping the product simple and useful, while road-mapping for their product and I think the "Paradox of Choice" should provide them the starting point to apply to Software Product Development.
A simple way to think about it in the context of Product Development of software both for the enterprise and the individual consumer is as follows (these are just my initial thoughts and I am still trying to wrap my head around it - i am hoping comments from readers will provide more insights):
1. The Feature-Rush Approach : Product Management and Product Marketing almost always rush to build more and more features to stay ahead of competition. Now, this may seem bad, given the fact that this mad rush can hamper quality and usability of the product. However, the fact that most customers will judge and make a "purchase decision" on mere capability (the list of features), makes this "feature-rush" approach attractive. For many large enterprises, software purchase decision is made by the procurement organization or the CIO/CTOs who don't use the software themselves, but buy it for the organization. Such people are more likely to evaluate the software on its capability rather than usability. This is one of the reasons for success of Microsoft software in the enterprise space. Even large and credible brands are not immune to the "Capability-Buy" phenomenon. Enterprise 2.0 vendors, while trying to make the product usable, will still need to be feature-capable in comparison to existing products, if they want to make any impact on the enterprise space.
2. The Use-and-Buy Approach: If you are really concerned about building a kick-ass product, that users love to use or betters their life, you will need to let users use it before they buy it. This is the approach most Social Media and Direct-to-Consumer products take. The best example is Google's Search. To be able to really be successful in this approach, you will need the conviction and the staying power of an innovator and the ability to keep persisting, before users see the benefit of your product and move in. Initially, the field will be spread across multiple such vendors, but if you really have the "killer app" with the best user experience, you can be sure that users will stick by you.
/Topic Tags in this Blog
Friday, 23 January 2009
The "more is less" paradox in Product Design
by saumitri at 5:58 pm
tags: more is less, paradox of choice, software product development, Web 2.0
Bookmark this on Delicious
No comments:
Post a Comment