Product Design – Flexible is Fat and Omnipotent is Impotent
I’m a huge fan of Marty Cagan’s book and blog. His most recent post on “The Domesticated Computer” got me thinking about how and why so many products not only take too long to develop but fall so short of user expectations.
I’m convinced that we have a nasty habit of attempting to launch products in all phases of development, and especially in the initial product launch, that simply do too much. While we’ve all heard of the Pareto Principle, it seems that we just don’t apply it to our product development efforts. Far too often we find ourselves in product discussions that look more like congressional pork barrel politics. Features are negotiated based largely on executive pet projects than structured methodologies like Moore’s Whole Product Concept.
As Marty C points out, the personal computer, with all of its flexibility, is still difficult to use in many respects. In the mid 90s I ran a project at Motorola that took computer keyboards off the manufacturing floor in favor of a yes/no device. While the activities of the manufacturing line stayed largely the same, productivity increased. Users indicated that the system was simply easier to use. Nothing changed in terms of keystrokes – only one was still needed. But less was better and faster. More was fat and impotent.
Contrast the PC with purpose built systems like the iPhone, iPod, iPad, Kindle, etc. The latter devices all have relatively limited primary input mechanisms. Sure some of them have keyboards – but they aren’t the primary means of interaction. More importantly these systems are designed to accomplish a subset of tasks as compared to the computer. This limitation in functionality allows for better interaction characteristics and less user confusion. It’s a lot easier to design easy to use systems if the system being designed only needs to flip pages and perform searches or scroll through and play music. As my partner Mike Fisher points out, there are probably reasons why kitchen appliances still largely do one thing rather than a combined fridge/toaster/fryer/baker/washer.
But what lesson does this have for us in designing web applications? Less functionality leads to less confusion, easier interaction development and faster time to market. Develop the 20% of functionality that will deliver 80% of your revenue and refine it until its perfect using multivariate (or simpler A/B) testing. Speed and focus is so much more important in web based properties, especially in early releases, than breadth and depth of functionality. The folks at 37 Signals say that you can always do less. Our point is not only that you can do less, but that you SHOULD do less. Less is faster. Less will allow you to get the core functionality out and perfected quickly. Less wins.