Almost every platform has a guideline written for user interface design. Microsoft has published the Design Guidelines for Class Library Developers, which you should follow when building .NET software. If you feel the need to improve upon the design, chances are you will remove your “improvements” when users begin to complain about the application not working the way they would normally expect.

If you are doing cross-platform development, maintain consistency by following the design guidelines for the host platform. Never make the different platform applications function the same if they break one of the guidelines of the platform. Chances are your users will be switching between applications on one platform, not switching between applications on different platforms. Users should be able to use the knowledge gained in other programs on a certain platform to anticipate the behavior of your program.

Users should also be able to anticipate the behavior of a control from its visual appearance and properties. For example, if a pushbutton on one of your user interfaces responds to single mouse click, every other button should respond to one mouse click as well.

When you develop a custom control, it is important that you try to make it behave in a similar fashion to other system controls. If you build a custom control that allows the user to type text into it, that control should have a blinking insertion pointer; it should have a vertical scrollbar if multi-line input is supported. If you build a custom control that allows the user to click on it, the control should behave in a similar fashion to a regular button.

If you have a custom control that behaves in a fashion that users are not accustomed to, be sure to give the control a distinct appearance so that users can associate that type of control with a unique behavior.

Consistency is also important to interface abstractions like accelerator keys, placement of menus and toolbars, and mouse gestures.

The concept of user interface transparency is a design that allows users to accomplish their tasks while being minimally aware of the interface itself. Interface transparency occurs when the attention of the user is drawn away from the interface and directed at the task itself.

Certain interface abstractions, such as accelerator (hot) keys, are quite useful in achieving interface transparency, but the best way to design a transparent interface is through iterative user testing throughout software development.

Watching how a user operates a tool and witnessing how quickly he learns an interface is an excellent way to gain an idea of what should be redesigned to improve the transparency of an interface.

This concept applies to the controls and activity of your tool, and is about the importance of providing adequate feedback to users. Users expect feedback while using an application, so they are aware of the current state of the application. It is a typical action and reaction situation, where something should happen when a user does something.

For example, when a button is clicked, it first draws itself in a depressed state, and then draws itself in a normal state when the mouse button is released. This is a method of user feedback that informs the user that he successfully clicked the button. If this visual appearance did not occur when the button was clicked, the user generally understands that he did not actually click the button and should do so again until the visual feedback is witnessed. You can imagine the frustration of your users if buttons in your application did not display this visual feedback when they were clicked.

As another example, a checkbox control changes its appearance when it is selected or deselected to inform the user whether the checkbox is checked or not. Again, this visual feedback is important to show users the current application state.

With any tool, there are instances when an operation occurs that takes longer than a few milliseconds to complete and requires visual feedback to inform the user that the application is performing a lengthy operation and did not actually lock up. When brief delays are to occur, one of the more popular methods is to change the mouse cursor into an hourglass. If a longer operation will occur, use a progress bar control so that users can see how long the operation will take to complete. An hourglass cursor will not suffice for a lengthy operation because users will still think that the application has locked up.

Lastly, every screen should be designed so the user knows what steps have been performed, especially any critical steps that have been performed.

One common mistake a lot of developers make is to throw a warning or error exception when the user performs an invalid operation. In actuality, you should view every warning and error message generated by your application as an opportunity to improve the interface and task sequencing techniques.

A good user interface is when warning and error messages are rarely generated, with the exception of disk failures or interrupted network connections. Otherwise, all other warning and error messages can be considered as design flaws.

Instead of letting the user do whatever he wants and throwing a warning or error message when he does something invalid, consider the prevention of these messages as a better design alternative.

The majority of erroneous user operations result from invalid input data and inappropriate task sequencing. If your program requires formatted data, such as dates or particular numeric ranges, help users enter correct data by using bounded input controls that limit input choices. Rather than letting the user enter whatever data he wants and complaining about the input when the user clicks the Save button, instead force the user to enter correct data using controls that strip invalid characters and perform automatic formatting.

If a particular step in the application cannot be legitimately performed until the user completes other steps, the dependent step should be disabled so that the user cannot attempt to perform it until all the dependencies of the step are satisfied. User action should be limited to only valid steps through the use of disabled controls. Most user interfaces have a dim appearance for disabled controls, and this visual feedback informs the user that the functionality of that control is unavailable until another step is completed.

The human race was born to be explorers, and our curious nature causes us to attempt certain things just to see what the outcome is. When prehistoric cavemen created fire, it is safe to assume there was at least one curious individual who wanted to see what happened when they touched fire—obviously burning themselves in the process. From that point on, everyone knew what would happen if they did the same thing, so their curiosity was satisfied.

The same analogy can be used for interfaces and user exploration. Humans want to explore any environment, but with tools, they risk corrupting the database or game content. This concept is based on the idea that the user interface and application should foster an environment safe for exploration. Safe environments are achieved through the use of undo and redo functionality. A great interface design invites and rewards user exploration, and offers the thrill of discovery and the satisfaction of unassisted accomplishment. Undo and redo functionality encourages your users to explore the application without fear of corrupting the database or game content.

Another great design advantage of undo and redo functionality is that it eliminates the need for dialogs requesting permission to perform an erroneous function. This is also a great technique to enhance interface transparency.

The use of modal dialogs is quite common in a user interface, yet they must be used wisely for a number of reasons. Programs generally use modal dialogs to force users to perform steps in a specific order. Modal dialogs are very advantageous for wizard tools that simplify complex tasks, and are also used to display warning and error messages for a critical issue that the user must first address before returning to the task.

The problem with modal dialogs is that they make users uncomfortable because they restrict natural or intuitive responses. Modality also interrupts user concentration and goal-oriented behavior, decreasing productivity with the tool.

Modal dialogs are a great way to build easy-to-use and straightforward interfaces, but they have to be used sparingly. Task sequencing techniques can be applied so that modal dialogs are only used when absolutely necessary.

Good applications have online reference materials and comprehensive manuals that explain features of the application and help to solve real-world problems. If a user is stuck on a particular problem, in theory he should be able to read the reference material, move past his issues, and resume productivity.

Great applications have online reference materials and comprehensive manuals available to the user, but users rarely need to refer to them to figure out how to perform a particular task. This is where the concept of a self-evident application comes into play.

A number of factors contribute to an interface that is self-evident; some of the factors include consistency, feedback, modality, and an environment that is safe for exploration.

Following the platform guidelines eliminates the problem of users becoming frustrated with the interface itself, and reduces the learning curve required to understand the application.

Proper feedback helps the user understand what the application is doing behind the scenes, and helps reduce the chances that the user will feel “in the dark” about the current state of the application.

Modality plays a big part in helping guide the user towards performing steps in the correct sequence, and it helps the user to understand how a complex interface works.

Lastly, with an environment safe for exploration, the user can attempt to guess what to do next if he is stuck on something, without fear of corrupting his data. A user will often try a couple of things through guesswork before going to the reference material, if he can do so without undue worry that he will break things in the application or project.

Remember that the difference between a good and a great interface is how self-evident it is. If time is short for the development of a tool, instead of investing time in producing reference material, a self-evident interface will be more than enough of a reference for users.

Most platforms have written conventions that describe the appropriate use of animation, color, sound, and multimedia clips, and they should be used sparingly.

You should never use sound and color as your sole means of communication with the user; many users are colorblind or hearing impaired. The application should be able to run with full functionality and productivity without any multimedia features.

Following the platform conventions, only use multimedia where it makes sense, and always allow the option to turn off multimedia features like sound effects. Some users find them distracting, and this decreases productivity.

This concept is centered on the idea that users love to customize their work environment to match their own personal style and preferences. Generally, offering work environment customization increases productivity because users can set up where toolbars are positioned, select fonts and colors that are easier to read, and show only the dialogs that they use often.

Another reason that customization is important is because there is such a wide variety of hardware that applications can run on, and the default appearance does not always look good on different hardware configurations.

The biggest issue is in regards to video options like screen size, resolution, and color depth. Your application may look fine on 1024×768 and 32bpp, but it may look absolutely terrible on 800×600 and 16bpp.

Allowing users to tailor the basic interface, such as fonts, toolbar location and appearance, menu entries, color scheme, and sound scheme, helps to alleviate this problem.

While customization is important, this feature is somewhat useless if the settings are not persistent between different instances of the application. If the user changes the settings, closes the application, and restarts it, the application should be in the same state it was left at in the previous session.

Persisting changes to the settings is a simple registry key with a single user, but multiple users present additional issues that must be addressed with an alternative solution. If your application supports multiple users on a single workstation, then consider recording preferences as user specific profiles, rather than as a single profile from the last time the application was run.

It is a misrepresentation of software to think of a user interface as “intuitive” because software applications simply do as they are instructed. It is the users who must “intuit” an application, meaning an interface that is intuitive to one user may be unintuitive to another.

The best way to design an interface that users can intuit is by designing an interface to respond just like all the other applications they are used to. The way to accomplish this is by following the Design Guidelines for Class Library Developers, as well as the principles and concepts in this chapter. It is also advantageous to look at similar applications and take note of how they operate.

A technique I have professionally used in the past is to open up any popular Microsoft product like Office and look at how the interface works in it. Microsoft has invested millions of dollars in user interface design research, and their research can be adapted into your applications by mimicking how their products work.

You can get the Design Guidelines for Class Library Developers off the corporate Microsoft site. These guidelines should be followed to produce a user interface that users can intuit, and to achieve interface transparency.

User interface design is necessary for any software application, especially when the application is a tool that is distributed to an external audience.