Highlighting Functionality

Research indicates that most users never find the majority of the functionality in any given application. Learning tends to reach a plateau early on, and is rarely expanded upon. And what that means is that most customers consistently undervalue the software products they purchase and use.

Only when good interface design helps users discover the true power of an application will development effort be truly appreciated by customers.

What defines a product? Depending on who you ask you'll get a wide variety of answers to that question. Most engineers would offer up a technical specification. A marketing executive might talk about 'benefits', 'niches' and product positioning. But neither these definitions reflect the user's experience of a product. From a usability perspective, a product is defined by the manner in which it is used. Its features and benefits are those enjoyed by the typical end-user.

Such a definition means that a product is most definitely not 'everything in the box'. Despite what a head engineer or webmaster might say, just because a feature has been added to the product does not mean that the user is experiencing it and recognizes it as a part of the offering. And research indicates that most users never find the majority of the functionality in any given application. Learning tends to reach a plateau early on, and is rarely expanded upon. And what that means is that most customers consistently undervalue the software products they purchase and use.

That might seem unlikely, but upon reflection most application users would admit that a huge number of features remain completely unknown to them. How many Internet Explorer users, for example, realise that the 'delete' button will send them back a page without reaching for the mouse? This is a useful feature, yet remains virtually unused due to a lack of transparency. And some applications have whole modules that remain un-used by the average customer.

So why does this happen? Most software developers would probably tell you that users are too lazy or stupid to read the manual. They're half right - but most users don't read manuals because they are too busy doing their jobs to digest and understand the extensive documentation that comes with most software products. So why don't they discover these features whilst using applications? The theory goes that after a certain amount of time all the various features of any given application will soon become apparent to a regular user.

Unfortunately it doesn't work like that. Most users tend to quickly establish a work pattern, from which they only deviate when necessary in order to resolve a problem. Features are only discovered that relate directly to issues arising from the everyday use of the application. This is why, for example, some users spend years with Microsoft Excel without discovering they can create charts and graphs with their data. It is simply not a feature that solves an obvious problem with the rest of the application. (Some users even manage to spend a lifetime with Excel whilst still adding up the columns with a calculator, but that's another story.)

The net result of hidden functionality is a poor customer perception of your product. What's the point of significant investment in features that are rarely used - or that users are unaware even exist? Just as important as developing impressive feature sets is making sure that your customers are aware of them - otherwise they will regard your application as only 20% of the product it is.

In the absence of users reading the manuals or exploring applications off their own bat, presenting and communicating product functionality is a central element of good usability engineering and interface design. The product interface is the starting point for any new use of the product and as such should suggest all possible or appropriate actions as clearly as possible. This can be achieved in a variety of ways, including:

• Clear contextual help or lists of contextual options easily available to the user
• Alternative 'shortcuts' displayed alongside traditional navigational methods
• Clear menus and navigation items that give an overview of the applications various key function groups and are always present on screen
• Occasional prompting of the user to try new product features (through such methods as 'tips of the day', for example)
• Plain language that effectively communicates what any particular command does and gives an effective 'scent' of the functionality behind any menu item or button.