Front panel prototypes provide insight into the organization of the program. Assuming the program is user-interface intensive, you can attempt to create a mock interface that represents what the user sees.
Avoid implementing block diagrams in the early stages of creating prototypes so you do not fall into the code and fix trap. Instead, create only the front panels. As you create buttons, listboxes, and rings, think about what needs to happen as the user makes selections. Ask yourself questions such as the following:
If new options are presented, follow those ideas by creating new front panels to illustrate the results. This kind of prototyping helps to define the requirements for a project and gives you a better idea of its scope.
However, prototyping cannot solve all development problems. You have to be careful how you present the prototype to customers. Prototypes can give an inflated sense that you are rapidly making progress on the project. You have to be clear to the customer, whether it is an external customer or other members of your company, that this prototype is strictly for design purposes and that you will rework much of it in the development phase.
Another danger in prototyping is overdoing it. Consider setting strict time goals for the amount of time you prototype a system to prevent yourself from falling into the code and fix trap.
Of course, front panel prototyping deals only with user interface components, not with I/O constraints, data types, or algorithm issues in the design. Identifying front panel issues can help you better define some of these areas because it gives you an idea of some of the major data structures you need to maintain, but it does not deal with all these issues. For those issues, you need to use one of the other methods, such as performance benchmarking or top-down design.