Archive for April 29th, 2011

Have you heard anyone tell you that they use less than x% of the features in [your software here]? x is usually somewhere in the range of 10 to 50.

Part of the reason may be that the need is limited [and therefore, there is a poor fit of the software to the need], or there may be several other reasons related to the usability design of the software. I imagine not many people recall how well MacWrite (or even WordStar) met our word processing needs. Most software today is bloated with features and impossible to master. And even with all the revisions, the structure and utility of some documents from the paper & pencil days are still not easily reproducible on a computer. There are some features we know are unused, there are some that we learned but never stayed in our workflow and we have forgotten, and there are those that we avoid (but tolerate their existence) because there is distrust or incompatibility.

Thus, we could have an exercise focused on “simplicity in design” where we list all the features and cut the ones in the lower priority half of the list – then see what we have left. Would we have something that more people would prefer? Would we gain a competitive edge? Would we get greater user satisfaction? Could we get greater product quality by having less buggy features? Would the persuasive message be simpler? Would be have to spend less on product development?