Validate assumptions with prototypes

In custom software development, the largest risk is lack of alignment when it comes to objectives and understanding the requirements. The team needs to establish a way to remove bias and spend money wisely. Invest in features that drive ROI rather than catering to multiple stakeholder demands. A great technique is to use a prototype to showcase ROI and build alignment around the general vision of the product.

These are the qualifying conditions for building a prototype:

It can be built for a small amount of money (and time).
The query it seeks to resolve is clearly identified and quantified, and the testing methodology has been proven to drive conclusive results.
An audience to test the prototype is available (access to end users, multiple focus groups, etc.).

Even if trivial, building and testing prototypes costs the team time and funding. Consider the following use cases when negotiating with stakeholders whether a prototype is necessary:

Check technical feasibility: For example, will a facial recognition library operate in dim lighting conditions, as needed for a warehousing client? Before undertaking a full build, a technical prototype is a smart investment.
Validate requirements: If the application initially needs to cater to two audiences and priorities are muddy, use a prototype and test with end users and gain an additional perspective.
Validate business model: If the ROI can’t be clearly calculated, perhaps a POC application should operate in an early alpha mode to test assumptions—perhaps a lender assumes that its new underwriting platform will accelerate the way data is entered and reviewed by processing staff. Consider a POC implementation where only a fragment of the workflow is operational yet allows for testing usability.

A prototype can be part of a sales process or the initial stage of delivery. Discuss the approach with your managing director and determine what level of investment is necessary to drive outcomes.

Prototyping flavors

Prototype investment should correlate with the potential return. Can a $30,000 prototype save $300,000 through simplification of needed functionality or elimination of technical unknowns? Can a $200,000 data-driven prototype validate a new business model that will require further funding in the tens of millions? Prototypes come in various flavors—from simple and lightweight to working, data-driven software that eventually matures into the final product.

Design prototype

The intent of a lightweight design prototype (e.g., wireframes, potentially high-fidelity UI) is to align the team around the direction for the product. Software requirements are often hard to visualize in the context of the device being used. For example, a group creates a story map with ten high-priority functions for the home screen of a flight reservations app. Only after sketching a couple of lightweight prototypes, the team collectively agrees that ten features carry too high a cognitive load for an infrequent user.

A word of warning about design prototypes: executives often get emotionally attached to the demonstrated early iterations of the product. This prototype is a manifestation of their product, the first real step toward making the idea a material thing. Prime the audience and navigate carefully through demonstrations of early versions, and always keep the objective closely tied to the demonstration session.

A design prototype is not the finished product. Set expectations that features are not locked and the designs will change.

Design prototypes can be characterized according to the following criteria:

Use: They are ideal for brainstorming and creating alignment.
Time: They are ready in one to two weeks.
Team: The team should be relatively small.
Cost: They are inexpensive.
Extras: They do not include proper testing or proof of concept as they are created early on.

Interactive prototype

An interactive prototype helps communicate a workflow as opposed to just a visual concept while also enabling the team to run testing sessions with a target audience. Interactive prototypes are great at aligning stakeholders around a new workflow concept—something that is hard to explain but simple to show and tell.

Because the prototype is interactive, can capture data, and has lightweight logic that changes the responses based on input, it benefits from user testing and formal observation sessions.

Features of an interactive prototype include the following:

Use: They are ideal for communicating a workflow or process.
Time: They take two to four weeks but may require a couple of months to develop with work facilitated in one-week sprints to help iterate quickly on the idea, potentially retesting with each change.
Cost: They require a financial investment of between $40,000 and $75,000.
Team: A midsized team is needed that should include design and engineering.
Extras: They should employ usability testing, shadowing, and observation to extract insight.

Proof of concept prototype

The POC prototype is typically a much more elaborate implementation with a real data schema, working back end, analytics, and more. The POC prototype perhaps does not have all the necessary components of a productionized app (e.g., a new product search and filtration mechanism that isn’t hooked up to the shopping cart); however, it mimics a finished application within the context of the prototype.

POC prototypes typically possess these features:

Use: They are used to mimic a finished application to validate the concept—such as for
- testing advanced technical feasibility—facial recognition within a set of constraints, augmented reality application, etc.;
- testing advanced, complex solutions that require fully functioning workflows to demonstrate ROI; and
- allowing the team to implement analytics and monitor a near-production environment (e.g., beta).
Time: They are built within three to four months; built in one-week sprints to quickly release, test, and iterate.
Team: A midsized to large team is needed.

Skip the prototype

Prototypes are not always necessary. Sometimes the business opportunity (and current issue) is so glaring—so brutally obvious in its inefficiency—that building a prototype is simply a waste of time.

For example, the trading desk at a major bank was manually (via phone) verifying and rekeying the trade price, amount, and customer name with the salesperson submitting the order. Our team immediately identified an opportunity for the rep to submit a digital trade request with specified parameters that the trader would simply need to execute against, assuming the price of the stock did not change drastically. Prototyping such a workflow would delay the go-to-market and reduce the agility of the product team.

Run dual-track scrum