Four Common Types of Software Prototypes
Prototypes aren’t one-size-fits-all.
What is software prototyping?
Much like 3D prototypes built during the development process of some of our favorite gadgets, virtual prototypes help you obtain early-stage feedback to develop a clear plan without the wasted time and resources. A prototype is an incomplete version of a software program or application — think of it like a draft or a sketch. In short, software prototyping is a method of agile software development that focuses on gathering insights on user behavior, design quality and functionality.
A prototype is an incomplete version of a software program or application — think of it like a draft or a sketch.
Just like any other prototype, a software prototype is a model used to test the viability of a product. Most people are familiar with the 3D models that companies use in product development for physical products, such as Nike sneakers and the Nerf Gun. Similar to the varying degrees of physical prototypes (paper, cardboard, 3D printed), we have different degrees of fidelity of our software prototypes. Each level of fidelity serves a purpose. Sometimes we stop at low-fidelity or skip mid- and high- to get to the super-fidelity prototype. It all depends on the data we need to gather.
Our software prototypes have no underlying database or backend code because they are used to test the user experience of the system. While some may use the term “prototype” for an early release of a working system, we define that as a Minimally Viable Product, or an MVP.
The Four Most Common Kinds of Software Prototypes
At Protoype1, we’ve built our own definitions of the four most common types of prototypes to help communicate better within our team.
Low-Fidelity
A paper prototype designed to illustrate user flow and where features would live. Paper prototyping, usually implemented through sketching, is especially helpful in quickly gathering thoughts or suggestions around a particular product idea within a team.
Mid-Fidelity
A prototype based on wireframes connected together, typically with a set path, that’s clickable through hotspotting but lacks a refined UI. This is usually a quick way to bring the basic idea of a product to life to center focus around user flow from one screen to the next.
High-Fidelity
A prototype that may visually appear real but is generally wired up through hot spotting or basic HTML/CSS with limited paths and capabilities. Someone interacting with this prototype could believe it’s real at first glance until they begin using it.
Super-Fidelity
A prototype that looks, acts and behaves as the intended final product. Someone interacting with this prototype may actually believe it to be software in a beta release.
Which Type of Prototype is Best for You?
Working backwards by understanding what you need to accomplish with your tests is key to choosing the correct format. We use these five questions to make our decisions. Identifying the 5 Ws — who, what, where, when and why — is a helpful early-stage method of discovery.
1. What is being measured? — There are various scenarios and metrics you’ll need to test before choosing a prototype. For example, sometimes we use a prototype to judge the accuracy of the data input, to focus on the speed of completion for certain tasks or simply to see if someone can get from point A to point B.
Example: If you’re working on, let’s say, an app for doctors to electronically send their patient forms, where previously they would fill out a paper document and fax it to the insurance company, a super-fidelity prototype could be critical here. Since you’re looking to not only test the efficiency and accuracy of the data input, you need a refined enough process that also shows you the outputted information. This output is what helps the insurance company determine if they need to follow-up. You’re dealing with two key stakeholders in this scenario and it’s difficult to accomplish proper testing with just a high-fidelity prototype.
2. Who needs to test this? — Identifying users and test cases will help you determine which elements of the design and functionality need to be present in the prototype. Is the mockup for an internal presentation to your product design team, project stakeholders or an end-user? All test users should be accounted for before deciding which type to select.
Example: Use a high-fidelity prototype if you’re looking to gain valuable insight from an end-user. If the prototype is just connected wireframes, in the case of a mid-fidelity prototype, they may be distracted by the visuals, or lack thereof, and not focus on accomplishing a task. If your end-users happen to be an internal product design team, who won’t get hung up by simply seeing wireframes, you could get away with a mid-fidelity prototype.
3. When does it need to be tested? — Timeframe will be an important part of picking your prototype. Time is always a limiting factor, so knowing when you need to test will guide your prototype project.
Example: There are way too many scenarios that can play out when it comes to time. Our best advice: when you answer all of these questions, you’ll get a holistic view of what needs to be created for success. The level of detail you put into any prototype will be based on time. However, skimping on the time and effort put into a prototype will end up causing a longer development cycle.
4. Why does it need to be tested? — Starting with the statement “This prototype will…” is a great way to help answer your “why” while also assisting you with which prototype to choose.
Example: Sometimes you just need a proof-of-concept for yourself before you go off and present an idea to a stakeholder or product team. A low-fidelity prototype is a great way of just getting ideas onto paper and interacting with them through physical touch. Easy, quick for iteration and most importantly, disposable. However, when you’re looking for client approval you will clearly need something more hi-fidelity.
5. Where does it need to be tested? — The location of your product will guide you to selecting the ideal prototype option for your testing needs. Understanding the scenario in which this product will be used will guide your user tests. To sufficiently test the product in similar environment can have huge benefits. Ensuring that the prototype we build will hold up in the test environment is critical to providing quality data from our user tests. You can ask yourself: Is the product a mobile app? Where is the user likely to use the app? Will the environment be a major factor? Does it need to be replicated as part of the test?
Example: Let’s say you’re testing a news product and you expect that commuters will be your target market. Having a high-fidelity prototype that provides a few story examples that they can consume while on a bus, train or in the back of an Uber provides enough realism in their environment that you can focus on how they’re interacting with your product in their current situation.
Have additional questions? We can help guide your prototyping process.
