Designing options

One of the biggest temptations for designers and customers alike is the addition of options. Options, options, options. How can you have too many options? You know when you have too many options when using a product becomes daunting. JRiver Media Center is a good example. I can barely get music to play without having first spent half an hour wading through the setup options. Yet, once going it's a fine program. As a user, I want lots of options but only if they're buried deep into the product. When I first fire up a piece of kit or a program, it should just work right out of the box. Later, if the urge strikes, I can delve into the secondary layers of options that cleverly lie underneath the surface. As designers, options are a true double-edged sword. Committing to a product without options means you've not only thought through what's needed (and not needed) but you're so confident in those choices you're willing to be rejected by potential customers who expected a feature or function that's unavailable. And, on the flipside, building in options increases the workload rather dramatically. Just imagine the hours of programming required to add the option of input naming: building a virtual keyboard, figuring out how to access it, allowing for mistaken entries, setting limits on character lengths, storing and retrieving the data, editing. We can't make products with so many options they make everyone happy, yet we have to offer enough that the product fulfills its purpose. My preference has always leaned towards purpose-built products where the designer takes a stand and puts their name on the product. "This is what I would want in my home". Of course, the alternative might just be a full-featured option-rich entry from Lirpa Labs! Wait. I missed April 1.