The Curse of Cost-Benefit Design

Weighing up the costs of a new feature against the benefits to the customer sounds like common sense. For those with a project manager mindset it is likely the only way to design a product. Agile methodologies too encourage us to design features only with a cost-effective benefit.

This mentality has it’s place in these tough economic times. But it needs countering by someone who cares less about ticking feature boxes, and more about creating a product that is a joy to use.

An example. Microsoft Windows Explorer - the bit of windows you use for navigating through your files and folders. For years neglected. This changed in Windows Vista. One tiny feature which now makes explorer more usable, is that it remembers where you were in a folder list when you navigate back to it.
In Windows XP, say you have a list of dozens of folders, and you need to navigate into several of them, to perform some action. Once you’re finished in that sub-folder, you click the ‘up arrow’ in the toolbar to take you back to the parent folder, and in XP the list of folders has scrolled back to the top, with the first folder selected. It’s annoying! To navigate into the next folder in your list, you need to have kept a mental note of where you were up to, scroll back down to that point, and find the next in the list. In Windows Vista/7, you go back, and the scroll position is where you left it, with the folder you’ve just been in pre-selected for you. It is a tiny UI improvement, but greatly improves satisfaction - or more accurately, it reduces dissatisfaction.

Was this a fancy feature that was listed in the Windows Vista product literature? No. These sort of benefits are impossible to measure, but are extremely important to the feel good factor of a product. As developers and product owners, we need to spend more time getting things right, and less effort on adding a multitude of half-finished ‘features’.