What Is Software Prototyping And Why Is It So Important?
If you’re starting a web or mobile project, it’s essential to begin with an interactive software prototype to help inform your estimate.
Editor’s note: This piece was originally published in 2014. It’s been so popular that we decided to update it in 2020.
Too many businesses start creating apps before they really understand how the app will deliver value, and whether that value is worth the investment). Jumping straight into development without conducting usability testing with a software prototype example results in directionless project management, wasteful spending, and finished (or unfinished) products that lack impact.
Keep reading to learn more about software prototypes, including their definition and importance to the estimation process.
Software Prototypes: a Definition
A software prototype refers to a working model of a product, which encapsulates how the end product will look and function. A prototype doesn’t include all the backend work, and is built before development is complete and often built quickly.
A prototype is a valuable way for a client to understand their investment prior to beginning a project, and as a guide to more accurately scope (that’s what this post is focused on). It’s also a good way for end-users to test a product out during its development and is instrumental in usability testing.
The Importance of Accurate Software Estimates
- A significant shortage of critical functionality delivered
- The project exceeds the budget by a significant margin
The report found a strong correlation between the skill of the Business Analysts on the project and the success rate. To go a little deeper into understanding this, I wanted to start by sharing an idea from Barry Boehm’s book Software Engineering Economics called the Cone of Uncertainty.
Predict Success (Or Failure) With The Cone Of Uncertainty
What the cone of uncertainty tells us is pretty simple: the earlier in a project we create estimates, the less accurate those estimates are. The key to understanding is when to trust your development team’s estimates and when to view them with a healthy dose of skepticism.
Most clients investing in a software project will tolerate a variance of 25%-50% between the estimate and actual cost. Per the cone of uncertainty if you cannot tolerate more than a 50% overage, you need to hold off on estimating until User Interface Design. This may seem surprising, however this model has been reinforced repeatedly and the same pattern emerges time and time again: estimate too early and all you get is fiction.
Create A Software Prototype To Improve Estimates
While most clients want estimates in the beginning of the project, that is not always the best method. At Praxent we have learned that providing estimates without crystal clarity can doom projects before they even begin. So, after some soul-searching, we landed on a solution: provide a UX prototype, or example product, upfront. We call this ClickModel.
Building an Example Software Prototype With ClickModel
ClickModel is Praxent’s proprietary method of creating a fully clickable, interactive software prototype of your concept. ClickModel allows you to experience your software before paying to have it built. While none of the expensive “plumbing” is in place yet, the important front-end user experience is.
ClickModel and other UX prototype examples often reveal areas that could benefit from more elaboration, as well as hidden opportunities or unconsidered potentials that influence the business case for the software investment. Having this visibility upfront allows the client and development partner refine the prototype together, until both parties agree it is done. One of the most valuable benefits we’ve enjoyed since implementing our ClickModel prototype is clients knowing with confidence that we understand their vision.
After the prototype phase, we assemble an estimate based in reality. This has benefits for developers as well; they can test a simulation of the finished product to experience the screens and requirements. Using a software prototype as an example upon which to base an estimate allows the project to be estimated with a 25%-50% variance, instead of a 200% – 400% variance.
>> Learn more about ClickModel in our post Usability Testing Case Studies: Validate Assumptions and Build Software with Confidence
As a client it’s important to maintain a healthy skepticism about your project estimate until you’ve seen a practical example like a software prototype. Building a prototype often changes the estimate greatly, and understanding the true cost and timeline upfront are keys to success. If you estimate too soon and are too far off, it’s more than likely the result will be failure.
Do You Need An Interactive Software Prototype?
Are you kept awake at night by the memory of failed projects that ran over budget or failed to ship on time? Research shows that up to 64% of software features built are never or rarely used. While we recommend always asking for an interactive prototype prior to estimation, if your company is thinking about starting a web or mobile project and needs more assurance, there are a few questions you can ponder.
- Question 1: Have you planned to do research on the needs of your users to make sure that your product will have a high rate of adoption, rather than a high rate of frustration?
- Question 2: Have you identified all of the necessary features and functions that your software will require so that you can accurately estimate the cost of development and plan a timely, successful launch of your minimum viable product?
- Question 3: What about workflow? Do you already know how to create a discoverable and intuitive path for your users so they can get the most out of your application? Or do you need to do more usability testing?
- Question 4: Do you even know for sure that there are people out there who want this solution in the first place?
For a predictable and proven path toward product validation, check out this example of our ClickModel software prototyping process. You’ll get the important questions identified and answered before investing in development.