Now that we’ve developed a full set of measurable and specific requirements, and we’ve converted these to a timeline for production, it is necessary to begin the process of prototyping the work we need to do. We do this before we start coding because it helps us to verify any assumptions we might have. More specifically, prototypes help us to understand if any of our assumptions are wrong, so we can fix them before we ever start coding. This is particularly important for large-scale systems that need to be developed.

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. And it could represent all aspects of a solution or thing, or it may only describe a small piece of it.

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

The act of developing a prototype can help us better understand a problem and its solution. It provides us the opportunity to critically assess our potential solution (ensuring it fits what the client expects, and supports the workflow that the user of the system might need), 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 is one that allows us to answer questions about the thing which we are modelling. Is this model addressing all of the requirements? Will this model allow the user to achieve what
they need to achieve in a manner that is straightforward and intuitive? Will this model hold up to edge cases? A good prototype will also help us 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 the users of the product. In the latter case, the use of prototypes can help clients and users feel a sense of ownership of the project. That is, they feel as if they are co-designers. When they see their ideas brought to life in a prototype, it helps to build a sense of trust and foster 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 is thinking when they use a particular word or phrase.

Low & High Fidelity Prototypes

There are two general types of prototypes: low fidelity, 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 to make and usually represent an almost complete understanding and representation of the system.

From a design point of view, we may only think of prototypes as those things that we’d use to better 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 each of these three perspectives, and 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 necessarily be used for every design project. The tools used will depend on the size of the project, personal preferences, and of course, standards that have been set by the designing company.

Prototyping Our Data Structures & Storage

Prototyping how data are going to be 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, so even if you are drawing a picture that relates to different tables in a database, you are building a prototype.

For CIS3750, we will explore one method for prototyping the data. Specifically, we will explore Class Diagrams.

Prototyping How Our System Behaves

The act of prototyping how our system will respond to different inputs is effectively asking us to consider if this, then that. That is, 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 it is moved 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, it is important for us 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 will be covered in class.

It should come as no surprise that requirements and user stories can also be considered prototypes that 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 simply 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 the system we want to design.

In CIS3750, we will explore three different prototypes that are 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