From time to time, we get so caught up in the technical details of software development that we forget that potential customers, seeing the application for the very first time, may not have the same level of understanding and familiarity as we do. Seeing your build in action, debugging it, and running through the program again and again, for days and weeks on end, brings a certain level of knowledge and intimacy to your thought process. It’s natural for a developer to become somewhat detached from the typical new user experience. It's even possible for a group of like-minded individuals to completely miss a design flaw or bug that is obvious to someone who looks at the program with new eyes.

It’s beneficial, then, to occasionally test your software interface using folks who have absolutely no idea what your application is supposed to do. Without a proper introduction, run the program for someone, put their hand on the mouse, and then sit back and watch what happens. Observe how they interact with your program, listen to their questions, and pay particularly close attention to anything that frustrates or confuses them.

Does the layout of your user interface allow your user to find functions intuitively? Do the field names on your screens make sense to non-technical people? Did you start calling a form name by the name of the variable that’s populated by it, and continue to do so today, even when a plain english label would make more sense? Does the person intuitively understand how to perform basic functions without asking you how it’s done, and do those basic functions invite the user to explore more advanced ways of using your program?

Listen to the feedback provided by your testers. You may not think that a particular feature was sufficiently important to include in your build, but if its absence is repeatedly mentioned by several different testers, you can bet that potential customers will also want to see it. Be prepared to swallow your pride and implement a feature that you, personally, may not see as useful, but that your target audience wants. Consider the impact of not including it - you get your way, sure, but who knows how many potential customers will elect to use a competing software product that is similar to yours, but has this one additional feature that they really want?

You may not always need to completely overhaul the design of your user interface. Based on the feedback you receive from non-technical user testing, you may be able to address some issues adequately just by clearly explaining a process, feature, or technique in your end-user documentation or embedded application help.