24 Why We Prototype
CONTENT
- What Is A Prototype?
- Why Do We Prototype?
- Low- And High-Fidelity Prototypes
- Looking Ahead
Key Points
- What a prototype is and why it is useful before building the final system.
- How prototypes help teams explore ideas, test assumptions, and gather feedback.
- How low-fidelity and high-fidelity prototypes serve different purposes.
- Why prototypes should support learning rather than simply look polished.
- How prototyping connects requirements to design decisions.
By this point in the design process, you’ve developed a clear set of measurable requirements and created a production timeline.
Although it may be tempting to begin coding immediately, experienced software teams rarely do.
Instead, they build prototypes.
Prototyping allows us to test ideas before investing time and effort implementing them. It helps us identify misunderstandings, uncover missing requirements, and explore alternative solutions while changes are still inexpensive.
Finding a design problem during prototyping is far better than discovering it after thousands of lines of code have already been written.
What Is A Prototype?
A prototype is a simplified representation of a proposed solution.
It might be:
- a sketch on paper,
- a flow diagram,
- a database model,
- an interactive wireframe,
- a written description, or
- a nearly complete version of the final product.
Some prototypes are static, while others allow users to interact with them. Some represent only a small part of a system, while others model an entire solution. Regardless of its form, a prototype has one purpose:
A prototype represents our current understanding of a solution so that we can test, discuss, and improve it.
Why Do We Prototype?
Software design is based on assumptions.
We assume users will understand the interface. We assume a particular workflow will make sense. We assume the information we’ve gathered from our client is complete and accurate.
Prototypes allow us to test those assumptions before implementation begins.
They help us answer questions such as:
- Does this solution satisfy the requirements?
- Can users complete the tasks they need to perform?
- Is the workflow intuitive?
- Have we overlooked important situations or edge cases?
- Is there a simpler or more effective design?
Rather than treating prototypes as preliminary versions of the final product, think of them as learning tools.
Every problem discovered during prototyping is one less problem you’ll need to solve during development.
Prototypes Are Communication Tools
Prototypes are not created solely for developers.
They are also valuable communication tools.
Within a development team, prototypes help everyone develop a shared understanding of the proposed solution.
With clients and users, prototypes make abstract ideas tangible. Instead of imagining how the finished system might work, clients can see it, interact with it, and provide meaningful feedback.
This often transforms clients from observers into collaborators.
As they contribute ideas and refinements, they develop a stronger sense of ownership over the final product. This collaborative relationship builds trust and often leads to better software.
For this reason, prototypes should:
- use language that clients and users understand,
- encourage discussion and feedback, and
- support multiple rounds of refinement as the design evolves.
Low- And High-Fidelity Prototypes
Not all prototypes have the same level of detail.
Low-fidelity prototypes are created early in the design process. They are intentionally simple, quick to produce, and easy to modify. Paper sketches, whiteboard drawings, and rough storyboards are common examples.
High-fidelity prototypes are developed later, once the team has a much better understanding of the solution. They often resemble the finished product and may include realistic layouts, interactions, colours, and navigation.
Neither type is inherently better.
Low-fidelity prototypes encourage exploration and experimentation, while high-fidelity prototypes allow the team to refine and validate a nearly complete design.
Most successful projects use both.

Prototyping Different Parts Of A System
When people hear the word prototype, they often think about user interface design.
In reality, prototypes can model many different aspects of a software system.
In CIS3750, we’ll consider prototyping from three complementary perspectives:
- the system’s data,
- the system’s behaviour, and
- the user interface.
Each perspective helps us answer a different set of design questions.
Prototyping Data
Before software can process information, it must know how that information will be organized and stored.
Designing database structures, modelling relationships between objects, and identifying the information the system must manage are all forms of prototyping.
Although students don’t always think of these activities as creating prototypes, they are exactly that: simplified models of how the system will manage its data.
In CIS3750, we’ll explore this aspect of design using Class Diagrams, which we’ll introduce in a later chapter.
Prototyping System Behaviour
A software system is much more than its interface.
Behind every button press or menu selection is a sequence of actions that determines how the system responds.
For example, when a user creates an account, the system might:
- validate the information,
- check whether the account already exists,
- encrypt sensitive information,
- store the new data,
- send a confirmation email, and
- display feedback to the user.
Most of these activities are invisible to the user, yet each must be carefully designed before implementation begins.
To model these interactions, we’ll use techniques such as Use Cases, Sequence Diagrams, and Storyboards.
Even well-written requirements and user stories can be viewed as behavioural prototypes because they describe how the system should respond to different situations.
Prototyping The User Interface
User interface prototypes describe what users will see and how they will interact with the system.
These prototypes allow designers and users to explore page layouts, navigation, workflows, and the overall user experience long before any code is written.
Throughout CIS3750, you’ll create several types of interface prototypes, including:
- Storyboards
- Paper Prototypes
- Wireframes
Notice that some tools appear in more than one category.
For example, a storyboard not only illustrates the appearance of individual screens, but also the sequence of interactions that connects them. Likewise, requirements may influence data design, system behaviour, and the user interface simultaneously.
The design process is highly interconnected, and many of the techniques you’ll learn support multiple aspects of software design.
Looking Ahead
Prototypes help us explore ideas, communicate with clients and users, validate assumptions, and improve designs before development begins.
They reduce risk, encourage collaboration, and save significant time during implementation.
In the chapters that follow, we’ll examine several prototyping techniques in greater detail and learn how each contributes to the design of high-quality software systems.