The usability of any application is ultimately determined by the user. Interface design is an iterative process; rarely is the first pass at designing an interface for your application going to yield a perfect interface. By getting users involved early in the design process, you can create a better, more usable interface with less effort.
The best place to start when designing a user interface is to look at some of the best-selling applications from Microsoft or other companies; after all, they probably didn't get to be best-sellers because of poor interfaces. You'll find many things in common, such as toolbars, status bars, ToolTips, context-sensitive menus, and tabbed dialogs. It's no coincidence that Visual Basic provides the capabilities for adding all of these to your own applications.
You can also borrow from your own experience as a user of software. Think about some of the applications that you have used; what works, what doesn't, and how you would fix it. Remember, however, that your personal likes and dislikes may not match those of your users; you'll need to validate your ideas with them.
You may have also noticed that most successful applications provide choices to accommodate varying user preferences. For instance, the Microsoft Windows Explorer allows users to copy files with menus, keyboard commands, or by drag and drop. Providing options will broaden the appeal of your application; as a minimum you should make all functions accessible by both mouse and keyboard.
One of the main advantages of the Windows operating system is that it presents a common interface across all applications. A user that knows how to use one Windows-based application should be able to easily learn any other. Unfortunately, applications that stray too far from the established interface guidelines aren't as easily learned.
Menus are a good example of this — most Windows-based applications follow the standard of a File menu on the left, then optional menus such as Edit and Tools, followed by Help on the right. It could be argued that Documents would be a better name than File, or that the Help menu should come first. There's nothing to prevent you from doing this, but by doing so you will confuse your users and decrease the usability of your application. Users will have to stop and think every time they switch between your application and another.
The placement of submenus is also important. Users expect to find Copy, Cut and Paste beneath the Edit menu; moving them to the File menu would be confusing at best. Don't deviate from the established guidelines unless you have a good reason to do so.
The best way to test the usability of your interface is to involve users throughout the design phase. Whether you're designing a major shrink-wrap application or a small application for limited use, the design process should be pretty much the same. Using your established design guidelines, you'll want to start by designing the interface on paper.
The next step is to create one or more prototypes, designing your forms in Visual Basic. You'll need to add just enough code to make the prototype functional: displaying forms, filling list boxes with sample data, and so forth. Then you're ready to start usability testing.
Usability testing can be an informal process, reviewing your design with a few users, or a formal process in an established usability lab. Either way, the purpose is the same — learning first-hand from the users where your design works and where it needs improvement. Rather than questioning the user, it's more effective to simply turn the user loose with the application and observe them. Have the user verbalize their thought process as they attempt to perform a set of tasks: "I want to open a new document, so I will look under the File menu." Make note of where the interface design doesn't respond to their thought processes. Test with multiple users; if you see several users having difficulty with a particular task, that task probably needs more attention.
Next, you'll want to review your notes and consider how you can change the interface to make it more usable. Make the changes to your interface and test it again. Once you are satisfied that your application is usable, you're ready to start coding. You'll also want to test occasionally during the development process to make sure that the assumptions for the prototype were valid.
One of the key concepts in usability testing is that of discoverability. If a user can't discover how to use a feature (or even that a feature exists), that feature is of little use. For example, the majority of Windows 3.1 users were never aware that the ALT, TAB key combination could be used to switch between open applications. There was no clue anywhere in the interface to help users discover this feature.
To test the discoverability of a feature, ask the user to perform a task without explaining how to do it (for example, "Create a new document using a Form Letter Template"). If they can't accomplish the task, or if it takes several attempts, the discoverability of that feature needs work.