Ilya Bogorad wrote an interesting blog article on the value/utility of default choices.
This practice can be applied to almost any product or service and yet it is interesting to see how poorly it is leveraged in software products.
Example 1) My office laptop uses a separate (from MS Windows) graphics driver from a Tier-1 IT company that has asked me every working day for the past three years what preferences I would like to use when connecting an external monitor. Had it once retained a memory of my last setting it could have offered that as a choice and cut down on the multiple mouse clicks I have to endure every day when I arrive at work.
Example 2) The MS Office 2007 ribbon – why not have the ribbon start out with the default groups and icons, but have a new group called “Frequently Used Commands” which would contain all the commands that the user has used more than “x” times in the last “y” times the program was run. Alas, nice idea but (to quote the online help) “it is not possible to customize the Ribbon without using XML and programming code.”
Walk a mile in the shoes of your end users. Even better, recruit some “real” end users to test usability factors and to provide feedback for incorporation into product design and development. The best way to create stickiness with any discretionary product is to make it as painless as possible for a user to use it.