Home > Articles > Programming > Visual Basic

Reasons to Prototype in Visual Basic

A prototype is a miniature version of the final application to be created. By building a prototype, you can better define an application's features, narrow the customer's needs, test untried technology, and refine the development team's skills. Even more important, building a smaller version of the program enables you to learn about the larger application in a shorter amount of time—and to make mistakes in miniature that are more easily fixed at this point.
This chapter is excerpted from Prototyping with VB.
This chapter is from the book

This chapter is from the book

In the most general terms, a prototype is a small test program designed to tell you something about another larger project that you have not yet built. You build the prototype and then use the information that you learn by building and using it to predict things about the bigger project. A prototype can also let you try different approaches and perfect development techniques. The following are some of the most important uses of a prototype:

  • Define application functionality

  • Test application architecture

  • Test untried technology

  • Predict project duration

  • Predict needed staffing

  • Determine project feasibility

  • Refine development techniques

  • Build the development team

The following sections describe these prototyping benefits and tell how you can maximize their value. Some of the information that you can gather during a prototype has subtle uses, so it's not always obvious how to use what you learn. If you don't keep some of these in mind while you develop the prototype, you may miss out on important clues.

This information is at least as important for team leaders, project managers, and customers as it is for developers. For example, if the developers build a prototype containing too much user interface code, they will probably give you low estimates of the time and staffing needed to finish the application. You need to be aware of these issues so that you can keep developers on track and so that you know how much to trust their results.

Because some of these issues are subtle, you need to pay close attention to them during prototype development. Make a list of the things you hope to learn from the prototype, and look over this list frequently. Be sure to share the prototype's goals with the other developers and customers. If everyone stays focused on the goals, you can greatly increase your chances of success in relatively little time.

Define Application Functionality

Probably the most important use of a prototype is to define the application's functionality. The goal is to ensure that the customers and the developers have the same view of what the final application will look like.

The project begins with a statement of what the application will do. The preliminary design suggests a possible method for performing the application's key tasks. A prototype solidifies that preliminary design so that everyone can see what the developers have in mind.

The prototype shows what the application will look like and, to some extent, what it will do. At a minimum, the prototype should let the developers perform a carefully scripted walkthrough to explain the program's most important features to the customers. Ideally it also demonstrates those features so that the customer can experiment with them and get a feel for how they will work in the final product.

Nonprogrammers often have trouble understanding what programmers mean when they describe a program. A programmer may say, "This form will display inventory in a grid control," and the users may think they understand what that means, but they often have trouble really understanding how that applies to their work until they see the form in action. A working prototype is the best way to give the customers a really good appreciation of what they are buying.

After they have seen and possibly experimented with the prototype, the customers can give feedback. The developers can adjust the development plan to make the product better fit the customers' needs. This greatly increases the chances that you will produce a product that the customer can actually use. This is one of those rules that is completely obvious but often ignored by developers. It's amazing how often developers build a product that no one wants.

Meeting with users gives developers more motivation because they see that they are building something that will actually be used by someone. They often get caught up in the customer's enthusiasm and want to do the best job possible. Working in isolation may be useful at times, but developers should stay focused on the end result.

If user feedback leads to major design changes, the developers can build a new prototype to let the customers see what the revised application will look like. You should repeat this cycle as often as necessary to ensure that the customers and the developers all agree on what the final system's functionality.

Incorporating feedback into new prototypes lets the customers know that you are listening to them. It shows that you take their concerns seriously, and is a great way to win customer buy-in. A customer who makes a personal contribution to the project is more likely to do so in the future and is more likely to struggle for the project's success.

Tale from the Trenches

One system we built was designed to assist dispatchers in routing several hundred repair trucks to their daily jobs. The work center where this was going to be installed was full of fear and resentment. Dispatchers were afraid they were being replaced and might lose their jobs. Operators and drivers didn't want to participate in something that might get their coworkers fired.

We picked out the dispatcher who was most traditional, was most antiautomation, and was totally convinced that our system would never work. It couldn't possibly do a better job than he did! We sat him down in front of a prototype and showed him how to use it. We listened to his feedback and adjusted the prototype as quickly as possible, sometimes the same day. After a few sessions, he realized that this was not a replacement for him but a tool he could use to do his job better. He saw that we valued his input, and he became one of our strongest supporters. That convinced everyone else. After all, if Skeptical Steve believed in the project, then it must work!

In some applications, defining the functionality the customer needs can be difficult. Customers may not know exactly what they need, or they may think they need one thing when they really need something else. Building a prototype can help clarify these needs. Sometimes the project definition emerges incrementally as the customers see a series of prototypes and make evolutionary adjustments to each. Other times after seeing an initial prototype, the customers realize what they really need, and the design may take a completely new approach. In any case, prototypes let you get feedback early and often.

Living Specification

When developers and customers have agreed that a prototype represents the system's functionality, the prototype can serve as a living specification. When customers have a question about what the final system will do, they can run the prototype and see.

Equally important, developers can look at the prototype to see what the final program should do. This lets them concentrate on writing code rather than trying to figure out what the program should do. It also helps prevent mismatches in which one developer thinks a feature should work one way while another developer thinks it should work another way. If everyone understands what the prototype does, they will not need to argue about how things should work.

By defining the application's features, a good prototype lets several different tasks move forward in parallel. That lets you apply more people to the development effort at the same time and thus reduce total development time. The following sections describe some of the more important of these tasks.

Detailed Specification

With an approved prototype in hand, you can begin preparing a detailed specification. Even the best prototype leaves some questions unanswered, and the specification answers them. Writing the specification is a lot easier once the prototype is complete because it gives everyone a clear idea of how things will work. After all, it's a lot easier to write about how an existing prototype works than it is to describe how a program that doesn't exist might work.

You can streamline the specification by referring to the prototype. Instead of describing every detail about how a scrolling list of inventory items works, the specification can state that it works as demonstrated by the prototype. A programmer or customer who has a question about some detail during development can simply fire up the prototype and see.

The specification can also state that one part of the system will be like another. Some large business applications contain dozens or hundreds of nearly identical reports. They are all very similar in format although they display different data. In that case, the prototype can demonstrate one report, and the specification can state that the others are similar.

If you use a series of prototypes, the specification also should state the version referenced. For example, it might say the Work List Screen will look like the one in prototype version 0.09.

The specification should explicitly point out any features in the final application that differ from the prototype. Those are the main points where confusion might arise. Even with small features, if customers expect one thing and developers deliver another, the customers may feel betrayed. If the prototype cannot be trusted about this, how do they know that they can trust the prototype about other things?

In one project, our team built a prototype and then transferred it to another part of the company for implementation. That team went off on its own for several months and created what it considered the final application without any feedback from the customers or the prototyping team.

When the customers saw the final product, they noticed that the implementation group had made several "improvements." Our project leader sat through a series of meetings in which the customers hammered the implementation team:

    CUSTOMER: With this version of the system, how would I do this?

    DEVELOPERS: Uh, we didn't think of that. I suppose you could use this roundabout method to do the same thing.

    CUSTOMER: What if you changed the application so that it worked this way? It would be a lot easier.

    DEVELOPERS: I guess that would work.

    CUSTOMER: That's the way the prototype did it. Change it back.

In the end, the developers spent a lot more time making the program work the way it did in the prototype. The customers were very unhappy. They didn't see why they had paid us to build a prototype, paid the development team to build the final application with improvements, and then paid the development team again to remove the improvements.

Development Plan

When the customers accept the prototype, the developers have a fairly good idea about what the final application should do. You can then start designing the application's architecture and building a development plan. Some of the fine points may change as the detailed specification is fleshed out, but the overall design should be clear.

At this point it is important to remember that the final program does not need to do things the same way the prototype did. The finished product should do what the prototype does, but it can use different methods. Prototypes are often built using quick-and-dirty methods that are effective in the short term but that may not be easily maintainable over time. If you blindly follow the prototype's methods, you may be stuck with a poor design.

Step back and think about the problem again from scratch so that you can build the best architecture possible.

Development Tools

After seeing the prototype, you may be able to tell what tools you will need to build the final application. For example, you may know that you will need an assortment of database development tools. Even before the main programming effort begins, the database team can start buying or building those tools.

Documentation and Training

User documentation and training depend only on what the program does, not how it works. This means that you can begin preparing user documentation and training material as soon as the customer accepts the final prototype. These tasks always take a lot longer than developers expect and are often left to the last minute. The result is a product with documentation that is weak, incorrect, or missing entirely.

When you have a final prototype, you can begin preparing documentation and training materials. However, not all prototyping approaches produce a single final prototype. In one method, developers build an initial prototype and get customer feedback. They build a new prototype and get more feedback. The process repeats until the prototype does everything the final application should do. In that situation, documentation has to wait until features are finalized.

I've worked on several projects that used evolutionary prototyping, and it can be very frustrating to the documentation and training people:

    TRAINING: Can you give me a rundown of how the user assigns an employee to a department so I can write it up?

    ME: Sorry, we don't know that yet.

    TRAINING: Can you at least tell me where the program gets the list of departments?

    ME: Nope. Perhaps in the next prototype.

Some companies require the developers to build a complete user interface prototype before starting the real programming. Documentation and development progress simultaneously. Although this makes it harder to accommodate last-minute changes, it makes it a lot easier to release a program with a good set of documentation.

Hollow Shell

A prototype does not necessarily implement features in the same way the final application will. The prototype may take huge shortcuts that make it less useable except in very specific instances. The goal here is to give the customer a feel for the application, not to build it yet.


Many programs begin with a sign-on form in which the user enters a user name and a password. The prototype may simply compare the values entered to a user name and password stored in the code. The final application will need to use a more flexible and robust system, such as trying to log on to a database using the entered values.

Prototypes are often short on formatting and error-handling code. For example, phone number fields may not verify that entered values look like valid phone numbers, so the user will need to use the right format.

Even so, the prototype should not be too stupid. It should save an invalid phone number into its test database, or at least present a somewhat meaningful error message, rather than crashing without warning. The prototype provides the first good chance for the customer to see what you are building. Making a good first impression is important, so don't mess it up with dozens of error messages and crashes.

If the prototype is too fragile to work safely, don't let the customer experiment with it. Instead, demonstrate it yourself following a thoroughly rehearsed script. Be sure you know what will work and what won't, and don't do anything that you haven't tried before.

First impressions can mean life or death to a new project. One application I built for the State of Minnesota began with a logon form shaped like the State of Minnesota—not just a rectangular form with a picture on it, but a form cut out to resemble the state.

When the users saw the first prototype, they loved it. When the demonstration was over, the first thing they asked was, "How did you make that logon screen?" They thought it was so cool. They also had lots of useful feedback, and we made a lot of changes to the design, but that one form had sold them. A little razzle-dazzle can make a powerful first impression.

One danger of a good prototype is that it may raise the customers' expectations. A good prototype looks like an almost-finished program. After seeing a demonstration, the customer may say something like, "The prototype looks great! Just fix up those few bugs and formatting problems in the next week or so, and we'll use that."

The customer doesn't understand that the prototype is like a movie studio set: It looks great in a carefully controlled demonstration, but behind the facade it's just a hollow shell.

Even if you convince the customers that you cannot just "fix up" the prototype, they may have trouble understanding why it will take you nine months to take the prototype from "almost done" to "done." You should warn customers of the prototype's "hollow" nature before you show it to them so that you don't raise their expectations prematurely.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020