Hidden Features

We used to have a saying during a recent major project I worked on.

“If a typical user can’t figure out how use the feature, we shouldn’t bother writing it.”

The Microsoft Office team went through a similar realization during the design phase of office 2007, when they introduced “the ribbon”.  They noticed that a lot of the features they had spent man years creating weren’t being used.

“Contrary to the conventional wisdom of the naysayers, we weren’t (and aren’t) “out of ideas” for Office. Customers weren’t telling us that they didn’t need new features–to the contrary, the list of requests is a mile long. Every version we were putting our heart and soul into developing these new features, undergoing a rigorous process to determine which of the many areas we would invest in during a release, and then working hard to design, test, and ship those features. The only problem was that people weren’t finding the very features they asked us to add.”

http://blogs.msdn.com/b/jensenh/archive/2008/03/12/the-story-of-the-ribbon.aspx

Their work was not being realized by many users.  You can argue whether the ribbon achieved it’s stated goal, but the goal itself was sound. If a user can’t find the feature, all the time and energy we spent creating it is wasted for that user.

Creating features that are discoverable can take significant design work and unfortunately, this design effort doesn’t contribute directly to the “bullet list” of features we are trying to create when building software products. It is often difficult to justify the ROI of this design effort to the higher-ups. Walking them through the frustration users encounter (I’m sure they have all gone through similar experiences) can help build the case that spending the few extra days it takes to put a feature in the right place will pay dividends in user satisfaction and loyalty.

If this ethos can make it’s way into your group’s culture, you have taken one major step forward in the experience you give your users.