Now we’ve developed a full set of measurable and specific requirements and a production timeline, it is necessary to begin prototyping our solution. We do this before we start coding because it helps us to verify any assumptions we might have. Prototypes allow us to understand if our assumptions are wrong, so we can fix them before we ever start coding. This is particularly important for large-scale systems.

Prototypes

A prototype is a model of something, a non-functional (or not completely functional) mock-up, or a reasonably close version of something. It might be a physical object that we can hold in our hands, or it might be as simple as a drawing on a napkin. It could be a written description of something, or it could be a highly detailed blueprint. It could be a static thing or it could be interactive and dynamic. It could represent all aspects of a solution or thing or describe a small piece.

The point is that a prototype represents our understanding of a solution or thing (often given a set of simplifying assumptions).

Developing a prototype can help us better understand a problem and its solution. It allows us to critically assess our solution (ensuring it fits what the client expects, and supports the workflow the user requires), and to correct them before we fully implement a system. Further, a prototype can help us validate whether or not our solution is stable. That is, a prototype will help us save time and money, and hopefully help us avoid complete redesigns.

A good prototype allows us to answer questions about the system. Does the model address all requirements? Will the model allow the user to achieve what they need to? Will the model be intuitive to the user? Will this model hold up to edge cases? A good prototype helps identify misconceptions or errors in our thinking/design. In short, a prototype should be used to test our solution, and better yet, to improve it.

Ultimately, prototypes should be considered tools for communication – with your team and other developers, and even with your client and users. In the latter case, prototypes help clients and users feel a sense of ownership of the project. They become co-designers. Seeing their ideas brought to life in a prototype builds trust and fosters the idea that they are part of the team. This relationship development is essential to managing any issues that might arise during the development process.

Prototypes should:

• be developed using vocabulary the client/users understand,
• allow for iterative refinement of the process, and
• help the design team understand what the user thinks when they use a particular word or phrase.

Low & High Fidelity Prototypes

There are two general types of prototypes: low and high fidelity. Low-fidelity prototypes are typically used early in the design process. They are often created with paper and pen, involve sketches, and are quick to change. High-fidelity prototypes usually arrive later in the design process. They are time-consuming and represent an almost complete understanding and representation of the system.

From a design point of view, we may only think of prototypes as things we’d use to understand the user interface design. However, prototypes are used throughout the design process – to model the way data might be stored and managed in our system, to model the way the system behaves (for example, how it might use data before it is shown to the user or stored in the database), and of course to model the user interface design.

In the following sections, we’ll consider prototyping from these three perspectives. We’ll outline several tools and techniques that you can use to assist in the prototyping process. The list of tools that are provided should not be considered exhaustive. Further, the tools outlined won’t be used for every design project. The choice of tools used will depend on the size of the project, personal preferences, and company standards.

Prototyping Our Data Structures & Storage

Prototyping how data are stored, organized, related to each other, and protected is an important part of the design process. Students, however, don’t often think of it as prototyping. Remember, a prototype is a model of something. Drawing a picture describing relationships between tables in a database is prototyping.

For CIS3750, we will explore one method for prototyping the data. Specifically, we will explore Class Diagrams. We’ll consider Class Diagrams in a future chapter.

Prototyping How Our System Behaves

Prototyping how the system will respond to different inputs asks us to consider if this, then that. What will our system do and how will it respond when it receives different inputs or commands?

While this might immediately conjure up images of how the user interface will respond to user actions, it also includes prototyping things the user doesn’t see. This could include, for example, identifying the string of actions that need to be carried out after a new user submits information to create a new user profile in your system. The user may not realize that the system will validate the data before sending it to the database. They might not realize the system will also check the data to ensure it isn’t harmful. And they won’t see the system check the database to see if the user already has an account. Despite this, we need to consider each of these steps – to prototype what happens when users or other systems interact with what we are designing.

There are several tools we will consider in CIS3750 that will help us prototype how the system behaves. These include Sequence Diagrams, Use Cases, and Storyboarding. Some of these will be covered in the lab, others in class.

Requirements and user stories can also be considered prototypes. They support our understanding of how the system behaves.

Prototyping Our User Interface Design

Developing prototypes for our user interface is probably something you’ve already done – even if that means drawing a picture of a single screen of a system you have designed for other courses. Prototypes do not have to be fancy to help us better understand and test a system.

In CIS3750, we will explore three different prototypes used for the user interface. These include Storyboarding, Paper Prototyping, and Wireframing.

You might have noticed that Storyboarding has also been listed under “How Our System Behaves”. This is not a mistake. Storyboards can help us understand the flow from one screen to another (i.e., how our user interface will react to inputs from the user), while at the same time giving us a sense of which items will be grouped on each page of our system (i.e. how our user interface will be organized). Similarly, other tools won’t necessarily fall under only one of these headings. For example, requirements might inform our data structures if they include a definition for a user profile or set standards for encryption. They might also inform the user interface design if they include AODA standards.

Review Questions