The profile of your features

You ask: "Is this interface user friendly?" and I'll ask "For whom?". An application that works well for one user may not be usable for another. A 3D CAD system able to render high resolution graphics is very user friendly for engineers but it is a mundane tool for 3D artists. Not all applications support the same range of users: some application domains support user profiles with vastly different skills while others have a more homogeneous user set. There are applications that should support profiles that change for a particular user over time. For example, a sales application could behave differently for beginners than it would for sales people that have expert domain knowledge. Most applications should acknowledge the difference between the needs for new application users and those imposed on it by advanced users.

A good user interface is one that leverages the strength of its users to help them achieve their goals. If you are in the business of developing tools for software developers you are in luck: you belong to the profile of your users. The high usability levels of IDEs (as attested by their wide adoption) is proof that knowing your user is actually a good thing.

You have probably heard it being said somewhere that all software developers are notoriously bad at user interface design. I despise this generalisation; but many developers actually agree with this assessment. The cause of this leniency towards us creating such abominations perhaps lies in a personality trait that we share. Software developers tend to enjoy keeping large and complex mental models in their heads. This is very useful when you are working in a small part of a very complex system. Surprisingly to us, not everyone is like this.

Most people dislike the idea of spending time to refine and perfect abstract models. They prefer to concentrate on the details that can seen in right front of them. This is not saying that they are less intelligent; just that they have a different personality type. For these people the user interface is the system, and the system is the user interface. To them, the following makes perfect sense: If you want to make the system easier, just fix the interface; and if you want to make the interface easier, just fix the system. What they get is what they see.

First impressions last, and the first thing the user sees when the application starts is the primary user interface. This interface strives to match a simplified conceptual model of the application by hiding away many features of the application. As the UI designer, you have many tools that can be used to hide features. Here are some of the most obvious ones listed in decreasing order of exposure:

• A toolbar button provides access to features that must be highly visible.
• A menu item requires a trivial user gesture to expose features.
• A submenu requires a more involved gesture.
• Dialogs exposes features that are invoked by an explicit user command.
• Secondary dialogs are exposed from commands available on primary dialogs.
• An advanced mode can be enabled to expose more features for advanced users.
• Some applications provides scriptable functions to expose features available to expert users.

As part of your primary user interface design, you need to decide what is on your primary user interface and how the rest of the features will be hidden. Carefully consider each user profile in your decision: some user profiles could need alternative primary interfaces. Also consider how application adapts as the user moves on the beginner-expert profile continuum.

Next time a user complains about an interface, try not to explain how it "actually" works. Think out of the box: come up with a visual cue that resolves the complaint on the user interface. Odds are that you will end up with a more usable application!